Great! Thank you! On Thu, Nov 3, 2011 at 1:46 PM, Ryan Barnett <[email protected]> wrote:
> > From: rm4dillo D <[email protected]<mailto:[email protected]>> > Date: Thu, 3 Nov 2011 06:39:09 -0500 > To: Ryan Barnett <[email protected]<mailto:[email protected]>> > Cc: "[email protected]<mailto: > [email protected]>" < > [email protected]<mailto: > [email protected]>> > Subject: Re: [Owasp-modsecurity-core-rule-set] Performance issues > > Hi Ryan, > > Even by disabling the "initcol" rules the problem was still there but > after some deeper analysis, I finally found the reason and a solution. > > Almost all the rules in "modsecurity_crs_40_generic_attacks.conf", > "modsecurity_crs_41_sql_injection_attacks.conf" and > "modsecurity_crs_41_xss_attacks.conf" are applied to the "REQUEST_COOKIES" > and "REQUEST_COOKIES_NAMES" variables, making ModSecurity execute about 500 > rules on every cookie's name and every cookie's value which means 10000 (2 > * 10 * 500) additional operator calls for each request because every > request I receive contains around 10 cookies. > By applying those rules to the whole "Cookie" header instead of every > cookie's name and value, ModSecurity will only perform 500 additional > operator calls instead of 10000. > > I solved the problem by replacing "REQUEST_COOKIES|REQUEST_COOKIES_NAMES" > by "REQUEST_HEADERS:Cookie". > > May this change be included in the next CoreRuleSet release? > > Understood. This is the whole "Performance vs. Security" debate. We will > need to think a bit as to the best options. Here is the short background - > > 1. We added the REQUEST_COOKIES variables as a result of the SQL > Injection Challenge - > http://blog.spiderlabs.com/2011/07/modsecurity-sql-injection-challenge-lessons-learned.html– > as our SQLi rules were not inspecting Cookie values and these are > obviously a valid injection point as many DBs are using this data in > queries. > 2. We added the REQUEST_COOKIES variables vs. REQUEST_HEADERS:Cookie due > to false positives. If you inspect the entire Cookie data as one payloads > instead of parsing it into cookie name = cookie value pairs, you will get a > higher number of false positives due to many of the SQL Tautology attack > rules ( 1 = 1, etc…). > > I think that he best option will be to re-architect the "Paranoid Mode" > concept and have a different directory of rules that is very aggressive in > the variables that it inspects. Those people that want to be aggressive to > minimize the chance of false negatives and are willing to deal with false > positives and make exceptions can then activate those rules. > > -Ryan > > > Thanks! > > Rm4dillo > > > On Mon, Oct 24, 2011 at 8:45 PM, Ryan Barnett <[email protected] > <mailto:[email protected]>> wrote: > My guess is that it is related to the initcol at the end of the 10 config > file. This is used to setup the IP collection for other rules to use. While > this is helpful, I think it is causing these types of perf issues on high > traffic sites as it is forcing ModSec to create a persistent collection for > ALL request. > > Try commenting out the final initcol SecRule at the end of the 10 file and > see if it helps. > > We will think of a better approach. > > Ryan > > On Oct 24, 2011, at 2:30 PM, "rm4dillo D" <[email protected]<mailto: > [email protected]>> wrote: > > > Hi, > > > > I recently installed ModSecurity with CRS 2.2.2 (base rules only, > paranoid mode set to off and SecResponseBodyAccess to off too) on a high > traffic server and the CPU usage almost reached 100% while it's usually > around 2 to 5% and I have no errors. > > > > By disabling mod_security_crs_4[01]* rules (generic, xss, sqli) it's way > better but not really useful :). > > > > Any clues? Does someone benchmark the rules before every release? > > > > Thanks. > > > > Rm4dillo > > _______________________________________________ > > Owasp-modsecurity-core-rule-set mailing list > > [email protected]<mailto: > [email protected]> > > https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set > > 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. > > > > ________________________________ > 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. > >
_______________________________________________ Owasp-modsecurity-core-rule-set mailing list [email protected] https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
