Восстановление взломанного WordPress: практический чек-лист на случай инцидента

Локализуйте инцидент до очистки

Неожиданные перенаправления, неизвестные учётные записи администраторов или результаты поиска со спамом могут указывать на взлом. Чистое сканирование плагином его не исключает. Точно так же один симптом не доказывает наличие конкретного бэкдора или техники атаки. Выясните, что сервер на самом деле отдаёт разным сессиям и устройствам.

Сначала защитите посетителей. Ограничьте доступ или временно отключите затронутые функции, если возможна выдача вредоносного контента или перехват платежей. Обещать нулевой простой неразумно, когда работающий скомпрометированный сервис может подвергнуть риску ещё больше людей.

Сохраните доказательства и определите масштаб

1. Сохраните в защищённом месте датированную копию файлов, базы данных и доступных журналов доступа, ошибок и аутентификации. Запишите текущий часовой пояс и все вносимые изменения.
2. Составьте перечень доменов, аккаунтов хостинга, установок WordPress, администраторов, плагинов и учётных данных для деплоя, у которых есть общий доступ.
3. Ищите неожиданные изменения в файлах ядра, must-use-плагинах, загрузках, запланированных задачах, конфигурации сервера и опциях базы данных.
4. Определите самую раннюю известную подозрительную активность, прежде чем выбирать резервную копию. Свежая копия уже может содержать следы взлома.

Проверяйте целостность из доверенной среды

Контрольные суммы WP-CLI помогают найти отличия от официальных пакетов. Используйте доверенные инструменты на копии или в контролируемой среде. Некоторые команды могут загружать код сайта, а скомпрометированная установка не является надёжной средой выполнения.

wp core verify-checksums --include-root
wp plugin verify-checksums --all --strict

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

Восстановите сайт и закройте точку входа

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

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

Проверьте восстановление перед повторным открытием

• Протестируйте страницы, формы, вход и процесс покупки из чистых сессий.
• Ищите неожиданные исходящие запросы, изменённые файлы и повторно появляющиеся запланированные задачи.
• Убедитесь, что резервную копию действительно можно восстановить в изолированной среде.
• Изучите проблемы безопасности в Search Console и запрашивайте проверку только после устранения указанной проблемы. Сроки проверки определяет провайдер.

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

Источники и дополнительное чтение

• WordPress: усиление защиты WordPress
• WP-CLI: проверка контрольных сумм ядра
• Google: отчёт о проблемах безопасности

Читайте дальше

Если нужна практическая помощь, посмотрите восстановление WordPress после вредоносного кода. После восстановления проверьте сканируемость сайта и его представление в поиске.