Коротко. Изолируйте сайт: включите режим обслуживания и отрежьте злоумышленнику доступ. Смените все пароли — хостинг, SSH, база данных, CMS. Сохраните логи и снапшот до любой чистки. Найдите точку входа и заражённые файлы, восстановитесь из чистого бэкапа, закройте уязвимость. Ниже — план по минутам.
Хаотичные действия вредят сильнее самого взлома: файлы, удалённые «на всякий случай», уносят следы точки входа. Если сайт просто лёг под трафиком, а файлы не тронуты, это не взлом — план в статье «DDoS-атака: что делать в первый час».
Как понять, что сайт взломали
| Признак | Что означает | Как проверить |
|---|---|---|
| Редиректы на чужие сайты | В код внедрён вредоносный JavaScript | Инкогнито-режим и телефон; проверка на вирусы |
| Новые администраторы | Злоумышленник закрепился в CMS | Список пользователей в админке |
| Изменённые или новые файлы | Веб-шелл или инъекция кода | find по дате; сверка с репозиторием |
| Рассылка спама с домена | Взломан почтовый скрипт или сервер | Очередь почты, отчёты DMARC, чёрные списки |
| Пометка в браузере или поиске | Сайт признан опасным | Панели вебмастеров |
| Всплеск исходящего трафика | Спам, атаки или слив данных | Графики у хостера; ss, netstat |
| Посторонние процессы и cron | Вредонос переустанавливает себя | crontab -l, ps aux |
Разбор признаков — в статье о проверке сайта на вирусы; внешний осмотр дают сканер вредоносного кода и сканер безопасности.
Первые 60 минут: пошаговый план
0–10 минут: изолировать сайт
Включите режим обслуживания или закройте сайт в панели хостинга, отдавайте заглушку с кодом 503, ограничьте админку и SSH своим IP. Нельзя удалять файлы, чистить логи и переустанавливать CMS — уничтожите улики, по которым будете искать точку входа.
Не затирайте взломанный сайт сразу: сначала копия логов и снапшот файлов. Пропустите шаг — не найдёте точку входа, и вас взломают снова тем же способом.
10–20 минут: сменить все доступы
Считайте скомпрометированным всё: панель хостинга, SSH, базу данных, админов CMS, FTP, API-ключи. Меняйте разом, начиная с панели хостинга. Затем уберите лишнее: посторонних админов, незнакомые ключи в ~/.ssh/authorized_keys, новых пользователей БД, свежие токены.
20–30 минут: зафиксировать улики
Снимите состояние системы: снапшот сервера или архив сайта с датами файлов, копия логов веб-сервера, журнала авторизаций и FTP за две-четыре недели — вне досягаемости злоумышленника. По логам вы восстановите, когда атакующий пришёл и что успел сделать.
30–45 минут: найти точку входа и заражение
Сначала — файлы за последние дни:
# файлы, изменённые за последние 3 суток find /var/www -type f -mtime -3 -not -path "*/cache/*" -ls
Типовые сигнатуры веб-шеллов в PHP-файлах:
# поиск веб-шеллов по характерным конструкциям
grep -rn --include="*.php" -e "base64_decode" -e "eval(" -e "gzinflate" /var/www
Планировщик — вредонос часто прописывает задание-реаниматор:
# cron текущего пользователя и системные задания crontab -l ls -la /etc/cron.d/ /etc/cron.hourly/
И последние входы на сервер:
# история логинов и успешные SSH-авторизации last -a | head -20 grep "Accepted" /var/log/auth.log | tail -20
Первый запрос к веб-шеллу в логах обычно и есть точка входа: уязвимый плагин, форма загрузки или подобранный пароль.
45–60 минут: чистка или откат
Есть бэкап заведомо до взлома и известна дата компрометации — откатывайтесь: быстрее и надёжнее ручной чистки. Нет — вычищайте вручную: веб-шеллы, изменённые файлы ядра, код в базе.
Откат из бэкапа без закрытия дыры — пауза, а не решение: уязвимость осталась и в копии, повторный взлом — вопрос пары дней.
Как сайт взламывают чаще всего
Уязвимые плагины и темы CMS. Самый массовый вектор: известную дыру в популярном плагине боты эксплуатируют через часы после публикации. Сюда же — «nulled»-темы с закладками.
Слабые пароли и отсутствие 2FA. Перебор паролей к админке и SSH идёт круглосуточно; пароль из утёкшей базы или «admin123» подбирается за минуты.
Устаревшее ПО. Старое ядро CMS, PHP без патчей, забытые библиотеки: сканеры ботнетов методично обходят весь интернет.
Заражённый компьютер разработчика. Стилеры крадут пароли FTP и SSH — сайт «взламывают» валидными учётными данными.
SQL-инъекции и свой код. Самописные формы без параметризованных запросов и валидации: реже плагинов, но тяжелее — вплоть до слива базы.
Восстановление и защита после
Не открывайте сайт сразу — сначала перенесите фиксы в восстановленную копию. Обновите всё: ядро CMS, плагины, темы, PHP; лишние плагины удалите. Смените ключи и соли CMS (wp-config.php в WordPress): сессии злоумышленника станут недействительными. Перевыпустите SSL-сертификат, если ключ был на сервере, — конфигурацию проверит проверка SSL.
Проверьте сайт снаружи через сканер вредоносного кода и сканер безопасности: второй покажет недостающие security-заголовки — разбор в гиде по security-заголовкам.
Помеченный как опасный сайт отправьте на пересмотр в Google Search Console и Яндекс Вебмастере и проверьте, что домен не попал в базы мошеннических ресурсов — детали в статье о проверке сайта на мошенничество.
Первые недели атакующий будет возвращаться проверить, закрыта ли дыра. Постоянный мониторинг аптайма, SSL и вредоносного кода — разумный минимум; как это устроено — на странице тарифов.
Если утекли персональные данные
Если к персональным данным пользователей мог быть доступ, оператор обязан уведомить Роскомнадзор: по действующим требованиям 152-ФЗ первичное уведомление — в течение 24 часов, результаты расследования — в течение 72 часов. Молчание рискованнее заявленной утечки. Готовность сайта к требованиям закона разбирает статья о проверке на соответствие 152-ФЗ.
Частые вопросы
Можно ли просто удалить вирус и работать дальше?
Нет: пока точка входа открыта, заражение вернётся, часто в тот же день. У вредоноса почти всегда есть дубли — второй шелл, задание cron, код в базе.
Через сколько сайт вернётся в поиск после пометки об угрозе?
Google снимает пометку Safe Browsing за один-три дня после запроса, Яндекс — в сопоставимые сроки, если сайт чист. Позиции восстанавливаются от недели до месяца.
Нужно ли сообщать пользователям?
Если могли пострадать их данные — да, и чем раньше, тем лучше: честное уведомление со сменой паролей дешевле для репутации, чем браузерное предупреждение. Платёжные данные — уведомите и провайдера.
Как понять, что дыра закрыта?
Вы нашли в логах запрос, через который вошли, и устранили причину: обновили компонент, сменили пароль. Не нашли — считайте дыру открытой и следите за изменениями файлов.
Что делать, если чистого бэкапа нет?
Чистить вручную: дистрибутив CMS поверх ядра, ревизия каталогов загрузок, поиск кода в базе. И сразу настройте бэкапы с хранением вне сервера.
Чеклист: первый час после взлома
- Включить режим обслуживания и закрыть сайт от посетителей
- Ограничить админку и SSH своим IP-адресом
- Сменить пароли: хостинг, SSH, БД, CMS, FTP, API-ключи
- Удалить посторонних админов и незнакомые SSH-ключи
- Снять снапшот и скопировать логи в надёжное место
- Найти изменённые файлы и веб-шеллы (find, grep)
- Проверить cron, процессы и историю входов
- Определить точку входа по логам веб-сервера
- Откатиться на чистый бэкап или вычистить заражение
- Закрыть уязвимость, обновить всё и включить мониторинг