4.4.7. Простая защита от ботов (брутфорса админ-панели) с помощью nginx

Защитить сайт от взлома брутфорсом (подобором пароля к админ-панели сайта) и снизить нагрузку, создаваемую ботами-взломщиками, можно с помощью nginx, установленного фронтендом на сервере, модифицировав его конфигурационный файл (чаще всего он находится в /etc/nginx/nginx.conf) таким образом — сразу после строки http { добавьте:

# антибот
limit_req_zone $binary_remote_addr zone=antibot:16m rate=6r/m;
limit_req_log_level warn;
limit_req_status 403;

Далее найдите блок, описывающий конкретный защищаемый сайт. Он начинается с server { и содержит директиву server_name с адресом сайта. Что-то вроде:

server {
server_name example.com www.example.com;
listen xxx.xxx.xxx.xxx;
# и далее ряд location, описывающих правила обработки запросов к server

В server добавьте location с таким содержимым:

location = /wp-login.php {
limit_req   zone=antibot burst=2 nodelay;
proxy_pass http://127.0.0.1:81;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}

Где:

• /wp-login.php — путь к защищаемой странице. Для OpenCart его нужно заменить на /admin, для Joomla! — на /administrator.
• 127.0.0.1:81 — замените на IP-адрес:порт веб-сервера, на котором размещён сайт (можно подсмотреть в соседних директивах location).

Сохраните внесённые изменения и проверьте правильность конфигурационного файла, выполнив в консоли сервера команду:

nginx -t

Если результат проверки «syntax is ok», то перезапустите nginx:

service nginx restart

Этот конфигурационный файл задаёт зону разделяемой памяти с названием antibot, объёмом 16 МБ и скоростью обработки запросов 6 запросов/минуту или 1 обращение к /wp-login.php в 10 секунд (ещё можно указывать этот параметр в запросах/секунду — r/s). Если количество поступающих запросов больше, чем значение rate, их обработка откладывается до тех пор, пока их количество не превысит значение, заданное в limit_req...burst (в нашем случае — 2), после чего все последующие запросы будут получать в ответ ошибку 403 (можно задать любой другой код ошибки в строке limit_req_status, например 423, как более точный для определения ситуации), отдаваемую nginx, что значительно более экономно в плане потребляемых сервером ресурсов, чем отлов той же ситуации и блокировка на уровне Apache.

Более подробную информацию о настройке модуля ngx_http_limit_req_module можно найти в официальной документации nginx.

С помощью утилиты ab (apache benchmark) можно создать HTTP-флуд на определённую страницу, например /wp-login.php, и посмотреть при этом Error-лог nginx:

ab -n 100 -c 1 http://example.com/wp-login.php