ConfigServer Community Forum

Hi guys,

We run a bunch of cPanel servers where we use the cPanel Mod_security vendor functionality, and there we include the "Comodo WAF" ruleset (https://waf.comodo.com/doc/meta_comodo-apache.yaml)

To control Mod_security further we use the CMC, since we can disable rules per site level if we want to.

One rule though (ID 220030) we disable globally through CMC, because the rule only applies to PHP versions before 5.4.2 (not something we offer).

When we disable this rule, it never actually takes effect - and mod_security continues to block based on this rule.

Then I tried disabling the same rule globally via cPanel's Mod Security rules list, and there it works perfectly.

Turns out the only difference (other than file location), is that CMC wraps the SecRuleRemoveById within a LocationMatch .* block - where cPanel's own tool doesn't do this.

Whenever you disable rules in mod_security, you have two options - using SecRules or the SecRuleRemovebyId - SecRuleRemoveById is a global directive, and shouldn't be put inside a LocationMatch block in first place (at least according to a bunch of "issues" on github from SpiderLabs itself.

So.. To investigate further, I enabled the rule in cPanel's own tool again, and then went into the ./conf.d/modsec2.whitelist.conf file and removed the LocationMatch .* that CMC puts around the rules when it disables it, and suddenly everything starts to work.

Is it possible CMC can get bugfixed to not include the LocationMatch at any point? Specially not when just using .* - since the LocationMatch becomes rather obsolete if you just want to match anything anyway (which turns out to not be the case for a bunch of rules).

Thank you in advance.

This was already in development and has now been released in v2.10 of cmc:
https://blog.configserver.com

ForumAdmin wrote: ↑14 Mar 2017, 10:15 This was already in development and has now been released in v2.10 of cmc:
https://blog.configserver.com

I found that after this change modsec user defined rules insde <LocationMatch> can not be disabled (Nor global, nor by user, nor by domain).

As a temp workaround, if I want to disable a user defined rule by domain I can create a .conf file manually with this content:

cat /etc/apache2/conf.d/userdata/ssl/2_4/my_user/my_domain.com/modsec-personal.conf

<IfModule mod_security2.c>
<LocationMatch .*>
# Start cmc block
SecRuleRemoveById 9999999
# End cmc block
</LocationMatch>
</IfModule>

This way this rule now it is disabled as expected but can not be managed from cpanel cmc plugin.

I'm having the exact same issue. I'm using cPanel, EasyApache 4 and ModSecurity 2.9.0.
I'll add an example so this can be better solved.

Take this custom rule: This doesn't whitelist the rule: This does: I eventually solved this by rewriting the rule itself to not use LocationMatch:

Looks like we'll have to implement both as sometimes you need LocationMatch and others not it seems. So:

ForumAdmin wrote: ↑27 Jul 2017, 16:47 Looks like we'll have to implement both as sometimes you need LocationMatch and others not it seems. So:

Code: Select all

<IfModule mod_security2.c>
SecRuleRemoveById 1010105
<LocationMatch .*>
	SecRuleRemoveById 1010105
</LocationMatch>
</IfModule>

I have the impression that LocationMatch isn't really used by any of the ruleset makers as I've only had thi issue with my custom rule. Maybe I simply shouldn't be using it in the first place.

I just modified my rule to not use LocationMatch anymore. Not sure what gives best performance, using Apache as a filter or ModSecurity itself. The above rule is hit about 1000 times an hour on my servers so I'll check server performance in a few hours.

Not sure what the actual issue is here, but this ModSecurity stuff is beyond rocket science. Most of this stuff makes my head hurt

WhiteDog wrote: ↑27 Jul 2017, 17:45 I have the impression that LocationMatch isn't really used by any of the ruleset makers as I've only had thi issue with my custom rule. Maybe I simply shouldn't be using it in the first place.

They do use it for script specific targeted rules, so we will consider it, but it is going to be a bit of a pain.

Saw the update today to address this, many thanks for the fix!