Rate limiting для защиты wp-login.php от брутфорса

Что такое rate limiting и как он останавливает брутфорс

Rate limiting ограничивает количество запросов к определенному ресурсу за заданный промежуток времени. Для wp-login.php лимит чаще всего рассчитывается по IP-адресу. После его превышения сервер возвращает ответ 429 Too Many Requests или временно блокирует дальнейшие запросы.

Например, можно разрешить до 5–10 неудачных попыток за 15 минут для одного IP-адреса. Точное значение зависит от количества администраторов, наличия общей корпоративной сети и особенностей работы команды.

Цель rate limiting — не сделать вход невозможным, а резко снизить скорость автоматического подбора паролей. При этом он не заменяет уникальные пароли, 2FA и своевременное обновление WordPress, тем и плагинов.

• При превышении лимита используйте статус 429, а не обычную страницу ошибки.
• Применяйте отдельные правила к wp-login.php, а не ко всему сайту.
• Перед блокировкой учитывайте, что несколько пользователей могут выходить в интернет через один публичный IP-адрес.
• Не полагайтесь только на ограничение по IP: распределенные атаки могут использовать множество адресов.

Как настроить ограничение на уровне Nginx

Если сайт работает на Nginx, rate limiting лучше выполнять до передачи запроса в PHP-FPM и WordPress. Это снижает нагрузку на процессы PHP и базу данных. Ниже приведен базовый пример, который необходимо адаптировать к конфигурации конкретного сервера.

Директива limit_req_zone обычно размещается в контексте http, а limit_req — в блоке server или location. Значение rate=10r/m означает примерно десять запросов в минуту для одного IP-адреса. Параметр burst разрешает кратковременный всплеск запросов, но не отменяет общее ограничение.

• Перед перезагрузкой сервера проверьте конфигурацию командой nginx -t.
• Не применяйте правило ко всему домену без тестирования: оно может заблокировать обычные страницы, AJAX-запросы и работу Elementor.
• Если перед Nginx работает CDN, балансировщик или reverse proxy, сначала настройте корректное определение реального IP-адреса клиента.
• Не доверяйте заголовку X-Forwarded-For без настройки списка доверенных прокси, иначе злоумышленник сможет подменить IP-адрес.

http {
    limit_req_zone $binary_remote_addr zone=wp_login:10m rate=10r/m;

    server {
        location = /wp-login.php {
            limit_req zone=wp_login burst=5 nodelay;
            limit_req_status 429;

            include fastcgi_params;
            fastcgi_pass unix:/run/php/php-fpm.sock;
        }
    }
}

Что проверить после изменения конфигурации

Убедитесь, что wp-login.php по-прежнему открывается, форма входа отправляется без ошибок, а после превышения порога сервер действительно возвращает 429. Проверяйте access log и error log, но не записывайте в журналы пароли, cookies или полное содержимое POST-запросов.

Фактический путь к PHP-FPM, имя сокета и структура конфигурации различаются на разных серверах. Не копируйте пример без проверки: неправильное значение fastcgi_pass может сделать страницу входа недоступной.

Apache, WAF и CDN: где лучше блокировать атаки

В Apache аналогичную задачу можно реализовать с помощью модулей, правил reverse proxy или внешнего WAF. Конкретный синтаксис зависит от хостинга, поэтому на shared hosting часто проще настроить правило в панели WAF или обратиться к администратору сервера.

WAF или CDN может отсеивать подозрительный трафик еще до его попадания на веб-сервер. Это особенно полезно во время массовой атаки, когда сами запросы к WordPress уже создают нагрузку. На этом уровне rate limiting можно сочетать с CAPTCHA, проверкой репутации IP и правилами для отдельных стран или сетей.

Не следует бездумно блокировать весь трафик к wp-login.php. Администраторы могут использовать VPN, мобильные сети или корпоративный NAT, а автоматические правила WAF иногда ошибочно принимают нормальное поведение за подозрительное.

• На уровне WAF ограничивайте частоту POST-запросов к wp-login.php, если это можно сделать без блокировки обычных GET-запросов.
• Используйте временную блокировку, а не бессрочный бан, если нет признаков серьезной компрометации.
• CAPTCHA целесообразнее показывать после подозрительной активности, а не каждому посетителю.
• Убедитесь, что health-check, системы мониторинга и разрешенные IP-адреса не попадают под действие правила.

Дополнительная защита WordPress и Elementor

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

Не используйте логин admin или очевидные имена вроде названия компании. Проверьте, не раскрывается ли имя пользователя через сообщения об ошибках, REST API, URL авторов или другие публичные механизмы. Сообщение о неудачном входе не должно подсказывать, существует ли конкретный пользователь.

WordPress, Elementor, дополнения Elementor, темы и все плагины необходимо своевременно обновлять. Уязвимый плагин может стать путем атаки даже в том случае, если wp-login.php хорошо защищен.

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

• Включите 2FA как минимум для администраторов и редакторов.
• Запретите повторное использование паролей.
• Удаляйте ненужные плагины и темы, а не просто деактивируйте их.
• Проверьте резервные копии и возможность восстановления сайта до начала настройки безопасности.
• Не меняйте URL входа как единственную меру: боты могут найти новый адрес через ссылки, ответы сервера или сканирование.

Как отслеживать неудачные входы и реагировать на атаку

Журналы веб-сервера помогают увидеть частоту запросов, IP-адреса, user agent, коды ответов и время атаки. Однако одного access log не всегда достаточно, чтобы понять, была ли попытка аутентификации неудачной. Для полной картины нужны журналы WordPress или инструмент аудита, настроенный без сохранения конфиденциальных данных.

Ищите повторяющиеся запросы к wp-login.php, резкий рост ответов 401, 403 или 429, обращения с большого количества адресов и попытки входа с несуществующими логинами. Важен не только отдельный IP-адрес, но и повторяющиеся шаблоны: одинаковые user agent, интервалы времени и сети.

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

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

Типичные ошибки при настройке rate limiting

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

Еще одна распространенная ошибка — настройка ограничения только в плагине. Плагин может уменьшить число попыток аутентификации, но каждый запрос уже обрабатывается веб-сервером и часто доходит до PHP. Для защиты ресурсов лучше сочетать уровень сервера или WAF с контролем в WordPress.

Не тестируйте блокировку только с того же IP-адреса без плана восстановления доступа. До внесения изменений подготовьте консольный или хостинговый доступ к серверу, список доверенных адресов и способ временно отключить правило.

• Не блокируйте IP навсегда без проверки: адреса могут быть динамическими или общими.
• Не считайте код 429 проблемой сервера — это ожидаемый ответ при превышении лимита.
• Не забывайте об IPv6: правила должны корректно обрабатывать IPv4 и IPv6.
• Не проверяйте защиту реальной массовой нагрузкой на рабочем сайте.