Безопасность WordPress: рабочий чек-лист на 30 минут

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

Зачем вообще защищать обычный сайт

«Кому мы нужны, у нас же не банк» — самое частое возражение от владельцев сайтов. Проблема в том, что 99% взломов WordPress — это не таргетированная атака на вас лично. Это автоматические сканеры, которые круглосуточно перебирают миллионы доменов в поисках известной уязвимости или слабого пароля. Сканеру всё равно, чей сайт: блог дачника, магазин запчастей или сайт стоматологии. Если есть дыра — её найдут и используют.

Что обычно делают со взломанным сайтом:

• Размещают скрытые страницы для SEO-спама (казино, реплики часов, дипломы) — ваш домен теряет позиции в Яндексе и Google.
• Рассылают через ваш SMTP спам — хостинг блокирует сайт и почту.
• Ставят редирект мобильных пользователей на партнёрки.
• Подменяют реквизиты для оплаты на странице «Контакты» или в форме заказа.
• Используют сервер как один из узлов ботнета для атак на чужие сайты.

Если уже поздно и сайт заражён — есть отдельный пошаговый план восстановления: «Сайт на WordPress взломали — план восстановления за один вечер». Эта статья — про то, как до этой ситуации не дойти.

Сразу важная оговорка: «100% защиты» не бывает. Цель — не сделать сайт неуязвимым (это невозможно), а поднять стоимость взлома выше, чем готов потратить автоматический сканер. На практике этого достаточно, чтобы вирусы и боты прошли мимо и нашли цель попроще.

Чек-лист на 30 минут: базовая защита

Это минимум, который закрывает 80% типовых сценариев взлома. Делается один раз, потом раз в квартал — короткая ревизия.

1. Сложный пароль администратора

Минимум 16 символов, со спецсимволами, без слов из словаря. Самый простой способ — сгенерировать через менеджер паролей (Bitwarden, KeePass, Яндекс Браузер встроенный). Запоминать его не нужно — менеджер подставит сам.

Заодно проверьте в Пользователи → Все:

• Нет ли пользователя с логином admin, administrator, root — это первые логины, которые перебирают боты. Если есть — создайте нового админа с уникальным логином, переназначьте на него все материалы старого, старого удалите.
• Все ли пользователи с правами «Администратор» вам действительно знакомы. Незнакомых — удаляйте сразу.
• Роли соответствуют задачам: контент-менеджеру не нужен «Администратор», ему хватит «Редактора».

2. Двухфакторная аутентификация для админов

Это та самая мера, которая в одиночку отсекает почти все автоматические атаки. Даже если пароль утёк — без второго фактора зайти не получится. Пошаговая настройка WP 2FA и Яндекс.Ключа — в отдельной инструкции.

Рабочие плагины:

• WP 2FA — простой, бесплатный, поддерживает Google Authenticator, Яндекс.Ключ, Authy.
• Wordfence Login Security — отдельный модуль от Wordfence, можно поставить без полного Wordfence.
• Two Factor от автоматтиковцев — минималистичный, без рекламы.

Достаточно включить для всех ролей выше «Автор». Для подписчиков и обычных покупателей — не обязательно, иначе раздражает.

3. Лимит попыток входа

Без лимита боты могут спокойно перебирать пароли месяцами. Решается одним плагином:

• Limit Login Attempts Reloaded — бесплатный, надёжный, поддерживается активно.
• WPS Limit Login — альтернатива от автора WPS Hide Login.

Разумные настройки: 4 попытки, блокировка на 20 минут, после 4 блокировок — на сутки. Учёт по IP. В whitelist добавьте свой статический IP (если есть) и IP офиса.

4. Скрыть страницу входа (опционально, но полезно)

Боты ломятся именно на /wp-login.php и /wp-admin/. Если перенести вход на нестандартный URL — большая часть атак просто упрётся в 404.

Плагин WPS Hide Login (бесплатный). Меняете URL входа на что-то вроде /moy-vhod-2026/ и сохраняете в менеджере паролей. Важно: это не защита от целевой атаки (опытный хакер найдёт страницу всё равно), но против ботов работает отлично — нагрузка на сайт от брутфорса падает в десятки раз.

5. Отключить XML-RPC, если не используете

XML-RPC — старый протокол для удалённой публикации (мобильное приложение WordPress, Jetpack, пингбэки). Если вы публикуете посты через админку или Gutenberg — XML-RPC вам не нужен, а ботам он удобен для перебора паролей пачками и DDoS-атак pingback'ами.

Способы отключения:

• Плагин Disable XML-RPC — две кнопки и готово.
• Либо в .htaccess в корне:

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

Если используете мобильное приложение WordPress или Jetpack — оставьте XML-RPC, но обязательно включите лимит попыток входа. Утечка логинов через /wp-json/wp/v2/users и связка REST + XML-RPC — отдельный разбор: «REST API WordPress: утечка логинов и защита wp-json» и проверка открытости REST API.

6. Запретить выполнение PHP в загрузках

Папка wp-content/uploads/ — место, куда WordPress кладёт картинки и документы. Никаких PHP-файлов там быть не должно. Если PHP туда попал — это либо ошибка плагина, либо уже вирус. Запрещаем выполнение заранее:

Создайте файл wp-content/uploads/.htaccess с содержимым:

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

<Files *.phtml>
  Require all denied
</Files>

<Files *.phar>
  Require all denied
</Files>

Если хостинг на Nginx (Beget Nginx-режим, ihc, часть тарифов Timeweb) — попросите поддержку добавить блок в конфиг сервера или используйте плагин безопасности, который сделает это сам.

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

В WordPress по умолчанию админ может править PHP-файлы тем и плагинов прямо из интерфейса (Внешний вид → Редактор тем). Если злоумышленник получил доступ к админке — это первая дверь к загрузке шелла. Отключаем одной строкой в wp-config.php (над строкой /* That's all, stop editing! */):

define('DISALLOW_FILE_EDIT', true);

Если хотите параноидальный режим — запретите и установку/обновление плагинов из админки:

define('DISALLOW_FILE_MODS', true);

Но тогда обновляться придётся вручную по FTP. Для большинства сайтов первой строки достаточно.

Регулярная гигиена: что делать каждый месяц

Базовые настройки выше — это «один раз и забыли». Но есть рутина, без которой защита деградирует за полгода.

Обновления — ядро, темы, плагины

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

• Минорные обновления ядра (например, 6.4.1 → 6.4.2) — автоматом. По умолчанию так и есть. Если выключали — включите обратно: define('WP_AUTO_UPDATE_CORE', 'minor'); в wp-config.php.
• Мажорные обновления ядра (6.4 → 6.5) — раз в 1–2 месяца, вручную, обязательно с бэкапом непосредственно перед обновлением.
• Плагины и темы — раз в неделю заходите в админку, читаете changelog, обновляете. Перед обновлением — бэкап.
• Заброшенные плагины (нет обновлений 2+ года) — ищите замену и удаляйте. На странице плагина в каталоге wordpress.org/plugins видно дату последнего обновления и тестируемую версию WP.

Бэкапы — главный страховой полис

Если защита всё же подведёт, единственное, что спасёт быстро и без потерь — свежий чистый бэкап. Правила, которые работают:

• Частота: сайт-визитка — раз в неделю; блог — раз в сутки; магазин с заказами — раз в 6 часов или после каждого заказа.
• Хранение — не на том же сервере. Если хостинг взломают или просто упадёт диск, локальные бэкапы пропадут вместе с сайтом.
• Глубина хранения — минимум 14 дней. Заражение часто замечают не сразу, и недельной глубины не хватает, чтобы найти чистую версию.
• Раз в квартал — проверка восстановления. Бэкап, который никто никогда не разворачивал, — это не бэкап, это файл. Разверните последний бэкап на тестовом поддомене и убедитесь, что сайт поднимается.

Рабочие связки для России:

• UpdraftPlus + Яндекс.Диск (через WebDAV) или Google Drive (если есть VPN/прямой доступ).
• BackWPup + FTP на отдельный аккаунт другого хостинга, или + Яндекс Object Storage (S3-совместимый).
• Встроенные бэкапы хостинга (Beget, Timeweb, Reg.ru — у всех есть) + ручная выгрузка раз в месяц на свой компьютер. Полагаться только на бэкапы хостинга нельзя: если аккаунт заблокируют, доступ к бэкапам тоже пропадёт.

Ревизия пользователей и активности

Раз в месяц 5 минут:

• В Пользователи → Все — отсортировать по дате регистрации, проверить новых.
• Если стоит плагин WP Activity Log или Simple History — пролистать журнал на предмет странных действий (создание админа, изменение опций siteurl, активация неизвестного плагина).
• Раз в квартал — ревизия списка плагинов. Всё, чем не пользовались 3 месяца, — удалить (именно удалить, а не «деактивировать»: деактивированный плагин с уязвимостью всё равно лежит на диске и может быть проэксплуатирован).

Внешняя проверка

• Яндекс.Вебмастер → «Диагностика → Безопасность и нарушения» — раз в неделю заглядывать. Яндекс ставит пометку быстрее многих сканеров.
• Google Search Console → «Проблемы безопасности» — там же.
• Sucuri SiteCheck (sitecheck.sucuri.net) — бесплатный внешний сканер, удобно проверять «вручную» раз в месяц.
• Если важно мониторить непрерывно — поставьте мониторинг доступности через Яндекс.Метрику (есть оповещения при недоступности) или платный UptimeRobot. Это не защита, но вы узнаете о проблеме за минуты, а не за дни.

Что делать НЕ нужно (типовые ошибки)

• Ставить два плагина безопасности одновременно. Wordfence + iThemes Security + Sucuri — это конфликты, ложные срабатывания и тормоза. Выберите один. Типовые дубли SEO, кэша и аналитики — в разборе про лишние плагины.
• Слепо включать все опции в плагине безопасности. «Скрыть версию WordPress», «изменить префикс таблиц БД на работающем сайте», «запретить пользователям просмотр через REST API» — половина этих опций ломает оплату, поиск или редактор и почти не повышает защиту. Включайте по одной, проверяйте сайт после каждой.
• Покупать плагины и темы на торрентах и складчинах. 90% «бесплатных pro-версий» в рунете — это легальный плагин со встроенным бэкдором. Цена темы — 50 долларов, цена очистки после такой темы — 15 000 рублей и потерянный месяц трафика.
• Полагаться на «хостинг сам всё защитит». Хостинг отвечает за безопасность сервера, не сайта. WAF хостинга помогает, но не заменяет обновлений и сильных паролей.
• Менять префикс таблиц БД на живом сайте. Раньше советовали в каждой статье, теперь это бесполезно — современные сканеры читают префикс из wp-config.php за секунду. А вот сломать сериализованные данные в БД легко.
• «Защитить» через .htaccess-парольную защиту на wp-admin/, не понимая последствий. Сломаете AJAX (корзина WooCommerce, автосохранение, Heartbeat). Если ставить — только аккуратно, с исключением для admin-ajax.php.

Когда стоит позвать специалиста

Самостоятельно настроить базовую защиту по чек-листу выше — реально, это 30–60 минут. Но есть ситуации, когда лучше не экспериментировать:

• Сайт коммерческий, простой стоит дорого. Любая ошибка в .htaccess или wp-config.php может уронить сайт на час.
• Интернет-магазин с приёмом оплаты и хранением данных покупателей. По 152-ФЗ вы — оператор персональных данных и несёте за это ответственность. Защита должна быть документированной.
• Сайт уже взламывали раньше. Один раз — случайность; два — закономерность. Нужен профессиональный аудит, чтобы найти, какая именно дверь осталась приоткрытой.
• Используете самописную тему или кастомные плагины. Уязвимости в кастомном коде не закрываются никакими плагинами безопасности — нужен код-ревью.

Если хочется один раз сделать «как надо» и потом не думать — посмотрите услугу «Безопасность WordPress» (настройка под ключ + ежемесячный мониторинг) или напишите в Контактах. Базовая защита настраивается за 2–3 часа, дальше — поддержка по подписке либо разовый чек-ап раз в квартал.

Минимальный чек-лист на сегодня

Если совсем нет времени — сделайте хотя бы это, прямо сегодня вечером:

• Поменяйте пароль администратора на длинный (16+ символов).
• Поставьте Limit Login Attempts Reloaded и включите.
• Включите двухфакторку для всех админов (WP 2FA).
• Добавьте .htaccess в wp-content/uploads/ с запретом PHP.
• Добавьте define('DISALLOW_FILE_EDIT', true); в wp-config.php.
• Проверьте, что бэкап реально создаётся и реально сохраняется не на этот же хостинг.

Этих 6 пунктов хватает, чтобы отсечь подавляющее большинство автоматических атак. Остальное — улучшения, которые можно добавлять по мере роста сайта.