I think there is a bug that won't allow us to omit log entries to the audit log. In my case, I tried several different phases and crs files as you can see below:
in modsecurity_crs_48_local_exceptions.conf AND I tried modsecurity_crs_15_customrules.conf - SecRule REQUEST_HEADERS:User-Agent "pingdom" "nolog,noauditlog,pass" - SecRule REQUEST_HEADERS:User-Agent "pingdom" "nolog,noauditlog,pass,ctl:auditEngine=Off" And after restarting apache, I still am getting these entries: --4489f76b-B-- GET /account/login/?next=/ HTTP/1.0 User-Agent: Pingdom.com_bot_version_1.4_(http://www.pingdom.com/) Host: blah.com Gil Vidals / VM Racks ESXi Hosting On Thu, Aug 18, 2011 at 6:26 AM, Ryan Barnett <[email protected]>wrote: > > On 8/18/11 3:21 AM, "Paul McGarry" <[email protected]> wrote: > > >Hi all, > > > >I have a site which is routinely scanned both internally and by > >external service. > >I want to have mod_security running and intervening but don't want any > >of the associated log noise, the scans originate from known IPs and > >have known User agents etc so I can easily identify them. > > > >So far I have been turning the auditEngine off with things like: > > > >SecRule REMOTE_ADDR "^123\.123\.123\.123$" "nolog,ctl:auditEngine=Off" > > Try this rule and see if it works any better - > > SecRule REMOTE_ADDR "@ipMatch 123.123.123.123" > "phase:1,t:none,nolog,pass,ctl:auditEngine=Off" > > This rule specifies phase:1 vs. defaulting to phase:2 if you don't > explicitly set one and it also uses the @ipMatch operator which is better > suited to handle IP addresses. > > > > > >but I have noticed this doesn't catch everything, specifically CRS > >rule 981227 (Apache Error: Invalid URI in Request). > > > >If I understand things correctly this is because Apache is blocking > >the request early and Modsec phases 1-4 don't run, it just goes > >straight to 5? > > > >Should I be putting my rule above in phase 5 (additionally or instead)? > > Good observation. Yes, there are some requests that may be handled by > Apache before it reaches the ModSecurity hooks. You may need to replicate > this rule to also run in phase:5. > > > > >Ryan's blog at: > > > > > http://blog.spiderlabs.com/2010/12/advanced-topic-of-the-week-handling-aut > >horized-scanning-traffic.html > > > >and modsecurity_crs_11_avs_traffic.conf CRS file seem to suggest that > >phase 1 is the preferred place but that doesn't seem to be entirely > >effective for me. Am I missing something? > > One other monkey wrench here... Reference this JIRA ticket - > https://www.modsecurity.org/tracker/browse/MODSEC-98. Ivan Ristic had > previously made a change to the code so that phase:1 and phase:2 actually > run in the same Apache hook (fixup phase - > https://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Referen > ce_Manual#Processing_Phases<https://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#Processing_Phases>). > This was done for a valid reason - running > rules in the post-read-request hook prevented users from nesting > ModSecurity SecRules within Apache scope locations (such as <Location>, > <Directory>, etc...). His change fixes that, however there are some > examples where you actually want a rule to run in the old phase:1 hook > (post-read-request). We are currently reviewing this change and > considering options. > > -Ryan > > > > >Paul > >_______________________________________________ > >Owasp-modsecurity-core-rule-set mailing list > >[email protected] > >https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set > > > > > 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 > -- Gil Vidals, VCP [email protected] www.vmracks.com - VMware Hosting Service Provider t. 760.705.4022 IM: [email protected] HIPAA Compliant Hosting VMware Hosting CONFIDENTIALITY NOTICE: The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, please contact the sender by reply email and permanently delete the original message.
_______________________________________________ Owasp-modsecurity-core-rule-set mailing list [email protected] https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
