Корректные действия по устранению последствий инцидентов в компьютерной безопасности стоят на втором месте по важности, уступая лишь превентивным мерам по предотвращению этих инцидентов. Неправильная обработка, или сбор имеющейся информации может нанести непоправимый вред исследованию. Исследователи должны хорошо знать, какую информацию они намерены собирать, а также какие инструменты они могут использовать, и какое влияние окажут эти инструменты на саму систему.
Михаил Разумов, по материалам SecurityFocus
Корректные действия по устранению последствий инцидентов в компьютерной безопасности стоят на втором месте по важности, уступая лишь превентивным мерам по предотвращению этих инцидентов. Неправильная обработка, или сбор имеющейся информации может нанести непоправимый вред исследованию. Исследователи должны хорошо знать, какую информацию они намерены собирать, а также какие инструменты они могут использовать, и какое влияние окажут эти инструменты на саму систему.
Исследователи знают, что не каждое событие требует полного исследования. Очевидно, что каждый инцидент требует различных действий от исследователей; однако, ответственному за устранение инцидента не следует отклоняться от рекомендуемых инструкций и полагать, что следует использовать для этого различные процедуры. Существуют определенные типы информации, которые могут быть собраны и быстро проанализированы с целью определить, какие последующие шаги следует предпринять. Эта статья содержит краткий обзор некоторых действий, которые следует предпринимать в первую очередь при возникновении инцидентов безопасности. Статья ориентирована на инциденты в Microsoft Windows 2000, вследствие ее популярности в корпоративных и серверных приложениях. Многие темы, обсуждаемые в этой статье, применимы для других платформ, и многие из обсуждаемых методик и инструментов могут также применяться на NT и XP системах.
В этой статье используются термины «исследователь» и «ответственный за устранение инцидента». Первый обозначает человека с исследовательскими обязанностями, а второй человека, который первым получает доступ к системе, на которой произошел инцидент.
Когда говорят о «компьютерной экспертизе» («computer forensics»), на ум приходят картины выключения (shut down) компьютера и побитное копирование жесткого диска. Существуют даже споры о том, как лучше всего выключать машины. Например, при выключении компьютера Win2k, может потеряться большое количество ценной информации. Все данные, относящиеся к сетевым подключениям, процессам и содержимому памяти будут потеряны при выключении системы. Вследствие этого такие данные называются «временной информацией».
Временная информация может быть критично важной не только для определения последующих действий исследователя, но и с финансовой точки зрения. Для многих организаций отключение критичных систем измеряется в долларах (десятках, сотнях и более) в минуту. Выключение системы может оказаться очень, очень дорогим, в то время как необходимая для определения природы инцидента информация может быть легко собрана без этого. Поэтому лицо, ответственное за устранение инцидента (обычно это администратор) должно хорошо понимать, какая информация может и должна быть собрана.
Обычно при возникновении инцидента, существуют очевидные шаги, ведущие к лог-файлам, таким как Журнал событий (EventLog), или IIS логи. Однако, после совершения атаки может остаться выполняемым процесс, такой как IRC bot или Троян. Информация об этом процессе, такая как полная командная строка, принадлежность к пользователю, может быть легко получена набором утилит, таких как Pslist 1.22, Handle v2.01, и ListDLLs, которые можно взять с sysinternals. Эти утилиты могут предоставить много информации о ресурсах, используемых процессом, но основной информации, названной выше, должно быть вполне достаточно для администратора или ответственного за устранение для обнаружения чего-нибудь подозрительного или необычного.
Более детальная информация, относящаяся к процессам, может быть получена с помощью утилит отображения процесс-порт, например fport.exe от Foundstone. Fport показывает, какие порты открыты какими процессами, и команда Windows netstat –a покажет, какой удаленный хост подключен к этому порту (в XP вместо fport нужно использовать netstat –o для определения PID процесса, использующего порт).
Часть информации, собранной с помощью этих утилит, может выглядеть «нормальной», но все может оказаться иначе после сбора дополнительной информации. Например, с помощью команд net и nbtstat можно получить огромное количество информации о NetBIOS подсоединениях исследуемой системы. Ниже представлен список команд, которые необходимо запустить для сбора начальной информации:
Вывод каждой из этих команд необходимо перенаправить в файл. Для детальной информации по каждой из этих команд, наберите команду и «/?» в конце (например net view /? или nbtstat /?).
Команды netstat и arp следует использовать для сбора временной информации, специфичной для Internet и Ethernet подсоединений системы:
Ответственный за устранение инцидентов должен получить содержимое Clipboard пострадавшей системы, используя pclip.exe из Unix Utilities archive. В Clipboard могут храниться важные улики, даже содержимое файлов или пароли. Если открыт на экране или свернут в панели задач command prompt, этот факт следует задокументировать, а затем запустить в нем команду doskey /history для получения истории выполненных команд.
Исследователю может также понадобиться информация из реестра подозреваемой машины. Хотя эта информация не может считаться временной, зачастую информация из реестра помогает принять решение относительно состояния исследования, стоит или нет выключать компьютер для снятия образа жесткого диска, и т.п. Ода из лучших утилит для сбора информации, содержащейся в ключах реестра это reg.exe, которая есть в архиве security.exe. Reg.exe – это утилита командной строки, которую можно использовать в командных файлах для получения информации из реестра. Для получения информации из ключа Winlogon необходимо набрать следующую строку:
Аналогично можно получить содержимое ключа Run и всех подключей:
Также можно получить информацию из специфичных ключей реестра:
Другая очень полезная утилита из архива security.exe – это auditpol.exe. Эта утилита дает информацию о текущей конфигурации аудита в системе, позволяя увидеть, какие события подвержены аудиту. И вновь, хотя эта информация не может считаться временной, она может оказаться очень ценной для исследователя.
После того, как исследователь или ответственный за устранение инцидента осознают, какую информацию, временную или нет, можно получить с системы Win2k, следует разработать и применить набор инструментов для сбора этой информации. После сбора необходимых утилит и автоматизации их использования с помощью скриптов, уменьшается возможность ошибок и потери информации. Копирование, например, на дискету набора утилит и написания скрипта, который их запускает имеет много преимуществ. Во-первых, процесс автоматизирован и может легко быть улучшен модификацией скрипта. Во-вторых, использование внешнего накопителя, такого как дискета, позволяет выводить собранную информацию на саму дискету, не затрагивая возможные улики на жестком диске системы. Следует только убедиться, что на дискете достаточно свободного места для выходной информации. В третьих, автоматизируя процесс, ответственный за устранение инцидента имеет меньше шансов совершить ошибку, такую как опечатка в наборе команды или ввод неправильных ключей в аргументах команды.
Другой метод получения информации с системы без записи ее на жесткий диск состоит в перенаправлении ее на другой компьютер через сеть. Одна из наиболее популярных программ, представляющих такую возможность – это Netcat, на которую часто ссылаются профессионалы безопасности. Использование Netcat на Solaris и Linux системах было популярно для выполнения таких задач, как создание образа диска по сети. Версия Netcat под Win32 хорошо работает под Win2k, и может использоваться для получения данных с систем.
Процесс использования Netcat начинается с установки прослушивания на экспертном (forensics) компьютере:
Эта команда открывает порт, и перенаправляет всю информацию, полученную через этот порт, в файл, названный "forensics.data". Для примера IP адрес экспертного компьютера примем за 10.1.1.6.
После установки прослушивания, ответственный за устранение инцидентов может вставить свою дискету со скриптом в «потерпевшую» систему. Этот скрипт уже должен содержать строки, которые отсылают выходные данные на удаленную систему вместо файла на дискете. Эти строки выглядят примерно так:
Если исследователь допускает наличие в сети сниффера, он может предпочесть не передавать данные через сеть в виде текста, а использовать шифрующую версию netcat, названную Cryptcat. Cryptcat – это netcat с добавленным шифрованием TwoFish, и может использоваться так же, как и Netcat (не забудьте использовать ключ «–k» для задания ключа шифрования).
Альтернативным методом для ответственного за устранение инцидентов может быть создание CD с утилитами и скриптами. Это позволяет записать большее количество утилит на один носитель, включая родные Win2k утилиты типа nbtstat.exe, netstat.exe, и net.exe, что обеспечивает дополнительную безопасность за счет гарантированного использования «чистых» утилит и невозможности их заражения в процессе использования.
Конечным результатом использования Netcat (или CryptCat) будет большой файл на экспертном компьютере, содержащий все собранную ответственным за устранение инцидентов информацию. Можно либо разбить на части для анализа этот большой файл, либо создавать разные файлы в процессе прослушивания потерпевшей системы, в зависимости от запускаемых на ней скриптов.
Альтернативой использованию Netcat или Cryptcat может быть разработка пакета программ, состоящего из сервера и клиентов, где весь процесс сбора и передачи информации автоматизирован. Проект такого пакета можно увидеть на Forensics Server Project
Исследователи могут сохранить большое количество времени, сил и нервов, готовясь к инцидентам заранее. Пожалуй, наиболее эффективными мерами подготовки к инцидентам являются защита хостов и сети, что поможет предотвратить возникновение инцидентов. Тем не менее, инциденты все равно случаются, и исследователи с ответственными за устранение инцидентов должны быть готовы к адекватным действиям. Есть надежда, что эта статья дала читателям информацию о некоторых шагах, требуемых для адекватной реакции на инциденты, а также некоторых доступных инструментах для выполнения этих шагов.