atom feed14 messages in ru.sysoev.nginxRe: nginx and Apache killer
FromSent OnAttachments
Igor SysoevAug 27, 2011 1:10 am.ranges
Juan Angulo MorenoAug 27, 2011 7:03 pm 
Maxim DouninAug 28, 2011 1:45 am 
Venky ShankarAug 28, 2011 2:41 am 
Gena MakhomedAug 28, 2011 7:18 am 
Maxim DouninAug 28, 2011 7:24 am 
Maxim DouninAug 28, 2011 9:35 am 
Venky ShankarAug 28, 2011 9:48 am 
Maxim DouninAug 28, 2011 1:21 pm 
Gena MakhomedAug 28, 2011 1:38 pm 
Maxim DouninAug 28, 2011 5:14 pm 
Gena MakhomedAug 29, 2011 11:30 am 
Igor SysoevAug 29, 2011 11:45 am 
Jim OhlsteinSep 1, 2011 4:59 am 
Subject:Re: nginx and Apache killer
From:Gena Makhomed (gm@csdoc.com)
Date:Aug 29, 2011 11:30:19 am
List:ru.sysoev.nginx

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

_______________________________________________ nginx mailing list ngi@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx