You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by fredk2 <fr...@gmail.com> on 2009/07/01 03:56:35 UTC
Re: mod_noloris: mitigating against slowloris-style attack
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 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