You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Nick Kew <ni...@webthing.com> on 2009/06/25 15:39:50 UTC
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
Re: mod_noloris: mitigating against slowloris-style attack
Posted by Gonzalo Arana <go...@gmail.com>.
On Wed, Jul 1, 2009 at 9:49 AM, Nick Kew<ni...@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
Re: mod_noloris: mitigating against slowloris-style attack
Posted by Eric Covener <co...@gmail.com>.
On Wed, Jul 1, 2009 at 8:49 AM, Nick Kew<ni...@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@gmail.com
Re: mod_noloris: mitigating against slowloris-style attack
Posted by Nick Kew <ni...@webthing.com>.
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
Re: mod_noloris: mitigating against slowloris-style attack
Posted by Gonzalo Arana <go...@gmail.com>.
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
Re: mod_noloris: mitigating against slowloris-style attack
Posted by Dan Poirier <po...@pobox.com>.
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.
Re: mod_noloris: mitigating against slowloris-style attack
Posted by Nick Kew <ni...@webthing.com>.
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
Re: mod_noloris: mitigating against slowloris-style attack
Posted by Nick Kew <ni...@webthing.com>.
Jeff Trawick wrote:
> On Wed, Jul 1, 2009 at 5:12 AM, Nick Kew <nick@webthing.com
> <ma...@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
Re: mod_noloris: mitigating against slowloris-style attack
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, Jul 1, 2009 at 5:12 AM, Nick Kew <ni...@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?
Re: mod_noloris: mitigating against slowloris-style attack
Posted by Nick Kew <ni...@webthing.com>.
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
Re: mod_noloris: mitigating against slowloris-style attack
Posted by fredk2 <fr...@gmail.com>.
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.
Re: mod_noloris: mitigating against slowloris-style attack
Posted by Nick Kew <ni...@webthing.com>.
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
Re: mod_noloris: mitigating against slowloris-style attack
Posted by Stefan Fritsch <sf...@sfritsch.de>.
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
Re: mod_noloris: mitigating against slowloris-style attack
Posted by Ruediger Pluem <rp...@apache.org>.
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
Re: mod_noloris: mitigating against slowloris-style attack
Posted by Nick Kew <ni...@webthing.com>.
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
Re: mod_noloris: mitigating against slowloris-style attack
Posted by Ruediger Pluem <rp...@apache.org>.
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@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@hatchepsut.acc.umu.se%3e
http://mail-archives.apache.org/mod_mbox/httpd-dev/200808.mbox/%3cPine.GSO.4.64.0808221104590.22704@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@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@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
Re: mod_noloris: mitigating against slowloris-style attack
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Nick Kew
> Gesendet: Donnerstag, 25. Juni 2009 15:40
> An: dev@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
Re: mod_noloris: mitigating against slowloris-style attack
Posted by Eric Covener <co...@gmail.com>.
On Thu, Jun 25, 2009 at 9:39 AM, Nick Kew<ni...@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@gmail.com
Re: mod_noloris: mitigating against slowloris-style attack
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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.
Re: mod_noloris: mitigating against slowloris-style attack
Posted by Nick Kew <ni...@webthing.com>.
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
Re: mod_noloris: mitigating against slowloris-style attack
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 :)
Re: mod_noloris: mitigating against slowloris-style attack
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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.