Nick Kew | 1 Sep 01:05 2009

Re: mod_reqtimeout: mitigating against slowloris-style attack (different approach)

Stefan Fritsch wrote:
> Hi,
> 
> since there was some doubt that the mod_antiloris and mod_noloris 
> modules use the correct approach against slowloris type attacks, I 
> hacked up something different.  mod_reqtimeout allows to set timeouts 
> for the reading request and reading body phases.  It is implemented as 
> an input connection filter that sets the socket timeout so that the 
> total request time does not exceed the timeout value. I have done only 
> limited testing but it seems to work (with prefork).  The source is 
> here:
> 
> http://www.sfritsch.de/mod_reqtimeout/mod_reqtimeout.c

On a quick glance: interesting approach, thanks for posting.
How does it relate to the Timeout directive?

One comment: you're returning APR_EGENERAL if there's no config.
I'd strongly suggest you always do-nothing if not configured.
Or if not-configured is a can't-happen event, catch it with
an ap_assert.

> - Is this a reasonable approach or did I overlook something important? 
> If the former, would you consider including something like it with 
> httpd?

Would need think-time to answer that (and it's way too noisy to think
here).

> - How do I prevent the filter from being inserted for other protocols 
(Continue reading)

Stefan Fritsch | 1 Sep 08:42 2009
Picon

Re: mod_reqtimeout: mitigating against slowloris-style attack (different approach)

On Tuesday 01 September 2009, Nick Kew wrote:
> How does it relate to the Timeout directive?

The Timeout directive sets the maximum time between two packets. 
mod_requtimeout will set the socket timeout to the minumum of 
{Timeout, time left for the current request}. You can set 
RequestTimeout to much lower values than Timeout and it still works as 
expected.

>
> One comment: you're returning APR_EGENERAL if there's no config.
> I'd strongly suggest you always do-nothing if not configured.
> Or if not-configured is a can't-happen event, catch it with
> an ap_assert.

Not-configured should not happen and would be a bug, I will change it 
to ap_assert.

> > - Obviously the body read timeout is only useful for sites that
> > do not allow file uploads. But an extension to a minimum body
> > transfer rate would probably be possible. Also, it would be
> > possible to make the body read timeout configurable by direcory,
> > which may be useful if file uploads are only allowed by
> > authorized users.
>
> The body part probably overlaps with what existing modules like
> mod_evasive and the bandwidth-management modules do.  Have you
> looked at them?

I haven't looked very closely at them. But from the descriptions it 
(Continue reading)

nikhil kohli | 1 Sep 11:58 2009
Picon

slowloris DoS attack-How to check time taken by server for reading a request

Hello Everyone,

This is regarding the slowloris issue. I'm trying to mitigate this issue using iptables by restricting the no. of connection to a certain limit. Also i see the new experimental module mod_noloris.c having similar approach to mitigate slowloris attack. I have few questions regarding this  approach.
1. Can we mitigate the issue using iptables only?
2. Even mod_noloris.c is vulnerable to slowloris attack, will there be a change in approach for solving this in future?
3. Is there a way to delay the process of creating connection until whole header is received?
4. How to check time taken by server for reading the request?
Also, may i know if apache team acknowledge slowloris as issue or not?
Thanks in advance.
Thanks and Regards,
Nikhil Kohli
Eric Covener | 1 Sep 13:38 2009
Picon

Re: slowloris DoS attack-How to check time taken by server for reading a request

On Tue, Sep 1, 2009 at 5:58 AM, nikhil kohli<ce.kohli.nikhil <at> gmail.com> wrote:

> 1. Can we mitigate the issue using iptables only?

That seems to be the conventional wisdom.

> 2. Even mod_noloris.c is vulnerable to slowloris attack, will there be a
> change in approach for solving this in future?

People seem to be working on it from a few angles, and there are
already multiple modules that address it -- I wouldn't call this one
authoritative or final in any way.

> 3. Is there a way to delay the process of creating connection until whole
> header is received?

I don't think so, can you elaborate on what you mean by creating a connection?

> 4. How to check time taken by server for reading the request?

The core notes the time when the request line is read, but not when
all the headers are done.  Modules are can easily note these times
though by springing to life in the right hook.

These types of questions are better posed on modules-dev <at> httpd.apache.org

> Also, may i know if apache team acknowledge slowloris as issue or not?

Can't speak for anyone else, but it seems to be acknowledged mostly as
a scalability/optimization issue which has already been on the radar
(and only as a pressing issue at the firewall level)

--

-- 
Eric Covener
covener <at> gmail.com

Torsten Foertsch | 1 Sep 16:26 2009
Picon
Picon

Re: mod_reqtimeout: mitigating against slowloris-style attack (different approach)

On Tue 01 Sep 2009, Stefan Fritsch wrote:
> http://www.sfritsch.de/mod_reqtimeout/mod_reqtimeout.c
>
> Any comments are welcome.

Just a few thoughts:

- You use GLOBAL_ONLY in ap_check_cmd_context. That means the directive 
must not appear in vhost context. AFAIK, conn->base_server reflects the 
vhost in a pre connection hook if it is IP-based. So, why don't you 
allow for RequestTimeout to be valid in ip-based vhost context? That 
way the protocol problem is solved, isn't it?

- Wouldn't RequestTimeout better be named RequestHeaderTimeout or 
ReadRequestHeaderTimeout? RequestTimeout is a bit missleading (IMHO). 
My first thought was: That thing limits the whole transaction.

- You mentioned a minimum body transfer rate instead of a simple 
timeout. If the default values for LimitRequestFields, 
LimitRequestFieldSize and LimitRequestLine are added up I get a max. 
request header size of 101*8190 bytes. This may take some time to 
transmit while still valid. So, perhaps a transfer rate limit for the 
header is a good option, as well. Perhaps having both a timeout and a 
rate limit would be good.

Just my 0.02€.

Torsten

--

-- 
Need professional mod_perl support?
Just hire me: torsten.foertsch <at> gmx.net

Stefan Fritsch | 1 Sep 20:47 2009
Picon

Re: mod_reqtimeout: mitigating against slowloris-style attack (different approach)

On Tuesday 01 September 2009, Torsten Foertsch wrote:
> Just a few thoughts:
>
> - You use GLOBAL_ONLY in ap_check_cmd_context. That means the
> directive must not appear in vhost context. AFAIK,
> conn->base_server reflects the vhost in a pre connection hook if it
> is IP-based. So, why don't you allow for RequestTimeout to be valid
> in ip-based vhost context?

Basically because I didn't get around to write the merge function yet. 
But it's on my todo list.

> That way the protocol problem is solved,
> isn't it?

That's true. It's probably not necessary to detect non-http virtual 
hosts automatically. Just let the admin configure it.

> - Wouldn't RequestTimeout better be named RequestHeaderTimeout or
> ReadRequestHeaderTimeout? RequestTimeout is a bit missleading
> (IMHO). My first thought was: That thing limits the whole
> transaction.

Maybe. I will think about this.

>
> - You mentioned a minimum body transfer rate instead of a simple
> timeout. If the default values for LimitRequestFields,
> LimitRequestFieldSize and LimitRequestLine are added up I get a
> max. request header size of 101*8190 bytes. This may take some time
> to transmit while still valid. So, perhaps a transfer rate limit
> for the header is a good option, as well. Perhaps having both a
> timeout and a rate limit would be good.

A more realistic estimate for the maximum for a valid request is 
10*8190 + 91*100, i.e. there are normally only very vew long lines. 
But if the transfer rate function is added for the body, it's easy to 
add it for the headers, too.

Ruediger Pluem | 1 Sep 21:09 2009
Picon

Re: mod_reqtimeout: mitigating against slowloris-style attack (different approach)


On 09/01/2009 04:26 PM, Torsten Foertsch wrote:
> On Tue 01 Sep 2009, Stefan Fritsch wrote:
>> http://www.sfritsch.de/mod_reqtimeout/mod_reqtimeout.c
>>
>> Any comments are welcome.
> 
> Just a few thoughts:
> 
> - You use GLOBAL_ONLY in ap_check_cmd_context. That means the directive 
> must not appear in vhost context. AFAIK, conn->base_server reflects the 
> vhost in a pre connection hook if it is IP-based. So, why don't you 
> allow for RequestTimeout to be valid in ip-based vhost context? That 
> way the protocol problem is solved, isn't it?
> 
> - Wouldn't RequestTimeout better be named RequestHeaderTimeout or 
> ReadRequestHeaderTimeout? RequestTimeout is a bit missleading (IMHO). 
> My first thought was: That thing limits the whole transaction.

Nice module. +1 to the comments above.

Regards

Rüdiger

Ruediger Pluem | 1 Sep 21:13 2009
Picon

Re: mod_reqtimeout: mitigating against slowloris-style attack (different approach)


On 09/01/2009 08:42 AM, Stefan Fritsch wrote:
> On Tuesday 01 September 2009, Nick Kew wrote:

> 
>>> - Apache should respond with HTTP_REQUEST_TIME_OUT and not
>>> HTTP_BAD_REQUEST when there is a timeout reading the request.
>> In the slowloris case, it needs to time out before there's any such
>> thing as an HTTP request, so it won't be sending an HTTP response.
>> But I guess you're talking about the body timeout?
> 
> No, about the request. When apache has received at least one line of 
> the request, it currently responds with HTTP_BAD_REQUEST when there is 
> a timeout before the complete request was read. In this case 
> HTTP_REQUEST_TIME_OUT is more appropriate. It means "the client did 
> not produce a request within the time that the server was prepared to 
> wait".

Is this just regarding better logging on the server side? Otherwise I
wouldn't care too much what we sent to an attacker.

Regards

Rüdiger

Gregg L. Smith | 1 Sep 21:38 2009

Re: svn commit: r808965 - signature spam and an existing restriction

Hi Devs,

A vote of mine does not count but I think I am leaning on a -1 here for 
a couple reasons.

1. in ap_release.h you have placed a restriction on just this sort of thing;

  * "Product tokens should be short and to the point -- use of them for
  * advertizing or other non-essential information is explicitly forbidden."

Granted, if someone wanted to, there is not much you can really do about 
it. What I might find as useful information you might just as well deem 
non-essential. BTW, advertising and essential are misspelled. Does 
handing the user a set of keys to do just this now negate this 
restriction or if it is still of concern, should this be added into the 
docs?

2. with mod_security this can already be done with the use of the 
SecServerSignature directive. 
http://www.modsecurity.org/documentation/modsecurity-apache/2.5.9/modsecurity2-apache-reference.html#N10B69

3. Not that Netcraft is a scientifically sound survey, I'd still hate to 
see Apache jump off the cliff.

Just a sampling of random thoughts I had when I saw this.

Regards,
Gregg

jim <at> apache.org wrote:
> Author: jim
> Date: Fri Aug 28 17:37:12 2009
> New Revision: 808965
> 
> URL: http://svn.apache.org/viewvc?rev=808965&view=rev
> Log:
> And additional ServerTokens improvement...
> 
> Modified:
>     httpd/httpd/trunk/CHANGES
>     httpd/httpd/trunk/docs/manual/mod/core.xml
>     httpd/httpd/trunk/server/core.c
> 

Stefan Fritsch | 1 Sep 22:16 2009
Picon

Re: mod_reqtimeout: mitigating against slowloris-style attack (different approach)

On Tuesday 01 September 2009, Ruediger Pluem wrote:
> On 09/01/2009 04:26 PM, Torsten Foertsch wrote:
> > On Tue 01 Sep 2009, Stefan Fritsch wrote:
> >> http://www.sfritsch.de/mod_reqtimeout/mod_reqtimeout.c
> >>
> >> Any comments are welcome.
> >
> > Just a few thoughts:
> >
> > - You use GLOBAL_ONLY in ap_check_cmd_context. That means the
> > directive must not appear in vhost context. AFAIK,
> > conn->base_server reflects the vhost in a pre connection hook if
> > it is IP-based. So, why don't you allow for RequestTimeout to be
> > valid in ip-based vhost context? That way the protocol problem is
> > solved, isn't it?
> >
> > - Wouldn't RequestTimeout better be named RequestHeaderTimeout or
> > ReadRequestHeaderTimeout? RequestTimeout is a bit missleading
> > (IMHO). My first thought was: That thing limits the whole
> > transaction.
>
> Nice module. +1 to the comments above.

Thanks to everyone commenting so far. I have changed these two things 
and uploaded the new version to the same place.

Stefan


Gmane