Защитить сайт от взлома брутфорсом (подобором пароля к админ-панели сайта) и снизить нагрузку создаваемую ботами-взломщиками можно при помощи nginx, установленного фронтэндом на сервере, модифицировав конфигурационный файл nginx (чаще всего он находится в /etc/nginx/nginx.conf) вот таким образом:
сразу после строки http { добавьте
#antibot 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 sitename.com www.sitename.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 как более точный для определения ситуации) отдаваемую нжинксом, что значительно более экономно в плане потребляемых сервером ресурсов, чем отлов той же ситуации и блокировка на уровне apache.
Более подробную информацию о настройке модуля ngx_http_limit_req_module, который использовался в этой заметке, можно найти в официальной документации nginx: http://nginx.org/ru/docs/http/ngx_http_limit_req_module.html
Прокомментировать