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

[nikhil kohli <ce...@gmail.com>]

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

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

[nikhil kohli <ce...@gmail.com>]

Thanks for the reply.

I just checked the size of the requests issued by slowloris, it is
very samll as comapred to the valid requests. So i was wondering if we
can adjust the timeout according the request length.

The idea is set to low timeout for the request lengths lower than a
threshold value. Please help me understand the consequences of such an
approach.

Thanks and regards,
Nikhil




On Tue, Sep 1, 2009 at 5:08 PM, Eric Covener <co...@gmail.com> wrote:
>
> On Tue, Sep 1, 2009 at 5:58 AM, nikhil kohli<ce...@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@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@gmail.com

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

[Eric Covener <co...@gmail.com>]

On Tue, Sep 1, 2009 at 5:58 AM, nikhil kohli<ce...@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@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@gmail.com