Mailing List Archive: Apache: Dev

mod_noloris: mitigating against slowloris-style attack

Index | Next | Previous | View Threaded

nick at webthing

Jun 25, 2009, 6:39 AM

Post #1 of 22 (1256 views)
Permalink

mod_noloris: mitigating against slowloris-style attack

I was just thinking about a quick&dirty fix we could offer
to admins who are suddenly concerned about DoS attack.

The following, backed by dbm or memcache and assuming configurable
default and per-host concurrent connection limits, looks like an
outline candidate and works as a module:

static int noloris_conn(conn_rec *conn)
{
/* kludge: just limit the number of connections per-ip */
/* increment num-conn-from-host
* register pool cleanup to decrement it
* limit = per-host-limit || default-limit
* if (num-conn > limit) {
* drop connection;
* return OK;
* }
return DECLINED;
}
static void noloris_hooks(apr_pool_t *p)
{
ap_hook_process_connection(noloris_conn, NULL, NULL, APR_HOOK_FIRST);
}

Is this worth hacking up, or more trouble than it saves?

--
Nick Kew

covener at gmail

Jun 25, 2009, 6:57 AM

Post #2 of 22 (1223 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

On Thu, Jun 25, 2009 at 9:39 AM, Nick Kew<nick[at]webthing.com> wrote:

> Is this worth hacking up, or more trouble than it saves?

I think an ultra-simple IP-limiting module is useful, but tough/scary
for users to get a whitelist right.

It sounds like wrowess trusted proxy stuff (don't recall the name)
might save us from having to worry about such a list in this module,
which is handy -- but does that account for things like NAT or
mac-forwarding?

--
Eric Covener
covener[at]gmail.com

ruediger.pluem at vodafone

Jun 25, 2009, 7:01 AM

Post #3 of 22 (1220 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

> -----Ursprüngliche Nachricht-----
> Von: Nick Kew
> Gesendet: Donnerstag, 25. Juni 2009 15:40
> An: dev[at]httpd.apache.org
> Betreff: mod_noloris: mitigating against slowloris-style attack
>
> I was just thinking about a quick&dirty fix we could offer
> to admins who are suddenly concerned about DoS attack.
>
> The following, backed by dbm or memcache and assuming configurable
> default and per-host concurrent connection limits, looks like an
> outline candidate and works as a module:
>
> static int noloris_conn(conn_rec *conn)
> {
> /* kludge: just limit the number of connections per-ip */
> /* increment num-conn-from-host
> * register pool cleanup to decrement it
> * limit = per-host-limit || default-limit
> * if (num-conn > limit) {
> * drop connection;
> * return OK;
> * }
> return DECLINED;
> }
> static void noloris_hooks(apr_pool_t *p)
> {
> ap_hook_process_connection(noloris_conn, NULL, NULL,
> APR_HOOK_FIRST);
> }
>
> 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.

Regards

Rüdiger

nick at webthing

Jun 25, 2009, 7:19 AM

Post #4 of 22 (1221 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

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

sf at sfritsch

Jun 25, 2009, 7:45 AM

Post #5 of 22 (1222 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

Nick Kew wrote:
> Is this worth hacking up, or more trouble than it saves?

It seems it already exists (I haven't tested it, though):
ftp://ftp.monshouwer.eu/pub/linux/mod_antiloris/mod_antiloris-0.3.tar.bz2

wrowe at rowe-clan

Jun 25, 2009, 8:12 AM

Post #6 of 22 (1223 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

Nick Kew wrote:
>
> Is this worth hacking up, or more trouble than it saves?

It already lives in /repos/asf/httpd/mod_ftp/trunk/modules/ftp/ ...
see the http://httpd.apache.org/mod_ftp/mod/mod_ftp.html#ftplimitloginip
docs. It would be reasonably simple to rip this out and use a single
shared implementation for both protocols.

An extended scoreboard based solution would be much more efficient,
I suspect.

nick at webthing

Jun 25, 2009, 9:06 AM

Post #7 of 22 (1222 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

On 25 Jun 2009, at 16:12, William A. Rowe, Jr. wrote:

> Nick Kew wrote:
>>
>> Is this worth hacking up, or more trouble than it saves?
>
> It already lives in /repos/asf/httpd/mod_ftp/trunk/modules/ftp/ ...
> see the http://httpd.apache.org/mod_ftp/mod/
> mod_ftp.html#ftplimitloginip
> docs. It would be reasonably simple to rip this out and use a single
> shared implementation for both protocols.

OK, will look.

> An extended scoreboard based solution would be much more efficient,
> I suspect.

How would you keep an index keyed on client-IP using scoreboard?
Or did you have something else in mind?

--
Nick Kew

wrowe at rowe-clan

Jun 25, 2009, 9:53 AM

Post #8 of 22 (1221 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

Nick Kew wrote:
>
> How would you keep an index keyed on client-IP using scoreboard?
> Or did you have something else in mind?

Exactly; this could not be keyed. Not without additional data and
additional cross-thread+cross-proc locking semantics.

If we can tolerate a 'soft limit' then simply memcmp'ing the client
of scoreboard slot might be more efficient than the whole locking
and db access overhead, at least for cases of ~500 clients or less.
To get a hard and fast limit, locking is required.

rpluem at apache

Jun 25, 2009, 10:38 AM

Post #9 of 22 (1210 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

On 06/25/2009 04:01 PM, Plüm, Rüdiger, VF-Group wrote:
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Nick Kew
>> Gesendet: Donnerstag, 25. Juni 2009 15:40
>> An: dev[at]httpd.apache.org
>> Betreff: mod_noloris: mitigating against slowloris-style attack
>>
>> I was just thinking about a quick&dirty fix we could offer
>> to admins who are suddenly concerned about DoS attack.
>>
>> The following, backed by dbm or memcache and assuming configurable
>> default and per-host concurrent connection limits, looks like an
>> outline candidate and works as a module:
>>
>> static int noloris_conn(conn_rec *conn)
>> {
>> /* kludge: just limit the number of connections per-ip */
>> /* increment num-conn-from-host
>> * register pool cleanup to decrement it
>> * limit = per-host-limit || default-limit
>> * if (num-conn > limit) {
>> * drop connection;
>> * return OK;
>> * }
>> return DECLINED;
>> }
>> static void noloris_hooks(apr_pool_t *p)
>> {
>> ap_hook_process_connection(noloris_conn, NULL, NULL,
>> APR_HOOK_FIRST);
>> }
>>
>> 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.

The idea to move mod_limitipconn inside httpd is nearly one year old.

See
http://mail-archives.apache.org/mod_mbox/httpd-dev/200806.mbox/%3cPine.GSO.4.64.0806181704510.11344[at]hatchepsut.acc.umu.se%3e
http://mail-archives.apache.org/mod_mbox/httpd-dev/200808.mbox/%3cPine.GSO.4.64.0808221104590.22704[at]hatchepsut.acc.umu.se%3e

David Jao the author of the module said that the latest version is ASL2.0 licensed

http://mail-archives.apache.org/mod_mbox/httpd-dev/200806.mbox/%3c485B942B.8060206[at]dominia.org%3e

and that he would sign a software grant if needed.

http://mail-archives.apache.org/mod_mbox/httpd-dev/200808.mbox/%3c48AF281F.1030303[at]dominia.org%3e

Do we need such a grant if it is ASL2.0 licensed?

Does anybody see any *license* (not *technical* or *project*) issues importing it into trunk and using
it as a base for a module to mitigate slowloris-style attacks?

Regards

Rüdiger

rpluem at apache

Jun 25, 2009, 10:43 AM

Post #10 of 22 (1206 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

On 06/25/2009 04:19 PM, Nick Kew wrote:
> 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 have and use a patch that hooks it up to the preconnection hook
and checks if the number of connections from the IP of the connection
that are in read state breaks a certain limit. If yes, the connection
is closed.
So this is fixable in principle.
But I must admit that my patch is very old and I don't know if it
still follows my current quality requirements for the httpd project :-).
Plus it is against an old version. But the only real problem that I
see here is that I am like others currently working very close to ENOTIME.

Regards

Rüdiger

nick at webthing

Jun 25, 2009, 12:48 PM

Post #11 of 22 (1208 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

Stefan Fritsch wrote:
> Nick Kew wrote:
>> Is this worth hacking up, or more trouble than it saves?
>
> It seems it already exists (I haven't tested it, though):
> ftp://ftp.monshouwer.eu/pub/linux/mod_antiloris/mod_antiloris-0.3.tar.bz2
>
Looks almost what I had in mind. But it's geared clearly to
the very small server. Which is, to be fair, exactly what's
most threatened by slowloris. I have a meeting now, but will
test-drive tonight.

I see it's also Apache-licensed :-)

--
Nick Kew

jim at jaguNET

Jun 29, 2009, 10:05 AM

Post #12 of 22 (1059 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

On Jun 25, 2009, at 11:12 AM, William A. Rowe, Jr. wrote:

> Nick Kew wrote:
>>
>> Is this worth hacking up, or more trouble than it saves?
>
> It already lives in /repos/asf/httpd/mod_ftp/trunk/modules/ftp/ ...
> see the http://httpd.apache.org/mod_ftp/mod/mod_ftp.html#ftplimitloginip
> docs. It would be reasonably simple to rip this out and use a single
> shared implementation for both protocols.
>
> An extended scoreboard based solution would be much more efficient,
> I suspect.
>

Actually, I have a hacked version that uses mod_slotmem :)

fredk2 at gmail

Jun 30, 2009, 6:56 PM

Post #13 of 22 (1029 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

Hi Nick,

I looked at the code (I am not a coder) and wondered what made you say "it's
geared clearly to the very small server. "

Rgds - Fred

Nick Kew wrote:
>
> Stefan Fritsch wrote:
>> Nick Kew wrote:
>>> Is this worth hacking up, or more trouble than it saves?
>>
>> It seems it already exists (I haven't tested it, though):
>> ftp://ftp.monshouwer.eu/pub/linux/mod_antiloris/mod_antiloris-0.3.tar.bz2
>>
> Looks almost what I had in mind. But it's geared clearly to
> the very small server. Which is, to be fair, exactly what's
> most threatened by slowloris. I have a meeting now, but will
> test-drive tonight.
>
> I see it's also Apache-licensed :-)
>
> --
> Nick Kew
>
>

--
View this message in context: http://www.nabble.com/mod_noloris%3A-mitigating-against-slowloris-style-attack-tp24203476p24282962.html
Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.

nick at webthing

Jul 1, 2009, 2:12 AM

Post #14 of 22 (1025 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

fredk2 wrote:
> Hi Nick,
>
> I looked at the code (I am not a coder) and wondered what made you say "it's
> geared clearly to the very small server. "

It gives you the overhead of reading the entire scoreboard for
every request. You don't want to do that with high traffic,
nor with anything but a very small scoreboard.

--
Nick Kew

trawick at gmail

Jul 1, 2009, 4:57 AM

Post #15 of 22 (1019 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

On Wed, Jul 1, 2009 at 5:12 AM, Nick Kew <nick[at]webthing.com> wrote:

> fredk2 wrote:
>
>> Hi Nick,
>>
>> I looked at the code (I am not a coder) and wondered what made you say
>> "it's
>> geared clearly to the very small server. "
>>
>
> It gives you the overhead of reading the entire scoreboard for
> every request. You don't want to do that with high traffic,
> nor with anything but a very small scoreboard.

[I haven't looked at the code for a moment but] why doesn't the parent do
the scanning? Aside from an implementation detail or two, isn't that the
only practical implementation?

nick at webthing

Jul 1, 2009, 5:04 AM

Post #16 of 22 (1021 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

Jeff Trawick wrote:
> On Wed, Jul 1, 2009 at 5:12 AM, Nick Kew <nick[at]webthing.com
> <mailto:nick[at]webthing.com>> wrote:
>
> fredk2 wrote:
>
> Hi Nick,
>
> I looked at the code (I am not a coder) and wondered what made
> you say "it's
> geared clearly to the very small server. "
>
>
> It gives you the overhead of reading the entire scoreboard for
> every request. You don't want to do that with high traffic,
> nor with anything but a very small scoreboard.
>
>
> [I haven't looked at the code for a moment but] why doesn't the parent
> do the scanning? Aside from an implementation detail or two, isn't that
> the only practical implementation?
>

I've actually hacked up mod_noloris to do exactly that. Was planning to
test-drive then post, but since you bring the matter up, I'll attach it
here and now.

Commit to trunk?

--
Nick Kew

Attachments:

mod_noloris.c (8.22 KB)

gonzalo.arana at gmail

Jul 1, 2009, 5:33 AM

Post #17 of 22 (1021 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

Hi,

Keeping whitelist up to date is rather tricky.

How about having any/all of these directives?

# time between accept(2) call and the full request has been read.
RequestTimeout 1

# minimum bandwith the user should have available to access this server.
MinInRate 2KB/s
MinOutRate 3KB/s

One extra note: it would be good to let these Min{In,Out}Rate be
overriden for large files (audio/video files, for instance).

Best regards,

--
Gonzalo A. Arana

nick at webthing

Jul 1, 2009, 5:45 AM

Post #18 of 22 (1017 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

Nick Kew wrote:

> I've actually hacked up mod_noloris to do exactly that. Was planning to
> test-drive then post, but since you bring the matter up, I'll attach it
> here and now.

Having already fixed a couple of typos in the attachment,
I've uploaded to http://people.apache.org/~niq/mod_noloris.c
Please review that rather than the attachment.

--
Nick Kew

nick at webthing

Jul 1, 2009, 5:49 AM

Post #19 of 22 (1019 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

Gonzalo Arana wrote:
> Hi,
>
> Keeping whitelist up to date is rather tricky.
>
> How about having any/all of these directives?
>
> # time between accept(2) call and the full request has been read.
> RequestTimeout 1
>
> # minimum bandwith the user should have available to access this server.
> MinInRate 2KB/s
> MinOutRate 3KB/s

That'll completely exclude people on slow connections!
But it's something you could implement in a bandwidth-management
module.

> One extra note: it would be good to let these Min{In,Out}Rate be
> overriden for large files (audio/video files, for instance).

You don't have anything as specific as a file in a slowloris-type
attack. You appear to be envisaging something much closer to
various (existing, third-party) bandwidth-management modules.

--
Nick Kew

covener at gmail

Jul 1, 2009, 6:12 AM

Post #20 of 22 (1020 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

On Wed, Jul 1, 2009 at 8:49 AM, Nick Kew<nick[at]webthing.com> wrote:
> Gonzalo Arana wrote:
>>
>> Hi,
>>
>> Keeping whitelist up to date is rather tricky.
>>
>> How about having any/all of these directives?
>>
>> # time between accept(2) call and the full request has been read.
>> RequestTimeout 1

Also interested here if anyone has given much thought to end-to-end
timers to evict the abusive clients that do make it in.

--
Eric Covener
covener[at]gmail.com

poirier at pobox

Jul 1, 2009, 6:30 AM

Post #21 of 22 (1007 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

To avoid a ban on 89.0.0.13 also banning 9.0.0.1, we might want to
include the separators in the strstr, as in the attached patch.

Attachments:

mod_noloris.c.patch (1.03 KB)

gonzalo.arana at gmail

Jul 1, 2009, 6:32 AM

Post #22 of 22 (1007 views)
Permalink

Re: mod_noloris: mitigating against slowloris-style attack [In reply to]

On Wed, Jul 1, 2009 at 9:49 AM, Nick Kew<nick[at]webthing.com> wrote:
> Gonzalo Arana wrote:
>>
>> Hi,
>>
>> Keeping whitelist up to date is rather tricky.
>>
>> How about having any/all of these directives?
>>
>> # time between accept(2) call and the full request has been read.
>> RequestTimeout 1
>>
>> # minimum bandwith the user should have available to access this server.
>> MinInRate 2KB/s
>> MinOutRate 3KB/s
>
> That'll completely exclude people on slow connections!

The RequestTimeout could aid in telling appart slow connections from
slowloris attack.

Is there any other way to tell apart a slow connection from slowloris
attack without keeping a whitelist?

The purpose of having this value tunable via a directive is to let any
sysadmin to change this value.

> But it's something you could implement in a bandwidth-management
> module.

I agree.

>> One extra note: it would be good to let these Min{In,Out}Rate be
>> overriden for large files (audio/video files, for instance).
>
> You don't have anything as specific as a file in a slowloris-type
> attack. You appear to be envisaging something much closer to
> various (existing, third-party) bandwidth-management modules.

I know the slowloris attack do not depend on the file size.
MinOutRate could be raised on some cases anyway.

These directives resemble bandwith-managment, but wouldn't this help
on the slowloris attack, without adding the need for a whitelist
managment?

>
> --
> Nick Kew
>

Best regards,

--
Gonzalo A. Arana

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com