 |
|
|
|
Свободные утилиты forensic
Свободные утилиты forensic Компьютеры и Интернет продолжают проникать и вторгаться в нашу жизнь, увеличивая тем самым вероятность оказаться жертвой компьютерного преступления. Как ни прискорбно замечать, несмотря на обилие и разнообразие средств защиты, с каждым годом количество взломов увеличивается. Оказавшись жертвой взлома, некоторые, бывает, и теряются, что порой приводит к неправильным решениям. Наверное, одна из самых распространенных ошибок состоит в немедленном удалении всех данных и восстановлении системы из резервных архивов и продолжении работы как ни в чем не бывало (хотя настаивать на своем мнении не буду, бывают разные ситуации). Почему так? Во-первых, не всегда можно сразу точно узнать, когда произошел взлом, и в архиве могут быть уже «зараженные» тем же rootkits файлы; во-вторых, если повезло с первым случаем, то где вероятность того, что злоумышленник не воспользуется тем же способом, что и ранее, для повторного проникновения, и в результате время будет потрачено зря, и в-третьих, иногда трудно сказать, произошел ли взлом вообще, и чтобы доказать это, требуется собрать максимальное количество информации, т.к. простой сервера ведет к финансовым потерям (а еще и имидж, и пр.), и кто-то должен отвечать за это. Другой путь состоит в том, чтобы остановиться и попытаться исследовать и проанализировать происшедшее, а главное, сохранить образ взломанного компьютера. К сожалению, насчет вопроса исследования последствий взлома и используемых при этом инструментов в рунете имеется некоторый дефицит информации (а об описываемых ниже утилитах доводилось читать все, кроме того, чем они действительно занимаются), которую одной статьей так сразу и не решить. Но надеюсь вызвать дискуссию (на страницах журнала или в форуме), в которой попытаться разобраться и ответить на извечный вопрос «Что делать?» после взлома. Так, к планированию своих действий в этой ситуации нужно подходить не менее тщательно, чем к действию при пожаре. Если на компьютере установлена одна из систем контроля целостности вроде tripwire (http://www.tripwire.org) или AIDE – Advanced Intrusion Detection Environment (http://sourceforge.net/projects/aide), а также система обнаружения вторжения наподобие Snort (http://www.snort.org), плюс средство аудита системы вроде того же Snare (http://www.intersectalliance.com/projects/Snare), то у вас будут ответы на основные вопросы – когда и где происходило событие, как все произошло, сколько времени и на какие файлы воздействовали в системе. Теперь осталось осторожно извлечь чужое и проанализировать подробнее. Стандартные инструментальные средства, которые имеются в любой системе, для данного действия не подходят по нескольким причинам. Для начала они могут быть введены в заблуждение при помощи любого широко доступного rootkits, некоторые инструментальные средства полагаются на файловую систему или системные команды, чтобы исследовать диск и поэтому им также нельзя доверять. Затем системные инструментальные средства могут изменять нужные метаданные (например, время последнего обращения к файлу). И главное, системные утилиты позволяют найти только распределенные файлы, но специализированные могут найти и нераспределенные, т.е. удаленные или спрятанные файлы. И наконец, дополнительно приведенные утилиты могут понадобиться для исследования файловой системы и процессов восстановления данных. The Coroner’s Toolkit (TCT) Разработанный Dan Farmer и Wietse Venema, это один из самых первых и самых известных и свободных инструментов, предназначенных для сбора данных на скомпрометированной системе (http://www.fish.com/tct). Работает с файловыми системами FFS (FreeBSD, OpenBSD, BSD/OS, Solaris) и EXT2/3FS, также при помощи патча, доступного на сайте, можно заставить работать со второй версией FFS (FreeBSD 5.x), что касается и всех остальных утилит, участвующих в обзоре, к глубокому сожалению, с новыми ФС под Linux – ReiserFS, XFS и JFS они не работают. Одной из особенностей этой и подобных утилит является максимальный отказ от утилит исследуемой операционной системы и максимальное протоколирование всех своих действий. Так, даже вместо системного командного интерпретатора используется свой. Установка заключается в получении архива, его распаковки и ввода команды make. После чего здесь же, в подкаталоге bin, появятся несколько исполняемых файлов. По назначению их можно условно поделить на четыре группы:
Теперь поподробней. Некоторые утилиты могут работать как с «живой» файловой системой, так и с образом, созданным при помощи команды dd. #dd if=/dev/hda9 of=./system.img
Для создания «мгновенного» снимка системы предназначена утилита grave-robber. По умолчанию grave-robber фиксирует информацию о процессах и состоянии сетевых соединений, выясняет все, что может, относительно конфигурации аппаратных средств, особенно обращая внимание на диски и дисковые разделы, и исследует состояние критических файлов (конфигурационные файлы, журналы и пр.). Список исследуемых каталогов программа берет в файле conf/look@first и основные настройки берет из файла grave-robber.cf. Вывод выглядит так: # ./grave-robber
Если требуется задать определенный каталог, необходимо пользоваться опцией -с, которая, в свою очередь, требует опцию -о, указывающую на используемую операционную систему. # ./grave-robber -c /data1 -o LINUX2 Из других параметров, разделенных на три группы (general, micro data collection и macro data collection), особо интересными, по моему мнению, являются (по умолчанию собирается максимальное количество данных, что занимает довольно много времени):
В результате работы утилиты в подкаталоге data/hostname_time (его можно изменить при помощи опции -d), образуется несколько файлов и каталогов.
В body содержится MAC-база времени, body.S тоже, но описаны файлы с установленным SUID; command_out – вывод программ, которые выполняются, с контрольными суммами и временными метками; conf_vault – программы, которые утилита нашла интересными, в основном критические и конфигурационные файлы; proc – копии исполняемых файлов запущенных процессов с контрольными суммами. Может быть еще каталог deleted_files, содержащий удаленные, но еще открытые файлы. Если необходимо просто просмотреть, изменялось ли MAC-время доступа к файлам, начиная с определенного времени (или промежуток при задании двух значений), то запускаем утилиту mactime, в результате получим колонку, состоящую из значений [date time size MAC (т.е. изменившееся поле) perms owner group file]. Давайте посмотрим, какие файлы изменились с 10 января 2004 г. (формат: месяц/дата/год). #./mactime 1/10/2004
То есть с указаного времени изменялся inode (..с) файла deallocvt, если файл недавно копировался или создавался другим способом, то это не должно вызывать подозрений, но если операционная система стоит не один день, а файл находится в неизменяемой обычно области (/bin, /sbin и т. д.), то это должно вызвать подозрения. Хотя, как вы понимаете, все эти времена можно без проблем изменить. Далее все, думаю, понятно по аналогии. Из интересных опций следует отметить -s, показывающую файлы с установленным SUID/SGID другим цветом, ее необходимо использовать совместно с -h, устанавливающую вывод в виде html. Просмотреть, чем сейчас занимается тот или иной процесс, найденный при помощи ps, netstat, или lsof, можно, запустив команду pcat, которая копирует содержание его памяти в стандартный вывод. ./pcat 881 | strings | less Наиболее полную информацию можно получить, используя опцию -H и направив при этом вывод в файл. В остальных опциях лучше один раз увидеть, чем сто раз прочитать. Теперь попробуем найти потерянные или спрятанные файлы. Для этого воспользуемся утилитой ils (inode list), которая открывает названное устройство и перечисляет inode. По умолчанию ils выводит inodes только удаленных файлов. Опций много, наиболее интересные следующие: опция -е выводит список всех inode; -o – выводит список всех inodes удаленных файлов, но таких, которые являются еще открытыми или выполняются; -r выводит список удаленных файлов. # ./ils -or /dev/hda9
Если запустить ее с опцией -о, то будет выведен только inode с номером 1. Поле st_alloc принимает два значения; «a2» – для allocated inode и «f» – для free inode. В первом столбце даны значения inodes удаленных, т.е. не прописанных ни в одном каталоге файлов. Теперь при помощи icat, позволяющей копировать файл, обращаясь к нему не по имени, а по номеру inodes, попробуем скопировать удаленный файл. # ./icat
# ./icat /dev/hda9 107 > /tmp/delete_file Чтобы определить, что за файл находится перед нами, применяется утилита file, которая при помощи трех тестов (filesystem tests, magic number tests и language tests) пытается дать ответ. Первый тест пытается выяснить, является файл двоичным (программа или данные в каком-то формате) или содержит ASCII-текст. На втором этапе при помощи системного вызова stat пытается определить тип (описаны в sys/stat.h). И наконец, пытается определить magic number, сохраненный в определенном месте файла и найти соответствующий известному типу файла (например, исполняемый elf или a.out). # ./file /tmp/delete_file
Все, по-моему, понятно без комментариев. От себя добавлю, что вовремя спасенная таким образом программа без проблем открывалась и выполнялась. Применив такую конструкцию, можно попытаться восстановить все удаленные файлы. # ./ils -rf ext2fs /dev/hda9 | awk -F "|" "($2=="f") {print $1}" | while read i; do /usr/local/tct-1.14/bin/icat /dev/hda9 $i > /tmp/deleted/$i; done Но для сохранения данных, содержащихся во всех свободных inodes файловой системы, в отдельный файл для последующего анализа предназначена другая утилита – unrm. При ее использовании необходимо помнить две вещи: записывать результат нужно в другой раздел жесткого диска, иначе потеряете все, и в этом разделе должно быть достаточно места для сохранения данных. Например, если создать образ файловой системы размером 10 Гб, заполненной на 3 Гб при помощи утилиты dd, то он займет 10 Гб, а если при помощи unrm, то места потребуется 7 Гб (10 – 3), плюс столько же для последующего анализа. Если не доверяете системной команде dd, то, запустив unrm с опцией -e, можно создать полный образ раздела: # ./unrm /dev/hda9 > /home/hda9_urm.res или если извлечь неиспользованные inodes из предварительно созданного dd образа. # ./unrm /image/system.img > /home/system_urm.res В результате можем получить файл довольно приличных размеров, который перебрать вручную довольно хлопотное дело. И не надо. Для этого есть специально обученная утилита lazarus, анализирующая поблочно весь файл и пытающаяся определить, что за информация находится в этих блоках, а также связать разрозненные блоки между собой. При этом lazarus понимает кроме FFS, EXT2/3 и NTFS с FAT32. Утилита читает данные порциями размером 1 Кб (значение можно изменить в lazarus.cf в переменной $BLOCK_SIZE), определяет по 10 % блока, что за данные (текст, двоичные, неизвестные) находятся в нем. Если текст, то, используя регулярные выражения, пытается прочитать их, в двоичных пытается определить формат. # ./lazarus -h /home/hda9_urm.res
Вывод утилиты – набор символов (если опция -h, то и HTML-файл, рис. 1), соответствующие распознанным типам блоков, которых lazarus смог определить. Кроме того, в каталоге blocks (определен в переменной $blocks в файле lazaruz.cf или, возможно, переопределить, использовав флаг -D) создаются файлы, которые содержат данные, найденные в блоках. Последовательные блоки того же самого типа считаются одним и тем же файлом и записываются в тот же самый выходной файл $blocks/*. Расшифровка выдаваемых значений видна на рис. 1.
Рисунок 1 Так, буква «T» означает текстовый файл, «M» – почтовый, «C» – код на Cи, точка «.» – файл неопределен. Хотя, бывает, утилита и ошибается. Далее процесс восстановления описан в документе help-recovering-file и lazarus.README, которые лежат в подкаталоге doc. Например, текстовые файлы с определенными словами можно попробовать найти при помощи grep: # egrep -l "keyword1|keyword2|..." blocks/*.txt > allfiles Вы видите, насколько мощные и удобные инструменты имеются в TCT, но все же их возможностей явно не достаточно. Так, нельзя обеспечить анализ по имени файла, провести соответствие inodes с блоками, просмотреть информацию, находящуюся в отдельных блоках. Поэтому был разработан еще один комплект инструментов, дополняющих TCT, названный TCTUtils (http://www.cerias.purdue.edu/homes/carrier/forensics) и использующий его библиотеки. Принцип работы прост и основывается на том, что информация при удалении файла фактически сохраняется в записях каталога. Выглядит это в общем приблизительно так (некоторые подробности работы ext2 смотрите в [1]. Каталог имеет для каждого файла четыре существенные записи: номер inode, длина записи в байтах rec_len, округленная до 4, имя файла (name) и длина имени файла (nam_len). При удалении файла в целях экономии времени запись о нем не удаляется, просто к значению rec_len предыдущего файла добавляется длина удаляемого, т.е. фактически утилиты теперь проскакивают над записью удаленного файла. И теперь утилиты из TCTUtils, анализируя поля, определяют, у которого поле rec_len больше требуемого, и таким образом находят спрятанный файл. Для компиляции TCTUtils потребуется наличие установленного TCT, путь к каталогу которого необходимо указать в файле src/Makefile в переменной TCT_DIR. После этого в подкаталоге bin появятся несколько исполняемых файлов. # ls bin
Разберем подробнее. В предыдущих примерах мы нашли несколько удаленных файлов и даже успели их спасти. Но кроме номера inode, о файлах не известно больше ничего. Пробуем при помощи утилиты istat извлечь остальную «спрятанную» информацию. ./istat /dev/hda9 107
Как видите, теперь, кроме номера inode, стала известна информация о размере файла, владельце, режимах доступа, МАС-временах, и главное, номера дисковых блоков, в которых записано тело файла. Чтобы заглянуть внутрь блока, используем другую утилиту bcat, которая может выводить информацию как сырой raw, текст ASCII (опция -а), hexdump (-h), html (-w), выводить статистику (-s), просматривать свап (-f swap). # ./bcat -h /dev/hda9 9364 512
Возможен и обратный поиск, т.е. известен номер блока и требуется найти номер inode, за которым данный блок закреплен. Для этих целей используется команда find_inode. Возможны три результата выполнения: блок будет в списке inode, блока не будет в списке inode и блок является частью большего фрагмента. # ./find_inode /dev/hda9 9364
# ./find_inode /image/system.img 12345
Но искать вручную каждый удаленный файл немного хлопотно, поэтому для начала можно пройтись по разделу или созданному образу утилитой fls, выводящей имена файлов и каталогов, и в том числе недавно удаленных. Из опций утилиты стоит отметить:
# ./fls -rd /dev/hda9
Как видите, удалось определить, что за файл скрывался в inode под номером 107, который теперь благополучно можно восстановить при помощи icat. Но если под Linux такой номер проходит, то в Solaris можно вообще не получить никакой информации. Удаленные файлы и каталоги помечаются знаком *. Первая буква показывает, что за файл, т.е. r-egular, d-irectory, l-ink, s-ocket или неопределен (?). Найти имя файла или каталога по известному inode можно при помощи утилиты find_file. В man не сказано, что означают те или иные опции, поэтому пришлось поначалу запустить ее со всеми сразу. #./find_file -adu /dev/hda9 107
Пробуем. # ./find_file -a /dev/hda9 107
Хотя программы по-прежнему нет в списке. # ls -al /data1/sort
И последняя утилита blockcalc из комплекта TCTUtils предназначена для отображения соответствия между номером блока в образах, созданных при помощи dd и unrm. ./blockcalc [-du] block dd_image
# ./blockcalc -u 9364 /image/system.img
Не знаю, что послужило причиной, но TCT и TCTUtils не развиваются уже с 2001 года (но это не значит, что их нельзя использовать и я зря о них рассказывал). Вместо них Brian Carrier выпускает единый комплект утилит, названный Sleuth Kit (http://www.sleuthkit.org/sleuthkit), основанный на их коде, объединяющий основные функциональные возможности и работающий с файловыми системами NTFS, FAT, FFS, EXT2FS и EXT3FS. Последняя на момент написания статьи версия 1.67 от 6 января 2004 года. Для удобства, чтобы легче было ориентироваться, названия утилит изменены и начинаются на букву, соответствующую тому уровню, на котором они работают. Их несколько: File System Layer – работа с файловой системой; Content Layer (буква d – data) – фактическое содержание блоков, кластеров, фрагментов; Meta Data Layer (inode) – описывает файл или каталог, т.е. все, что можно извлечь из inode; Human Interface Layer (file) – более удобный уровень взаимодействия с файлами, чем при использовании метаданных. Во многих утилитах были добавлены новые опции, например, -m, позволяющая выводить одновременно информацию и о MAC-временах; -z – для указания временного пояса; обязательной стала опция -f, предназначенная для указания файловой системы. После компиляции в подкаталоге bin вы найдете 18 утилит. /home/work/forensic/sleuthkit-1.67/bin # ./
С назначением утилит file, icat, ils, mactime, istat, fls мы уже знакомы. Утилита ifind является новой версией find_inode, ffind пришел на замену find_file, dcalc – blockcalc, соответственно, dcat – bcat, dls назывался когда-то unrm, утилиты md5 и sha1 предназначены для работы с контрольными суммами в одноименных алгоритмах. Остались незнакомыми только hfind, dstat, fsstat, mmls и sorter. Появившаяся в Sleuth Kit v1.63 утилита mmls предназначена для вывода таблицы разделов. Ее применение может помочь в поиске «спрятанных» данных, т.к. показывает, какие сектора не используются. # ./mmls -?
т.е. команда для запуска выглядит так: # ./mmls -t dos /image/system.img Для выдачи информации о состоянии конкретного блока или сектора dstat используется утилита dstat. # ./dstat
# ./dstat -f linux-ext3 /image/system.img 9364
Или для выдачи более подробной информации: # ./dstat -v -f linux-ext3 /image/system.img 19496
Утилита fsstat отображает подробности, связанные с файловой системой. # ./fsstat -f linux-ext3 /data2/bin.img
До этого все программы предназначались в основном для сбора данных, но вот анализ целиком возлагался на плечи исследователя, и для того, чтобы найти в нескольких гигабайтах информации инструменты взломщика, ему потребуется много опыта, времени, потраченных на исследование. Утилита hfind как раз и предназначена для поиска хеш-функций в предварительно созданной базе. Для сравнения может использоваться предварительно созданная база, тогда ее работа в чем-то напоминает Tripwire. Но наибольшая эффективность от применения будет достигнута при использовании National Software Reference Library (NSRL), которую можно найти на http://www.nsrl.nist.gov. Проект поддержан Национальным Институтом Американского Министерства юстиции (NIJ, http://www.ojp.usdoj.gov/nij/sciencetech/ecrime.htm), Национальным Институтом Стандартов и Технологии (NIST) и другими подобными организациями, и предназначен для того, чтобы эффективно использовать компьютерные технологии в расследовании преступлений, инструментом которых является компьютер. NSRL разработана, чтобы собрать программное обеспечение из различных источников и включить профили файлов в справочный информационный набор Reference Data Set (RDS). На декабрь 2003 года NSRL обеспечил профили и цифровые сигнатуры для 17 909 964 файлов. Использовав NSRL, возможно идентифицировать критические системные файлы, которые были изменены, одним из назначений этой библиотеки является поиск программ при расследовании преступлений, направленных против интеллектуальной собственности. Hfind проверяет значения хеш-функции в базе данных, используя двоичный алгоритм поиска. Это быстрее, чем grep, но требует создания индексного файла (опция -i). # ./hfind –h
Применение этой утилиты очень широкое, некоторые варианты даны в man, например, для контроля за наиболее важными системными файлами можно использовать комбинацию: Сначала создаем базу данных, используя md5sum. # md5sum /bin/* /sbin/* /usr/bin/* /usr/bin/* /usr/local/bin/* /usr/local/sbin/* > system.md5 Теперь создаем из полученной базы индексный файл. # ./hfind -i md5sum system.md5
Теперь в текущем каталоге будут находиться два файла. # ls
Проверяем, что происходит в /bin. # md5sum /bin/* > bin.md5 # ./hfind -f bin.md5 system.md5
Как видите, с /bin/umount что-то случилось после создания базы данных, и его контрольная сумма не совпадает. И наконец, скрипт на Perl – sorter, который анализирует образ при помощи fls и icat, находит файлы, в том числе и скрытые, для найденного файла запускает команду file, для того чтобы его распознать. При использовании библиотеки NSRL возможно отделение плохих файлов от хороших. Список плохих тут же попадет в файл alert.txt. Опция -s позволяет сохранить в указанном каталоге фактическое содержание файла, но для этого необходимо указать при помощи опции -С файл конфигурации, некоторые шаблоны можно найти в каталоге sorter/sort, этот файл позволяет задать соответствие между расширением и типом файла. В каждом файле имеются поля шаблонов (конечно же, можно добавить и свои), например:
В общем же случае работа утилиты выглядит так: #mkdir data
Теперь в подкаталоге data появятся до тринадцати файлов, количество которых зависит от типов данных, и файл sorter.sum, в котором содержится суммарная информация о найденных файлах. # ls data
Например, exec.txt содержит рассортированный по алфавиту список исполняемых файлов, найденных в образе.
А sorter.sum выглядит так.
Как видите, утилит предостаточно, еще больше у них опций, что, согласитесь, может запутать новичка или человека, не привыкшего к командной строке, что требует некоторое время на освоение и сужает круг пользователей. Поэтому дополнительно к Sleuth Kit был создан инструмент визуализации Autopsy Forensic Browser (http://www.sleuthkit.org/autopsy/index.php). После распаковки архива и запуска команды make, в ходе работы которой необходимо ответить на вопросы расположения Sleuth Kit, необходимости закачки библиотек NSRL и пути (Evidence Locker), куда будут складываться файлы отчетов, логи и данные. Последние могут потребовать довольно много свободного места, поэтому укажите на раздел посвободнее. После чего запускаем, опционально можно указать порт. # ./autopsy
Вставив строку с URL в браузер, попадаем в окно (см. рис. 2), заметьте, доступна помощь (рис. 3).
Рисунок 2
Рисунок 3 Первоначально требуется создать базу данных образов, взятых с различных компьютеров командой dd или dls (unrm), на которых будут проводиться исследования. Указываем на образ, с которым будем работать. Для этого жмем на New Case и заполняем пункты, здесь необходимо ввести название и короткое описание, чтобы затем можно было без проблем найти нужный образ. После чего заполняем пункт Adding a New Host, в котором указываем имя компьютера (будет затем создан подкаталог с этим именем в Evidence Locker), его короткое описание, временной пояс и опционально расхождение времени и путь к базам NSRL. И наконец, в Adding a New Image (рис. 4) заполняем данные на исследуемый образ. Обратите внимание, что после ввода пути к образу можно выбрать вариант копирования в папку Evidence Locker, перемещение или вариант по умолчанию – создание симлинка. Здесь же указываем файловую систему и точку монтирования, с которой снимался образ, если известна MD5-сумма, то ее можно указать, по умолчанию она будет высчитана заново, после чего будет выдан итог (рис. 5).
Рисунок 4
Рисунок 5 Нажав Add Image, можно добавить следующий образ к базе данных. Если не нужно, то теперь можно начинать работать с образом. Например, во вкладке Image Details можно сразу извлечь все строки или удаленные файлы в отдельный файл (рис. 6). А переходя к нужному пункту, можно получить всю необходимую информацию о данных, содержащихся в тех или иных блоках (рис. 8, 8а), причем обратите внимание, доступен вывод информации в нескольких видах (ASCII, Hex, String), добавление комментария к интересному блоку, последовательный просмотр блоков, экспорт блока в отдельный файл. Аналогично можно вывести список файлов (рис. 9), данные о состоянии дисковых inode (рис. 10, 11) и другую информацию, которую можно получить при помощи утилит Sleuth Kit.
Рисунок 6
Рисунок 7
Рисунок 8
Рисунок 8a
Рисунок 9
Рисунок 10
Рисунок 11 Если первоначальная возня с образами мне не очень понравилась, зато последующая работа оставила приятное впечатление, все-таки намного удобнее пользоваться Autopsy Forensic Browser, по крайней мере возможность выбора меня всегда радует. Описанные выше утилиты относятся к так называемым forensic, т.е. применяются для поиска доказательств взлома, которые затем могут быть представлены в суде. Поэтому одним из требований к ним является особо бережное отношение к данным и протоколирование всех действий. Также, чтобы затем не замучили адвокаты, подобные утилиты проходят тщательное тестирование на предмет соответствия поставленной задаче. Для нас подобные разбирательства скорее исключение, чем правило, хотя, правда, это не значит, что хакеры у нас не водятся. Водятся, и в больших количествах. И второе применение этих утилит очевидно – сохранение случайно или умышленно стертых данных. К сожалению, размер статьи разросся до неконтролируемых пределов, поэтому пришлось остановиться, но в будущем надеюсь вернуться к этой теме. Успехов. И чтобы вам никогда не довелось использовать подобные утилиты по назначению. Литература
|
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
