Welcome! Log In Create A New Profile

Advanced

Re: 444 return code and rate limiting

B.R.
September 27, 2016 01:10PM
Responding 444 is... a response.

It is not anything else than a (non-standard, thus 'unknown', just like 499
nginx chose to illustrate client-side premature disconnection) HTTP status
code as any other.
Some speedup might come from using return instead of doing further
processing, but there is still a connection, data sent, data processed and
response sent. Basically resources are being burned up and not available
for another request/client.

HTTP status code do not do anything by themselves, they are just part of a
protocol legitimate clients implement. I do not think attackers care much
about status code other than what they guess about the server.

In case of DoS, your only hope is to divert/absorb the flow.
​Blabbering about status codes​ as a potential solution to DoS shows deep
misunderstanding of what is being discussed and is pure nonsense.
---
*B. R.*

On Tue, Sep 27, 2016 at 6:44 PM, <lists@lazygranch.com> wrote:

> I pulled this off the rate limiting thread since I think the 444 return is
> a good topic all on its own.
>
> "But under a DoS attack I always feel those values would be better being
> "444" since the server won't respond and cut's the connection rather than
> waste bandwidth on a client who is opening and closing connections fast as
> a
> bullet.‎"
>
> Looking at the times in my nginx access.log, I don't believe any
> connection is cut. Rather nginx just doesn't respond. A browser will wait
> an appropriate amount of time before it decides there is no response, but
> the code from the hackers just keeps hammering the server.
>
> What I don't know is if the 444 return effects the nginx rate limiting
> coding since you have effectively not returned anything, so what is there
> to limit?
>
> The experiment would be to hammer your webserver from the server itself
> rather than over the Internet, and see if it does get rate limited. That
> would take network losses out of the picture.
>
> When I get a chance, I'm going to pastebin the logs from that attack I got
> from the Hong Kong server so the times can be seen.
>
> _______________________________________________
> 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: 145
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