Как обнаружить и устранить последствия взлома сайта на сервере

Самый простой способ устранить последствия взлома сайта

Делайте бекапы (резервное копирование) и, в случае заражения, восстанавливайтесь из них. Это самый простой, эффективный и надёжный способ быстро устранить последствия взлома. Если бекапов нет, то в помощь советы ниже, но после восстановления обязательно настройте регулярное резервное копирование сайта, ведь теперь весьма доходчива и очевидна ещё одна причина, зачем они нужны.

Необходимый инструментарий

• Доступ к SSH c правами root;
• Putty или Far Manager.

Примеры будут приводиться преимущественно для Debian, Ubuntu, но могут работать и в других системах.

Подготовка к устранению взлома сайта

Чтобы просканировать весь сервер, перейдите в корень сервера:

cd /

Либо в директорию с сайтами (в разных системах местоположение может отличаться):

cd /var/www

Чтобы очистить содержимое консоли, воспользуйтесь командой clear.

clear

Полезно очищать вывод данных между командами, чтобы не запутаться в результатах.

Ищем уязвимости в логах log, сжатых gzip, gz

Если сайт неожиданно получает неестественную для него нагрузку, первым делом проверьте логи ошибок на предмет доступа к необычным местам, файлам и тому подобное.
Сначала изучите логи ошибок сайта, ищите следы исполнения eval():

Эта команда сканирует логи .log:

find . -type f -name '*.log' | xargs grep "eval()'d code on line" --color

А эта — исследует запакованные в gzip логи (обычно их пакует ротатор логов):

find . -type f -name '*.gz' | xargs zgrep "eval()'d code on line" --color

Этот пункт самый важный — поиск уязвимости. Важно понять, откуда пришёл первый зловред. Если не устранить источник заражения, инцидент может повториться. Ищите первое появление в логах посторонних файлов и их инициатора.

Поиск последних изменённых файлов

Довольно часто (но не всегда) помогает поиск последних изменённых файлов:

find . -type f -name '*.php' -mtime -7

Эта команда ищет всех файлы .php, которые изменялись за последние 7 дней

find . -type f -name '*.ico' -mtime -4

А эта — файлы .ico, которые изменялись последние 4 дня.

Поиск уязвимостей в файлах php

find . -type f -name '*.php' | xargs egrep "eval\/|eval\(" --color

find . -type f -name '*.ico' | xargs egrep "eval\/|eval\(" --color

Проверяет .php и .ico файлы на наличие в них eval().

find . -type f -name '*.*' | xargs grep "@\$GLOBALS\[\$GLOBALS\[" --color

Команда ищет GLOBALS. Надёжный вариант, если что-то находит, то это бекдор.

find . -type f -name '*.*' | xargs grep "\$GLOBALS\[" --color

Ещё одна команда ищет GLOBALS. Бывают ложноположительные результаты, но изучить их стоит внимательно.

find . -type f -name '*.*' | xargs grep "@include \"" --color

Ищет инклуды. Без них бекдоров не бывает, поэтому очень пристально изучите результаты.

find . -type f -name '*.*' | xargs grep "base64_decode" --color

Команда ищет base64_decode. Ну, какой же бекдор без шифрования? Однако, часты и ложноположительные результаты.

find . -type f -name '*.*' | xargs grep "\$_COOKIE" --color

Команда ищет $_COOKIE. Не всегда информативно, так как часто срабатывает на чистых файлах, однако помогает находить самые изощрённые бекдоры.

find . -type f -name '*.*' | xargs grep "\$auth_pass" --color

Команда ищет $auth_pass. В этих переменных часто хранят пароли.

find . -type f -name '*.*' | xargs grep "IonCube_loader" --color

Бекдоры часто используют загрузчик IonCube

Как выглядит зашифрованный код инъекции

Инфицированные файлы определить легко — обфусцированный код инъекции занимает много места и отличается от обычного. Ниже пример инфицированного файла /wp-admin/load-styles.php:

Хотя, бывают и маленькие файлы-бекдоры, поэтому внимательно изучите всю выдачу и перепроверьте её несколько раз. Скажем, вот пример, когда файл .php не должен располагаться в директории загрузок WordPress:

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

Поиск уязвимостей в файлах иконок ico

То же самое сделайте для файлов .ico, бывает, бекдоры и там шифруются

find . -type f -name '*.ico' | xargs grep "\$_COOKIE" --color

find . -type f -name '*.ico' | xargs grep "base64_decode" --color

find . -type f -name '*.ico' | xargs grep "@\$GLOBALS\[\$GLOBALS\[" --color

Устранение последствий взлома сайта на WordPress

Самое простое — это восстановить сайт из бекапа (резервной копии), который заведомо не заражён. Если это невозможно, то можно воспользоваться следующей инструкцией:

1. Временно отключаем сайт;
2. Удаляем всё, кроме /wp-content/, /wp-config.php (предварительно проверьте его, лучше сканером антивируса) и остальных текстовых файлов, что вы используете;
3. Скачиваем свежий дистрибутив WordPress и распаковываем его в директорию сайта;
4. В /wp-content/ перезакачиваем все плагины, предварительно удалив старые (они наверняка заражены);
5. Сканируем все папки на наличие бекдоров. Часто файлы .php располагаются в директории загрузок /uploads/, где их быть не должно, и если таковой обнаружен, он должен насторожить;
6. Досконально проверяем файлы темы на наличие в них инъекций. Если есть возможность — перезаливаем файлы темы из старого бекапа или репозитория git, svn (как правило, на рабочих сайтах они меняются редко).