nginx and Apache killer

[Gena Makhomed]

On 29.08.2011 3:15, Maxim Dounin wrote:

>>>>> We'd also like to notify you that for standalone nginx installations
>>>>> we've produced the attached patch. This patch prevents handling
>>>>> malicious range requests at all, instead outputting just the entire file
>>>>> if the total size of all ranges is greater than the expected response.

>>>> this not protect nginx from "frequent nginx disk seek (D)Dos attack",
>>>> and additional max_ranges checks/protections for nginx is required!!!

>>> I don't think the "attack" you are talking about is something
>>> practical.  It requires prior knowledge of urls of many really
>>> large (and "cold", i.e. not cached) files on the attacked site,
>>> and it as well relies on disk seeks to be costly which is not
>>> always true (and almost always not true for a single file, as even
>>> "really large" still usually means "much less than disk size",
>>> i.e. one can't force full disk seeks).

>> one - can't. but, multiple such requests can make very high seek rate
>> of disk subsystem, and performance of disk subsystem will be very low

> For multiple requests you need multiple large and cold files.
> That is what I was talking about.

for example - public mirror servers with multiple large *.iso files

in this and like cases - web server disk subsystem will be bottleneck,
if one malicious request can force nginx to make 411 seek operations
and immediately send to such attacker only ~ 411 bytes as server reply.

nginx now easy can handle thousands of requests in one second,
but server disk subsystem can't efficiently handle so many seeks.
all other methods of DDoS attack to such servers are more laborious.

and if nginx build without optional rewrite module - no way to protect.

>>> (On the other hand, I *do* think that limiting number of ranges to
>>> low number like 5 suggested here and there *is* harmfull.  Quick
>>> look over logs on my server for a couple of days reveals perfectly
>>> valid requests from Adobe Reader with up to 17 ranges.  Minimum
>>> sane value will be something about 50.)

> FWIW: grepped a bit more logs, and it looks like Adobe Reader uses
> up to 200 ranges in a single request.  At least I see multiple
> requests with 200 ranges used (or less), but not any single
> request with more than 200.

for relatively small and "hot" pdf files - this is not problem at all.
such popular pdf file can be completly in operating system file cache.

also, only for such special cases more ranges can be easy allowed:

http {

     max_ranges 1;

     server {

         location ~* \.pdf$ { max_ranges 200; }
     }
}

Adobe Reader will be happy, and also web server will not be
vulnerable to "very frequent disk seek by nginx DDos attack".

or - make the built-in nginx max_ranges autotuning feature:

for bigger files - smaller count of range requests is allowed.

for example:

sz == file_size of requested file_name

sz <= 1M: range requests limited only by large_client_header_buffers

1M < sz <= 64M: allow only 200 range requests, else return 416 error

64M < sz <= 128M: allow only 64 range requests, else return 416 error

128M < sz <= 256M: allow only 32 range requests, else return 416 error

256M < sz <= 512M: allow only 16 range requests, else return 416 error

512M < sz <= 1G: allow only 8 range requests, else return 416 error

1G < sz <= 2G: allow only 4 range requests, else return 416 error

2G < sz <= 4G: allow only 2 range requests, else return 416 error

4G < sz <= inf: allow only 1 range requests, else return 416 error

also - use these rules only if "max_ranges auto;"
and make "auto" the default value for "max_ranges" directive.

if "max_ranges off;" - totally disable this type of protection,
and range requests are limited only by large_client_header_buffers

if "max_ranges N;" - limit current and nested locations to N ranges.

>> probably - this is (special) feature only of some pdf readers software,
>> and for all other file types "max_ranges 1;" will be safe and harmless?

> I've not seen myself any applications using multiple ranges except
> Adobe Reader.  Though there were at least attempts to implement
> JPEG2000 streaming using multiple ranges requests, and probably
> there are other applications as well.

Ok.

Maxim, what you think about built-in nginx protection feature
such as "max_ranges" directive - it will be useless or useful?

I think: with "max_ranges" directive with default value "auto",
nginx will be "secure by default" as vsftpd or postfix servers.

-- 
Best regards,
  Gena