Hello, Ruleid's should never be reused. I think it would be also a great benefit if the rev field is only updated if something has changed in the actual rule. That would make it easier to search with normal diff command for updates.
Thanks Michael 2012/6/7 Ryan Barnett <rbarn...@trustwave.com>: > > On 6/6/12 6:47 PM, "Klaubert Herr da Silveira" <klaub...@gmail.com> wrote: > >>Ryan, >> >>The "highly optimized regexes" will be written optimized or will be >>optimized by a tool? If is written and then optimized, will be very >>useful to have the "source" for debuging purpose, like a version >>minified and a standard version of a js lib. > > Yes, we can do that. Just to be clear, we are planning on extensively > using the @pm/@pmf to do fast pre-qualification of groups of rules. If > these rules match, then we will execute the optimized regular expression > rules. What we can do is provide the smaller regex sources with Apache > comments prior to the rules. > > So, you would really have two ways of knowing the source data for the > optimized regexes: > 1) The plain text string pm data, and > 2) The smaller, individual regexes. > > -Ryan > >> >>Klaubert Herr >> >>On Wed, Jun 6, 2012 at 11:23 AM, 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=Refer >>>ence_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 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 - 900100900199 >>> Cross-site Scripting - 900200900299 >>> Š >>> >>> 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 >>> >> > > > 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 _______________________________________________ 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
