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: nginx@nginx.org
Reply To: nginx@nginx.org
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 fr‎om 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: nginx@nginx.org
> Reply To: nginx@nginx.org
> 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
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> 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
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx