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

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