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

Reply via email to