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

Reply via email to