По статистике безопасности, более 90% всех атак на WordPress направлены на уязвимости в плагинах и темах, что делает стандартную установку «из коробки» легкой мишенью. Безопасность — это не установка одного плагина, а комплексный слой настроек, который сокращает поверхность атаки на 70-80% еще до первого визита пользователя.
Защита ядра и критические правки wp-config.php
Первым делом отключаем редактирование файлов через админку: define('DISALLOW_FILE_EDIT', true);. Это блокирует возможность внедрения вредоносного кода в шаблоны через панель управления, если злоумышленник получит доступ к аккаунту администратора. Также рекомендую сменить стандартный префикс таблиц wp_ на уникальный (например, site77_), что усложняет SQL-инъекции, так как боты ищут стандартные имена таблиц.
Кейс: при восстановлении сайта клиента после взлома выяснилось, что хакеры использовали стандартный префикс для быстрого поиска таблицы wp_users. Смена префикса на этапе разработки увеличивает время подбора структуры БД в десятки раз. Экспертный вывод: Любой сайт без DISALLOW_FILE_EDIT — это риск мгновенного уничтожения всего фронтенда при компрометации одного пароля.
Укрепление базы данных и прав доступа
Установите права на файлы 644, а на папки 755. Файл wp-config.php должен иметь права 400 или 440, чтобы другие пользователи сервера не могли прочитать ваши ключи соли и пароль от БД. Обязательно используйте уникальные salts (соли) из официального генератора WordPress; это делает сессионные куки практически неуязвимыми для перехвата.
В среднем, неправильные права доступа к папке wp-content/uploads позволяют злоумышленникам загружать PHP-шеллы, которые исполняются сервером. Проверка прав занимает 10 минут, но закрывает 40% векторов атак через загрузку медиафайлов. Экспертный вывод: Переходите на модель минимальных привилегий: веб-серверу должно быть разрешено писать только в те папки, где это критически необходимо для работы сайта.
Безопасность административной панели и авторизации
Смена адреса /wp-admin на кастомный (например, /private-entry) отсекает до 95% автоматизированных брутфорс-атак, которые бьют по стандартному URL. Внедрение двухфакторной аутентификации (2FA) делает кражу пароля бесполезной. Ограничьте количество попыток входа до 3-5; после этого IP должен блокироваться на 1-2 часа.
Сравнение: стандартный вход подвергается атакам каждые несколько секунд (мониторинг логов показывает до 10 000 запросов в сутки на свежих доменах), тогда как скрытый вход практически не фиксирует попыток подбора. Экспертный вывод: Не полагайтесь на сложные пароли — используйте 2FA и скрытый URL, так как человеческий фактор в выборе пароля остается самым слабым звеном.
Контроль стороннего кода и фильтрация трафика
Отключите XML-RPC (wp-json оставить, если нужен REST API), так как этот протокол часто используется для DDoS-атак и брутфорса. Также удалите все неиспользуемые плагины и темы, даже деактивированные — они остаются в файловой системе и могут содержать уязвимости. При выборе стека помните, что кастомная разработка всегда безопаснее перегруженных функций-комбайнов из бесплатных библиотек.
Пример: удаление одного заброшенного плагина-слайдера, который не обновлялся 2 года, закрывает критическую дыру RCE (Remote Code Execution). Стоимость такой «ошибки» — полная потеря данных или попадание в черный список Google Safe Browsing. Экспертный вывод: Лучшая защита — это отсутствие кода. Чем меньше плагинов, тем меньше точек входа для атаки.
Мониторинг и автоматизация защиты
Настройте автоматическое резервное копирование с выгрузкой на внешний сервер (S3, Google Drive, FTP), а не на тот же хостинг. В случае взлома локальный бэкап будет удален или зашифрован первым. Используйте WAF (Web Application Firewall) на уровне сервера или через Cloudflare для фильтрации вредоносного трафика до того, как он достигнет вашего WordPress.
Инсайт: восстановление сайта из бэкапа занимает от 30 минут до 4 часов, в то время как ручная чистка сайта от вирусов может длиться днями и стоить от 10 000 до 50 000 рублей за один инцидент. Экспертный вывод: Инвестируйте в автоматический внешний бэкап сегодня, чтобы не платить за экстренную очистку сайта завтра.
Вывод
Безопасность WordPress начинается с гигиены кода. Мой вердикт: начните с запрета редактирования файлов в админке и смены URL входа — это бесплатные меры, закрывающие большинство типовых атак. Избегайте перегруженных «безопасных» плагинов-комбайнов, которые тормозят систему; лучше настроить WAF на уровне DNS (Cloudflare) и жестко ограничить права доступа к файлам. Помните, что разработка сайта на WordPress требует системного подхода к безопасности на каждом этапе, а не разовой установки антивируса после взлома.
Связанный обзор по теме — Разработка сайтов на WordPress.