Sounds like you have a non-standard install. Saying that the before_rules and after_rules files were only example files I made up.
I can't recommend Ivan Ristic's Modsecurity handbook enough available at feistyduck.com. He's the original author of ModSecurity but has since moved on. It's were I learned how to use it. Quite cheap and the install section is available free. Only for old versions so bit out of date but nearly all still relevant. Main thing missing is that id is now mandatory. I turned 960015 off completely as didn't find it that useful and lots of false positives. SecRuleRemoveById 960015 Which annoyingly had to be specified AFTER rule 960015 is defined. Or you could use the ctl version, for a rule which will match always, and specify it before. Finally it sounds like you have SecAuditLog set to On (log everything) rather than DetectionOnly (log only traffic which fails a rule). Have a good weekend! Thanks, Barry > On 16 May 2015, at 17:40, Guilherme Y <[email protected]> wrote: > > 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/OWASP > and 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.BAD > REQUEST-13-SCANNER-DETECTION.conf > and 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: [email protected] > 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: [email protected]; [email protected] > To: [email protected] > > 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 <[email protected]> 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: [email protected] > To: [email protected]; [email protected]; > [email protected] > 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 <[email protected]> > Date: Friday, May 15, 2015 at 10:51 AM > To: Barry Pollard <[email protected]>, > "[email protected]" > <[email protected]> > 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 [email protected] https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
