Базовая защита WordPress от взлома: разбор на примере

Небольшой сайт на WordPress 6.x обычно взламывают не через сложную уязвимость ядра, а через старый плагин, украденный пароль администратора или доступ к резервной копии. На примере сайта за Nginx и PHP 8.2 разберём четыре слоя защиты: обновления, учётные записи, конфигурацию веб-сервера и восстановление после сбоя. Все изменения можно проверить без атакующих инструментов, а базовую настройку реально выполнить за один рабочий день.

Исходные условия и цена ошибки

Представим сайт компании на WordPress 6.x. Сервер работает на Linux, перед приложением стоит Nginx, база данных — MySQL или MariaDB. У владельца есть SSH-доступ, доступ к панели WordPress и возможность создавать резервные копии. На сервере нет отдельного стенда, поэтому каждое изменение сначала проверяется на копии или в период низкой нагрузки.

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

Защита сайта — это не одна кнопка «Безопасность». Это цепочка, в которой резервная копия ограничивает ущерб, обновления уменьшают поверхность атаки, а раздельные доступы не дают одной украденной учётной записи открыть весь сервер.

Поверхность атаки^[1] — все доступные извне точки, через которые можно воздействовать на систему: форму входа, панель администратора, плагины, API, загрузку файлов и сам сервер.

Четыре подхода и их ограничения

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

Разбор на примере: что изменить сначала

1. Составьте список компонентов

В панели WordPress откройте разделы обновлений и выпишите версии ядра, активной темы и каждого плагина. Удалите неиспользуемые плагины и темы, а не просто отключите их: оставшийся на диске код всё равно может содержать уязвимость. Перед обновлением сохраните базу данных и каталог wp-content.

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

2. Разделите административные доступы

Не используйте учётную запись с именем admin и не давайте всем редакторам роль администратора. Для публикации достаточно роли редактора, для управления плагинами нужен отдельный технический доступ. У каждого человека должна быть своя учётная запись: так журнал действий сохраняет смысл, а увольнение сотрудника не требует смены общего пароля.

Включите многофакторную аутентификацию через проверенный плагин или функцию корпоративного менеджера паролей. Сохраните резервные коды вне сайта. Не отправляйте их в чат и не кладите в папку с резервной копией на том же сервере.

Проверка: в списке пользователей нет общих аккаунтов, у редактора отсутствует доступ к установке плагинов, а вход с включённой MFA требует второй фактор.

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

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

define('DISALLOW_FILE_EDIT', true);

Эта настройка не запрещает обновления из панели, но убирает встроенный редактор. Если обновления тоже нужно запретить и выполнять только через CI или SSH, используйте отдельную политику после проверки процесса развёртывания. Не добавляйте её вслепую: можно лишить владельца сайта рабочего способа обновлять компоненты.

Проверка: в разделе редактора файлов нет возможности открыть и изменить код темы или плагина.

4. Закройте конфигурацию на уровне Nginx

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

location = /wp-config.php {
    deny all;
}

location ~ /\. {
    deny all;
}

Второе правило блокирует запросы к файлам и каталогам, начинающимся с точки. Оно может повлиять на отдельные сценарии, если сайт или инструмент действительно публикует такой файл, поэтому после перезагрузки проверьте сайт и логи. Не переносите этот фрагмент в конфигурацию Apache без адаптации: синтаксис другой.

Проверка: запрос к /wp-config.php не возвращает содержимое файла, а обычные страницы, медиафайлы и административная панель открываются.

5. Настройте резервное копирование как план восстановления

Для WordPress нужны как минимум две части: база данных и каталог wp-content, где находятся загрузки, темы и плагины. Резервная копия на том же сервере не считается полноценной защитой: злоумышленник с доступом к серверу может удалить и сайт, и копии.

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

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

Что ломается чаще всего

Сайт начал отдавать 403 после настройки Nginx

Чаще всего правило блокирует каталог или файл, который нужен приложению. Посмотрите error log Nginx, временно отключите только добавленное правило и проверьте конфигурацию небольшими изменениями. Не удаляйте все ограничения сразу: иначе вы потеряете понимание, какая строка вызвала проблему.

После обновления появилась белая страница

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

Пользователь не может войти после включения MFA

Проверьте время на телефоне и сервере, резервные коды и предусмотренный плагином способ восстановления. Не удаляйте базовую таблицу пользователей вручную. Если доступ потеряли все администраторы, обращайтесь к документации конкретного плагина и владельцу сервера.

Резервная копия создана, но восстановить её нельзя

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

Когда выбирать какой уровень защиты

Для визитки с редкими публикациями минимальный набор — актуальные компоненты, MFA, запрет редактора, закрытая конфигурация и отдельные резервные копии. Для интернет-магазина этого мало: добавьте журналирование входов, контроль изменений, отдельный тестовый контур и процедуру быстрого отката. Если сайт принимает персональные данные или платежи, оцените WAF, изоляцию сервера и доступ к журналам вместе с инфраструктурным специалистом.

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

Что делать дальше

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