Access blocked using anomaly scoring with a high threshold

[Stephan Fourie]

Hello,

We are currently in initial rollout/testing phase of CRS on shared web hosting servers. We've set CRS to use anomaly scoring and we've set the anomaly scoring threshold to 1000 in order to detect and rule out false positives. We are however getting sporadic reports from customers where a CRS rule has blocked a request, even while in anomaly scoring mode with a high threshold.

In order to enable anomaly scoring, we've enabled the following sections in the crs-setup.conf:

SecDefaultAction "phase:1,log,auditlog,pass"
SecDefaultAction "phase:2,log,auditlog,pass"

The anomaly threshold was changed by enabling this section in the crs-setup.conf:

SecAction \
 "id:900110,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.inbound_anomaly_score_threshold=1000,\
  setvar:tx.outbound_anomaly_score_threshold=1000"

Here is an example log entry of a request that was blocked:

xxxxxxxxxxxx [Tue May 14 08:15:25 2019] [error] [pid 28416] apache2_util.c(271) [client xxx.xx.xx.xxx:53713 ] - [client xxx.xx.xx.xxx] ModSecurity: Warning. Match of "rx ^%{tx.allowed_request_content_type}$" against "TX:0" required. [file "/opt/modsecurity/owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "1013"] [id "920420"] [msg "Request content type is not allowed by policy"] [data "text/html"] [severity "CRITICAL"] [ver "OWASP_CRS/3.1.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/POLICY/CONTENT_TYPE_NOT_ALLOWED"] [tag "WASCTC/WASC-20"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag "PCI/12.1"] [hostname "xxxxxxxxxxxxx"] [uri "/plugins/system/jcemediabox/themes/standard/popup.html"] [unique_id "XNpc-cQWjtMAAG8Axm4AAAAB"]

Does anyone have some advice or guidance for me? I'm not sure whether this is working as intended or if our configuration is missing something? If the audit log entry is needed please let me know.

Thanks!

Stephan

[Christian Folini]

Hi Stefan,

Are you sure, it is CRS blocking this? The single alert you posted below bring
you to a score of 5 and that's far from the 1,000 which you set. Also, the
rule itself only says "ModSecurity: Warning" which is a deadsure indicator
that it was not _this_ rule that blocked the request (so the behaviour is
exactly what you said you configured). With this being said, here are some
thoughts:

- What is the total score of this request. Have you configured an extended
access log that tells you the total score of every request. If not, this
would be helpful here.
If not, look for rule 949110 with the same request-id. It should bring
you the score too.
- It is not always CRS which blocks. Often it is one of the recommended rules
(range 200,000+) or one of the limits. However, I do not think 920420
would trigger in that situation. Said rules and limits would be faster
usually.

So I do not really know, but maybe you can still use these idea.

Best,

Christian

P.S. I have raised the proposed default anomaly threshold from 1,000 to
10,000 in my tutorials at netnea.com.

> --
> You received this message because you are subscribed to the Google Groups "ModSecurity Core Rule Set project" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to modsecurity-core-rule-...@owasp.org.
> To post to this group, send email to modsecurity-core...@owasp.org.
> Visit this group at https://groups.google.com/a/owasp.org/group/modsecurity-core-rule-set-project/.
> To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/modsecurity-core-rule-set-project/4a0fa265-c4bf-47b6-a0bf-5260977da858%40owasp.org.
> For more options, visit https://groups.google.com/a/owasp.org/d/optout.