Защита WordPress от взлома: 12 шагов

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

Откуда приходят взломы

По данным разборов взломанных сайтов, которые публикуют компании вроде Sucuri и Patchstack, подавляющее большинство заражений WordPress происходит через уязвимые плагины и темы, а не через ядро. Оставшееся — слабые пароли, украденные доступы и дырявый хостинг. Из этого следует стратегия: обновляться, ставить меньше кода, усложнить вход.

Шаг 1. Обновляйте всё — и включите автообновления

Уязвимость в популярном плагине начинают эксплуатировать в течение часов после публикации. Окно «обновлюсь на выходных» — это окно для бота.

• Ядро: минорные обновления безопасности ставятся автоматически — не отключайте это.
• Плагины и темы: включите автообновления хотя бы для критичных («Плагины → Автообновления»).
• Неиспользуемое — удаляйте, а не деактивируйте: файлы отключённого плагина остаются на сервере и уязвимость в них рабочая.

Шаг 2. Сильные пароли и никакого логина admin

Логин admin боты пробуют первым. Если он у вас — создайте нового администратора с другим именем, зайдите под ним и удалите старого (контент можно передать новому пользователю при удалении).

Пароль — от 16 символов, сгенерированный, уникальный. WordPress сам предлагает сильные пароли — не заменяйте их на «Vasya2026!». И отдельное правило: у каждого человека — своя учётка с минимально нужной ролью. Автору статей не нужна роль администратора.

Шаг 3. Двухфакторная аутентификация

Даже украденный пароль бесполезен, если вход подтверждается кодом из приложения. Бесплатные варианты: плагин Two-Factor (разрабатывается участниками core-команды WordPress), модули двухфакторки в Wordfence и Solid Security. Включите 2FA как минимум всем администраторам.

Шаг 4. Лимит попыток входа

Из коробки WordPress позволяет перебирать пароли бесконечно. Плагин Limit Login Attempts Reloaded (или аналогичный модуль в плагине безопасности) блокирует IP после нескольких неудачных попыток. Это самый дешёвый способ обесценить брутфорс.

Шаг 5. Защитите wp-login.php дополнительно

Смена адреса входа (плагин WPS Hide Login) убирает шум ботов, но главный приём — второй слой авторизации на уровне сервера. Для Apache — базовая HTTP-авторизация на wp-login.php:

<Files wp-login.php>
    AuthType Basic
    AuthName "Restricted"
    AuthUserFile /home/user/.htpasswd
    Require valid-user
</Files>

Бот, который не прошёл HTTP-авторизацию, даже не доберётся до формы WordPress. Если админов мало и IP статичные — ещё проще: разрешить доступ только со своих адресов.

Шаг 6. Отключите XML-RPC, если им не пользуетесь

Файл xmlrpc.php — легаси-интерфейс, через который удобно и брутфорсить (метод system.multicall позволяет проверить сотни паролей одним запросом), и организовывать DDoS через pingback. Если вы не используете старые мобильные приложения и Jetpack — отключайте: плагином безопасности или на уровне сервера:

<Files xmlrpc.php>
    Require all denied
</Files>

Современный REST API при этом продолжает работать — на нём держится админка и блочный редактор.

Шаг 7. Закройте редактирование файлов из админки

По умолчанию администратор может править код тем и плагинов прямо в браузере. Для взломщика, получившего доступ к админке, это готовый шелл. Отключается одной строкой в wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

Шаг 8. Права на файлы и защита wp-config.php

Базовые права: папки — 755, файлы — 644, wp-config.php — 600 или 640. Никаких 777 — если инструкция к плагину требует 777, ищите другой плагин.

Дополнительно закройте wp-config.php от прямых запросов (Apache):

<Files wp-config.php>
    Require all denied
</Files>

И запретите исполнение PHP в папке загрузок wp-content/uploads — туда чаще всего заливают бэкдоры:

<Directory "/path/to/wp-content/uploads">
    <FilesMatch "\.php$">
        Require all denied
    </FilesMatch>
</Directory>

Шаг 9. Смените секретные ключи и следите за сессиями

Секретные ключи в wp-config.php подписывают куки авторизации. Если сайт когда-либо ломали или доступы утекали — сгенерируйте новые на api.wordpress.org/secret-key/1.1/salt и замените блок в конфиге. Все активные сессии сбросятся, включая сессии взломщика.

Шаг 10. HTTPS везде

Бесплатный сертификат Let's Encrypt выпускается в панели любого нормального хостинга. После выпуска укажите https-адрес в «Настройки → Общие» и настройте редирект с http. Без HTTPS пароль администратора летит по сети открытым текстом — в кафе с публичным Wi-Fi этого достаточно для взлома.

Шаг 11. Сканер и файрвол

Плагин безопасности — Wordfence или Solid Security — даёт файрвол против известных атак и сканер изменённых файлов: он сравнит файлы ядра с эталоном с wordpress.org и покажет, что подменено. Подробнее о выборе — в подборке базовых плагинов.

Если хостинг предлагает WAF на своей стороне (или вы за Cloudflare) — включите: фильтрация до PHP всегда дешевле фильтрации плагином.

Шаг 12. Бэкапы — ваша последняя линия обороны

Все предыдущие шаги снижают вероятность взлома. Бэкап — единственное, что гарантирует восстановление после него. Правила:

• копии делаются автоматически по расписанию (база — ежедневно, файлы — минимум еженедельно);
• хранятся вне хостинга: Google Drive, S3, Dropbox — если хостинг заблокируют, копии останутся;
• глубина хранения — от 30 дней: заражение часто замечают не сразу, и вчерашняя копия может быть уже заражённой;
• восстановление проверено руками хотя бы раз.

Если сайт уже взломали: план действий

Не паникуйте и не сносите всё сразу — сначала зафиксируйте, потом чистите.

Симптом	Первое действие
Чужие заголовки/иероглифы в выдаче поиска	Проверить сайт из режима инкогнито и как Googlebot; искать код в базе (wp_posts) и в файлах темы
Редирект посетителей на чужой сайт	Проверить .htaccess, wp-config.php, index.php и заголовок темы на посторонний код
Неизвестный администратор в «Пользователи»	Удалить, сменить все пароли, сбросить секретные ключи (шаг 9)
Хостинг прислал письмо о вредоносных файлах	Запросить список файлов у хостинга, сверить с отчётом сканера
Письма с сайта улетают в спам, жалобы на рассылку	Искать PHP-файлы в uploads, проверить очередь почты на сервере

Порядок восстановления:

1. Закройте вход: смените пароли (WordPress, база данных, FTP/SSH, панель хостинга), сбросьте секретные ключи.
2. Сделайте копию заражённого сайта — она понадобится для анализа, как взломщик вошёл.
3. Восстановитесь из чистого бэкапа или переустановите ядро/плагины из официальных источников поверх, вычистив лишние файлы.
4. Найдите точку входа: устаревший плагин, слабый пароль, соседний заражённый сайт на том же аккаунте хостинга. Иначе взлом повторится через неделю.
5. Обновите всё и пройдите 12 шагов заново.
6. Если сайт помечен в поиске как опасный — запросите перепроверку в Google Search Console и Яндекс Вебмастере.

Официальная инструкция WordPress на этот случай — developer.wordpress.org/advanced-administration/security/hacked.

Шпаргалка: 12 шагов одним списком

1. Автообновления ядра, плагинов, тем; лишнее — удалить.
2. Уникальные пароли 16+, логина admin не существует.
3. Двухфакторка для всех администраторов.
4. Лимит попыток входа.
5. HTTP-авторизация или ограничение по IP на wp-login.php.
6. XML-RPC отключён.
7. DISALLOW_FILE_EDIT в wp-config.php.
8. Права 755/644, wp-config закрыт, PHP в uploads запрещён.
9. Свежие секретные ключи.
10. HTTPS с редиректом.
11. Файрвол и сканер файлов.
12. Автобэкапы вне хостинга, восстановление проверено.

Первые четыре шага закрывают самый массовый вектор — перебор паролей — и делаются за вечер. Остальные восемь займут ещё пару часов.

Отдельно про хостинг: часть мер зависит не от вас. Если на одном аккаунте виртуального хостинга живут несколько сайтов без изоляции друг от друга, заражение одного означает заражение всех — держите чужие и заброшенные сайты на отдельных аккаунтах. И раз в месяц заглядывайте в «Инструменты → Здоровье сайта» и в журнал доступа на хостинге: всплеск POST-запросов к wp-login.php или xmlrpc.php виден там задолго до последствий. Дешевле потратить эти часы сейчас, чем потом выяснять, почему сайт рассылает спам, а хостинг грозит блокировкой. И помните: бэкапы (шаг 12) пригодятся не только при взломе — например, при переносе сайта на другой хостинг они же становятся транспортом.