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
