False Positive which can't be skipped?

Hi Ale_V2 Thank you for connecting with the Sophos community team. It may have chances that some other mod security rule also have been triggered that has detected an anomaly with the reason "Multipart parser detected a possible unmatched boundary" which you may check and get from reverseproxy.log around an issue or error time. Once you may get those rules you may again try by adding them in Skip filter rules to validate the issue status.

Hello there

Thank you for your fast response.
I now checked the Log and it states the ID number 20004, I entered it in the skipping list exactly how it is stated in the article.

Still the upload gets blocked and the same ID gets logged.

[Wed Oct 12 21:42:54.658203 2022] [security2:error] [pid 3519:tid 13980364389760
0] [client X] [client X] ModSecurity: Access d
enied with code 403 (phase 2). Match of "eq 0" against "MULTIPART_UNMATCHED_BOUN
DARY" required. [file "/usr/apache/conf/waf/modsecurity.conf"] [line "14"] [id "
200004"] [msg "Multipart parser detected a possible unmatched boundary."] [hostn
ame "XXXXXXXXXX"] [uri "/webapi/entry.cgi"] [unique_id "Y0c0xU5wA
bIkr-cgrBeTTwAAAAI"] 

There are no other IDs in the Log with the following command:
tail -n 5000 -f /log/reverseproxy.log | grep security2:error          

This kind of confuses me.                     

Loading the full log (tail -n 5000 -f /log/reverseproxy.log) takes forever. Is there a way to only flush the rev proxy log?

Edit:
If I look into the Log collected with the command that takes forever then there's no ID 200004 but 949110 and 942110.
9494110 being one of these infrastructure rules and 942110 being some sort of SQL injection.

With both 200004 and 942110 in the skipping list I can get through. The Question now is if this is a "safe" way to handle it?

Sincerely
Ale

Hi Ale_V2 For the last occurrence if the logs are not rotated yet and are still present on XG then please DM me reverseproxy.log and reverseproxy.log.0 files in zip format and also share the outside Public IP from which the file upload was done and the issue was triggered with issue date and around time details. OR Re-produce the issue again and share the fresh logs and requested details via DM. Thanks. 

Hi, Ale_V2  Regarding both the ID (200004 and 942110 ) I found blogs that confirm that a particular OWASP ModSecurity Rule id is generating frequent false positives.

https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/

https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/827

For ID 942110 

github.com/.../1648

https://gitlab.com/swisspost-evoting/e-voting/e-voting-documentation/-/blob/master/Operations/ModSecurity-CRS-Tuning-Concept.md

Also, the same logs lines when both the above ID has been triggered - you may also share those logs with your In house Web App Dev team who is maintaining the end server for which WAF hosting is done to have their opinion on this detection i.e. that detection is a kind of false positive or not and it is ok to add ID in the skip filter rule to avoid such false detection or not. 

Unless and Until it is a non-infrastructure rule and you are also sure that the end legitimate user's actual genuine activity has been blocked and dropped due to anomaly detection, it is ok to add them in the exception by consulting In house Web App Dev team.