slowloris, accf_http and POST requests

[Dan Nelson]

In the last episode (Jun 22), Ruben de Groot said:
> On Mon, Jun 22, 2009 at 08:45:23AM -0700, Norbert Papke typed:
> > On June 22, 2009, Ruben de Groot wrote:
> > > Can enybody explain why the http accept filter only works on GET/HEAD
> > > requests?
> > >
> > > The reason I ask is I was checking up on the slowloris DOS tool
> > > (http://ha.ckers.org/slowloris/slowloris.pl) and, like others before
> > > me, found that the -httpready switch (which uses POST instead of GET)
> > > renders the accf_http module useless as a protection against this kind
> > > of attack.
> > 
> > With the POST request, the client sends additional data after the
> > header.  This additonal data is the form data (the x-www-form-urlencoded
> > encoded name-value pairs).  The filter will allow the request to proceed
> > to the application after the header as been received but before the form
> > data has been received.
> > 
> > A "slowloris" attack could exploit this fact by sending a complete
> > header but then slowing doling out the form data.
> 
> Apparently, the current incarnation of the slowloris script doesn't do
> that, so adding POST to the methods handled by the http accept filter
> would protect me from script kiddies who want to attack my servers by this
> method.
> 
> My main concern here is if applying the trivial patch I posted would break
> anything in the http protocol layer. And if not, why isn't the POST method
> included in the http accept filter in the first place?

The filter wasn't designed to be an anti-DOS tool; it was an optimization to
save some context switches at the beginning of every request.  POSTs are
infrequent, always include extra trailing data after the headers, and end up
doing more processing at the server end than plain GET or HEADs, so
buffering the first line of the request doesn't really help much.

You're better off adding a request-max-time limit to your webserver, or
doing random-drops of existing connections if you get close to your fd or
thread limit.


-- 
	Dan Nelson
	dnelson at allantgroup.com