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

[Oleg G. <ole...@ya...>]

Hello,

Has anyone had a chance to compare efficiency of mod_sec vs. QoS when it comes to mitigating against slow HTTP attacks? I've heard different opinions, e.g. that mod_sec might work well for slow reads, but not writes, while QoS is good for both. 

Are there any research papers or just objective data that can confirm that or prove opposite?

The other question is related to performance impact in both solutions when it comes to high volume systems.

Any pointers are highly appreciated.  

--- On Thu, 7/7/11, Christian Folini <chr...@ti...> wrote:

From: Christian Folini <chr...@ti...>
Subject: Re: [Mod-security-developers] Advanced Slow DoS Mitigation
To: mod...@li...
Date: Thursday, July 7, 2011, 1:34 AM

Hi there,

On Wed, Jul 06, 2011 at 07:42:50AM -0500, Ryan Barnett wrote:
> Great preso and really highlights the threat.  I was wondering what
> percentage of WikiLeaks DoS attacks were utilizing Slowloris-type
> techniques.

Me2. ;)

To be honest there was too much noise to do any sort of measurements.
We have seen a lot of things, also a lot of vanilla slowloris,
but we also must have missed a lot of other interesting attacks.

> 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.

I bumped into the old phase:1 / Location issue before so I understand
the motivation. But I thought it would have been the better
countermeasure to have apache refuse to start with a phase:1 rule
inside a location.

> 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.

That sounds nice.

> 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.

That does not sound very nice, though.

Was not there a discussion on the Apache ML to hand over mod_uniqueid
(functionality) to ModSecurity? I think that would be wrong, but maybe
it is possible to introduce a patch to have mod_uniqueid run at this
early hook too (and before phase:0).

Cheers,

Christian


-- 
If we could read the secret history of our enemies, we should find in
each man's life sorrow and suffering enough to disarm all hostility.
-- Henry Wadsworth Longfellow

------------------------------------------------------------------------------
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