<html><head></head><body lang="en-US" style="background-color: rgb(255, 255, 255); line-height: initial;"> <div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">If you just reply to these hackers, you will be "pinged" until oblivion. I choose to fight, you don't. I have a different philosophy. I log the offenders and if from a colo, VPS, etc., they can enjoy their lifetime ban. Machines are not eyeballs. </div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><span style="font-size: initial; line-height: initial; text-align: initial;"><br></span></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><span style="font-size: initial; line-height: initial; text-align: initial;">Drop the map? So do I stop looking for bad referrals and bad user agents as well? Maybe, just maybe, nginx was given these tools to be, well, used. </span></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">Questions? I really don't have any burning questions since I don't expect to use 444 as rate limiting. My only question was does it actually work in limiting, as the other poster suggested.</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">I assume you have evidence of the CPU cycles used by the map module. I mean, you wouldn't just make stuff up, right? </div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">Running uptime, my server peaks at around 0.8, and usually runs between 0.5 to 0.6. I don't see a problem here. </div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><span style="font-size: initial; text-align: initial; line-height: initial;">Oh, and you can bet those clowns proving for WordPress vulnerabilities today will be employing the next script kiddie to come along in the future. </span></div> <div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br style="display:initial"></div> <div style="font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"></div> <table width="100%" style="background-color:white;border-spacing:0px;"> <tbody><tr><td colspan="2" style="font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"> <div style="border-style: solid none none; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>B.R.</div><div><b>Sent: </b>Wednesday, September 28, 2016 9:57 AM</div><div><b>To: </b>nginx ML</div><div><b>Reply To: </b>nginx@nginx.org</div><div><b>Subject: </b>Re: 444 return code and rate limiting</div></div></td></tr></tbody></table><div style="border-style: solid none none; border-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"></div><br><div id="_originalContent" style=""><div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">If you are to quote what you call documentation, please use some real one:<br><a href="http://nginx.org/en/docs/http/request_processing.html#how_to_prevent_undefined_server_names">http://nginx.org/en/docs/http/request_processing.html#how_to_prevent_undefined_server_names</a><br><br>What I said before remains valid: accepting connection, reading request & writing response use resources, by design, even if you thn close the connection.<br>When dealing with DoS, I suspect Web servers and WAF (even worse, trying to transform a Web server in a WAF!) are inefficient compared to lower-level tools.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Use tools best suitable to the job...<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)"><br>DoS is all about processing capacity vs incoming flow. Augmenting the processing consumption reduces capacity.<br><br>Issuing simple return costs less than using maps, which in turn is better than processing more stuff.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">If your little collection sustains your targeted incoming flow then you win, otherwise you lose.<br>Blatantly obvious assertions if you ask me...<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)"><br>I do not know what you are trying to achieve here. Neither do you as it seems, or you would not be asking questions about it.<br></div><div class="gmail_extra"><div style="font-size:small;color:rgb(51,51,153)" class="gmail_default">Good luck, though.</div><div><div class="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 Tue, Sep 27, 2016 at 9:12 PM, <span dir="ltr"><<a href="mailto:lists@lazygranch.com" target="_blank">lists@lazygranch.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If you dig through some old posts, it was established that the deny feature of nginx isn't very effective at limiting network activity. I deny at the firewall. <br>
<br>
What remains is if you should deny dynamically or statically. <br>
<br>
Original Message <br>
From: c0nw0nk<br>
Sent: Tuesday, September 27, 2016 11:42 AM<br>
To: <a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<span class="gmail-im gmail-HOEnZb">Reply To: <a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
Subject: Re: 444 return code and rate limiting<br>
<br>
</span><div class="gmail-HOEnZb"><div class="gmail-h5">It is a response by the time the 444 is served it is to late a true DDoS is<br>
not about what the server outputs its about what it can receive you can't<br>
expect incoming traffic that amounts to 600Gbps to be prevented by a 1Gbps<br>
port it does not work like that Nginx is an Application preventing any for<br>
of DoS at an application level is a bad idea it needs to be stopped at a<br>
router level before it hits the server to consume your receiving capacity of<br>
1Gbps.<br>
<br>
Adding IP address denies for DDoS to the Nginx .conf file at the application<br>
level is to late still also the connection has been made the request headers<br>
/ data of 100kb or less what ever the client sent has been received on your<br>
1Gig port its already consuming your connection.<br>
<br>
The only scenario I can think of where returning 444 is a good idea is under<br>
a single IP flooding "DoS" because then your not increasing your ports<br>
bandwidth output responding to someone who is opening and closing a<br>
connection, But in this scenario its more like they are trying to make your<br>
server DoS itself by making it max out its own outgoing bandwidth to just<br>
their connection alone so nobody else can receive anything.<br>
<br>
Posted at Nginx Forum: <a href="https://forum.nginx.org/read.php?2,269873,269879#msg-269879" rel="noreferrer" target="_blank">https://forum.nginx.org/read.<wbr>php?2,269873,269879#msg-269879</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>
<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>
<br><!--end of _originalContent --></div></body></html>