Here is my philosophy. A packet arrives at your server. This can be broken down into two parts: who are you and what do you want. The firewall does a fine job of stopping the hacker at the who are you point.
When the packet reaches Nginx, the what do you want part comes into play. Most likely nginx will reject it. But all software has bugs, and thus there will be zero days. Thus I rather stop the bad actor at the firewall. Original Message From: c0nw0nk Sent: Thursday, December 15, 2016 2:23 AM To: [email protected] Reply To: [email protected] Subject: Re: limit_req per subnet? gariac Wrote: ------------------------------------------------------- > This is an interesting bit of code. However if you are being ddos-ed, > this just eliminates nginx from replying. It isn't like nginx is > isolated from the attack. I would still rather block the IP at the > firewall and prevent nginx from doing any action. > > The use of $bot_agent opens up a lot of possibilities of the value can > be fed to the log file. > Original Message > From: shiz > Sent: Wednesday, December 14, 2016 5:24 PM > To: [email protected] > Reply To: [email protected] > Subject: Re: limit_req per subnet? > > I've inplemented something based on > https://community.centminmod.com/threads/blocking-bad-or-aggressive-bo > ts.6433/ > > Works perfectly fine for me. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?2,271483,271535#msg-271535 > > _______________________________________________ > nginx mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx > _______________________________________________ > nginx mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx Any layer 7 attack that Nginx begins struggling to accept connections is a successful one and at that point should be blocked at a router level. But Nginx handles allot of connections very well hence why the limit_conn and limit_req modules exist because the majority of layer 7 attacks Nginx won't have a problem denying them itself. The bottle necks are backend processes like MySQL, PHP, Python, If they clog up accepting traffic Nginx will run out of connections available to keep serving other requests for different files / paths on the server. http://nginx.org/en/docs/ngx_core_module.html#worker_connections that is the cause to your entire Nginx server going slow / unresponsive at that point even the 503 error and 500x errors won't display, all connections begin to time out and at this point you should block those IP's exhausting Nginx's server connections at a router level since Nginx can no longer cope. Nginx has small footprint in resources used layer 7 based attacks you should only start blocking at a router level when Nginx can no longer handle them fine on its own and begins timing out due to worker_connections getting exhausted. But it is rare that a attack is large enough to exhaust those and you can increase worker_connections and decrease timeout values to fix that easily. Posted at Nginx Forum: https://forum.nginx.org/read.php?2,271483,271546#msg-271546 _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
