Mark, Good points. You are correct in that we can address this already with the tag action: tag:'WEB_ATTACK/SQL_INJECTION'
This allows users to disable categories of rules with SecRuleRemoveByTag directive. Perhaps we should just keep existing rule IDs to help ease with updates. I will reiterate though that we will be consolidating rules and many rule IDs may just go away. This brings up the issue of rule ID reuse. Should we ever re-use a rule ID? If so, how should we notify the user. I believe that we can address that by utilizing the "rev" action. If we update a rule or re-use the rule ID for another purpose, we should then increment the rev value. Thoughts? -Ryan On 6/6/12 3:50 PM, "Mark Boos (IntCom)" <m...@intcom.nl> wrote: >To me, it sounds like a database / categorization problem which you want >to >solve via id's. Is there no other way to add a category indication ? In my >field, customers want to order member numbers to the alphabet. It's ok to >do >that when you start, but the next new member that comes gets max_id+1 >regardless of his last name. > >Also, it sounds like a lot of work to categorize every rule to new >numbers, >also in the future. > >And lastly, indeed; for the people who make exceptions based on the >current >rule id's, this will cause a lot lot of problems for them. > >Regards >Mark > >-----Oorspronkelijk bericht----- >Van: owasp-modsecurity-core-rule-set-boun...@lists.owasp.org >[mailto:owasp-modsecurity-core-rule-set-boun...@lists.owasp.org]Namens >Ryan >Barnett >Verzonden: woensdag 6 juni 2012 17:40 >Aan: David Sinclair; owasp-modsecurity-core-rule-set@lists.owasp.org >Onderwerp: Re: [Owasp-modsecurity-core-rule-set] [Rule Update - Discussion >Thread]Updating Rule IDs > > >I will investigate the idea of a rule mapping, but keep in mind that >following - >One of our goals with the update is to make the rule accuracy better (less >false positives). So, just because a specific rule is currently a false >positive and you chose to add an exception to disable it, that does not >mean >that you would need to keep the exception with the new version of the >rule. >ModSecurity v2.7 (will be released very soon) has the new "accuracy" and >"maturity" actions. This will allow us (Trustwave) to give a relative >score >for each of these settings. This will help you to decide which rules to >run >default or not. >As for directory structure groupings, it is my belief that all rules in >the >"base_rules" directory should have a very high quality of accuracy (low FP >rate). If a user wants to get more aggressive with detection, then they >will be able to activate other rule files under the "experimental_rules" >directory in which the accuracy/maturity values would be lower. > > >-Ryan > > >From: David Sinclair <dbsincl...@multiservice.com> >Date: Wed, 6 Jun 2012 10:28:01 -0500 >To: Ryan Barnett <rbarn...@trustwave.com>, >"owasp-modsecurity-core-rule-set@lists.owasp.org" ><owasp-modsecurity-core-rule-set@lists.owasp.org> >Subject: RE: [Owasp-modsecurity-core-rule-set] [Rule Update - Discussion >Thread]Updating Rule IDs > > > >I think it is a good idea to better group the rules but it will require an >extensive review of rule exceptions. If there is a mapping available from >the old id to the new id for those rules that are reassigned that would be >very helpful and reduce the review effort. > >David B. Sinclair >Security Manager >Multi Service Corporation > >+1-913-663-9474-w >+1-816-718-0449-m >dbsincl...@multiservice.com > > > > >From:owasp-modsecurity-core-rule-set-boun...@lists.owasp.org >[mailto:owasp-modsecurity-core-rule-set-boun...@lists.owasp.org] On Behalf >Of Ryan Barnett >Sent: Wednesday, June 06, 2012 9:24 AM >To:owasp-modsecurity-core-rule-set@lists.owasp.org >Subject: [Owasp-modsecurity-core-rule-set] [Rule Update - Discussion >Thread]Updating Rule IDs > >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=Refere >nc >e_Manual#id > >900,000999,999: reserved for the OWASP ModSecurity Core Rule Set >[12] project > >The rationale for this change is to make it easier to users to do >exceptions >and disable groups ofrules 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 - 900100900199 >Cross-site Scripting - 900200900299 >Š >We would give each rule group approx 100 rule IDs. The initial number >would >be less than thatwhich 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. >-------------------------------------------------------------------------- >-- >----------- >This email is intended solely for the use of the addressee and may >contain information that is confidential, proprietary, or both. >If you receive this email in error please immediately notify the >sender and delete the email. >-------------------------------------------------------------------------- >-- >----------- > > > > > >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 > 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
