Welcome! Log In Create A New Profile

Advanced

Re: 444 return code and rate limiting

Richard Stanway
September 28, 2016 02:00PM
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.

Stick with 429 or 503.

On Wed, Sep 28, 2016 at 7:30 PM, <lists@lazygranch.com> wrote:

> 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.
>
> 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.
>
> 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.
>
> ‎I assume you have evidence of the CPU cycles used by the map module. I
> mean, you wouldn't just make stuff up, right?
>
> 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.
>
> 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.
>
> *From: *B.R.
> *Sent: *Wednesday, September 28, 2016 9:57 AM
> *To: *nginx ML
> *Reply To: *nginx@nginx.org
> *Subject: *Re: 444 return code and rate limiting
>
> If you are to quote what you call documentation, please use some real one:
> http://nginx.org/en/docs/http/request_processing.html#how_
> to_prevent_undefined_server_names
>
> What I said before remains valid: accepting connection, reading request &
> writing response use resources, by design, even if you thn close the
> connection.
> 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.
> Use tools best suitable to the job...
>
> DoS is all about processing capacity vs incoming flow. Augmenting the
> processing consumption reduces capacity.
>
> Issuing simple return costs less than using maps, which in turn is better
> than processing more stuff.
> If your little collection sustains your targeted incoming flow then you
> win, otherwise you lose.
> Blatantly obvious assertions if you ask me...
>
> 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.
> ​Good luck, though.​
> ---
> *B. R.*
>
> On Tue, Sep 27, 2016 at 9:12 PM, <lists@lazygranch.com> wrote:
>
>> 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.
>>
>> What remains is if you should deny dynamically or statically. ‎
>>
>> Original Message
>> From: c0nw0nk
>> Sent: Tuesday, September 27, 2016 11:42 AM
>> To: nginx@nginx.org
>> Reply To: nginx@nginx.org
>> Subject: Re: 444 return code and rate limiting
>>
>> It is a response by the time the 444 is served it is to late a true DDoS
>> is
>> not about what the server outputs its about what it can receive you can't
>> expect incoming traffic that amounts to 600Gbps to be prevented by a 1Gbps
>> port it does not work like that Nginx is an Application preventing any for
>> of DoS at an application level is a bad idea it needs to be stopped at a
>> router level before it hits the server to consume your receiving capacity
>> of
>> 1Gbps.
>>
>> Adding IP address denies for DDoS to the Nginx .conf file at the
>> application
>> level is to late still also the connection has been made the request
>> headers
>> / data of 100kb or less what ever the client sent has been received on
>> your
>> 1Gig port its already consuming your connection.
>>
>> The only scenario I can think of where returning 444 is a good idea is
>> under
>> a single IP flooding "DoS" because then your not increasing your ports
>> bandwidth output responding to someone who is opening and closing a
>> connection, But in this scenario its more like they are trying to make
>> your
>> server DoS itself by making it max out its own outgoing bandwidth to just
>> their connection alone so nobody else can receive anything.
>>
>> Posted at Nginx Forum: https://forum.nginx.org/read.p
>> hp?2,269873,269879#msg-269879
>>
>> _______________________________________________
>> 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
>>
>
>
>
> _______________________________________________
> 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
Subject Author Posted

444 return code and rate limiting

gariac September 27, 2016 12:46PM

Re: 444 return code and rate limiting

B.R. September 27, 2016 01:10PM

Re: 444 return code and rate limiting

gariac September 27, 2016 01:16PM

Re: 444 return code and rate limiting

c0nw0nk September 27, 2016 02:42PM

Re: 444 return code and rate limiting

gariac September 27, 2016 03:14PM

Re: 444 return code and rate limiting

c0nw0nk September 27, 2016 03:28PM

Re: 444 return code and rate limiting

B.R. September 28, 2016 12:58PM

Re: 444 return code and rate limiting

gariac September 28, 2016 01:32PM

Re: 444 return code and rate limiting

Richard Stanway September 28, 2016 02:00PM

Re: 444 return code and rate limiting

gariac September 28, 2016 04:00PM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 124
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 500 on July 15, 2024
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready