Если WordPress уже ведёт себя странно — редиректит на чужие сайты, показывает неизвестные ссылки, создаёт новых администраторов или хостинг прислал предупреждение о вредоносном коде, — это не тот случай, когда достаточно «поставить плагин безопасности» и надеяться на лучшее. Сначала нужно остановить распространение проблемы, потом найти источник заражения, очистить сайт и только после этого возвращать его в работу.
Ниже — практический порядок действий. Он подходит и для небольшого сайта, и для интернет-магазина, и для проекта с несколькими редакторами. Разница будет в том, насколько жёстко можно ограничить доступ на время восстановления.
Сначала изолируйте сайт, чтобы не усугубить инцидент
Главная задача на этом этапе — не дать вредоносному коду продолжать рассылку спама, подменять контент, воровать данные или заражать другие сайты на том же хостинге. Если сайт уже под атакой, любая задержка работает против вас.
Что сделать в первую очередь:
- включить режим обслуживания, если он не мешает диагностике;
- временно закрыть публичный доступ к админке по IP, если это возможно на уровне хостинга или веб-сервера;
- при серьёзном заражении поставить сайт за техническую заглушку или временно ограничить доступ через пароль на уровне хостинга;
- если есть признаки компрометации учётных записей, сразу отключить доступ всем, кроме тех, кто участвует в восстановлении.
Если сайт на общем хостинге и рядом лежат другие проекты, сообщите хостеру об инциденте. Это важно не только для вас: заражение часто распространяется через общие права на файлы, украденные FTP-доступы или слабые пароли.
На этом этапе не удаляйте всё подряд. Когда владелец в панике стирает тему, плагины и логи, потом сложнее понять, откуда пришёл взлом и что именно было изменено.
Проверьте, что именно сломано: симптомы, которые нельзя игнорировать
У разных взломов разные следы. Иногда это очевидный редирект, иногда — тихая подмена файлов, которая проявляется только в поиске или в панели администратора.
Ищите такие признаки:
- неизвестные администраторы в разделе Пользователи;
- новые записи, страницы или виджеты с чужими ссылками;
- редиректы только для гостей или только с мобильных устройств;
- непонятные файлы в
wp-content/uploads,wp-includes, корне сайта или рядом сwp-config.php; - изменения в теме, которые вы не вносили;
- подозрительные задачи в cron, если у вас есть доступ к серверу;
- предупреждение от хостинга, антивируса или Google Search Console о вредоносном коде.
Если у вас есть доступ к панели WordPress, проверьте список пользователей и дату последних изменений. Если доступа нет или админка ведёт себя странно, ориентируйтесь на файловую систему, базу данных и отчёты хостинга.
Полезно сразу понять масштаб: взломан только сам WordPress, заражена тема, подменены файлы ядра, или проблема уже затронула базу данных и учётные записи. От этого зависит, можно ли обойтись очисткой отдельных файлов или придётся восстанавливать сайт из чистой резервной копии.
Сделайте копию текущего состояния перед очисткой
Перед любыми изменениями сохраните текущие файлы и базу данных. Да, сайт уже заражён, но эта копия нужна как доказательство и как страховка, если в процессе очистки вы удалите лишнее или поймёте, что часть проблемы осталась.
Сохранять нужно именно текущее состояние, а не только «последнюю хорошую» резервную копию. Хорошая копия пригодится для восстановления, а текущая — для анализа.
Если вы работаете через хостинг-панель, обычно достаточно создать архив файлов и экспорт базы данных. Если есть SSH и вы понимаете, что делаете, можно снять копию и отложить её в отдельное место. Но не храните заражённый архив рядом с рабочим сайтом без необходимости.
Если у вас есть только одна резервная копия и она сделана уже после заражения, не считайте её безопасной. Восстановление из такой копии вернёт проблему обратно.
Очистите сайт: файлы, темы, плагины и базу данных
Очистка — это не «удалить подозрительный файл». Взлом часто оставляет несколько точек закрепления: изменённый файл ядра, скрытый код в теме, вредоносный фрагмент в базе данных и новый пользователь-администратор. Если убрать только один элемент, сайт может снова заразиться через оставшиеся.
Проверьте ядро WordPress
Сначала сравните файлы ядра с официальной версией той же ветки WordPress. В норме в корне не должно быть лишних PHP-файлов, а стандартные файлы ядра не должны содержать чужой код. Если вы не уверены, проще и безопаснее заменить ядро чистой копией WordPress той же версии или обновить его до актуальной стабильной версии после резервного копирования.
Особое внимание — файлам в корне, а также wp-includes и wp-admin. Вредоносные вставки там часто маскируются под системные функции.
Проверьте темы и плагины
Если заражение сидит в теме или плагине, переустановка из официального источника обычно надёжнее, чем ручная правка. Сначала удалите компонент, затем поставьте чистую копию. Это особенно важно для тем и плагинов из сомнительных источников, включая nulled-сборки: они часто и становятся точкой входа.
Если сайт использует кастомную тему, не стирайте её без копии. Сначала сохраните изменения, затем ищите подозрительные вставки в functions.php, шаблонах и подключаемых файлах. Типичный признак — длинные закодированные строки, вызовы eval(), base64_decode(), gzinflate() и похожие конструкции, которые вы сами не добавляли.
Проверьте базу данных
Редиректы и скрытые ссылки часто сидят не в файлах, а в базе данных: в записях, страницах, виджетах, настройках темы, опциях плагинов. Ищите чужие ссылки, вставки скриптов, неизвестные рекламные блоки и изменения в полях, которые отвечают за главную страницу, меню и футер.
Если у вас интернет-магазин или сайт с регистрацией, дополнительно проверьте пользователей, заказы, формы и письма. Иногда злоумышленник не ломает сайт «в лоб», а использует его для спама или подмены контактных данных.
Удалите лишние учётные записи и задачи
После взлома часто остаются новые администраторы, редакторы или пользователи с повышенными правами. Удаляйте только те учётные записи, которые вы не создавали и не подтверждаете. Перед удалением проверьте, не были ли на них завязаны записи или заказы.
Если у вас есть доступ к серверу, проверьте cron-задачи и автозапуск. Вредоносный код нередко закрепляется через планировщик, чтобы возвращаться после очистки файлов.
Смените все доступы, а не только пароль администратора
После очистки нельзя оставлять старые пароли и ключи. Если злоумышленник уже получил доступ к FTP, панели хостинга, базе данных или почте, он может вернуться даже после полной очистки WordPress.
Смените:
- пароли всех администраторов WordPress;
- пароли FTP/SFTP, SSH, панели хостинга и базы данных;
- пароли почтовых ящиков, через которые восстанавливаются доступы;
- ключи и соли в
wp-config.phpчерез официальный генератор WordPress; - пароли у всех пользователей с повышенными правами, если они могли быть скомпрометированы.
Если на сайте несколько сотрудников, проверьте, кто реально должен иметь доступ. Восстановление — хороший момент, чтобы убрать лишние учётные записи и перейти на принцип минимальных прав: каждому только то, что нужно для работы.
Для сайтов клиентов на общем хостинге я обычно советую ещё раз проверить, не используются ли одинаковые пароли на разных проектах. Один украденный пароль часто тянет за собой несколько сайтов.
Когда можно восстановить сайт из резервной копии, а когда лучше чистить вручную
Если у вас есть точно чистая резервная копия, сделанная до инцидента, восстановление из неё часто быстрее и надёжнее ручной чистки. Но только если вы уверены, что копия не содержит вредоносный код и не была сделана уже после заражения.
Ручная очистка нужна, когда:
- чистой копии нет;
- взлом затронул только часть сайта, а остальное нужно сохранить;
- после восстановления из бэкапа проблема возвращается;
- нужно понять источник атаки и закрыть его;
- сайт сильно кастомизирован, и откат на старую копию приведёт к потере важных данных.
Если вы восстанавливаете магазин, форум или сайт с активными заказами и регистрациями, не спешите откатывать всё без разбора. Сначала оцените, какие данные появились после точки резервной копии, чтобы не потерять заказы, заявки и новые аккаунты.
Проверьте результат до того, как открывать сайт всем посетителям
После очистки не стоит сразу считать инцидент закрытым. Сайт нужно проверить в нескольких местах: в браузере, в админке, в поиске и на стороне хостинга.
Минимальная проверка выглядит так:
- главная и внутренние страницы открываются без редиректов;
- в исходном коде нет чужих скриптов и ссылок;
- в Пользователи не осталось неизвестных администраторов;
- в папках сайта нет новых подозрительных PHP-файлов;
- хостинг больше не показывает предупреждение о вредоносном коде;
- если сайт был в поиске с предупреждением, вы видите, что проблема устранена, и можете отправить сайт на повторную проверку в инструментах для вебмастеров.
Если редиректы были только для гостей, проверьте сайт в режиме инкогнито и с мобильного устройства. Если проблема проявлялась только для авторизованных пользователей, проверьте отдельные роли.
Что сделать после восстановления, чтобы не повторить тот же сценарий
Когда сайт уже очищен и снова работает, не ограничивайтесь разовой уборкой. Взлом почти всегда показывает слабое место: устаревший плагин, слабый пароль, лишний доступ, небезопасный хостинг или отсутствие нормальных резервных копий.
Практически полезный минимум после инцидента:
- обновить WordPress, плагины и темы до актуальных версий, если это не ломает совместимость;
- удалить всё ненужное: неиспользуемые плагины, старые темы, тестовые учётные записи;
- пересмотреть права доступа к файлам и папкам на сервере;
- включить регулярные резервные копии и проверить, что они действительно восстанавливаются;
- ограничить число администраторов и использовать уникальные пароли с двухфакторной аутентификацией там, где это возможно;
- проверить, не использовались ли сомнительные темы и плагины из неофициальных источников.
Если вам нужно быстро убрать лишние служебные элементы WordPress и сократить поверхность атаки без ручной правки кода, можно посмотреть Clearfy. Но важно понимать границу: такой плагин помогает навести порядок в настройках и отключить ненужные функции, а не лечит уже заражённый сайт. Для очистки после взлома всё равно нужны проверка файлов, базы данных и доступов.
Если инцидент затронул не только WordPress, а ещё хостинг, почту или соседние сайты на сервере, лучше подключать специалиста по безопасности или техподдержку хостинга. На этом уровне проблема уже выходит за рамки обычной настройки WordPress.
Самый надёжный порядок здесь простой: изолировать сайт, зафиксировать состояние, найти все точки заражения, очистить их, сменить доступы и только потом возвращать проект в работу. Если пропустить хотя бы один шаг, взлом часто возвращается через несколько часов или дней.