Если сайт взломали — не начинайте с удаления файлов
Сначала сохраните копию текущих файлов, базы и логов. Даже заражённое состояние полезно: по времени изменения, логам и отличиям от чистой версии можно понять, как злоумышленник вернулся на сайт.
Цель восстановления: не «сделать главную снова красивой», а убрать вредоносные изменения и закрыть путь, через который они появились.
Что делать в первые часы
| Шаг | Действие | Зачем |
|---|---|---|
| 1 | Ограничить доступ к сайту/админке | Остановить новые изменения |
| 2 | ||
| ранить файлы, БД и логи | Не потерять следы | |
| 3 | Сравнить с чистым backup/Git | Найти изменённые файлы |
| 4 | Проверить аккаунты и доступы | |
| администраторов | ||
| 5 | ||
| ода | Не допустить повторного заражения | |
| 6 | Восстановить чистую версию | Вернуть проект в работу |
| 7 | Сменить секреты и проверить снова | Закрыть украденные доступы |
Найти недавно изменённые PHP-файлы
find /path/to/site -type f -name '*.php' -mtime -14 -printf '%TY-%Tm-%Td %TH:%TM %p\n' 2>/dev/null | sort -r | head -n 200Проверка ClamAV без автоматического удаления
clamscan --recursive --infected --log=clamav-site-scan.log /path/to/site
# Сначала анализируйте результат.
# Не используйте --remove как первый шаг.Почему нельзя просто восстановить backup
Если резервная копия была сделана после проникновения или уязвимый плагин остался активным, сайт может заразиться повторно. После восстановления проверьте CMS/ядро, дополнения, пользовательские аккаунты, cron-задачи, SSH/FTP-ключи, панель хостинга и исходящие подключения.
От чего зависит стоимость восстановления
Цена определяется не количеством «вирусных файлов», а временем на локализацию причины и объёмом безопасного восстановления.
Факторы, которые сильнее всего влияют на объём работ
| Фактор | Быстрее | Дольше |
|---|---|---|
| Есть чистый backup/Git | Да | Нет |
| Один сайт на аккаунте | Да | Несколько проектов заражены |
| Есть SSH и логи | Да | Только файловый менеджер |
| CMS и плагины обновляемы | Да | Старый/самописный код |
| Известно время взлома | Да | Неизвестно |
| Повторное заражение | Нет | |
| ода |
Что проверить после восстановления
- новые администраторы и API-ключи;
- cron/systemd tasks;
- неожиданные PHP-файлы в uploads/cache/tmp;
- изменения в .htaccess/Nginx rules;
- пароли панели, SSH, FTP/SFTP, БД и CMS;
- логи входа и запросов после публикации чистой версии.
Пароли и ключи лучше менять после подготовки чистой среды, чтобы новые секреты не оказались снова доступны заражённому коду.