Simple protection against bots (brutforsa admin panel) with nginxUkraine Hosting › FAQ › Dedicated servers and VPS › Simple protection against bots (brute-force admin panels) with nginx
You can protect the site from hacking by brute-force (password pickup to the admin panel of the site) and reduce the load created by hackers using nginx installed by the front-end on the server by modifying the nginx configuration file (most often it is located in /etc/nginx/nginx.conf ) like this:
immediately after the http line { add
# antibot
limit_req_zone $ binary_remote_addr zone = antibot: 16m rate = 6r / m;
limit_req_log_level warn;
limit_req_status 403 ;
Next, find the block describing a specific protected site. It starts with server { and contains the server_name directive with the site address. Sort of:
server {server_name sitename.com www.sitename.com;listen xxx.xxx.xxx.xxx;and further a number of location describing the rules for processing requests to the server In the server, add a new location with the following contents: 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 ;
}
Where,
/wp-login.php - path to the protected page. For Opencart you need to replace it with / admin, for Joomla - with / administrator127.0.0.1:81 - replace with IP address: port of the web server on which the site is located. ( can be peeped in nearby location directives ) After all changes, save the changes and check the correctness of the config by running in the server console: nginx -t
if the scan result is syntax is ok , then restart nginx:
service nginx restart
Principle of operation:
This config sets a shared memory zone with the name antibot, 16MB volume and request processing speed - 6 requests / minute or 1 access to /wp-login.php in 10 seconds (you can also specify this parameter in requests / sec - r / s). If the number of incoming requests is more than the value of the rate - their processing is postponed until their number exceeds the value specified in limit_req .... burst (in our case - 2), after which all subsequent requests will receive an error 403 ( You can specify any other error code in the limit_req_status line, for example, 423 as more accurate to determine the situation ) given by nzhinks, which is much more economical in terms of resources consumed by the server than catching the same situation and blocking at the apache level. More information about configuring the ngx_http_limit_req_module module used in this article can be found in the official nginx documentation: http://nginx.org/ru/docs/http/ngx_http_limit_req_module.html
System operation check:
Using the ab utility (apache benchmark), you can create http flood to a specific page, for example wp-login.php and see the error log of nginx:
$ ab -n 100 -c 1 http: // ... / wp-login.php