Tks so much Barry!I totally agree with you that it gets difficult to explain such things to a newbie like me, but I plead you to concede that it is very difficult to understand mod_security OWASP setup because it seems to be very different from what is described in https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#id or https://www.trustwave.com/Resources/SpiderLabs-Blog/ModSecurity-Advanced-Topic-of-the-Week--(Updated)-Exception-Handling/ or from what you describe in your kind message below. For instance, my installation has no such file rules/modsecurity_crs_21_protocol_anomalies.conf or conf/modsecurity/crs/ or my_modsecurity_before_rules.conf, or even Include my_modsecurity_after_rules.conf. I only have this folder/files structure: /usr/local/apache/conf/modsec_vendor_configs/OWASPand then:/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/usr/local/apache/conf/modsec_vendor_configs/OWASP/util My rules folder have a bunch of files duplicated: each duplicate has the suffix.BAD, like this one exampe:REQUEST-13-SCANNER-DETECTION.conf.BADREQUEST-13-SCANNER-DETECTION.confand so on. I don't have the faintest idea why it got that way. I feel a lack in documentation and I also agree with you that flexibility is a must. But good standards need clear placeholders where all users may easily find where to customize. And definitely there will be always this need for cutomization in a product like firewall rules. Well, those are just facts and feelings to share. Anyway, I thank you again very much because your keen observations and one particularly useful suggestion solved my 960009 issue!I followed your preference and included the ipmatch directive in modsecurity_crs_10_setup.conf, since it is a "before" kind of tweak.(I would say, in my defence, that no user could ever have guessed this by his own, I believe.)And it worked like a charm!No more false positives from my own server IP and rule 960009!I will toast you a beer for that in a short while (because it's Saturday!)!So now, the only other false positive filling up my audit log is rule 960015 on Google's IPs! I still couldn't figure out a way to exclude this.I thought of using the same ipmatch directive but Google has so many IPs and they seem to change networks from time to time that it might not be a good idea.I would appreciate to know how you guys do this.Another thig that intrigues me about mod_security and OWASP is the audit log itself. I log rotate it every night at daily crons, but when I look at the Hits Listin CPanel, under Security Center/Mod_Security/Tools, all hits since the very first day (May 2nd) I installed OWASP are there. I wonder where they keep them because in a short time it will become the largest file in the server! Any tips as where to find this file are welcome! Tks a lot Barry!And enjoy the weekend!Cheers!Luiz From: barry_poll...@hotmail.com Subject: Re: [Owasp-modsecurity-core-rule-set] Rule 960009 generates false positives from my own server IP Date: Sat, 16 May 2015 06:38:19 +0100 CC: csand...@trustwave.com; owasp-modsecurity-core-rule-set@lists.owasp.org To: asiaya...@hotmail.com
No. Chaim is saying you cannot remove rule 960009 if it's already been defined previously in your config. Some overrides need to be defined before the rule they are overriding and some after, depending on what command you use to do the override. It's a bit confusing alright which was why it was discussed to change on the link Chaim gave - though ultimately it looks like they decided to leave as is. Anyway, it's important to understand how your rules are loaded. Let's you have something like this in your config: Include modsecurity_crs_10_setup.conf Include rules/*.conf Then rule 960009 is defined in rules/modsecurity_crs_21_protocol_anomalies.conf. So you must define your rule, which switches off that rule for certain scenarios, before that file is loaded. There are lots of ways to do this. You could change your setup to something like this, for example: Include my_modsecurity_before_rules.conf Include modsecurity_crs_10_setup.conf Include rules/*.conf Include my_modsecurity_after_rules.conf Then your new rule should go in the my_modsecurity_before_rules.conf file so it is processed before any of the other rules. Or you could add to a rules/modsecurity_crs_15_customrules.conf file, which will automatically be included with above code and, as they are loaded in alphabetical order, this file would be loaded before the rules/modsecurity_crs_21_protocol_anomalies.conf file. Point is, that if you add your rule to the my_modsecurity_after_overrides.conf file, in above example, then it won't work as rule 960009 will have already been loaded and will be defined at that stage, so it will be too late so you can't use ctl:ruleRemoveById on it. My personal preference is to put any "before" rules and tweaks directly the modsecurity_crs_10_setup.conf file (since you have to edit this file anyway to define your own customisations) and the also have an "after" rules file where any other rules and tweaks are defined. I also don't like * including files as sounds risky to me, so have an individual "Include" line for each rules file I want included, in the order I want it included. So my set up looks something like this: Include conf/modsecurity/modsecurity_crs_10_setup.conf Include conf/modsecurity/crs/base_rules/modsecurity_crs_20_protocol_violations.conf Include conf/modsecurity/crs/base_rules/modsecurity_crs_21_protocol_anomalies.conf ...etc. Include conf/modsecurity/my_custom_rules.conf And I make any edits in either modsecurity_crs_10_setup.conf (for tweaks I want before the rest of the rules load) or in my_custom_rules.conf (for tweaks I want after the rest of the rules load). I never edit anything in the conf/modsecurity/crs/ folder which makes it easy to drop a new version of the crs rules in here. But it's all a personal preference as to how you set it up. The downside with this flexibility, is that it's difficult to help people like you, when they ask for help without knowing exactly how they've set their own ModSecurity up. Thanks,Barry On 16 May 2015, at 00:53, Guilherme Y <asiaya...@hotmail.com> wrote: Tks Chaim!But now I really got confused.I am tring to use this line: SecRule REMOTE_ADDR "@ipMatch 999.99.99.99" "id:1000,phase:2,t:none,pass,ctl:ruleRemoveById=960009" You´re telling me to use this: "ctl:ruleRemoveById=960009,id:1000,phase:2,t:none,pass" SecRule REMOTE_ADDR "@ipMatch 999.99.99.99" YIs this right?I probably got it all wrong....Tks a lot!Best regards!Luiz From: csand...@trustwave.com To: asiaya...@hotmail.com; barry_poll...@hotmail.com; owasp-modsecurity-core-rule-set@lists.owasp.org Subject: Re: [Owasp-modsecurity-core-rule-set] Rule 960009 generates false positives from my own server IP Date: Fri, 15 May 2015 16:48:07 +0000 ctl:ruleRemoveById must appear BEFORE the rule in question. Where as SecRuleRemoveByID must appear after. See the excerpt from this issue (https://github.com/SpiderLabs/ModSecurity/issues/209). Hope this isn’t too confusing :) From: Guilherme Y <asiaya...@hotmail.com> Date: Friday, May 15, 2015 at 10:51 AM To: Barry Pollard <barry_poll...@hotmail.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 960009 generates false positives from my own server IP ctl:ruleRemoveById 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
