Вы садитесь за машину и начинаете работать... Берете записи и регистрируете дату, а также время. И тут начинается интенсивная работа, документирование времени и деталей каждого шага,
принимаемого Вами. Следующий ваш шаг - запись на CD-ROM или дискету всех ценных данных, для обеспечения их целостности, ввиду
возможности изменений системы хакером.
Порядок внесения изменений злоумышленником является достаточно важным фактором, поэтому резервное копирование необходимо делать как можно быстрее.
Дайте знать о себе, дайте узнать все о себе
До этого вторжения вы провели много времени, используя вашу систему. Вы знаете ее
как изнутри, так и снаружи. Она имеет резервную копию. Вы ведете учет всех процессов (или учет системы, если Вы используете *BSD). Используете системный коллектор данных о предпринимаемых действиях
(sadc), чтобы сохранить данные о действиях в системе. Вы управляете вашими логами, но имеете достаточно, дискового пространства, чтобы не удалять их слишком часто. Вы посылаете syslog данные на безопасную машину, которая защищена против нападения. И
вот, час Х настал...
Вы получаете запрос от одного из ваших
вебмастеро, который замечает, что у сервера сети CPU занято, хотя он обычно в день обслуживает
всего несколько тысяч пользователей.
Мастеря, типа, обеспокоен. vmstat и mpstat (не доступные в *BSD) показывают, что CPU, используется одним или более пользовательскими процессами, но память и подсистемы ввода/вывода не используются. iostat также показывает, что идет активная работа с диском.
Sar (sa в *BSD) показывает, что CPU начал использоваться
предыдущей ночью в 03:17. Lastcomm показывает, что FTP клиент использовал права root несколько раз до 03:17. last не показывает время последнего использования
root. Кроме того видно, что ваш подопытный
использовал sudo, чтобы управлять привилегиями root. Есть два системных администратора, которые могли теоретически входить в систему под именем root, но
практически это маловероятно, особенно в три
часа ночи. На данном этапе, вы принимаете решение воспользоваться CD с копией всех утилит и исполняете команду top -d1. Процесс Apache использует 100% CPU.
Вы изучаете error_log Аpache, используя GNU grep и его
опции -A, -B и -C, которые позволяют определять число выводимых строк за, перед, или вокруг искомого текста. GNU grep также позволяет
использовать опцию -E для расширенных возможностей в использовании регулярных выражений. Также
вы проверяете системные отчеты. И тут вы обнаруживаете события, кажущиеся вам странными.
Вы продолжаете ваш поиск, запускаете ps -eflcyL (Sol9), ps-eflcym --headers (Deb 3.0, RH 8.0) или ps auwxhkwvl (OBSD 3.2). Вы смотрите на работу процесса apache, но кое-что
здесь находите странным. Работает apache и многократные процессы
httpd. Однако вы знаете, что httpd - фактически Аpache, потому что httpd выполняется apachectl файлом. Но даже если исполняемый файл был переименован в "apache" он должен запускать множество процессов. Хммм... кое-что здесь не так...
Вы запускаете lsof-p <pid> и находите, что процесс
Аpache использует файл, называемый john.pot. Ясно,
что вероятный преступник - взломщик пароля, называемый "John the Ripper", что объясняет активное использование CPU.
Вы решаете проверять этот так называемый apache. Для этого воспользуйтесь командой file apache. file говорит, что это - исполняемый ELF файл. Вы решаете рыть глубже и запускаете readelf-a apache. readelf подтверждает результаты,
полученные утилитой file. Od-xc apache|less показывает волшебный номер (7f454c46) ELF в начале файла. Ldd показывает, что
библиотек, используемых apache при компоновке, значительно меньше, чем
в реальном httpd:
$ ldd ./apache
libc.so.6 => /lib/libc.so.6 (0x4001f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ ldd /usr/sbin/httpd
libm.so.6 => /lib/libm.so.6 (0x7002c000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x700c4000)
libdb.so.2 => /lib/libdb.so.2 (0x70100000)
libdb2.so.2 => /lib/libdb2.so.2 (0x70120000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x70180000)
libdl.so.2 => /lib/libdl.so.2 (0x701b4000)
libc.so.6 => /lib/libc.so.6 (0x701c8000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x70000000)
Вы запускаете strings | grep -i john и видите следующее:
$ strings apache | grep -i john
/usr/share/john/password.lst
/etc/john.ini
~/john.pot
/etc/john.ini
john
John the Ripper Version 1.6 Copyright (c) 1996-98 by Solar Designer
/etc/john.ini
/etc/john.ini
/etc/john.ini
Вы решили проследить за работой процесса Apache используя strace -fp `pgrep apache` (Deb 3.0, RH 8.0), truss -fp `pgrep apache` (Sol9), или ktrace -dip <pid>(OBSD 3.2).
По используемым системным вызовам вы
можете окончательно убедится в том, что Apache
на самом деле JtR.
Теперь вы уверенны, что происходит именно подбор некоторого пароля. Поскольку никто из вас и ваших
работников не устанавливал John the Ripper, вы были успешно атакованы.
Заключение
В следующей статье, мы продолжим исследовать то, что случилось с нашим сервером используя инструменты роботы с файловой системой. Помните, лучшая подготовка к любой угрозе инцидента - предотвращение.
