slowloris, accf_http and POST requests

[Ruben de Groot]

On Tue, Jun 23, 2009 at 05:23:19PM +0200, Fabian Keil typed:
> Ruben de Groot <mail25 at bzerk.org> wrote:
> 
> > On Mon, Jun 22, 2009 at 05:35:56PM -0500, Dan Nelson typed:
> > > In the last episode (Jun 22), Ruben de Groot said:
> > > > 
> > > > 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
> > 
> > I know this. But in this particular case, it *works* as an anti-DOS
> > tool. And a pretty good one too.
> 
> How did you verify this?

By using the slowloris script against my own servers.
Running the script from a single client pc:

./slowloris.pl -dns myserver.domain.tld -port 80 -timeout 2000 -num 500 -tcpto 5 -httpready

brings apache to its knees. No more connections are accepted as there
are allready MaxClients processes running (150) and they're all 
just sitting there waiting.
With accf_http just slightly adjusted as posted, nothing happens at all.
Apache just doesn't see the connections, even with multiple clients
running the DOS.
(Off course, there'll be memory buffers in the kernel filling, but
from that I haven't seen any negative side effects yet)

> accf_http doesn't require a complete request but will also
> pass the connection to the userland if its buffer is full.

Haven't seen that, but it sounds sane.

> If you continue to send headers that will happen eventually and if
> you're impatient, you simply have to send a bit more headers at the
> beginning to reach the application faster.

Yes. A real and prolonged DDOS is hard to counter. And the accept filter
was not designed for that. It was just an observation about this
particular script.

cheers,
Ruben