owaspmod-securitymod-security2

How do I configure the ModSecurity engine to be ON for a single attack type and DetectionOnly for all others?


I need to gradually implement ModSecurity. It must be configured to only block attacks by a single attack type (e.g. SQLi), but log all other attacks from the other attack types.

For ease of upgrading the owasp rules, it is recommended to avoid modifying the original owasp rules. Ideally I'm looking for a solution which will follow this guideline and won't require modifying the original owasp rules.

Currently my test configuration is only accomplishing part of this. With this Debian installation of ModSecurity, I have removed individual rule files from /usr/share/modsecurity-crs/rules/*.conf from the configuration. This allows me to enable ModSecurity with engine=on and only the rule sets for the particular attack type loaded in the configuration, but it is not logging the incidents of other attack types.


Solution

  • You’ve a few options:

    1) Use anomaly scoring and the sql_injection_score value that the OWASP CRS sets for SQLi rules.

    This can be achieved with an extra rule like this:

     SecRule tx.sql_injection_score "@gt 1” 
        "id:9999,\
        phase:5,\
        ctl:ruleEngine=on \
        block"
    

    Setting the ”@gt 1” to an appropriate threshold.

    The OWASP CRS sets similar variables for other categories as well.

    2) Load rules individually and rules before and after to turn rule engine on and off.

    Within a phase rules are executed in order specified. You can use this to have config like the following:

    SecRuleEngine DetectionOnly
    Include rules/other_rules_1.conf
    Include rules/other_rules_2.conf
    SecAction “id:9000, phase:2, ctl: ctl:ruleEngine=on”
    Include rules/sqli_rules.conf
    SecAction “id:9001, phase:2, ctl: ctl:ruleEngine=off”
    Include rules/other_rules_3.conf
    Include rules/other_rules_4.conf
    

    However if a category contains several phases then you’ll need to add several SecActions - one for each phase used.

    3) Active the rules you want by altering the Actions to include turning on the ruleEngine.

    This is probably a bit fragile as depends on knowing the specific rule ids and also requires checking the actions per rule or assuming they are all the same. Probably better to just edit the CRS files to be honest.

    This is probably the best if you want to only enable a set of rules, rather than a full category.

    4) Edit the files, to do the same as above directly.

    This is not a bad option if you know this will be a short term option and eventually you hope to enable all rules anyway. Revert the file back when ready.

    Alternatively leave the original rules in place and copy the rules, giving them new ids, and with the addition of the ctl:ruleEngine=on action.