nginx and Apache killer

[Igor Sysoev]

On Mon, Aug 29, 2011 at 09:30:54PM +0300, Gena Makhomed wrote:
> 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.

max_ranges is obvious soultion. With default value "any".


-- 
Igor Sysoev