All, Ok I'll have a go at helping out, seeing as hit the same issue yesterday.
All the mod rules update the ANOMALY_SCORE when something bad is found. Then in modsecurity_crs_49_inbound_blocking.conf, rule 981175 checks the value of ANOMALY_SCORE against tx.inbound_anomaly_score_level. The request is blocked if the score is higher than the score level and ANOMALY_SCORE_BLOCKING is set to on. So to enable anomaly score blocking when you deploy a new set of CRS rules, copy modsecurity_crs_10_setup.conf.example and make the following edits 1) Change SecDefaultAction to "phase:1,pass,log" 2) uncomment 900004 - this turns sets tx.anomaly_score_blocking to on We wished for different mechanism for blocking, e.g. friendly "security says you are doing something bad" page, so we edited the4 rules in modsecurity_crs_49_inbound_blocking.conf and modsecurity_crs_59_outbound_blocking.conf such that they moved from "...,t:none,deny,msg:...." to from "...,t:none,deny,status:412,msg:....". Then we added the following to apache conf ErrorDocument 412 /error/securityIssue.html We tested with an attempted path traversal, and via audit console we can see that this is blocking using anomaly score detection. Hope that helps Thanks Chris On Thu, Aug 8, 2013 at 12:19 AM, Ryan Barnett <ryan.barn...@owasp.org> wrote: > FYI I am on vacation and will respond next week. Hopefully someone else can > offer advice in my stead. > > -- > Ryan Barnett > Lead Security Researcher > Trustwave - SpiderLabs > > On Aug 7, 2013, at 11:32 AM, Damien Wyart <damien.wy...@gmail.com> wrote: > >> Hi, >> >> I've not had time to test it myself, but this message seemed a bit >> annoying and important, so I am surprised there was no "official" >> response (from Ryan). >> >> Would it be possible to have some opinions on this potential problem? >> >> Many thanks in advance, >> >> Damien >> >>> In anomaly scoring mode, CRS 2.2.8 no longer blocks based only on >>> tx.anomaly_score >>> exceeding the tx.inbound_anomaly_score_level. >> >>> Example: >> >>> - This rule worked on some previous CRS version. But, in 2.2.8, it does not >>> block based on tx.anomaly_score: >>> SecRule REQUEST_URI "^/local/modsec/test$" >>> "id:'10999',auditlog,block,msg:'LOCAL: modsec >>> test',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score}" >> >>> - Appending setvar:'tx.%{rule.id}-local-modsec-test=bad' to the above rule >>> "fixes" that: >>> SecRule REQUEST_URI "^/local/modsec/test$" >>> "id:'10999',auditlog,block,msg:'LOCAL: modsec >>> test',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:'tx.%{rule.id}-local-modsec-test=bad'" >> >> >>> Here was the mod that changed the behavior to >>> base_rules/modsecurity_crs_49_inbound_blocking.conf: >>> https://github.com/SpiderLabs/owasp-modsecurity-crs/commit/b054a4d92a00812b031facb3f81dd70e728ae8b3 >> >>> So, is the fact that CRS 2.2.8 now longer really blocks based only >>> on tx.anomaly_score an unintended consequence ? >> >> _______________________________________________ >> Owasp-modsecurity-core-rule-set mailing list >> Owasp-modsecurity-core-rule-set@lists.owasp.org >> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set > _______________________________________________ > Owasp-modsecurity-core-rule-set mailing list > Owasp-modsecurity-core-rule-set@lists.owasp.org > https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set _______________________________________________ Owasp-modsecurity-core-rule-set mailing list Owasp-modsecurity-core-rule-set@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set