Восстанавливаем сервер после взлома

Итак, рассмотрим на примере сервера, который был взломан путем закачки эксплоита через ошибку в php скрипте, запуск через него же и получение доступа к shell с правами веб-сервера. Об этом красноречиво свидетельствуют "следы" в директориях, доступных на запись для всех: /tmp, /var/tmp, /dev/shm.

[ad#ad-5]

Взлома можно было бы избежать на этом этапе, примонтировав разделы для временных файлов без права запуска, отключением опасных функций php и просто более тщательным кодом в php. Однако ничего этого сделано не было.
Хакер не терял времени даром. Он закачал разнообразные эксплоиты, скомпилировал их и после запуска получил права суперпользователя root, воспользовавшись одной из уязвимостей.
И на этом моменте можно было бы его остановить, отключив wget и компиляторы для непривилегированных пользователей и поставив патч, запрещающий выполнение кода в стеке или libsafe. Но, увы, и это не было сделано.
Ситуация была неоднозначной. С одной стороны - очень важные данные, потеря которых критична, с другой стороны - проблема backdor, когда хакер мог бы зайти с помощью какого-то пользователя или выслав определенный набор пакетов демону, слушающему порт. Было принято решение о восстановлении сервера и дальнейшем тщательным наблюдении за ним.
Отключив ряд процессов, которые явно носили в себе нечто чуждое системе, первым делом был установлен, обновлен и запущен rkhunter - утилита для отлова троянов.
Вывод rkhunter был неутешительный - минимум два руткита, масса измененных бинарников.
В такой ситуации поможет только одно - замена зараженного руткитом бинарника на чистый. Однако необходимо знать, какие именно бинарники заменять. Но тут немного повезло. Хакер поставил на измененные файлы атрибуты, запрещающие изменение, удаление или замену файла при помощи команды chatter. Для неофитов, знакомых только с chmod, это создало бы эффект контроля над системой со стороны хакера - зараженные бинарники не переписываются, хотя права на запись стоят.
Создав список зараженных бинарников, все атрибуты удалось восстановить командами

chattr -iacsuASDd /bin/*
chattr -iacsuASDd /sin/*
chattr -iacsuASDd /sbin/*
chattr -iacsuASDd /usr/sbin/*
chattr -iacsuASDd /usr/bin/*
chattr -iacsuASDd /usr/local/bin/*
chattr -iacsuASDd /usr/local/sbin/*

Однако ряд бинарников, которые не были защищены от изменения, все-таки были заражены. Это показал rkhunter. Таким образом, стало ясно, что это неординарный взломщик, который специально оставил взломанные файлы с целью их восстановления. Соответственно, в системе установлен backdor.
Также не работал ряд команд, хотя rkhunter этого не показал. Например, top не выводил ряд присутствующих в системе процессов. По всей видимости, заражение было на уровне модуля ядра, что обеспечивало стелс-защиту зараженных бинарников.
Однако хакер не предусмотрел, что в rpm-based дистрибутивах Linux есть возможность узнать, был ли изменен файл или нет при помощи rpm.
Методика достаточно проста - сначала узнаем, где расположен подозрительный бинарник, например:

which top

Эта команда выдаст полный путь к утилите top - /usr/bin/top. Теперь с помощью rpm узнаем, к какому пакету относится данный файл:

rpm -qf /usr/bin/top

Эта команда сообщит, что утилита top входит в пакет procps. Переустановим его с помощью менеджера apt командой:

apt-get --reinstall install procps

Во время установки было сообщение, что предыдущий top был слинкован с библиотекой /lib/libext-2.so.7. Возможно, это и есть часть стелс-механизма. Запросив с помощью rpm информацию об библиотеке

rpm -qf /lib/libext-2.so.7

была получена информация, что данный файл не является частью системы. Естественно, что он был удален:

chattr -iacsuASDd /lib/*
rm /lib/libext-2.so.7

Далее обнаружилось несколько скрытых процессов, которые были убиты с помощью утилиты killall.
Естественно, что переустановить пришлось не только procps, но и ряд других пакетов, подозреваемых во взломе: util-linux, psmisc, net-tools, kernel, dev, initscripts и многие другие.
После замены ядра сервер был перезагружен и была проведена проверка изменения всех файлов с помощью команды

rpm -Va

Были замечены косвенные признаки наличия в системе backdor. После небольшого исследования системы бэкдор был обнаружен. Также было обнаружено, что у всех системных пользователей сменена оболочка на /bin/sh. Таким образом, это позволяло обратиться к backdor от имени любого пользователя. Для избегания такой ситуации был отключен ряд нежелательных сервисов и создан новый пользователь, который может заходить по сети в оболочку через ssh. Все остальные были отключены.
В настоящее время не замечено никаких попыток несанкционированного доступа, что свидетельствует о весьма высоком уровне взломщика и нежелании его засветиться.

Данная история описана с согласия владельца взломанного сервера. По его словам, все что он сделал, это добавил поддержку php в apache. О том, к каким последствиям это может привести, он даже и не подозревал.

Будьте бдительны! Во время летних каникул происходит очень много взломов. Защищайте свой выделенный сервер до того, как его взломают. Предотвращайте взлом на разных уровнях. И главное - периодически проверяйте содержимое каталогов для временных файлов. Возможно, что там уже что-то есть.

Особенно остерегайтесь файлов, начинающихся с точки или состоящих из одних пробелов, - это прямое свидетельство успешного взлома.