[Owasp-modsecurity-core-rule-set] ctl:auditEngine=Off recommendations

[Paul McGarry]

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"

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

Ryan's blog at:

http://blog.spiderlabs.com/2010/12/advanced-topic-of-the-week-handling-authorized-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?

Paul

[Christian Bockermann]

Hi Paul,

in which phase are you putting your ctl:auditEngine=off rule?

The ModSecurity default phase is 2. You might want to turn off the
audit-logging as soon as possible, so putting your rule into phase 1
and moving it to the very beginning should solve your problem.

Best regards,

Chris

Post by Paul McGarry
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.
SecRule REMOTE_ADDR "^123\.123\.123\.123$" "nolog,ctl:auditEngine=Off"
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)?
http://blog.spiderlabs.com/2010/12/advanced-topic-of-the-week-handling-authorized-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?
Paul
_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set

[Ryan Barnett]

Post by Paul McGarry
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.
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.

Post by Paul McGarry
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.

Post by Paul McGarry
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

Post by Paul McGarry
Paul
_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
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.

[Gil Vidals]

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

Post by Ryan Barnett

Post by Paul McGarry
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.
SecRule REMOTE_ADDR "^123\.123\.123\.123$" "nolog,ctl:auditEngine=Off"

Try this rule and see if it works any better -
"phase:1,t:none,nolog,pass,ctl:auditEngine=Off"
This rule specifies phase:1 vs. defaulting to phase:2 if you don't
suited to handle IP addresses.

Post by Paul McGarry
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.
http://blog.spiderlabs.com/2010/12/advanced-topic-of-the-week-handling-aut

Post by Paul McGarry
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

Post by Paul McGarry
Paul
_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
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
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set

--
Gil Vidals, VCP
***@vmracks.com
www.vmracks.com - VMware Hosting Service Provider
t. 760.705.4022 IM: ***@hotmail.com

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.