<div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">The original confusion came from the fact you slided away from the basic mantra of the Unix philosophy stating 'Make each program do one thing well'.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">nginx is a Web server, which generalized itself into a stream server. It serves content and manages access (protects it).<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">What you are trying to achieve is turning nginx into a firewall, which it is not.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">A content server does not simply cut connections. It behaves and responds to requests. That is standard.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">All you can do at the connection level is limiting their number (cf. limit_conn).<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)"><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">It has been suggested you used iptables, as it is a firewall. At the software level, I would rather recommend nftables.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Some log analyzers could help you make the interface between a content server and a software firewall, such as fail2ban.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)"><br>You could also go for hardware (D)DoS protection, depending on the scale of your needs.<br></div><div class="gmail_extra"><br><div style="font-size:small;color:rgb(51,51,153)" class="gmail_default">​There is nothing to be surprised of, the product you are using merely doing the job. it has been made for​</div><div><div class="gmail_signature" data-smartmail="gmail_signature"><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font></div></div>
<br><div class="gmail_quote">On Wed, Aug 2, 2017 at 6:27 AM, Gary Sellani <span dir="ltr"><<a href="mailto:lists@lazygranch.com" target="_blank">lists@lazygranch.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The trouble is nginx does a fair amount of work before blocking the IP address, unless things have changed. My recollection is it parses the whole request. Obviously it doesn't send any data. So you are better off blocking with the firewall.<br>
<br>
You do need to know your audience. Something related to a university could generate a number of simultaneous users behind one IP. In my case Boeing triggered the limit.<br>
<br>
<br>
  Original Message  <br>
From: <a href="mailto:nginx-forum@forum.nginx.org">nginx-forum@forum.nginx.org</a><br>
Sent: August 1, 2017 9:08 PM<br>
<span class="im HOEnZb">To: <a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
Reply-to: <a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
Subject: Re: nginx limit_req and limit_conn not working to prevent DoS attack<br>
<br>
</span><div class="HOEnZb"><div class="h5">Yes. Firewall would be another option. But before to that, i would like to<br>
try out all options at nginx level if one or other would resolve the issue<br>
at nginx layer itself.<br>
<br>
cant we put accept() filters? or<br>
how the deny option works? can we use deny option to not to accept any new<br>
connections if number of connections already exceeds max limit from a client<br>
IP.?<br>
are there any third party modules available for nginx to embed firewall<br>
functionality? something reliable !!<br>
<br>
My objective is, using limit_conn directive, when number of connections<br>
exceeding limit, instead of sending 503, or 444, just do not accept any new<br>
connections from that specific IP only(if a client is opening 10000<br>
connections at a time, it should be fine to not accept connections from that<br>
IP citing the reason that it could be malicious).<br>
<br>
Thoughts !!<br>
<br>
Thanks.<br>
<br>
Posted at Nginx Forum: <a href="https://forum.nginx.org/read.php?2,275796,275801#msg-275801" rel="noreferrer" target="_blank">https://forum.nginx.org/read.<wbr>php?2,275796,275801#msg-275801</a><br>
<br>
______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx</a><br>
______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx</a></div></div></blockquote></div><br></div></div>