ModSecurity false positive rule 218500 breaks wordpress site

[itcms]

A Wordpress website is not accessible after recently wordpress update 8.x version

The error :
Forbidden
You don't have permission to access this resource.

Root Cause : Comodo rule with ID 218500 is false-positively triggered when Woocommerce 8.x is in us ( depends plugins and version )

The lines below can be found in /var/log/[ http or nginx ]/domains > example.com.error.log:

22:48:56 [error] 2311512#0: *127470 [client 37.6.255.227] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Rx' with parameter `[\[\]\x22',()\.]{10}$|\b(?:union\sall\sselect\s(??:null|\d+),?)+|order\sby\s\d{1,4}|(?:and|or)\s\d{4}=\d{4}|waitfor\sdelay\s'\d+:\d+:\d+'|(?:select|and|or)\s(??g_)?sleep\(\d+\)|\d+\s?=\s?(?:dbms (436 characters omitted)' against variable `REQUEST_COOKIES:sbjs_first_add' (Value: `fd%3D2024-01-16%2008%3A20%3A34%7C%7C%7Cep%3Dhttps%3A%2F%example.com%2F%7C%7C%7Crf%3D%28none%29' ) [file "/usr/local/cwaf/rules/22_SQL_SQLi.conf"] [line "109"] [id "218500"] [rev "18"] [msg "COMODO WAF: SQLmap attack detected||example.com|F|2"] [data "Matched Data: |||rf=(none) found within REQUEST_COOKIES:sbjs_first_add: fd=2024-01-16 08:20:34|||ep=https:/example.com/|||rf=(none)"] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] [tag "CWAF"] [tag "SQLi"] [hostname "10.0.0.5"] [uri "/wp-admin/admin-ajax.php"] [unique_id "170543813693.032521"] [ref "v5,24o77,12v1383,163t:urlDecodeUni,t:htmlEntityDecode,t:normalizePath,t:compressWhiteSpace,t:lowercaseo46,12v985,95t:urlDecodeUni,t:htmlEntityDecode,t:normalizePath,t:compressWhiteSpace,t:lowercaseo46 (93 characters omitted)"], client: 37.6.255.227, server: example.com, request: "POST /wp-admin/admin-ajax.php HTTP/2.0", host: "example.com", referrer: "https://example.com/wp-admin/index.php"

Reference :

Major Critical Errors with Woo 8.5.1. Why the lack of response?

Support » Plugin: WooCommerce » Major Critical Errors with Woo 8.5.1. Why the lack of response? Major Critical Errors with Woo 8.5.1. Why the lack of response? flowsheff (@flowsheff) 1 …

wordpress.org

 

[itcms]

The only workaround is temporary to disable specific mod security rule
Old thread with guide how to :

modsecurity breaks Wordpress

Fresh DA server install on AlmaLinux. I followed this guide as part of my task to secure the new server: https://docs.directadmin.com/operation-system-level/securing/general.html#basic-system-security Regarding item number 8: Enable mod_security.open in new window See the CustomBuild Faqopen...

forum.directadmin.com

 

[Roberto]

Plus 1... I've also had the same problem with some WordPress sites with Modsecurity rule 218500. I have also disabled that rule to allow those sites to now load. A bit annoying. Hopefully, this will be looked at and fixed without having to disable rules. I had some clients emailing me that the sites were not loading, so glad I found this thread. Hopefully will be looked at. Cheers!

 

[sparek]

Plus 1... I've also had the same problem with some WordPress sites with Modsecurity rule 218500. I have also disabled that rule to allow those sites to now load. A bit annoying. Hopefully, this will be looked at and fixed without having to disable rules. I had some clients emailing me that the sites were not loading, so glad I found this thread. Hopefully will be looked at. Cheers!

I wouldn't count on it.

As far as I know, the CWAF project is dead. There hasn't been an update to it in years.

Unless you are using another ruleset that is based on the Comodo rulset.

 

[Roberto]

@sparek

Thanks for responding. I'm happy to remove CWAF from the sever. Are there some instructions on the recommended alternative default advised security config I should know about? Should I just remove CWAF and the Directadmin server will function securely by default?

 

[Ohm J]

normally, if you don't enable 3rd party rules like OWASP or COMODO rules. you must create your own rules and place in "./custombuild/custom/modsecurity/conf/{ANY_NAME}.conf"

and this, when you re-build modsecurity, it will copy all your rules to correct directory of modsec system.

 

[BillyS]

Is there a reason people are sticking with COMODO over OWASP? COMODO looks like it's dead while OWASP does keep moving (although very slowly).

 

[sparek]

Is there a reason people are sticking with COMODO over OWASP? COMODO looks like it's dead while OWASP does keep moving (although very slowly).

I started using the Comodo ruleset a long, long time ago. One reason for not switching is all of the exceptions I have made in regards to certain websites and the Comodo ruleset IDs. Switching to a different ruleset will create a lot of issues, because those IDs won't refer to the same rule any more.

I have made several modifications and additions to the ruleset on my own over the years. That's another reason to continue using it.

BUT... you're point is valid, we really need to switch over to the CRS ruleset, because most of the rules in the Comodo ruleset are outdated. Or is there a better, more updated ruleset to use? One that will be around for a long time.

You asked why, and that's our why. It's not necessarily as easy as just flipping a switch to a new ruleset and continuing on our own merry way.

 

[BillyS]

It really was just a

You asked why, and that's our why

It really was just a question. I use OWASP and while they are slow to make changes, it does appear people continue to work on the rules. I was wondering if had experience with Atomic (both paid and free). I dont want to hijack this thread, but wondering if there are viable alternatives.

 

[sparek]

It really was just a question. I use OWASP and while they are slow to make changes, it does appear people continue to work on the rules. I was wondering if had experience with Atomic (both paid and free). I dont want to hijack this thread, but wondering if there are viable alternatives.

That's kind of another reason why I'm still using my modified Comodo ruleset. I've looked for another free alternative before (admittedly not very hard though) and I don't want to choose one that will go belly up 6 months into use, meaning I'll have to repeat the process again.

If you just have one or two servers, it's not that difficult to make a switch like this. But the more servers you manage, the more difficult it is to make wholesale changes.

But I do agree with your premise. If there's someone just starting out, I wouldn't choose the Comodo ruleset. And if you are using the Comodo ruleset and you're in a position to switch to a different ruleset, I would encourage you to do so.

 

[hoi.kamy.15]

Hi, I experienced similar issues too in the last week.

Comodo rule 218500 was seen at one point, but I was not only having issues with WooCommerce.

Websites which did not use WooCommerce, some plain WordPress on our development server, WordPress login, and even phpMyAdmin had 403 Forbidden.

We lost access to some parts of servers, sometimes could not even login, eventually we had to switch the ruleset to owasp in order to settle the emergency situations.

Owasp ruleset does cease the 403 Forbidden, but now we need to deal with updating the ModSecurity Disabled Rules all the time in order to solve tiny issues which previously did not have problems with comodo ruleset.

Do you guys have any better suggestions than comodo and owasp?

 

[itcms]

Anyone can suggest better than comodo and owasp?
I have see from malware.expert and atomicorp but I dont have use them, any one have test them ?

 

[lurch]

I've logged on to waf.comodo... and noticed that they have newer version of rules available than CWAF in DA provides. On the Comodo site they have release 1.241 with the date 2024-01-21, which looks to fix this rule based on its short description of "218500 FP fix".

Is there a way to reliably apply this version of the rules? As I tried and custombuild then overwrote them with the old 2020 version again when it applied updates.