Re: [mod-security-users] Question regarding load order and vhosts

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hey Christian,
I think this all boils down to conflicts between ModSecurity phases and Apache Scope Locations.  Reference this graphic -
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Processing_Phases

In ModSecurity phase:1, it hooks into the "post-read-request" Apache phase.  At this point, there is NO Apache scope context available (Vhost, Directory, Location, etc…).  Those are only avaiable to ModSecurity if hooking into phase:2.  So, some of your exception rules are using "phase:1" however you are nesting them inside Vhost containers which aren't read until phase:2.

The cleanest method for this scenario is to specify these per-Vhost exceptions in the main Apache config scope but to use the ModSecurity REQUEST_HEADERS:host variable to apply them to the proper Vhost.  Example -

SecRule REQUEST_FILENAME "^/path[goog_1677425180]$"chain, phase:1, id:'99', rev:'1', t:none, t:normalizePath, nolog"
    SecRujle REQUEST_HEADERS:Host "@streq www.foobar.com" chain
      SecRule REQUEST_METHOD "^POST$"\
        ctl:ruleRemoveById=960010,\
        ctl:ruleRemoveById=960015,\
        ctl:ruleRemoveById=990012"

Hope this helps.

Ryan Barnett
Lead Security Researcher, SpiderLabs

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>

From: Christian Mehlmauer <fir...@gm...<mailto:fir...@gm...>>
Reply-To: "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>>
Date: Tuesday, April 1, 2014 11:29 AM
To: "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>>
Subject: [mod-security-users] Question regarding load order and vhosts

Hi,
I am currently setting up a mod_security installation and I have a few question about the load order, VHOSTS and why the following exceptions are not working.

Currently we are running mod_security 2.7.7 with OWASP CRS in logging only mode on apache 2.7.7 (Redhat). Apache is configured on a VHOST basis with 80+ VHOSTs.

Our load order currently looks like this:
httpd.conf
  --> Include mod_security.conf
      --> mod_security.conf: SecRuleEngine DetectionOnly and other basic options
  --> Include pre_vhost.inc
      --> Include modsecurity.d/modsecurity_crs_10_setup.conf
      --> Include modsecurity.d/modsecurity_crs_15_customrules.conf
      --> Include modsecurity.d/owasp-modsecurity-crs/base_rules/xxxxxxx.conf (some base rules)
  --> Include vhost/*.conf
      --> Vhost specific Apache configuration (VirtualHost *:port)
      --> Vhost A contains another "Include vhost/A_exceptions.conf" with mod_security rules only for this vhost (there are 80+ VHOSTs, each vhost has it's own exception file)
          --> A_exceptions.conf Exceptions for false positives triggered on this VHOST
          --> B_exceptions.conf
              --> Include: inc/application.conf (exception for an application running on multiple vhosts, so you can include the only once defined exceptions file on seperate VHOSTs)
          --> C_exceptions.conf
              --> Include: inc/application.conf (same application as on VHOST B)
  --> Include post_vhost.inc
      --> Include modsecurity.d/modsecurity_crs_48_local_exceptions.conf
      --> Include modsecurity.d/owasp-modsecurity-crs/base_rules/modsecurity_crs_49_inbound_blocking.conf
      --> Include modsecurity.d/owasp-modsecurity-crs/base_rules/modsecurity_crs_60_correlation.conf

So as you can see we have the basic CRS applied to all VHOSTs and a per VHOST based false postive exception configuration. The file modsecurity_crs_48_local_exceptions.conf contains exceptions applied to all VHOSTs, modsecurity_crs_15_customrules.conf contains rules like disabling mod_security for specific IPs.

Currently a few rules seem to be ignored and I hope you can help me with it.

Question 1:
I included the following Rule in the file inc/application.conf (which is included in a <VirtualHost> directive):

SecRule REQUEST_FILENAME "^/path[goog_1677425180]$"chain, phase:1, id:'99', rev:'1', t:none, t:normalizePath, nolog"
    SecRule REQUEST_METHOD "^POST$"\
        ctl:ruleRemoveById=960010,\
        ctl:ruleRemoveById=960015,\
        ctl:ruleRemoveById=990012"

It seems like this rule is never triggered. The audit log still contains the entry:
[modsecurity] [client xx.xx.xx.xx] [domain xx.xx.xx] [200] [/20140401/xxxxx]  [file "/etc/httpd/modsecurity.d/owasp-modsecurity-crs/base_rules/modsecurity_crs_30_http_policy.conf"] [line "64"] [id "960010"] [rev "2"] [msg "Request content type is not allowed by policy"] [data "application/octet-stream"] [severity "CRITICAL"] [ver "OWASP_CRS/2.2.8"] [maturity "9"] [accuracy "9"] [tag "OWASP_CRS/POLICY/ENCODING_NOT_ALLOWED"] [tag "WASCTC/WASC-20"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag "PCI/12.1"] Warning. Match of "rx ^%{tx.allowed_request_content_type}$ against "TX:0" required.

If I specify the rule in modsecurity_crs_15_customrules.conf before the VHOST and the base rules are loaded, the rule works correctly. The reference manual says:

ruleRemoveById - since this action us triggered at run time, it should be specified before the rule in which it is disabling.

So this would make sense. I tried to change the load order, so the CRS base rules are loaded AFTER the vhost rules and exceptions (in post_vhost.inc before crs_48). Then I put the exception back into the application.conf. This was also not working alltough the exclude was specified before the CRS rules. Is there a difference in the VHOST loading scheme? Also the file application.conf contains ctl:ruleRemoveById:xxx and ctl:UpdateTargetById:xxxx statements. Is it possible to keep this way of defining exceptions, so we can simply include it in other vhosts? An example for application.conf would be piwik which can be enabled on multiple VHOSTs and all exceptions need to be the same.

Question 2:
As said before piwik is an example for an application.conf. Currently the content of the piwik tracking cookie triggers some SQLI rules. The following rule is included in an application.inc which is included in a specific VHOST

# ignore piwik tracking cookies _pk_ref.1.ea53
# 981172: Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded
# 981257: Detects MySQL comment-/space-obfuscated injections and backtick termination
# 981243: Detects classic SQL injection probings 2/2
SecRule &REQUEST_COOKIES_NAMES:/_pk_ref\./ "@gt 0" "phase:1, id:'48', rev:'1', t:none, t:normalizePath, nolog,\
    ctl:ruleRemoveTargetById=981172;REQUEST_COOKIES:/^_pk_ref\./,\
    ctl:ruleRemoveTargetById=981257;REQUEST_COOKIES:/^_pk_ref\./,\
    ctl:ruleRemoveTargetById=981243;REQUEST_COOKIES:/^_pk_ref\./"

The exceptions defined here are also not working correctly. If I change the rule from "nolog" to "log" I can see that the expression matchted greater 0, but the excluded rules are sill firing and blocking the requests.

I hope I described my problem so anyone can understand and someone here on this list can help me.

Chris

________________________________

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.