From owner-freebsd-questions@FreeBSD.ORG Mon Jun 22 22:36:01 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D175B106567F for ; Mon, 22 Jun 2009 22:36:01 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id 86B3E8FC2D for ; Mon, 22 Jun 2009 22:36:00 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id n5MMZwSU021429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Jun 2009 17:35:58 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id n5MMZwNg072057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Jun 2009 17:35:58 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.3/Submit) id n5MMZulK072054; Mon, 22 Jun 2009 17:35:56 -0500 (CDT) (envelope-from dan) Date: Mon, 22 Jun 2009 17:35:56 -0500 From: Dan Nelson To: Ruben de Groot , Norbert Papke , freebsd-questions@freebsd.org Message-ID: <20090622223556.GC76275@dan.emsphone.com> References: <20090622112607.GA80249@ei.bzerk.org> <200906220845.23920.npapke@acm.org> <20090622171516.GA82862@ei.bzerk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090622171516.GA82862@ei.bzerk.org> X-OS: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: ClamAV version 0.94.1, clamav-milter version 0.94.1 on email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Mon, 22 Jun 2009 17:35:59 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: Subject: Re: slowloris, accf_http and POST requests X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 22:36:02 -0000 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