modsecurity rule blocking my site from saving

[rhett]

My site is a woocommerce store built with Bricks Builder page builder.
DirectAdmin panel + litespeed web server, running on unmanaged VPS.

I found in modsecurity log below rule set blocking:
Blocking saving in Bricks settings:
932235
941110
941100
941160
941180
Blocking entering editor canvas and causing redirect to /my-account/page
933150
Blocking saving in editor canvas
932230

How to bypass the security for administrator's operation without disabling those rules completely, please?

I attached 4 ruleIDs blocking log in the attached link. Please have a look.

[alevchenko]

Hi,

The rule IDs you posted are a part of the OWASP ModSecurity Core Rule Set (CRS), not Imunify360. You can refer to https://www.netnea.com/cms/core-rule-set-inventory/
If you are using Imunify360, we recommend disabling all other vendors except the Imunify ruleset, as using different rulesets simultaneously may cause a high false-positive rate and inconsistent rule functioning. More at: https://cloudlinux.zendesk.com/hc/en...-in-Imunify360

Since you're on an unmanaged VPS, you’ll need to edit the ModSecurity/OWASP CRS config yourself (or ask the person managing the server to).

You can add targeted exclusions just for your Bricks admin/editor URIs using `SecRuleUpdateActionById`. This will keep the rules alive everywhere else; it only loosens them for those specific pages.
Here is some tuning advice on practical examples of disabling or altering specific rules https://security.stackexchange.com/q...detection-mode

[rhett]

Great. Thanks. I just removed OWASP, and the issues are missing now.
🙏🙏🙏

By the way, I use DirectAdmin Panel. I bought your single user per server plan from hosting.com. Do you know where to add the custom modsecurity rule? Just in case similar issue happens, I can easily locate the file to place the rules

[alevchenko]

Good to know removing the OWASP ruleset sorted the issue 👍

By the way, I use DirectAdmin Panel. I bought your single user per server plan from hosting.com. Do you know where to add the custom modsecurity rule? Just in case similar issue happens, I can easily locate the file to place the rules

On the DirectAdmin panel, there should be an option to manage Custom Rules (menu Extra Features -> ModSecurity):

Also, it can be achieved via the server configuration: https://cloudlinux.zendesk.com/hc/en...9EEJJCGM0NQ1JY

[rhett]

Thanks.

So in future I have similar issue, can I create the custom_rules_conf and paste following rule to solve it:

SecRule REQUEST_FILENAME "@beginsWith /wp-admin/" \
"id:1001,\
phase:2,\
pass,\
nolog,\
ctl:ruleRemoveById=911100,\
ctl:ruleRemoveById=932260,\
ctl:ruleRemoveById=920340,\
ctl:ruleRemoveById=932235,\
ctl:ruleRemoveById=941100,\
ctl:ruleRemoveById=941130,\
ctl:ruleRemoveById=941160,\
ctl:ruleRemoveById=941170,\
ctl:ruleRemoveById=949110,\
ctl:ruleRemoveById=980130"

[alevchenko]

Hi,

Regarding your proposed rule, it works syntactically, but it’s too broad (all of /wp-admin/ for all users) and it disables a lot of CRS coverage, including 949110 (overall blocking) and 980130 (in some stacks, a generic rule used by vendors) — I’d recommend avoiding it. Instead, start with the minimal set that actually tripped in your logs and scope to the precise endpoint (and ideally only for authenticated users).
The @beginsWith style is fine; see ModSecurity examples: https://www.netnea.com/cms/apache-tu...g-modsecurity/

However, this should not pose an issue in the future; the custom rules for the aforementioned rule IDs will be extra, as you previously indicated that you removed the OWASP ruleset.
Furthermore, should you consider re-enabling the OWASP ruleset in the future, please be aware that the potential for WAF inconsistency cannot be excluded — it may not function correctly when two or more rulesets are enabled simultaneously (e.g., Imunify360 ruleset + OWASP).

Lastly, if you are referring to a similar issue involving false-positive triggers from the Imunify360 ruleset, we recommend reporting such instances to our team so that we can investigate the behaviour and update the affected rule if necessary, rather than resorting to the workaround of simply disabling it for the entire domain or a specific URL.