I like the idea of consolidating and making it easier to find rules. Is there any way to map existing rule IDs to the new ones? It might allow the change to happen without breaking so much stuff.
Sent from my iPhone On Jun 6, 2012, at 11:24, Ryan Barnett <rbarn...@trustwave.com> wrote: One of the items we are considering with the CRS v3.0 update is to start from scratch with all of the rule IDs. We have a defined range reserved for the OWASP CRS - https://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#id 900,000–999,999: reserved for the OWASP ModSecurity Core Rule Set [12]<http://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project> project The rationale for this change is to make it easier to users to do exceptions and disable groups of rules by using SecRuleRemoveById, etc… That directive has the capability to remove ranges of rule IDs, however over the years the rule IDs were added ad-hoc and they are not properly grouped in this manner. For instance, groupings could be something similar to this - - Protocol Violation – 900000-900099 - Protocol Policies - 900100–900199 - Cross-site Scripting - 900200–900299 - … We would give each rule group approx 100 rule IDs. The initial number would be less than that which would allow some growth. After some analysis of the current rules, we really shouldn't ever exceed those allotments as there ends up being rule logic duplication and you just end up with bloated rule amounts. Keep in mind that the active rule IDs were going to change a bit anyways with this update as we will be consolidating many rules into highly optimized regexes, etc.. The only concern that I have with making this move would be if users have extensively implemented exceptions based on the current rule IDs. They would need to be aware of this when they migrate to v3.0. Comments? -- Ryan Barnett Trustwave SpiderLabs ModSecurity Project Leader OWASP ModSecurity CRS Project Leader ------------------------------ 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 Owasp-modsecurity-core-rule-set@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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