простая защита от ботов (брутфорса админ-панели) при помощи nginx
более детальную информацию можно найти в нашей вики:https://wiki.ukraine.com.ua/vps:administration:simple-nginx-bot-protection. защитить сайт от взлома брутфорсом (подобором пароля к админ-панели сайта) и снизить нагрузку создаваемую ботами-взломщиками можно при помощи 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 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 проверка работы системы: с помощьюутилиты ab (apache benchmark)можно создать http флуд на определенную страницу, например wp-login.php и посмотреть при этом error лог nginx: $ ab -n 100 -c 1 http://.../wp-login.php