Первые шаги

Можно отключить сай т, остановив веб-сервер или переведя WP в режим обслуживания, но мы пока не знаем, что искать. Если отключить невозможно, то на этом этапе можно запретить регистрацию новых пользователей и комментарии, изменить пароли администратора WP и пароли к СУБД. При наличии свежего бэкапа можем восстановить сай т, затем перей ти к анализу и заняться локализацией проблем и усилением защиты. Иначе придется чистить фай лы вручную. Как минимум можно сразу заменить фай лы WP новыми из архива, удалив предварительно старые фай лы и каталоги (кроме, естественно, каталогов тем, плагинов и upload).

Далее обновляем (если не сделали это раньше) движок, тему и плагины. Неактивные темы и плагины безоговорочно удаляем. Проверяем сами плагины. Хакер некоторые просто отключает, изменив название каталога (добавив знак подчеркивания в начало). Проверяем корректность фай лов.htaccess, их содержимое хакер может просто обнулить. Если фай л.htaccess был неправильно настроен, то к фай лам сай та можно получить доступ из поисковика: site: example.org inurl: /wp-admin/. Переименуй тему, некоторые атаки идут пакетом, когда просто подбираются уязвимости к популярным темам. Переименовав тему, мы изменим URL, а значит, такая атака ее минует.

Если до сих пор не использовалась капча, то ставь любой понравивший ся плагин. Это снизит вероятность брутфорса. Некоторые к тому же предоставляют дополнительные возможности: блокировку IP в случае неправильного ввода несколько раз, ограничение по времени ввода, белый список. Проверять на зараженность можно как изнутри при помощи инструментов, доступных в ОС, так и через внешние сервисы. Запускаем антивирусную проверку.

Кроме антивируса, можно прогнать еще сканер Linux Malware Detect и скрипт AI-Bolit. Но най дут они не все.

Первые данные от внешних сервисов уже есть. Гугл выдал подсказку, просто ищем фай лы, проверяем, дей ствительно ли они вредоносны, и удаляем. Для последующего поиска сохраняем небольшой специфический текст, который будем использовать в качестве сигнатуры. Анализ самого кода позволит получить IP, URL и другие специфические параметры, их будем искать в логах и блокировать с помощью фай рвола.

В Сети доступно множество ресурсов, проверяющих, безопасны ли сай ты. Не все они полезны. Некоторые, например, просто получают данные о вредоносности от API Яндекса и Гугла. Услугу проверки URL предлагают и производители антивирусов. Например, сканер от Dr.Web проверяет страницы и анализирует, есть ли редирект на другие сай ты. К сожалению, кроме того, что сай т заражен, и типа вируса, больше никакой полезной информации он не дал. Ресурс 2ip.ru показал, что на сай те обнаружены iframe-вставки. К сожалению, для повторной проверки он бесполезен, так как, очевидно, запоминает результат и сообщает, что сай т заражен, когда все остальные уже считают его безопасным.

Наибольшую пользу в поиске принес онлай н-сканер SiteGuarding.com, специально разработанный для поиска специфических вредоносных программ. В отчете были не только показаны проблемные ссылки, но и дана конкретика, позволяющая в дальней шем най ти этот код в фай лах при помощи grep. Проект предлагает и свой плагин WP Antivirus Site Protection, доступный из каталога плагинов WP.

В бесплатной версии он сканирует фай лы, проверяя их на наличие опасного кода, и выдает отчет по обнаруженным malware и фай лам, показавшимся подозрительным эвристическому анализатору. Правда, выданное не стопроцентно проблема, но это уже что-то. Число сканирований ограничено, но этого достаточно, чтобы решить проблемы и некоторое время контролировать ситуацию.

Полученную на SiteGuarding.com информацию о коде малвари скармливаем grep. Принцип простой: берем некий уникальный кусок (например, там указан URL сай та, на который идет редирект, или имя фай ла) и пробуем най ти этот текст в остальных фай лах веб-сай та.

Если при ручной разборке будут попадаться зараженные фай лы, то анализируем и небольшой кусок уникального текста также предлагаем grep для поиска других аналогичных фай лов. Код в фай лы сай та вставляется либо в начало, либо в конец, и он, в отличие от остального, плохо структурирован, то есть идет сплошной массой.

Это сразу бросается в глаза в любом текстовом редакторе, особенно с подсветкой кода. Но бывает, код специально отбивают за пределы видимой части экрана вправо или вниз. Можно составить небольшой скрипт, чтобы сразу вырезать кусок кода. Правда, остатки потом най ти будет сложнее. Например, в decode использована последовательность HtI9Opn…Z. Создаем такой скрипт:

Запускаем:

Най денное имя фай ла сразу проверяем на остальных подкаталогах и сай тах при помощи find.

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

Самый простой diff -aqr dir1 dir2 покажет только отличающиеся фай лы без самих изменений, полный diff -ruN > out.diff выдаст информацию в стиле patch. Внутри каталогов обнаружилось большое число лишних PHP-фай лов, некоторые называются похоже на фай лы WP или так же, но лежат в другом каталоге. Например, class-wp-*.php, wpconfig.php (с пробелом). А также всякие users.php, confg.php, about.php и случай ные имена (вроде a249yh.php, их легко заметить).

Каталог /var/spool/exim4/input был буквально забит спам-сообщениями. Количество сообщений в очереди, выведенное exim -bpc, достигало нескольких тысяч. Вывод ps aux показывал процесс sendmail, пытавший ся отправить письмо от неизвестного пользователя с доменом сай та. Чтобы не рассылать спам, SMTP-сервер лучше пока остановить. При попытке очистить командой «rm -rf /var/spool/exim/input/*» bash вываливался с ошибкой из-за большого количества фай лов. Можно использовать маску и удалять фай лы по частям, но в случае с exim проще ввести