Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Using HTTP POST for denial of service

Posted Dec 2, 2010 16:41 UTC (Thu) by adamgundy (subscriber, #5418)
Parent article: Using HTTP POST for denial of service

seems to me the traditional solution for slowloris would solve this ('put nginx in front of your vulnerable server'). it has configurable limits on HTTP body size (post size), which can be configured per-server or per-page, and buffers all of the request before sending it on to the backend server (ie: slow GETs or POSTs get absorbed in their entirety before being handed off to the backend server as fast as possible). you can also set request timeouts. I'm guessing other C10K web servers or proxies would provide the same protection (lighttpd, Cherokee, pound, varnish, etc etc).

(Log in to post comments)

Posted Dec 2, 2010 18:45 UTC (Thu) by skorgu (subscriber, #39558) [Link]

Not to mention the use of CDNs or other proxies as the first point of connection. Does slowlaris et al persist through an Akamai or similar cache?

Using HTTP POST for denial of service

Posted Dec 2, 2010 19:19 UTC (Thu) by adamgundy (subscriber, #5418) [Link]

same thing, but generally CDNs are used for static content (lots of GET requests). some support POST for uploading large files (images, video, etc), but that's less common.

you don't generally put a CDN in front of your 'dynamic' web server domain (because for dynamic content it can't usually help with caching, and just adds another layer of indirection and delay)

layer 7 load balancing proxies will almost certainly 'fix' slowloris AND this 'slowpost' attack - that's what nginx or any of the other servers I listed are doing - DNS round robin etc (poor man's balancing) obviously won't help.

Using HTTP POST for denial of service

Posted Dec 2, 2010 19:34 UTC (Thu) by adamgundy (subscriber, #5418) [Link]

I guess I should add the typical reason people DON'T want to put a smart proxy in front of their apache or IIS server - it breaks their 'fancy upload' script.

most sites that accept content uploads have to work around the fact that browsers don't display any useful progress messages when uploading a file (why? historical I think). they usually end up providing a flash plugin (sigh), then a non-flash solution for flash-refusers (including the vast crowd using any device named iXXXX).

the non-flash solution typically involves polling the server every few seconds to ask 'how much now?' over and over (recent browser enhancements let you get this info client side, but you have to support IE6+ of course - sigh again).

SO: nginx (or any 'caching' proxy) thoughtfully collects all the data before handing it off to the backend server (PHP, ruby, ASP, whatever), and the answer to your poll requests is always 'zero' until it's suddenly '100%'. most of these servers (nginx included) now provide builtin 'upload monitoring' modules that let you poll a particular page to retrieve the answer direct from the proxy instead of your backend script... but that means rewriting your polling code (hiring a web developer, checking that it works, blah, blah - instead of just getting your sysadmin to stick a proxy in front of your web server).