Hi Barry!Well, it didn't work...This is what I did:My mod_security conf and
rules files are set up like this:
modsecurity_crs_15_customrules.conf file has only this line:
SecRule REMOTE_ADDR "@ipMatch 999.99.99.99"
"id:1000,phase:2,t:none,pass,nolog,ctl:ruleRemoveById=960009"
I restarted Apache, but rule 960009 still process that IP as source.
What did I do wrong?
There is also a file named /usr/local/apache/conf/modsec2.whitelist.conf with
just this on it:
# ConfigServer ModSecurity whitelist file<LocationMatch .*></LocationMatch>
I'm confused, don't know in which files this directive should go or what else
should I have done.Tks!All the best!Luiz
> From: barry_poll...@hotmail.com
> To: asiaya...@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: Wed, 13 May 2015 10:07:24 +0100
>
> 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
