Среднее время до первой попытки брутфорса нового сайта на WordPress составляет от 15 минут до 2 часов после смены DNS-записей. При доле рынка в 43%, CMS является главной мишенью, где 90% взломов происходят через уязвимости в сторонних плагинах или слабые права доступа к файлам.
Изоляция wp-config.php и прав доступа
Стандартная установка WordPress оставляет файл конфигурации доступным для чтения в корневом каталоге. Практика показывает: перенос wp-config.php на один уровень выше корня сайта (в директорию /home/user/) полностью исключает его утечку при ошибках сервера. Установите права доступа 400 или 440 для этого файла и 755 для папок, 644 для файлов.
Кейс: на одном из проектов при использовании общего хостинга соседний скомпрометированный аккаунт позволил злоумышленнику прочитать конфиги через симлинки. Решение — строгий запрет на выполнение PHP в папке /uploads/ через .htaccess (deny from all). Экспертный вывод: любые права выше 755 на папках — это дыра, через которую в систему зальют шелл за секунды.
Защита wp-admin и API-запросов
Брутфорс админки — самый дешевый метод атаки. Смена URL входа с /wp-admin на уникальный путь (например, /private_entry_2024) снижает количество автоматизированных попыток входа на 98%. Также необходимо отключить XML-RPC, который используется для DDoS-атак и перебора паролей, добавив в .htaccess строку: 'deny all' для /xmlrpc.php.
Сравнение: стандартная авторизация пропускает до бесконечности запросов, пока не сработает лимит хостинга. Ограничение через Fail2Ban на уровне сервера блокирует IP после 5 неудачных попыток на 24 часа, что делает атаку бессмысленной. Экспертный вывод: скрытие входа — это базовый гигиенический минимум, который отсекает 99% бот-трафика.
Безопасность базы данных и префиксов
Использование стандартного префикса 'wp_' делает SQL-инъекции предсказуемыми. При разработке сайта на WordPress в 2024 году обязательно меняйте префикс на рандомный (например, 'x7_wp_'). Это усложняет автоматизированный поиск таблиц пользователей и настроек. Также создавайте отдельного пользователя БД с ограниченными правами: только SELECT, INSERT, UPDATE, DELETE — без прав GRANT и DROP.
Пример: при использовании общего пользователя БД с правами суперпользователя, одна уязвимость в плагине дает доступ к удалению всех баз данных на аккаунте. Разделение прав сокращает риск полной потери данных до минимума. Экспертный вывод: префикс — это не панацея, но обязательный слой защиты, который ломает логику большинства простых эксплойтов.
Конфигурация сервера и PHP-директивы
Безопасность начинается с php.ini. Отключите выполнение опасных функций: allow_url_fopen, allow_url_include и disable_functions = exec, passthru, shell_exec, system. Это блокирует выполнение удаленного кода (RCE), даже если хакер нашел дыру в коде темы. Версия PHP должна быть строго 8.1+, так как поддержка 7.4 прекращена, и патчи безопасности для неё больше не выходят.
Кейс: сайт на PHP 7.2 был взломан через старую уязвимость в ядре, которая давно исправлена в новых версиях. Обновление до PHP 8.2 не только закрыло дыру, но и ускорило TTFB на 15-20%. Экспертный вывод: серверная конфигурация важнее любого плагина безопасности; если PHP настроен дыряво, Wordfence вас не спасет.
Контроль архитектуры и стороннего кода
Архитектура плагинов при разработке на WordPress требует жесткого фильтра. Каждый новый плагин расширяет поверхность атаки. Рекомендуемый лимит — не более 15-20 активных модулей. При превышении этого порога вероятность конфликта скриптов и появления уязвимости растет экспоненциально. Используйте только проверенные репозитории и избегайте 'nulled' (взломанных) тем, где в 70% случаев зашит бэкдор.
Сравнение: кастомная тема с 3-мя оптимизированными плагинами против конструктора с 25-ю аддонами. В первом случае время аудита безопасности занимает 2 часа, во втором — 2 дня, при этом риск взлома во втором варианте в 5 раз выше. Экспертный вывод: чем меньше стороннего кода, тем выше стабильность и безопасность. Выбирайте функционал, который можно реализовать через functions.php.
Вывод
Безопасность WordPress — это не установка одного плагина, а многослойный пирог. Начинать нужно с сервера: перенос wp-config.php, отключение XML-RPC и жесткие директивы php.ini. Затем — гигиена админки (смена URL, лимиты попыток). Избегайте перегруженных стеков из 30+ плагинов и любой 'бесплатной' премиум-темы. Мой вердикт: инвестируйте время в кастомную разработку и серверный харднинг — это дешевле, чем чистить сайт от вирусов и восстанавливать репутацию в глазах поисковиков после попадания в черный список.