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). 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
