Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: Stefan Fritsch <sf@sfritsch.de>
To: dev@httpd.apache.org
Subject: Re: Crazy slowloris mitigation patch
Date: Sun, 18 Oct 2009 10:37:31 +0200
User-Agent: KMail/1.12.2 (Linux/2.6.30-1-686; KDE/4.3.2; i686; ; )
References: <1255640418.4989.42.camel@shrek.rexursive.com>
 <1255851358.4989.62.camel@shrek.rexursive.com>
In-Reply-To: <1255851358.4989.62.camel@shrek.rexursive.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <200910181037.31497.sf@sfritsch.de>

On Sunday 18 October 2009, Bojan Smojver wrote:
> The idea here is that a busy server is highly unlikely to be stuck
> reading using all its children over a maintenance interval (i.e. we
> expect at least one of those readers to turn into something else
>  during the interval).

An attacker can easily circumvent this by opening one connection that 
slowly downloads a large file. Checking for a certain percentage of 
all children would be better.

However, there is a real problem with all approaches that look for 
SERVER_BUSY_READ: The attacker can just use a URL that accepts POST 
requests and send the request body very slowly. These connections have 
the state SERVER_BUSY_WRITE. This problem affects mod_antiloris and 
mod_noloris, too (but not mod_reqtimeout).

Maybe another state SERVER_BUSY_READ_BODY could be introduced? Or the 
state could be changed to SERVER_BUSY_READ again when the request body 
is read? I haven't checked how difficult this would be, though.