Forwarded to devs Recurring issues in all websites with ModSecurity ruleset

[Bitpalast]

User name: Peter Debik

TITLE

Recurring issues in all websites with ModSecurity ruleset

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Obsidian, latest MU, CentOS 7.8

PROBLEM DESCRIPTION

The ModSecurity default basic rules keep blocking website users as described in this thread:

Issue - Lots of ongoing issues with the default Comode ModSecurity ruleset

It's not a bug, but it's a bit annoying.:On Obsidian no day passes on which we don't get a call or support ticket from a customer who is blocked by fail2ban because his website offended some Comodo basic ModSecurity rule. We have seen it on Wordpress websites frequently when customers simply use...

talk.plesk.com

Further, frequently in many customer accounts, ModSecurity is loggin "Failed deleting collection" which leads to a Fail2Ban reaction on this, too, blocking customers.

Example: ModSecurity: collections_remove_stale: Failed deleting collection (name "ip", key "157.245.183.64_1759fce451e56b4eb624eea72c06ca78e73f27d0"): Internal error [hostname "asdfghjk.com"] [uri "/wp-content/plugins/bdthemes-element-pack/assets/css/ep-time-zone.css"] [unique_id "XrvJZkNG8bkOPzsiuu0nrgAAAAQ"], referer: https://asdfghjk.com/?elementor-preview=2&ver=1589365086

STEPS TO REPRODUCE

Activate ModSecurity (Web Application Firewall), install Wordpress, then start creating a website and work on it as a normal website creator does.

ACTUAL RESULT

Sooner or later at least these two rules
210710
214930
apply. Then Fail2Ban blocks your IP.

EXPECTED RESULT

No issues for websites creators.

ANY ADDITIONAL INFORMATION

The issue does not only apply to Wordpress websites. We have seen it in several different other sites, too, like Nextcloud, forum software, shops etc.

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug

 

[IgorG]

Thank you for the report, Peter.
The bug has been confirmed and submitted as PPPM-11961

As a possible workaround just disable rules 210710, 214930:
How to disable specific ModSecurity rules in Plesk

 

[Azurel]

@IgorG
What is here the status?

In my Obisidian there are this two rules set by default, what is here the detect pattern?

210710
222212

I found for COMODO more very critical bad rules that block visitors that visit a page or use a search function on it.

211120 => Match of "endsWith /modules/paypal/express_checkout/payment.php"
211270 => Pattern match "(?rint|echo|eval|exec)\\("
211630 => Pattern match "(??:select|?(?:benchmark|if|sleep)\\(.)"
211650 => Pattern match "(?i?:[\\x22'`](?:;? ?\\b(?:having|select|union)\\b ?[^\\s]| ?! ?[\\x22'`\\w])|\\b(?:c(?nnection_id|urrent_user)|database)\\b ?\\(|\\bunion\\b[\\w(\\s]*?select\\b|\\buser ?\\(|\\bschema ?\\(|\\bselect.*?\\w?\\buser ?\\(|\\binto[\\s+]+(?:dump|out)fil ..."
212790 => Pattern match "(?:alert|eval|\\.fromcharcode)(?:\\(|`)"

When you have a "search" function on your website thats kick in. Like search for "Karneval (2020)" and id 211270 find "eval" in it. Same with 211630 when its search words include a "if" like a name "Harif (2020)". Or id 211650 thats detect a "union" in search text and so on.
211120 because I use matomo analytics => found within REQUEST_FILENAME: /matomo.php".

Where I see the current used version number for comodo-rules?

 

[ahoi]

Happens here all the time. Any updates on this?

 

[Bitpalast]

I can only say that the Comodo ruleset brought so many problems that we switched back to Atomic. In once case, a temporary file where Comodo caches rule hits grew so big that it took longer to scan the file for existing entries before the next request could be processed which lead to server failures within seconds after restarting the web server. It just does not seem to work right, at least not when you have lots of domains and traffic on a system.

 

[weltonw]

I can only say that the Comodo ruleset brought so many problems that we switched back to Atomic. In once case, a temporary file where Comodo caches rule hits grew so big that it took longer to scan the file for existing entries before the next request could be processed which lead to server failures within seconds after restarting the web server. It just does not seem to work right, at least not when you have lots of domains and traffic on a system.

Yes, can confirm this has been our experience too. Not the caching issue specifically, but Comodo is just not worth any of the benefits (selective rule classes, pricing) it brings. Atomicorps Advanced has served us well.

 

[Azurel]

I also have many problems with Comodo. Comodo rule set is partly like created by interns without really thinking about it. However, for a very long time in Plesk Obsidian there is no Atomic.

 

[weltonw]

Project is also mostly "dead" - based on their forums: Is this project dead? - Free Modsecurity rules - Comodo Web Application Firewall

 

[ahoi]

I can only say that the Comodo ruleset brought so many problems that we switched back to Atomic. In once case, a temporary file where Comodo caches rule hits grew so big that it took longer to scan the file for existing entries before the next request could be processed which lead to server failures within seconds after restarting the web server. It just does not seem to work right, at least not when you have lots of domains and traffic on a system.

Thanks Peter and John for sharing this. I will consider atomic for the future.