slowloris, accf_http and POST requests

Michael Powell nightrecon at
Tue Jun 23 14:33:54 UTC 2009

Ruben de Groot 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.
>> 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.
> Well, it helps against this slowloris script. And I don't see it costing
> 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.
> I'm exploring these options as well, but they have their own drawbacks.
> Anyway, since it doesn't look like I'm breaking anything by buffering the
> POST headers, I'm gonna maintain this as a local patch until something
> better comes along.

I was interested to follow this, as I was under the impression http accept 
filter was more for performance rather than security. Since I use it anyway 
I was happy to learn of these facts.

Although not directly related, per se, you may also be interested in:

It can be useful in narrowing the scope of allowable POST content to 
mitigate SQL injection techniques. The default pattern is overly broad but 
if you are only intent on tightening up one web app on one server it is 
possible to tune it to be more specific. Not a magic bullet, but every layer 
in the onion helps.


More information about the freebsd-questions mailing list