That would work though I personally prefer to use @ipMatch which also allows you to match multiple IPs:
SecRule REMOTE_ADDR "@ipMatch XXX.YYY.Z.WWW XXX.YYY.Z.VVVV" "id:1000,phase:2,t:none,pass,nolog,ctl:ruleRemoveById=960009" A few other things to note: 1) 960009 is a phase 2 rule and you have specified phase 1 in your rule below. I'm pretty sure that rules cannot see other rules outside of their phase so it needs to be in the same phase. So I've updated this to phase 2 in my version above. 2) Your rule must have it's own id (as of ModSecurity 2.7) so I've given it an id of 1000. Make sure this doesn't clash with any existing rule you have. Principal is anything less than 99,999 are your own use. See here for more info: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#id 3) You could disable ModSecurity completely for internal addresses with a ctl:ruleEngine=off rule. Personally I don't like that as I want them on for testing purposes so we're not caught out with a rule that only runs in production so think just disabling the specific rules is a better option. However I think it would be good to understand why you need to do this at all. Rule 960009 checks for requests missing a user agent. All decent browsers send a user agent hence why this rule is in place as the lack of a user agent is probably due to some script or such like, so it is a good rule. So why are you getting so many requests from internal addresses without a user agent and should you fix that rather than add the above rule to get around that? I can think of two reasons: 1) Monitoring scripts or tools which are not quite as compliant as web browsers. So perhaps change these to also report the user agent as that could be useful information to know (though with third party tools that might not always be possible). 2) Needlessly connecting to Apache. We use Apache to server up static pages and also in proxy mode to pass dynamic requests on to an application server. After installing mod security and noticing similar to you, we investigated and discovered some of our dynamic applications were needlessly making calls to Apache, just to connect back to the app server again. It was actually better to change them to connect directly to the app server, which resolved the issue, as well as saving network traffic and a (admittedly small amount of) Apache load. Thanks, Barry ________________________________ > From: asiaya...@hotmail.com > To: owasp-modsecurity-core-rule-set@lists.owasp.org > Date: Tue, 12 May 2015 20:34:22 -0300 > Subject: [Owasp-modsecurity-core-rule-set] Rule 960009 generates false > positives from my own server IP > > Hi! > > I don't know if anyone experiences the same issue as us here, but I > suppose at least this might contribute to all. > > I installed OWASP rules on a Centos running 2 Joomla sites with nearly > 5,000 unique visitors a day. > > I was fortunate enough to identify and disable 12 rules that delivered > a bunch of false positives (one of them locked down the server when one > of us in the team submitted a security scan from CSF/LFD...). > > So, now it is running fine but one rule still delivers near 1,000 false > positives a day and oddly enough having our own server IP as source! > > And severity level for ALL of the hits are NOTICE. So, this is not so > much troublesome, except for the extra load on the server and the log > size. I rotate it automatically everynight but it comes out at nearly > 0,3 GB as standard size. > > So, what I am trying to do but don't know exactly how is to implent > something like this in a file named modsecurity_crs_15_localrules.conf: > > SecRule REMOTE_ADDR "@streq XXX.YYY.Z.WWW" >> "phase:1,t:none,pass,nolog,ctl:ruleRemoveById=960009" > > where XXX.YYY.Z.WWW is my server's IP address. > > Does anyone know if this is correct and if it can actually work to keep > my server out of this rule execution? > > Tks a lot! > > All the best! > Luiz Guilherme > > _______________________________________________ > 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
