Сайт взломали: технический чек-лист очистки и восстановления

После взлома сайта часто хочется быстро удалить найденный вредоносный файл и вернуть проект в работу. Это понятно, но недостаточно. Если не найти входную точку, злоумышленник вернётся через тот же пароль, старый плагин, открытый upload, cron или оставленный web shell.

Восстановление после взлома — это не только очистка файлов. Это расследование, закрытие причины и контроль повторного заражения.

Сначала зафиксировать состояние

Перед массовой чисткой полезно сохранить копию подозрительных файлов и логов. Это поможет понять, как произошёл взлом.

• архив подозрительных файлов;
• access.log и error.log;
• список изменённых файлов;
• список пользователей админки;
• cron-задачи;
• текущие процессы.

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

Найти изменённые файлы

Посмотреть недавно изменённые PHP-файлы:

find /var/www/site.ru -name "*.php" -mtime -7 -exec ls -lh {} \;

Подозрительны PHP-файлы в uploads, cache, tmp, images и других директориях, куда обычно загружаются не скрипты.

find /var/www/site.ru/web/uploads -name "*.php" -exec ls -lh {} \;

Типовые признаки web shell

Вредоносный код часто использует eval, base64_decode, gzinflate, shell_exec, system, passthru, assert. Но эти функции могут встречаться и в легальном коде, поэтому поиск — только первый шаг.

grep -R "base64_decode" -n /var/www/site.ru
grep -R "shell_exec" -n /var/www/site.ru
grep -R "eval(" -n /var/www/site.ru

Особенно внимательно нужно смотреть файлы с бессмысленными именами и свежей датой изменения.

Проверить .htaccess и nginx-конфиги

Злоумышленники часто добавляют редиректы, скрытые правила или обработку PHP в неожиданных директориях. Для Apache нужно проверить .htaccess:

find /var/www/site.ru -name ".htaccess" -exec ls -lh {} \;

Для nginx — конфиги сайта и include-файлы. Не должно быть странных proxy_pass, rewrite на чужие домены или разрешения PHP в uploads.

Пользователи админки

Если сайт на CMS или фреймворке с админкой, нужно проверить пользователей:

• не появились ли новые администраторы;
• не изменились ли email у старых пользователей;
• когда был последний вход;
• есть ли слабые пароли;
• включена ли двухфакторная защита, если доступна.

Пароли администраторов после взлома лучше менять всем, кто имел доступ.

Cron и автозапуск

Вредоносный код может восстанавливаться через cron. Проверить нужно системный cron, пользовательский crontab и задачи панели хостинга.

crontab -l
ls -la /etc/cron.d
ls -la /etc/cron.hourly

Если сайт на shared-хостинге, cron может быть настроен в панели.

Логи доступа

По access.log можно найти, какой файл вызывали перед появлением подозрительного скрипта. Ищите POST-запросы к upload-формам, админке, старым скриптам и неизвестным PHP-файлам.

grep "POST" /var/log/nginx/access.log | tail -n 200
grep "uploads.*php" /var/log/nginx/access.log

Обновления и уязвимости

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

• запретить выполнение PHP в uploads;
• закрыть служебные файлы;
• ограничить доступ к админке;
• обновить пароли и ключи;
• проверить права файлов;
• убрать старые тестовые скрипты.

Запрет PHP в uploads

Для nginx можно запретить выполнение PHP в директории загрузок:

location ~* ^/uploads/.*\.php$ {
    deny all;
}

Конкретный путь зависит от проекта. Идея простая: пользовательские файлы не должны выполняться как код.

Чек-лист

1. Сохранить копию подозрительных файлов и логов.
2. Найти недавно изменённые PHP-файлы.
3. Проверить PHP-файлы в uploads, cache и tmp.
4. Проверить eval, base64_decode, shell_exec и похожие вызовы.
5. Проверить .htaccess, nginx-конфиги и редиректы.
6. Проверить администраторов и сменить пароли.
7. Проверить cron и автозапуск.
8. Найти подозрительные POST-запросы в access.log.
9. Закрыть входную точку и обновить уязвимые компоненты.
10. Настроить наблюдение за повторным появлением файлов.

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