Re: [Mod-security-developers] Advanced Slow DoS Mitigation

[Ryan B. <RBa...@tr...>]

On 7/5/11 2:42 PM, "Christian Folini" <chr...@ti...>
wrote:

>Hi there,

Hey Christian!  Application (D)DoS detection and mitigation is a very
challenging and important topic and merits more discussion so thank you
for the email.


>
>ModSecurity always had a few nice options to help with request delaying
>mitigation. The combination with mod_reqtimeout is a good strategy as
>explained by Ryan at
>http://blog.spiderlabs.com/2010/11/advanced-topic-of-the-week-mitigating-s
>low-http-dos-attacks.html

Did you see that Breno recently added SecWriteStateLimit as well to help
mitigate Slow POST Attacks?
http://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Referenc
e_Manual#SecWriteStateLimit



>
>In May, I did a presentation on the defense against Request Delaying DDoS
>aka as Slow DoS or Slowloris type attacks. That Swiss Cyberstorm talk is
>now online at http://www.youtube.com/watch?v=svN49PIbcks

Great preso and really highlights the threat.  I was wondering what
percentage of WikiLeaks DoS attacks were utilizing Slowloris-type
techniques.

>
>Around 32:30, I mention some advanced ideas on how to identify attackers
>very easily.
>
>As you know, a POST request to /index.html is perfectly okay with
>Apache. You can prevent it with ModSecurity, but not immediately
>when the server receives the requestline.
>
>Ideally, you should be able to drop a request trying this immediately.
>I would like to write rules that trigger as soon as the request line
>has been received. A phase 0 somehow.

We are currently having a discussion about ModSecurity's phases in this
Jira ticket - https://www.modsecurity.org/tracker/browse/MODSEC-98

Specifically, phase:1 was moved by Ivan awhile ago to be the same as
phase:2 (instead of Apache post-read-request) due to many users wanting to
use phase:1 rules inside Apache scope directives like <Location>.  I
personally do not agree with this change and we are reviewing a potential
change back.

Regardless - I believe that we should consider a "phase:0" option that
would essentially work at the Apache Filter level hook.  So, this would
not be parsed like the other variables but could give basic access to src
IP data and the entire request payload as perhaps a new variable -
THE_REQUEST.

>
>This would also be handy to drop requests that try to upload files
>before the user has been authenticated. Apache does not mind large
>uploads from unauthenticated users until it has received the whole
>blob. Not even mod_reqtimeout is of big help if you need to allow
>big file uploads.
>
>Now I doubt that Apache allows for a phase 0 (I am not an apache
>developer and
>as you know not even a ModSecurity developer) as there seems to be no
>hook at that moment and if I get it right, the whole request record
>is not being prepared until post-read-request. But maybe I am wrong.

The main issue that I see with a Filter level hook is that mod_uniqueid is
not yet available and that is used by ModSecurity for proper logging.

I will let Breno comment on some ideas.

Cheers,
Ryan


>
>So what do you guys think?
>
>Cheers,
>
>Christian
>
>
>--
>I think IT projects are about supporting social systems - about
>communications between people and machines. They tend to fail due to
>cultural issues.
>-- Tim Berners-Lee
>
>
>--------------------------------------------------------------------------
>----
>All of the data generated in your IT infrastructure is seriously valuable.
>Why? It contains a definitive record of application performance, security
>threats, fraudulent activity, and more. Splunk takes this data and makes
>sense of it. IT sense. And common sense.
>http://p.sf.net/sfu/splunk-d2d-c2
>_______________________________________________
>mod-security-developers mailing list
>mod...@li...
>https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>ModSecurity Services from Trustwave's SpiderLabs:
>https://www.trustwave.com/spiderLabs.php
>


This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.