Средства инцидентного анализа для Unix. Часть вторая. Утилиты файловых систем.

Средства инцидентного анализа для Unix. Часть вторая. Утилиты файловых систем.

Вашему вниманию представлена вторая из серии статей, описывающих средства, используемые для инцидентного анализа и исследования произошедшей дискредитации операционных систем Linux, OpenBSD и Solaris. Эта статья опишет программы файловых систем. Информация, использованная в этой статье базируется на операционных системах OpenBSD 3.2, Debian GNU/Linux 3.0 (woody), RedHat 8.0 (psyche), и Solaris 9 (Solaris 2.9 или SunOS 5.9). Практически все обсужденные ниже программы присутствуют в перечисленных операционных системах, хотя также будут обсуждены некоторые программы не присущие данным ОС.

Хольт Соренсон, http://www.securityfocus.com/infocus/1738

Вашему вниманию представлена вторая из серии статей, описывающих средства, используемые для инцидентного анализа и исследования произошедшей дискредитации операционных систем Linux, OpenBSD и Solaris. Эта статья опишет программы файловых систем. Информация, использованная в этой статье базируется на операционных системах OpenBSD 3.2, Debian GNU/Linux 3.0 (woody), RedHat 8.0 (psyche), и Solaris 9 (Solaris 2.9 или SunOS 5.9). Практически все обсужденные ниже программы присутствуют в перечисленных операционных системах, хотя также будут обсуждены некоторые программы не присущие данным ОС. Все программные средства, охваченные в статье, выполняются в пользовательском пространстве. Если взломщик дискредитировал систему и установил модуль ядра, скрывающий его действия, то информация, выдаваемая нашими программами, скорее всего не будет соответствовать действительности. Это является одной из причин выполнения автономного анализа после защиты данных на действующей системе.

Мы не подчеркиваем, что средства инцидентного анализа должны запускаться только с защищенных от записи носителей или с системы, зарезервированной для автономного анализа. Использование таких носителей дает нам гарантию того, что эти программы были не изменены и не дискредитированы взломщиком. При реакции на инцидент, защитный персонал сразу должен определить приоритеты при перехвате данных. Необходимо решить, что является более важным - немедленно переводить машину в автономный режим и делать образ файловой системы или производить перехват данных типа информации о запущенных процессах, установленных сетевых соединениях, распределенной для процессов памяти и зарегистрированных в системе пользователях. Чем дольше система остается в сети после дискредитации, тем больше вероятность повреждения данных взломщиком. Заметьте, мы не утверждаем, что необходимо перехватывать данные и не создавать образы файловой системы - если Вы решаете, что данные важны, то после перехвата данных, все же необходимо сохранить образ файловой системы.

Предыдущая статья закончилась на том, что после сообщения web мастером о проблемах с производительностью сервера, на нем был найден взломщик паролей "John the Ripper".

Программы, необходимые для проверки.

Взломщик начал использовать web-сервер для взлома паролей в 03:17. 03:17 - это время, когда необходимо начинать анализ системы, но необязательно в это время взломщик дискредитировал систему. Взломщики часто используют автоматизированные программы, которые сканируют и атакуют уязвимую систему. Возможно, что взломщик только посетил систему, которую автоматические программы уже взломали некоторое время назад. Теперь необходимо запускать программы, помогающие нам определить изменения в файловой системе. Некоторые из таких программ включены прямо в операционную систему, а некоторые, изготовленные другими производителями, устанавливаются дополнительно для каждой ОС.

В Solaris и Linux существуют собственные команды, помогающие сравнивать текущую инсталляцию операционной системы с метаданными содержащимися в архивной базе данных. Это команды: rpm -Vva (RedHat 8.0), pkgchk -vn (Solaris 9), и debsums -ac (Deb 3.0). И rmp и Debian, для проверки подлинности пакетов могут использовать совместимые сигнатуры RFC2440 (OpenPGP). Также, для проверки контрольных сумм, обе команды также используют MD5 хеширование. Для проверки неизменности файлов в ОС Solaris, pkgchk использует систему контроля System V(SYSV). Алгоритм SYSV проверяет была ли произведена модификация файла, размер которого остался неизменным. Однако данный алгоритм недопустим для проверки целостности файлов. Это только немного более надежно, чем проверка на размер файла и время модификации. Любой из вас, кто потратил проработал хотя бы некоторое время с шестнадцатеричным редактором или использовал команду touch, знает насколько просто можно изменить содержимое файла оставив при этом неизменный размер и время модификации. В Debian GNU/Linux, Вы можете определить комплект программ для повторной проверки. Если вы установили набор защищенных от записи программ /mnt, то для повторной проверки будет использоваться команда - debsums -cagp /mnt/*. Эквивалентная команда rpm: rpm -Vvp /mnt/RedHat/RPMS/*. rpm, может также проверять базу rmp, отличную от установленной на вашей системе. Используйте команду rpm -Vva --dbpath для проверки дополнительной базы данных. Эквивалентная команда на системе Debian : debsums -cagd . Эти базы данных должны постоянно находиться на защищенных от записи носителях. Если вы желаете узнать дополнительные подробности при использовании команды rmp, то необходимо использовать ключ -v. Информация, выдаваемая этими командами, может использоваться для поиска изменений вызванных действиями взломщика.

package tools verifying current file system state against package metadata:
{redhat80} $ rpm -vVa
[ snip lots of output ]
..5....T   /bin/ls
[ snip lots of output ]

{solaris9} $ pkgchk -vn
[ snip lots of output ]
ERROR: /usr/bin/ls
    modtime <04/06/02 10:54:41 PM> expected <09/08/03 01:04:01 AM> actual
    file cksum <63074> expected <63042> actual
/usr/bin/ls
[ snip lots of output ]

{debian30} $ debsums -ac
[ snip lots of output ]
bin/ls
[ snip lots of output ]

Сравнение архивной базы данных с установленной в настоящее время операционной системой несмотря ни на что дает нам некоторую уверенность. В некоторых ОС, метаданные в архивных системах и фактическое состояние файловой системы могут значительно отличаться друг от друга. Использование архивирующих программ для сравнения текущего состояния файловой системы с архивной базой данных может не дать вам ожидаемых результатов. В OpenBSD есть инструмент, называемый mtree [4], использующий хеш-функции [5], дающие гарантию того, что файлы не были модифицированы со времени последнего обновления базы данных файловой системы. Если взломщик запускает программу-троян или модифицирует файлы, чьи хеш-данные были сохранены в базе mtree, то эти изменения будут обнаружены. Подобных результатов можно достичь, установив программы типа AIDE, Osiris, и tripwire на Solaris и Linux. Программы типа changedfiles, dnotify, и FAM используют модули ядра или опрашивают файловую систему, для обнаружения сделанных в ней изменений. Такие программы гораздо быстрее предупреждают нас о происходящих изменениях в целостности файловой системы. Поэтому программы проверяющие целостность файловой системы необходимо запускать периодически, потому что из-за использования в них хеш-функций они проводят интенсивные вычисления. В то же время, очевидно, что такие программы должны быть установлены и сконфигурированы до взлома вашей системы.

В случае, если данные программы не доступны или вам необходимо "рыть глубже", то существует другие средства, используемые при инцидентном анализе. Обычно такие программы используются только для файлов, хотя в ОС Solaris, они также могут работать и для каталогов. Результаты выполнения программ вам не пригодятся, если у вас нет надежной системы, с которой можно было бы запустить эти программы и сравнить результаты. Если Вы доверяете The Shmoo Group, то чтобы найти в двоичном коде хеш-данные и размеры файлов, Вы можете провести сравнение с базой данных Known Goods. Средство, поддерживающее MD5 хеш-функцию на Linux системах, называется md5sum (это часть пакета программ coreutils). Аналогичная программа в OpenBSD - md5. OpenBSD также поддерживает программы sha1 и rmd160, основанные, соответственно, на хеш-функциях SHA1 и RIPEMD160. Библиотека OpenSSL поддерживает хеш-функции, запускаемые из командной строки приложения openssl. Openssl dgst по умолчанию использует хеш-функцию MD5. Используйте openssl dgst -?, для справки об использовании команды openssl dgst и различных хеш-алгоритмах, поддерживаемых данной командой. Также возможно выполнение команды без лексемы 'dgst'. Другая утилита, shash [8] поддерживает "контрольные суммы", использующие предварительно указанные алгоритмы хеш-функций (запустите shash -l для вывода списка алгоритмов).

При инцидентном анализе, нельзя полагаться на команды, не использующие хеш-функции для вычисления контрольных сумм. Два примера таких команд - cksum и sum. Даже если вы записали контрольную сумму некоторых данных, а затем сохранили эти данными на защищенных от записи носителях, для гарантии того, что сохраняемые данные не были подделаны, защита могла просто создать другие наборы данных, которые имели бы ту же самую контрольную сумму. При использовании алгоритмов sum и cksum существует слишком большая вероятность совпадения. Вероятность совпадения при использовании программ, основанных на функции хешировани MD5, составляет 1 к 2^128 вариантов, а при использовании SHA1 - 1 к 2^160. Обе функции MD5 и SHA1 отвечают таким условиям, что практически невозможно найти два набора данных, для которых хеш-функция выдаст тот же результат. Алгоритмы вычисления контрольной суммы разработаны, для предохранения от случайного искажения данных, а не для предохранения от злонамеренных атак. Поэтому просто необходимо использовать средства, основанные на хеш-функциях типа MD5 или SHA1.

Hash/Checksum tools in action:

{deb30} $ md5sum /bin/ls
a5c720b6776331b9695d9a1f4f5c2194  /bin/ls
{deb30} $ openssl dgst /bin/ls
MD5(/bin/ls)= a5c720b6776331b9695d9a1f4f5c2194
{deb30} $ shash /bin/ls
# MD5 HASH
a5c720b6776331b9695d9a1f4f5c2194  /bin/ls
{deb30} $ cksum /bin/ls
2890986056 43784 /bin/ls
{deb30} $ sum -r /bin/ls
56701    43
{deb30} $ sum -s /bin/ls
6968 86 /bin/ls

Unix (и unix-подобные) файловые системы хранят наборы временных меток в своих метаданных файловой системы. Эти временные метки, названы MAC метками (модификация, доступ и изменение) и сохранены в структуре файловой системы называемой inode. Вместе с этими временными метками, inode содержит дополнительную информацию о файле - тип файла, права доступа, владелец, группа, размер, количество постоянных связей, и блоки данных, занимаемые содержимым файла. Структура inodes также существуют и для каталогов. Каталог inodes содержит информацию о названиях файлов внутри каталога и номера inode, содержащих информацию о файлах.

Mtime отражает время последнего изменения файла. Системные вызовы типа write, truncate, и mknod изменяют значение mtime. Ctime отражает время, в которое в последний раз был изменен inode файла. Atime отражает время, последнего обращения к данным файла. Значение atime изменяется системными вызовами типа execve, read, mknod, utime, и pipe. Большее количество подробностей относительно atime, mtime, и ctime можно найти в вашей системной странице stat. На этой странице также можно найти системные вызовы, которые привели к изменению данных временных меток.

Множество команд, во множестве различных случаях изменяют значение MAC меток. Ниже представлена таблица, показывающая, как некоторые команды изменяют МАС метки. Эти таблицы были созданы на Debian 3.0 с помощью файловой системы ext2, содержащей сплошные файлы, установленные в "петлевом" устройстве. Если Вы находите, что у вас установлено слишком большое количество образов по петлевому устройству на вашей Linux системе, Вы можете установить в вашем загрузчике значение параметра 'max_loop=255. После этого вы сможете создавать до 255 образов файловой системы вместо 8, установленных по умолчанию. Как только файловая система будет установлена на "петлевом" устройстве, она может быть проверено с помощью debugfs. Вы можете сами поэкспериментировать с вашей собственной системой, для того чтобы проверить информацию в представленных ниже таблицах. Однако эти таблицы могут служить только как общее руководство.

How common commands change MACtimes for a directory (foo):

Action

atime

ctime

mtime

creation (mkdir foo)

X

X

X

directory move (mv foo bar)

X

X

file creation (touch foo/foo)

X

X

file creation (dd if=/dev/zero of=foo/foo count=1)

X

X

list directory (ls foo)

X

change directory (cd foo)

file test (-f foo)

file move/rename (mv foo foo_mvd)

X

X

permissions change (chmod/chown foo)

X

file copy (mv foo_mvd foo)

X

X

file edit (vim foo)

X

X

file edit (emacs foo)

X

X

X

file edit (nvi/nano foo)

How common commands change MACtimes for a file (f1):

Action

atime

ctime

mtime

creation (touch foo)

X

X

X

creation (dd if=/dev/zero of=foo count=1)

X

X

X

rename (mv foo bar)

permissions change (chmod foo)

X

copy (cp foo bar)

X

copy overwrite (cp bar foo)

X

X

append (cat >> foo)

X

X

overwrite (cat > foo)

X

X

truncate (cp /dev/null foo)

X

X

list file (ls foo)

edit (vim/emacs/xemacs/joe/jed foo)

X

X

X

edit (ed/nvi/vi (sun)/vi (obsd)/nano/pico foo)

X1

X1

X1

1 - all times changed, but atime is slightly older than mtime and ctime

Команда ls может использоваться для показа времени модификации, изменения или последнего обращения к файлу. В следующей таблице показаны варианты использования команды ls отсортированные в обратном порядке по mtime, atime, или ctime.

displaying MACtimes using ls:

Linux (ls from GNU fileutils)

OpenBSD

Solaris

mtime

ls -latr --full-time

ls -latTr

ls -latr

atime

ls -laur --full-time

ls -lauTr

ls -laur

ctime

ls -lacr --full-time

ls -lacTr

ls -lacr

Одной из наиболее полезных команд является командв find. Она используется для поиска в файловой системе файлов, которые были модифицированы, изменены или к ним было произведено обращение. Find использует в качестве аргументов значения -ctime, -atime, -mtime. Необходимо помнить, что при использовании команды find в каталогах измениться значение atime. Если цель использования find не более чем формальность, то Вы должны работать над защищенном от записи образом.

В большинство Linux систем включает в себя GNU find[10], из пакета программ coreutils. Из-за многобразия возможностей, предлагаемых пользователям, версия GNU find более мощная. Можно определить временные границы и find будет выдавать временные метки только из этого диапазона. Если к примеру вы желаете найти файл измененный более чем два, но менее чем 7 дней назад и хотите просмотреть значения mtime, ctime, и inode этих файлов, то необходимо использовать следующую конструкцию:

# find / \( -mtime +2 -a -mtime -7 \) -a -printf "M:%t C:%c %i\t%p\n"

    # find / \( -mtime +2 -a -mtime -7 \)|perl -ne
'chomp;($i,$m,$c)=(stat)[1,9,10];printf"M:%s\t$i\t$_\n",localtime($m)." 
 C:".localtime($c)'

Одним из возможных направлений взломщиков в дискредитации систем является использование взломанного suid или двоичного sgid для увеличения уровня привилегий. Иногда, для удобства, взломщики оставляют на файловой системе корневые оболочки suid. Для поиска таких файлов можно использовать команду find. Для поиска suid и sgid файлов и вывода информации о них, необходимо использовать:

find / -perm -6000 -ls

Ниже приведены еще несколько примеров использования команды find:

the find command in action:
##==
##== find all files which have had their status changed in
##==   the last 24 hrs (display ctime, inode, and filename)
# find / -ctime -1 -printf "%c  %i\t%p\n"
Fri Sep  7 11:55:14 2003  174945        /var/lib/rpm
Fri Sep  7 11:55:14 2003  174946        /var/lib/rpm/__db.001
Fri Sep  7 11:55:17 2003  174947        /var/lib/rpm/__db.002
Fri Sep  7 11:55:17 2003  174948        /var/lib/rpm/__db.003
Fri Sep  7 11:55:55 2003  160125        /var/lib/random-seed
Fri Sep  7 11:55:16 2003  222706        /var/log
Fri Sep  7 12:17:05 2003  224545        /var/log/messages
[ output deleted ]
##==
##== find all files which have had their status changed from
##==   5 to 30 (inclusive) days ago and display the ctime, inode, and filename
# find / -ctime +4 -ctime -31 -printf "%c  %i\t%p\n"
Sat Aug 30 19:49:52 2003  414661        /boot/System.map-2.4.20-20.8bigmem
Sat Aug 30 19:49:52 2003  414662        /boot/config-2.4.20-20.8bigmem
Sat Aug 30 19:49:52 2003  414663        /boot/module-info-2.4.20-20.8bigmem
Sat Aug 30 19:49:53 2003  414664        /boot/vmlinux-2.4.20-20.8bigmem
Sat Aug 30 19:49:53 2003  414665        /boot/vmlinuz-2.4.20-20.8bigmem
[ output deleted ]

Для создания образов файловой системы в ОС Unix и Linux, чаще всего используется команды dd. Dd создает и сохраняет побитовый образ файловой системы. При выполнении команды Dd не отображается прогресс и она медленно работает если размер входных блоков отличается от размера выходных блоков. Более удобной версией команды dd, явлется избавленная от этих недостатков команда sdd [11]. Sdd может также отображать текущую статистику, когда она посылает SIGQUIT, а также данная команда реально отображает количество обработанных данных.

До вызова команды dd, вы должны выполнить утилиту, генерирующую хеширование файловой системы, образ которой мы хотим сохранить. Предположим, что у вас ОС Linux и вы желаете создать образ /dev/hda, в таком случае вы должны выполнить команду md5sum /dev/hda, а затем запустить команду dd. После завершения работы команды dd, необходимо запустить ту же самую утилиту на сохраненном образе. В случае, если значения не будут соответствовать, необходимо обязательно найти причины расхождения. В ОС OpenBSD и Solaris, для анализа инцидента должны привлекаться RAW устройства.

В ОС Linux, для создания образов файловых систем ext2 и ext3, используется утилита e2image. E2image интерпретирует заданную файловую систему, вместо сохранения "сырых" битов. E2image не может сохранять данные, которые прозорливые взломщики сохранили на диске вне структуры файловой системы. E2image создает "необработанные" и "нормальные" образы, которые для сохранения дискового пространства создаются как фрагментированные файлы. Образ файловой системы, созданный с помощью e2image имеет хеш, отличный от хеша файловой системы хранимой на диске, что создает трудности при обеспечении данных, которые вы желаете зафиксировать. Все это приводит к выводу, что утилита e2image не должна использовать вместо команды dd, для создания судебных образов.

Другой утилитой, используемой для создания образов системы является partimage, позволяющая через SSL сохранять файлы образов на сервере partimage. Данная утилита в настоящее время поддерживает ext2, ext3, ReiserFS, JFS и XFS. Также поддерживаются FAT16/32 и HPFS (OS/2). Ведутся работы на UFS (Solaris, *BSD), HFS (MacOS), и NTFS.

Утилита Partimage сохраняет только используемые блоки раздела, образ которого мы хотим создать. Как и при использовании e2image, возможно, что образ, созданный с помощью Partimage, не будет точно представлять состояние диска во время создания образа. Также мы должны знать, что популярная программа Chost может создавать образы не пригодные для forensics. Перед использованием Chost в критической ситуации, необходимо сперва внимательно прочитать описание данной версии программы, чтобы убедиться в том, что вы можете её использовать.

Теперь Вы можете спросить, зачем в статью включены программы не пригодные для forensics. Я включил такие программы, чтобы создать следующий пункт:

При выборе программы[13] для создания forensics образов, необходимо выбрать такую программу, которая сможет, во время создания образа, обеспечить точное отображение состояния диска.

Когда в программе утверждается, что она создает образы, то необходимо узнать, что авторы этой программы имеют ввиду под названием "образ". Ниже представлен эмпирический метод для выяснения четкого определения образа:

  1. Переведите машину с тестируемой файловой системой в автономный режим.
  2. Запустите на устройстве, содержащем файловую систему утилиту md5sum или утилиту поддерживающую SHA1
  3. Для сохранения данных используйте ваше средство создания образов
  4. Запустите на созданном образе md5sum или утилиту, поддерживающую SHA1

Если результаты не соответствуют друг другу, то не используйте это средство forensics целей.

Вы хотели бы, чтобы некоторая файловая система была вместе со своим отладчиком?

Иногда утилиты командной строки типа ls, stat, и find не дают нам полного представления о состоянии анализируемой нами файловой системы. Возможно вы хотите просмотреть образ файловой системы созданной командой dd, возможно вы взволнованы тем, что был установлен rootkit и что программа ls была заражена вирусом, или вы думаете, что существует некоторый удаленный, но все же восстановимый, файл содержащий полезные данные.

Во всех трех операционных системах существует отладчик файловой системы. В ОС OpenBSD и Solaris этот отладчик называется fsdb. В Solaris отладчикк наиболее сложный и требуется определенное время, чтобы в нем разобраться. В отладчиках Fsdb для OpenBSD и debugfs для ext2 и ext3 существеут интегрированная справочная система, к которой можно обратиться набрав "help". В настоящее время не существует интерактивных отладчиков для популярных файловых Linux систем типа JFS и reiserfs. Xfs_db - отладчик файловой системы, доступный для XFS. Такие файловые системы не описаны в данной статье, потому что они не являются широко распространенными в описанных операционных системах.

Способность операционной системы Linux работать с внешними файловыми системами полезна только для forensic работы в режиме только для чтения. Утилиты ffs для *BSD's и ufs для Solaris могут устанавливаться только с помощью модуля ядра ufs. Могут быть установлены файловые системы доступные на Linux, такие как ext2, ext3, JFS, reiserfs, и XFS. Также поддерживаются файловые системы MS DOS (FAT16), FAT32, и большинство NTFS образов. Однако в Linux не включены отладчики для внешних файловых систем.

Вы можете узнать, какие файловые системы поддерживаются в вашей версии Linux с помощью команды find /lib/modules/`uname -r`/kernel/fs/* -type f|grep -v 'nls\/'. Чтобы узнать о загруженных в настоящее время файловых системах необходимо использовать: grep -v '^nodev' /proc/filesystems. Для получения дополнительной информации про установленные файловые системы, используйте mount(8).

Для установки образа в защищенном от записи режиме используйте: mount -t ext2 -o ro,loop=/dev/loop0 /var/tmp/2003_02_17_attack.bin /mnt. Теперь вы можете исследовать вновь установленную файловую систему с помощью поставляемых с операционной системой программ. Поскольку вы исследуете образ, то будет происходить изменение времени доступа к манипулируемым вами файлам и каталогам. Эти изменения будут происходить только в памяти.

mounting a file system image in Linux:
##==
##== mount the image read-only so that the image doesn't change on disk
# mount -o ro,loop=/dev/loop0 /var/space/images/2003_02_17_linux.bin /mnt
##==
##== list of files
# ls -la /mnt
total 146
drwxr-xr-x   19 root     root         1024 Feb 17  2003 .
drwxr-xr-x   19 root     root         4096 Sep 12 11:55 ..
-rw-r--r--    1 root     root            0 Sep 12 11:55 .autofsck
-rw-------    1 root     root          186 Sep  6 19:58 .bash_history
drwxr-xr-x    2 root     root         2048 Feb  8  2003 bin
drwxr-xr-x    3 root     root         1024 Sep  6 19:59 boot
drwxr-xr-x   20 root     root       116736 Feb 17  2003 dev
drwxr-xr-x   41 root     root         3072 Sep 12 14:13 etc
[ output deleted ]
##==
##== unmount /mnt
# umount /mnt
	    

Для использования debugfs, необходимо набрать debugfs . Ниже представлен пример использования debugfs:

using debugfs on an ext2 file system image in Linux:
##==
##== 
# debugfs /var/space/images/2003_02_17_openbsd_attack.bin
debugfs 1.27 (8-Mar-2002)
##== show file system statistics
debugfs:  stats
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          93bfa3ee-d684-4d07-a5d0-1654f488aabd
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      filetype sparse_super
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              65536
Block count:              262144
Reserved block count:     13107
Free blocks:              214567
Free inodes:              57335
First block:              1
Block size:               1024
Fragment size:            1024
Blocks per group:         8192
Fragments per group:      8192
Inodes per group:         2048
Inode blocks per group:   256
Last mount time:          Fri Jan  9 14:13:42 2003
Last write time:          Fri Feb 17 23:13:04 2003
Mount count:              1
Maximum mount count:      27
Last checked:             Fri Jan  9 14:13:35 2003
Check interval:           15552000 (6 months)
Next check after:         Wed Jul  9 14:13:35 2003
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
 Group  0: block bitmap at 3, inode bitmap at 4, inode table at 5
           7928 free blocks, 2033 free inodes, 3 used directories
[output deleted]
##== print the contents of the current inode in directory format
debugfs:  ls -l
      2   40755 (2)      0      0    1024 17-Feb-2003 23:13 .
      2   40755 (2)      0      0    1024 17-Feb-2003 23:13 ..
   4097   40700 (2)      0      0    1024  8-Feb-2003 15:17 lost+found
   8193   40755 (2)      0      0   116736 17-Feb-2003 23:13 dev
  57345   40755 (2)      0      0    1024  8-Feb-2003 16:20 var
  43010   41755 (2)      0      0    1024 17-Feb-2003 23:13 tmp
  47106   40755 (2)      0      0    3072 17-Feb-2003 11:55 etc
[ output deleted ]

##== show inode information for etc
debugfs:  stat etc
Inode: 47106   Type: directory    Mode:  0755   Flags: 0x0   Generation: 461325
User:     0   Group:     0   Size: 3072
File ACL: 0    Directory ACL: 0
Links: 41   Blockcount: 6
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x3f61d525 -- Fri Feb 17 14:16:05 2003
atime: 0x3f61d4ff -- Fri Feb 17 14:15:27 2003
mtime: 0x3f61d496 -- Fri Feb 17 14:13:42 2003
BLOCKS:
(0):188678, (1):189498, (2):189746
TOTAL: 3

##== chdir into directory inode etc
debugfs:  cd etc
##== show inode information for passwd
debugfs:  stat passwd
Inode: 47121   Type: regular    Mode:  0644   Flags: 0x0   Generation: 461394
User:     0   Group:     0   Size: 1282
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 4
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x3f61d505 -- Fri Feb 17 14:50:04 2003
atime: 0x3f61d4b2 -- Fri Feb 17 23:14:10 2003
mtime: 0x3e5e259c -- Thu Feb 17 14:50:04 2003
BLOCKS:
(0-1):188692-188693
TOTAL: 2

##== dump the contents of inode that corresponds to passwd
debugfs:  cat passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
[ output deleted ]
debugfs:  quit
	    

Работа с образами OpenBSD занимает еще несколько шагов. Перед установкой, образы должны быть сконфигурированы на дисковом устройстве vnode:

mounting a file system image in OpenBSD:
##==
##== associate the image with the vnode pseudo disk device
# vnconfig -v -c svnd0 /var/space/images/2003_02_17_openbsd_attack.bin
svnd0: 7277544448 bytes on /var/space/images/2003_02_17_openbsd_attack.bin
##==
##== mount the image read-only so that the image doesn't change on disk
# mount -o ro /dev/svnd0c /mnt
##==
##== mount the image read-only so that the image doesn't change on disk
# ls -la /mnt
total 9026
drwxr-xr-x  14 root  wheel      512 Nov  4  2002 .
drwxr-xr-x  14 root  wheel      512 Nov  4  2002 ..
-rw-r--r--   2 root  wheel      685 Nov  4  2002 .cshrc
-rw-r--r--   2 root  wheel      179 Nov  4  2002 .profile
drwxr-xr-x   2 root  wheel      512 Oct  4  2002 altroot
drwxr-xr-x   2 root  wheel     1024 Oct  4  2002 bin
-r-xr-xr-x   1 root  wheel    53248 Nov  4  2002 boot
-rw-r--r--   1 root  wheel  4515116 Nov  4  2002 bsd
drwxr-xr-x   4 root  wheel    19968 Sep 12 11:56 dev
drwxr-xr-x  19 root  wheel     2048 Mar 28 12:44 etc
[ output deleted ]
##==
##== unmount the image
# umount /mnt
##==
##== dis-associate the image from the vnode pseudo disk device
# vnconfig -v -u svnd0
svnd0: cleared
	    

Fsdb это ffs редактор в OpenBSD. В Fsdb нет режима "только для чтения", поэтому необходимо работать только над копиями образов.

using fsdb on a file system image in OpenBSD:
##==
##== associate the image with the vnode pseudo disk device
# vnconfig -vc svnd0 /var/space/images/2003_02_17_openbsd_attack.bin
svnd0: 7277544448 bytes on /var/space/images/2003_02_17_openbsd_attack.bin
##==
##== start fsdb on /dev/svnd0c
# fsdb -f /dev/rsvnd0c
** /dev/rsvnd0c
** File system is already clean
Editing file system `/dev/rsvnd0c'
Last Mounted on /mnt
current inode: directory
I=2 MODE=40755 SIZE=512
        MTIME=Nov  4 19:49:30 2002 [0 nsec]
        CTIME=Nov  4 19:49:30 2002 [0 nsec]
        ATIME=Apr 11 14:06:57 2003 [0 nsec]
OWNER=root GRP=wheel LINKCNT=14 FLAGS=0 BLKCNT=2 GEN=e32f2a77
fsdb (inum: 2)> ls
slot 0 ino 2 reclen 12: directory, `.'
slot 1 ino 2 reclen 12: directory, `..'
slot 2 ino 0 reclen 16: regular, `boot'
slot 3 ino 7488 reclen 16: directory, `altroot'
slot 4 ino 33216 reclen 12: directory, `bin'
slot 5 ino 14016 reclen 12: directory, `dev'
slot 6 ino 42816 reclen 12: directory, `etc'
slot 7 ino 42048 reclen 16: directory, `home'
slot 8 ino 59904 reclen 12: directory, `mnt'
slot 9 ino 6528 reclen 16: directory, `root'
slot 10 ino 5568 reclen 16: directory, `sbin'
slot 11 ino 45888 reclen 16: directory, `stand'
slot 12 ino 27072 reclen 12: directory, `tmp'
slot 13 ino 41472 reclen 12: directory, `usr'
slot 14 ino 6336 reclen 12: directory, `var'
slot 15 ino 6529 reclen 16: regular, `.cshrc'
slot 16 ino 6532 reclen 20: regular, `.profile'
slot 17 ino 4 reclen 12: symlink, `sys'
slot 18 ino 0 reclen 260: regular, `bsd'
fsdb (inum: 2)> cd etc/passwd
component `passwd': current inode: regular file
I=42860 MODE=100644 SIZE=1033
        MTIME=Feb 27 21:38:23 2003 [0 nsec]
        CTIME=Feb 27 21:38:23 2003 [0 nsec]
        ATIME=Apr 11 13:49:57 2003 [0 nsec]
OWNER=root GRP=wheel LINKCNT=1 FLAGS=0 BLKCNT=4 GEN=4bf628a5
fsdb (inum: 42860)> quit
##==
##== dis-associate the image from the vnode pseudo disk device
# vnconfig -vu svnd0
svnd0: cleared
	    

Подобно OpenBSD, работа с образами в Solaris требует еще нескольких дополнительных шагов. В Solaris есть драйвер, называемый lofi. Вы должны найти этот драйвер, после первого использования lofiadm. Для этого используйте команду modinfo, отображающую загруженные в настоящее время модули ядра. Код lofiadm включен в пакет UNWCSU - один из основных пакетов операционной системы. Ниже представлен пример установки образа через lofi драйвер:

mounting a file system image in Solaris:
##==
##== register the image available as a block device via the loopback driver:
# lofiadm -a /mnt/images/2003_02_17_attack.bin
/dev/lofi/1
##==
##== verify that the image is registered
# lofiadm
Block Device             File
/dev/lofi/1              /var/space/images/2003_02_17_attack.bin
##== 
##== mount the image read-only so that the image doesn't change on disk
# mount -o ro /dev/lofi/1 /mnt
##== 
##== mount the image read-only so that the image doesn't change on disk
# ls -la /mnt
/mnt:
total 586
drwxr-xr-x  21 root     root         512 Dec  3 04:10 .
drwxr-xr-x  21 root     root         512 Dec  3 04:10 ..
-rw-------   1 root     other       4432 Feb 17 04:25 .sh_history
lrwxrwxrwx   1 root     root           9 Nov 28 06:07 bin -> ./usr/bin
drwxr-xr-x   2 root     nobody       512 Nov 28 07:32 cdrom
drwxr-xr-x  15 root     sys         4096 Feb 17 04:14 dev
drwxr-xr-x   4 root     sys          512 Nov 28 06:29 devices
drwxr-xr-x  41 root     sys         3584 Feb 16 17:00 etc
[ output deleted ]
##== 
##== un-mount the image
# umount /mnt
##== 
##== unregister the image from the loopback driver
# lofiadm -d /dev/lofi/1
	    

Fsdb – это программа, на которую необходимо потратить некоторое время, чтобы потом быстро реагировать в критических ситуациях.

using fsdb on a file system image in Solaris:
##==
##== register the image available as a block device via the loopback driver:
# lofiadm -a /mnt/images/2003_02_17_attack.bin
/dev/lofi/1
##==
##== verify that the image is registered:
# lofiadm
Block Device             File
/dev/lofi/1              /mnt/images/2003_02_17_attack.bin
##== 
##== browse the image using fsdb:
# fsdb /dev/lofi/1
fsdb of /dev/lofi/1 (Read only) -- last mounted on /
fs_clean is currently set to FSCLEAN
fs_state consistent (fs_clean CAN be trusted)
##== 
##== print the super block
/dev/lofi/1 > :sb
        super block:
magic   11954   format  dynamic time    Mon Feb  17 18:36:05 2003
nbfree  605536  ndir    6363    nifree  889612  nffree  8252
ncg     290     ncyl    4631    size    8314960 blocks  8187339
bsize   8192    shift   13      mask    0xffffe000
fsize   1024    shift   10      mask    0xfffffc00
frag    8       shift   3       fsbtodb 1
cpg     16      bpg     3591    fpg     28728   ipg     3392
minfree 1%      optim   time    maxcontig 16    maxbpg  2048
rotdelay 0ms    fs_id[0] 0x0    fs_id[1] 0x0    rps     120
ntrak   27      nsect   133     npsect  133     spc     3591
trackskew 0     interleave 1
nindir  2048    inopb   64      nspf    2
sblkno  16      cblkno  24      iblkno  32      dblkno  456
sbsize  5120    cgsize  5120    cgoffset 72     cgmask  0xffffffe0
csaddr  456     cssize  5120    shift   9       mask    0xfffffe00
cgrotor 187     fmod    0       ronly   0
blocks available in each of 8 rotational positions
cylinder number 0:
[ output deleted ]
##== 
##== show current entries in this directory:
/dev/lofi/1 > :ls -l
/:
i#: 2           ./
i#: 2           ../
i#: 2bc0        etc/
i#: 8c02        kernel/
i#: 3           lost+found/
i#: 8c0         usr/
[ output deleted ]
##== 
##== set the current block to be examined to block 2bc0 (/etc) and display the 
##==   information in block 2bc0 as an inode:
##== note that :pwd will still show the current location as / because you're
##==  examining data blocks on the file system. You haven't actually left /.
##==  To navigate the directory hierarchy, you need to use :cd <some_path>
/dev/lofi/1 > 2bc0:inode?i
i#: 2bc0           md: d---rwxr-xr-x  uid: 0             gid: 3       
ln: 29             bs: 8              sz : c_flags : 0           e00                 

db#0: 65a8         
        accessed: Tue May 27 04:38:06 2003
        modified: Mon May 26 17:00:44 2003
        created : Tue May 27 04:38:06 2003
/dev/lofi/1 > :ls -l
i#: 2c25        nsswitch.conf 
i#: 2c21        passwd 
i#: 2c1e        path_to_inst 
i#: 2c3e        pwck@
i#: 2bee        rc0@
i#: 6042        rc0.d/
i#: 2bef        rc1@
i#: 6901        rc1.d/
i#: 2bf0        rc2@
i#: 71c2        rc2.d/
i#: 2bf1        rc3@
i#: 7a82        rc3.d/
i#: 2bf2        rc5@
i#: 2bf3        rc6@
i#: 2bf4        rcS@
i#: 834e        rcS.d/
i#: 2c2d        shadow 
i#: 2c27        syslog.conf 
[ output deleted ]
##== 
##== set the current block to be examined to block 2c21 (/etc/passwd) 
##==  and display the 
##==   information in block 2c21 as an inode:
/dev/lofi/1 > 2c21:inode?i
i#: 2c21           md: ----r--r--r--  uid: 0             gid: 3       
ln: 1              bs: 2              sz : c_flags : 0           20f                 

db#0: 6554         
        accessed: Tue May 27 04:37:58 2003
        modified: Thu Nov 28 08:18:06 2002
        created : Tue May 27 04:37:58 2003
##== 
##== display the information in current block as ASCII data:
##== you can display the block in hex using: 0:db:block,*/X
/dev/lofi/1 > 0:db:block,*/c
 1955000:       r   o   o   t   :   x   :   0   :   1   :   S   u   p   e   r 
 1955010:       -   U   s   e   r   :   /   :   /   s   b   i   n   /   s   h 
 1955020:       \n  d   a   e   m   o   n   :   x   :   1   :   1   :   :   / 
 1955030:       :   \n  b   i   n   :   x   :   2   :   2   :   :   /   u   s 
 1955040:       r   /   b   i   n   :   \n  s   y   s   :   x   :   3   :   3 
 1955050:       :   :   /   :   \n  a   d   m   :   x   :   4   :   4   :   A 
 1955060:       d   m   i   n   :   /   v   a   r   /   a   d   m   :   \n  l 
 1955070:       p   :   x   :   7   1   :   8   :   L   i   n   e       P   r 
 1955080:       i   n   t   e   r       A   d   m   i   n   :   /   u   s   r 
 1955090:       /   s   p   o   o   l   /   l   p   :   \n  u   u   c   p   : 
 19550a0:       x   :   5   :   5   :   u   u   c   p       A   d   m   i   n 
 19550b0:       :   /   u   s   r   /   l   i   b   /   u   u   c   p   :   \n
 19550c0:       n   u   u   c   p   :   x   :   9   :   9   :   u   u   c   p 
 19550d0:           A   d   m   i   n   :   /   v   a   r   /   s   p   o   o 
 19550e0:       l   /   u   u   c   p   p   u   b   l   i   c   :   /   u   s 
 19550f0:       r   /   l   i   b   /   u   u   c   p   /   u   u   c   i   c 
 1955100:       o   \n  s   m   m   s   p   :   x   :   2   5   :   2   5   : 
 1955110:       S   e   n   d   M   a   i   l       M   e   s   s   a   g   e 
 1955120:           S   u   b   m   i   s   s   i   o   n       P   r   o   g 
 1955130:       r   a   m   :   /   :   \n  l   i   s   t   e   n   :   x   : 
 1955140:       3   7   :   4   :   N   e   t   w   o   r   k       A   d   m 
 1955150:       i   n   :   /   u   s   r   /   n   e   t   /   n   l   s   : 
 1955160:       \n  n   o   b   o   d   y   :   x   :   6   0   0   0   1   : 
 1955170:       6   0   0   0   1   :   N   o   b   o   d   y   :   /   :   \n
 1955180:       n   o   a   c   c   e   s   s   :   x   :   6   0   0   0   2 
 1955190:       :   6   0   0   0   2   :   N   o       A   c   c   e   s   s 
 19551a0:           U   s   e   r   :   /   :   \n  n   o   b   o   d   y   4 
 19551b0:       :   x   :   6   5   5   3   4   :   6   5   5   3   4   :   S 
 19551c0:       u   n   O   S       4   .   x       N   o   b   o   d   y   : 
 19551d0:       /   :   \n  k   r   h   :   x   :   1   1   1   9   :   1   1 
 19551e0:       1   9   :   K   r   4   D       H   a   X   0   R       y   o 
 19551f0:       :   /   e   x   p   o   r   t   /   h   o   m   e   /   k   r 
 1955200:       h   :   /   u   s   r   /   b   i   n   /   k   s   h   \n  
[ output deleted ]
##== 
##== unregister the image from the loopback driver:
# lofiadm -d /dev/lofi/1
	    

Передача данных со взломанного хоста

Если вам требуется пересылка данных с работающего в онлайновом режиме хоста до создания резервного образа, то необходимо рассмотреть ряд проблем.

  • Передача должна как можно меньше затрагивать файловую систему
  • В идеале, передача должна происходить по безопасному каналу к проверенному хосту.
  • Используемые вами программы не должны быть дискредитированы. В идеале необходим запуск с компакт диска

· Если для сохранения данных вы используете мандаты для авторизации на удаленном хосте, то вполне возможно, что хакер, взломавший ваш компьютер, уже использовал или захватил ваши мандаты.

Имеется ряд способов для сохранения наиболее важных данных. Первый способ заключается в использовании концентратора или соединительных кабелей для передачи данных с дискредитированного хоста на другой компьютер. Если вы не можете или не желаете отключать компьютер от сети, то возможно использовать ssh для надежной передачи данных с хоста. Ниже представлен сценарий, сохраняющий информацию о текущем состоянии сетевых подключений, списке процессов и другую системную информацию, на удаленных хост:

Пример скрипта для передачи данных с хоста с помощью ssh
#!/bin/bash

# This is a quick hack for demonstration purpose only. It needs
# to be adapted to your environment. This script works on Linux.
# YMMV elsewhere.

rem_host="192.168.27.23"

ssh="ssh forensics@${rem_host}"

# get uname -a, uptime, and Debian or RedHat version info
echo -e `uname -a` "\n" `uptime` "\n" 
  `[ -s /etc/debian_version ] && 
    echo Debian $(cat /etc/debian_version) || cat /etc/redhat-release` 
  | ${ssh} "dd of=/var/tmp/incidents/sysinfo"

# save process information
ps auwwx | ${ssh} "dd of=/var/tmp/incidents/processes_bsd"
ps -eflyc | ${ssh} "dd of=/var/tmp/incidents/processes_sysv"

# save list of open files
lsof | ${ssh} "dd of=/var/tmp/incidents/lsof"

# save networking information
netstat -A INET -anv | ${ssh} "dd of=/var/tmp/incidents/netstat_infos"
lsof -Pni | ${ssh} "dd of=/var/tmp/incidents/lsofnet_infos"

# save loaded modules
# use modinfo on Solaris, modstat on OpenBSD
lsmod | ${ssh} "dd of=/var/tmp/incidents/modules"

# wtmp info from last
# snagging /var/log/[wu]tmp* might not be bad idea
last | ${ssh} "dd of=/var/tmp/incidents/last"

# info from process accounting
# snagging /var/account/* might not be a bad idea
# lastcomm is used here, dump-acct can work too
# system accounting (sar) if enable can be useful too. files are usually ing
#   /var/log/sysstat
lastcomm | ${ssh} "dd of=/var/tmp/incidents/last"

# save /etc and logs
tar cvjf - /etc /var/log/* | ${ssh} "dd of=/var/tmp/incidents/files_and_logs.tar.bz2"

# use mount to determine currently mounted drives to image. This might need
#  tweaking depending on your system, so that it only picks up the drives you want.
#  Is compressing with bzip2 ok for forensics in your world? Since you're applying
#  a transform before taking an md5sum, it's possible it could cause an issue. Consult
#  LE or Legal.
#
#  This doesn't handle swap if swap lives on a drive that isn't in the list that
#  mount generates. Use 'swapon -s'.
#
#  bzip2 can run on whichever machine is faster, or it can be used before the
#   data goes over the network. If your network is fast enough, bziping on the remote
#   host is a good idea to conserve space. Software compression can take more time than
#   it takes to move uncompressed data across a network, if the network is fast enough.
#   In these situations compress only if you're worried about space, or compress after
#   the transfer is done.
for drive in `mount |grep '^\/dev.* (rw'|awk '{print $1}'|sed 's/[0-9]\+$//'|sort|uniq`
do
    drive_name=`basename ${drive}`
    dd if=${drive} |${ssh} "bzip2 -9c|dd of=/var/tmp/incidents/${drive_name}.raw.bz2"
done
	    

Заключение

В этой статье были рассмотрены различные программы, необходимые для исследования файловой системы. Необходимо также не забывать использовать несколько программ для проверки результатов выдаваемых одной программой. Если вы кое-что заметили с помощью ls, то используйте для проверки find -ls. Убедитесь, что вы применяли программы использующие алгоритмы хеширования типа MD5 или SHA1. Проверьте, что вы перевели хост в автономный режим, чтобы переместить данные с этого хоста на другой. Создавайте процедуры, которые облегчат вам проведение инцидентного анализа. Работайте для наращивания своего мастерства, и приятных Вам исследований.

Ссылки

[1] Acquiring/Installing software

[2] CD-ROM and Floppy distributions

[3] Package Formats

[4] OpenBSD's mtree

[5] Hash functions

[6] File-system integrity verification tools

[7] changedfiles, dnotify, and FAM

[8] shash

[9] Creating file systems for experimentation

Linux

  1. create a file that is about the size of a file system that you'd like to test:
    dd if=/dev/zero of=/var/tmp/testfs bs=1048576 count=
  2. create the file system: mke2fs -m0 /var/tmp/testfs
  3. turn off forced fsck: tune2fs -c 0 /var/tmp/testfs
  4. mount the file system or use debugfs:
    • mount -o loop=/dev/loop0 /var/tmp/testfs /mnt
    • debugfs /var/tmp/testfs
      • unmount the file system if necessary: umount /mnt

OpenBSD

  1. create a file that is about the size of a file system that you'd like to test using:
    dd if=/dev/zero of=/var/tmp/testfs bs=1048576 count=
  2. configure the pseudo file system as vnode disk device: vnconfig -v -c svnd0 /var/tmp/testfs
  3. create the file system: newfs /dev/rsvnd0c
  4. mount the pseudo file system or use fsdb:
    • mount /dev/svnd0c /mnt
    • fsdb -f /dev/rsvnd0c
  5. unmount the file system if necessary: umount /mnt
  6. unconfigure the vnode disk device: vnconfig -v -u svnd0

Solaris

  1. create a file that is about the size of a file system that you'd like to test:
    dd if=/dev/zero of=/var/tmp/testfs bs=1048576 count=
  2. register the file system with the loopback device driver: lofiadm -a /var/tmp/testfs
  3. create the file system: newfs /dev/lofi/1
  4. mount the file system or use fsdb:
    • mount /dev/lofi/1 /mnt
    • fsdb /dev/lofi/1
      • unregister the file system from the loopback device driver: lofiadm -d /dev/lofi/1
      • unmount the file system if necessary: umount /mnt

[10] GNU Coreutils

[11] Shily's dd
  • sdd (schily dd)

[12] Partition Image

[13] Forensics Tools

[14] Cross-over cables

[15] netcat

[16] socat

[17] stunnel

[18] OpenSSL

Ищем баги вместе! Но не те, что в продакшене...

Разбираем кейсы, делимся опытом, учимся на чужих ошибках

Зафиксируйте уязвимость своих знаний — подпишитесь!