<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);">I don't do 444 for rate limiting. I figure a hacker doesn't deserve a response. I see the occasional double request, but not 10. </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);">Most likely the entity trying to log into my WordPress control panel  is not typing on a keyboard  into a browser. It is a script with fake user agent. Oh, and I don't use WordPress. ;-) </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 had a nice fake Baidu spider today. Obvious hacking related to Joomla. (Don't use that either.) No dupes, it just went down the script. </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);">The real Baidu spider is a pig. I have blocked their actual IP space, so I only get fake Baidu spiders that come back to Chinese ISPs.</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 serve so few 444s a day, it is hardly worth the energy to discuss. Now it is fair to claim because all requests are examined by maps, that is where I am using resources. </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);"><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);"><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>Richard Stanway</div><div><b>Sent: </b>Wednesday, September 28, 2016 10:58 AM</div><div><b>To: </b>nginx@nginx.org</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">Keep in mind a terminated connection (444) is not a valid HTTP response. Abruptly terminated connections may also be caused by broken middleware boxes or other things interrupting the connection. Modern browsers have retry mechanisms built in to safeguard against transient connection issues, for example, returning 444 to a Firefox client will cause it to retry the request up to 10 (!) times. This is the opposite of what you want in a rate limited scenario.<div><br></div><div>Stick with 429 or 503.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 28, 2016 at 7:30 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div 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><div class="h5"><div><b>Reply To: </b><a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a></div><div><b>Subject: </b>Re: 444 return code and rate limiting</div></div></div></div></td></tr></tbody></table><div><div class="h5"><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><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" target="_blank">http://nginx.org/en/docs/http/<wbr>request_processing.html#how_<wbr>to_prevent_undefined_server_<wbr>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><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" target="_blank">nginx@nginx.org</a><br>
<span>Reply To: <a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
Subject: Re: 444 return code and rate limiting<br>
<br>
</span><div><div>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.p<wbr>hp?2,269873,269879#msg-269879</a><br>
<br>
______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailm<wbr>an/listinfo/nginx</a><br>
<br>
______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailm<wbr>an/listinfo/nginx</a></div></div></blockquote></div><br></div></div>
<br></div></div></div></div>

<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></blockquote></div><br></div>
<br><!--end of _originalContent --></div></body></html>