Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4A43876D.1050604@webthing.com>
Date: Thu, 25 Jun 2009 15:19:25 +0100
From: Nick Kew <nick@webthing.com>
User-Agent: Thunderbird 2.0.0.21 (X11/20090323)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: mod_noloris: mitigating against slowloris-style attack
References: <4A437E26.2050103@webthing.com>
 <99EA83DCDE961346AFA9B5EC33FEC08B02551D35@VF-MBX11.internal.vodafone.com>
In-Reply-To: 
 <99EA83DCDE961346AFA9B5EC33FEC08B02551D35@VF-MBX11.internal.vodafone.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Pl�m, R�diger, VF-Group wrote:

>> Is this worth hacking up, or more trouble than it saves?
> 
> I guess the approach is good, but there are already modules in the
> wild that provide this. So the question is: Should we do our own?
> BTW: I remember that there was a request a while ago to move mod_limitipconn
> (one of those modules) inside httpd, but I haven't got the archives
> at hand right now to check. Maybe an idea to come back to this.

mod_limitipconn works at the request level, so won't help with
slowloris-style attacks.  Same goes for mod_evasive - someone
posted "mod_evasive doesn't help" on users@, and that'll be why.

I'm not sure whether any of the traffic-management modules
work on connections (anyone know)?  If so, then yes, we could
just point to them as a fix until we produce something better
than mod_noloris.

-- 
Nick Kew