Date: Mon, 22 Jun 2009 17:35:56 -0500 From: Dan Nelson <dnelson@allantgroup.com> To: Ruben de Groot <mail25@bzerk.org>, Norbert Papke <npapke@acm.org>, freebsd-questions@freebsd.org Subject: Re: slowloris, accf_http and POST requests Message-ID: <20090622223556.GC76275@dan.emsphone.com> In-Reply-To: <20090622171516.GA82862@ei.bzerk.org> References: <20090622112607.GA80249@ei.bzerk.org> <200906220845.23920.npapke@acm.org> <20090622171516.GA82862@ei.bzerk.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@allantgroup.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090622223556.GC76275>