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 <christian.fol...@time-machine.ch> wrote: From: Christian Folini <christian.fol...@time-machine.ch> Subject: Re: [Mod-security-developers] Advanced Slow DoS Mitigation To: mod-security-develop...@lists.sourceforge.net 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-security-develop...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mod-security-developers ModSecurity Services from Trustwave's SpiderLabs: https://www.trustwave.com/spiderLabs.php
_______________________________________________ Owasp-modsecurity-core-rule-set mailing list Owasp-modsecurity-core-rule-set@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
