Tks so much Barry! Pretty much standard modsecurity install: installed from WHM, enabled vendor OWASP and that was it. Maybe my Centos has some oddities... I understood your examples as part of the flexibility, that's OK. But newbies like me are not very imaginative and most (like me!) need these examples as part of the documentation so that at least we get to know what are the possibilities. If it wasn't for your kind help I would be sitting still staring and wondering what I did wrong! I had Modsecurity configured to log noteworthy transactions only but just a while ago I found out why my modsec_audit.log was filling up so fast: I had a permissions issue on var/cpanel/Secdatadir folder that was restraining Apache httpd user to write in there. Also my Apcahe error_log was growing excessively because of this issue. Fixed the group/owner and it all worked out as it should! I also appreciated your suggestion of disabling 960015 and already did it. Thank you very much for that too. BTW, I have disabled the following rules:958977 - it seems to deal with PHP injection and I don't know if I did right to disable it, do you agree with this? 960015 - that one! - your suggestion worked out just right981138 - blocks Google bot for bad IP reputation - I thought it's OK to disable, didn't you?981175 - blocks Google bot for bad IP reputation - I thought it's OK to disable, didn't you?981204 - it seems to issue a Warning from anomaly score and blocks our iPhone app - had to disable981242 - this blocks entirely one of my apps - had to disable981245 - has to do with SQL authentication and seems to block logins from our iPhone app - had to disable981246 - has to do with login SQL auth and seems to block logins from our iPhone app - had to disable981257 - this blocks entirely one of my apps - had to disable I did not block but found the following rules already blocked after installing the OWASP rules vendor (I don't have the faintest idea why):970901973337981205990002Any idea why this is so? Is it OK to leave these disabled? PS.: I still did not find any hint in the documentation as to where (which file) hits are stored. I flushed modsec_audit.log but all hits since May 2nd still show up at WHM/Security Center/Modsecurity Tools. If you ever find an answer to this, please let me know, just out of curiosity. Thank you again!Have a great week, live long and prosper!All the best!Luiz
Subject: Re: [Owasp-modsecurity-core-rule-set] Rule 960009 generates false positives from my own server IP From: barry_poll...@hotmail.com Date: Sat, 16 May 2015 18:17:07 +0100 CC: csand...@trustwave.com; owasp-modsecurity-core-rule-set@lists.owasp.org To: asiaya...@hotmail.com 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 <asiaya...@hotmail.com> 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/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
