Большинство руководств по безопасности WordPress начинают с установки плагина Wordfence и заканчивают фразой «делайте бэкапы». Это поверхностный подход. Настоящая защита строится снизу вверх — от файловой системы сервера до логики приложения.
В этой статье разберём четыре уровня обороны, которые я использую на реальных проектах. Каждый уровень работает независимо: если один слой прогнётся, остальные удержат систему.
Уровень 1: Фундамент — сервер и DevOps
Безопасность сайта начинается задолго до того, как WordPress загрузит свой первый PHP-файл. Речь о настройках веб-сервера и правах доступа к файлам.
Изоляция через права доступа
Это базовая гигиена, которую игнорируют 80% владельцев сайтов. Файлы ядра WordPress, темы и плагины должны быть доступны веб-серверу только на чтение.
- Папки: 755
- Файлы: 644
- wp-config.php: 600 или 440
Если для корректной работы сайта требуются права 777 — значит, что-то настроено неправильно. Веб-сервер должен иметь возможность записи только в одну папку: wp-content/uploads. Всё остальное — только чтение.
Защита на уровне конфигурации сервера
Файл .htaccess для Apache или конфигурационный блок для Nginx — это первая линия обороны, которая отсекает большинство массовых атак ещё до обращения к PHP.
Что обязательно нужно сделать:
- Запретить выполнение PHP в папке загрузок. Атакующие регулярно загружают веб-шеллы, маскируя их под изображения с расширением
.jpg.php. Один такой файл — и сервер скомпрометирован. - Заблокировать прямой доступ к wp-config.php и другим чувствительным файлам. Если вы не используете
xmlrpc.php(а в большинстве случаев не используете) — заблокируйте и его. - Скрыть версию сервера. Зачем давать атакующему информацию о том, какие уязвимости могут быть на вашем хостинге? Отключите
ServerSignatureи установитеServerTokens Prod.
Префикс таблиц базы данных
Стандартный префикс wp_ — это приглашение для автоматизированных SQL-инъекций. Массовые эксплойты заточены именно под дефолтные имена таблиц. При установке WordPress задайте уникальную строку вроде x7k2_ — и большинство шаблонных атак потеряют актуальность.
Уровень 2: Архитектура и гигиена кода
Переходим от инфраструктуры к самому приложению. Здесь главный враг — не хакер, а разработчик, который поставил nulled-тему «на проверку» и забыл её удалить.
Минимализм в плагинах
Каждый установленный плагин — это потенциальная точка входа. Удалите всё, что не используется. Не деактивируйте, а именно удалите. Неактивный плагин с уязвимостью так же опасен, как активный.
Оптимальный набор для типичного проекта: один кеширующий плагин, один SEO, один для форм. Всё остальное — только если обоснована бизнес-необходимость. Коллекционирование плагинов ведёт к конфликтам, замедлению сайта и дырам в безопасности.
Принцип наименьших привилегий
Контент-менеджер, который публикует статьи, не должен иметь прав редактирования файлов темы или установки плагинов. Роль Editor подходит для редактуры, но если нужна только публикация постов — хватит и Author.
Прямое редактирование PHP-файлов через админку (Appearance → Theme Editor) — это то, что должно быть физически отключено в каждом проекте:
define('DISALLOW_FILE_EDIT', true);
Обновления: автоматика с умом
Полный автопилот на мажорные релизы — рискованная стратегия для сложных проектов. Обновление WordPress с 5.x на 6.x может сломать совместимость с кастомными решениями.
Но минорные обновления безопасности — критически важные патчи — должны устанавливаться автоматически:
define('WP_AUTO_UPDATE_CORE', 'minor');
Для плагинов и тем из официального репозитория рекомендую авто-обновление минорных версий. Для кастомных решений — Composer, CI/CD-пайплайн и тестирование в стейджинг-окружении перед деплоем на продакшен.
Уровень 3: WAF и защита периметра
Третий уровень — защита от брутфорса, инъекций и атак нулевого дня. Здесь мы работаем с трафиком до того, как он дойдёт до WordPress.
Отказ от стандартного входа
Адрес /wp-login.php обрабатывается миллионами ботов ежедневно. Стандартный логин-пароль без дополнительных слоёв защиты — это вопрос не «взломают ли», а «когда».
Решения, которые работают:
- Двухфакторная аутентификация (2FA) — обязательный стандарт для всех учётных записей с правами администратора. TOTP через Google Authenticator или аналог — минимум усилий, максимум защиты.
- Смена URL входа — простая обфускация, которая не заменяет 2FA, но отсекает 95% автоматизированного шума.
- Геоблокировка — если ваша аудитория и редакторы работают из конкретных стран, заблокируйте доступ к админке из остальных на уровне DNS-провайдера или файрвола.
Web Application Firewall на DNS-уровне
Cloudflare в режиме прокси или аналогичные сервисы — лучшая защита от DDoS и массовых инъекций. Трафик фильтруется до того, как дойдёт до вашего сервера.
Полезные правила WAF:
- Блокировка запросов, содержащих пути к известным уязвимым плагинам (например,
/wp-content/plugins/revslider/). - Challenge для прямых запросов к
xmlrpc.php. - Ограничение частоты запросов к страницам авторизации.
Fail2ban на сервере
Если вы управляете VPS, интеграция WordPress с fail2ban — это гашение брутфорса на уровне сетевого стека. Плагины вроде WP Fail2ban пишут попытки входа в системный лог, а fail2ban банит IP-адреса через iptables. Это не нагружает PHP и блокирует атакующего до того, как он сделает десятую попытку.
Уровень 4: Глубокая защита данных
Последний уровень — защита того, что уже внутри. Даже если атакующий прорвался через три предыдущих слоя, эти меры ограничат ущерб.
Ключи и соли безопасности
Все восемь уникальных ключей в wp-config.php должны быть сгенерированы через официальный генератор WordPress.org. Одинаковые или дефолтные ключи — это ситуация, когда украденная cookie даёт полный доступ к админке без пароля.
Отладка и логирование
На продакшене WP_DEBUG должен быть выключен. Файл debug.log в папке wp-content часто содержит абсолютные пути сервера, SQL-запросы и структуру базы данных — идеальная разведывательная информация для атакующего.
Защита содержимого wp-content
Перемещение папки wp-content — спорный приём, который может сломать совместимость с плагинами. Гораздо надёжнее:
- Запретить листинг директорий (
Options -Indexes). - Заблокировать доступ к чувствительным файлам плагинов напрямую.
- Ограничить типы файлов, разрешённых для загрузки.
Бэкапы — не защита, а последний рубеж
«Случится взлом — откачусь» — это не стратегия безопасности, а рецепт для повторного взлома. Бэкапы нужны, но они не устраняют причину компрометации.
И никогда не храните резервные копии в папке /wp-content/uploads/backups/. Для атакующего это бесплатный архив с дампом базы данных и конфигурацией сервера.
Итог: предполагай взлом
Правильный подход к безопасности WordPress — строить защиту так, чтобы компрометация одного модуля не роняла всю систему. Платные плагины безопасности патчат симптомы, но защита закладывается на уровне архитектуры: в настройках сервера, в wp-config.php, в ролевой модели и сетевом экране.
Не гонитесь за галочками вроде «Защита +100500». Настройте HTTPS с HSTS, включите двухфакторную аутентификацию, организуйте нормальное логирование и контролируйте обновления. Это даст больше реальной безопасности, чем любой плагин с красивым дашбордом.