ModSecurity OWASP 3.3.2 breaking Nextcloud - cannot solve this one - owasp

Question

Running ModSecurity 2.93, and OWASP ModSecurity Core Rule Set (CRS)
3.3.2.
Enabled the Nextcloud exceptions contained in REQUEST-903.9003-NEXTCLOUD-EXCLUSION-RULES.conf, and they are being loaded fine.
Nextcloud is updated to the last stable version, and passes all checks.
However, ModSecurity breaks its functionality in many important ways.
I get several false positives in regards to the activity of the sync app on desktop, the sync app on mobile and WebDav in general.
This is entirely ModSecurity doing. Nextcloud reports no errors and disabling ModSecurity solves the problems.
My attempts to fix this have failed. In particular, adding the following rules to REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf completely breaks Nextcloud functionality, and doesn't solve any false positives. Not sure why:
SecRule REQUEST_URI "#beginsWith /remote.php/dav/files/admin/" \
"id:10000003,\
phase:2,\
pass,\
nolog,\
ctl:ruleRemoveTargetById=921110,\
ctl:ruleRemoveTargetById=980130,\
ctl:ruleRemoveTargetById=949110"
Samples from the ModSecurity Audit log:
Message: Warning. Match of "within %{tx.allowed_request_content_type}" against "TX:content_type" required. [file "/etc/modsecurity/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "956"] [id "920420"] [msg "Request content type is not allowed by policy"] [data "|image/png|"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.2"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/255/153"] [tag "PCI/12.1"]
Message: Access denied with code 403 (phase 2). Operator GE matched 5 at TX:anomaly_score. [file "/etc/modsecurity/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "93"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.2"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"]
Message: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file "/etc/modsecurity/rules/RESPONSE-980-CORRELATION.conf"] [line "91"] [id "980130"] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5 - SQLI=0,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): individual paranoia level scores: 5, 0, 0, 0"] [ver "OWASP_CRS/3.3.2"] [tag "event-correlation"]
Apache-Error: [file "apache2_util.c"] [line 273] [level 3] [client <ip>] ModSecurity: Warning. Match of "within %{tx.allowed_request_content_type}" against "TX:content_type" required. [file "/etc/modsecurity/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "956"] [id "920420"] [msg "Request content type is not allowed by policy"] [data "|image/png|"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.2"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/255/153"] [tag "PCI/12.1"] [hostname "<hostname>"] [uri "/index.php/apps/files/"] [unique_id "Y8Yq5sm-7UrRygrbZZNbsgAAABc"]
Apache-Error: [file "apache2_util.c"] [line 273] [level 3] [client <ip>] ModSecurity: Access denied with code 403 (phase 2). Operator GE matched 5 at TX:anomaly_score. [file "/etc/modsecurity/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "93"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.2"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "<hostname>"] [uri "/index.php/apps/files/"] [unique_id "Y8Yq5sm-7UrRygrbZZNbsgAAABc"]
The message in the Android sync app is usually "you are not permitted to upload to this folder". In general all sync apps are stumped by the 403 error provided by ModSecurity. I am not positive this isn't happening only for certain file types or certain folders, or, as I think, for all files.

Answer 1

CRS Dev-On-Duty here. You seem to have two issues with your tuning rules.
The first issue is that you're using the control statement ctl:ruleRemoveTargetById=921110 without specifying a target after the rule. Either specify a target with ctl:ruleRemoveTargetById=9xxxxx;ARGS:myArg or only remove the rule by using ruleRemoveById instead of ruleRemoveTargetById.
Second issue: never ever remove the blocking rule 949110 or the correlation rule 980130. You switch off the WAF.
To solve your problem (I only see one rule that matched, besides of the blocking and correlation rule), I think it's best to add the Content-Type: image/png to the list of allowed request content-types. This can be done by uncommenting the rule 900220 in your crs-setup.conf and adding your required request content type:
https://github.com/coreruleset/coreruleset/blob/v3.3/dev/crs-setup.conf.example#L422
If you need more tuning help, I highly recommend the tuning guide of our CRS co-lead Christian Folini, especially "Handling False Positives with the OWASP CRS": https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/.

Answer 2

I think I may have figured out my problem.
I had this enabled in my crs-setup.conf:
SecRule SERVER_NAME "<hostname>" \
"id:10000001,\
phase:1,\
pass,\
nolog,\
setvar:tx.error_anomaly_score=4"
Which was an old attempt I had made to lower MS sensitivity, after reading about it in the MS handbook. Obviously I had made some serious misjudgment there. Things seem to be working now.
By the way: how to properly change the anomaly score for an hostname, so that MS is less sensitive? What's the normal value? I thought it was 5...
EDIT: Other problems in my log file, that caused sync with nextcloud to malfunction with certain file types, seemed to be due to a new Nextcloud bug documented for version 25.