feat: accidental firewall disability prevention

[azurit]

This is only a proof-of-concept, probably not the best one.

Everyone of our users, who is new to rule exclusions and is trying to write his/her own exclusion rules, is disabling also one or both of the rules 949110 and 959100. What is worse, in most cases, users see that it helped to resolve the problem and doesn't know that the whole firewall was disabled. Such cases are discovered probably only by accident, because users are having more problems they are unable to resolve and are asking for help where they show us currently used exclusion rule. How many installations of CRS are there with rules 949110/959100 disabled?

This PR is showing how it is possible to partially prevent this and, at least, log a huge warning for a user.

Any ideas how to do this better are welcomed.

[dune73]

I see what you want to do here, but do you really think this is such a big deal?

I agree it can happen, but any functionality test of the WAF will fail afterwards anyways.

For the record: My modsec-rulereport.rb script used to generate rule exclusions refuses to do a rule exclusion for one of the evaluation rules but displays an explanation instead. The same is true for c-rex.netnea.com.

[azurit]

I agree it can happen, but any functionality test of the WAF will fail afterwards anyways.

It depends, most of the exclusion rules looks like this:

SecRule REQUEST_FILENAME "@streq /wp-admin/admin-ajax.php" \
    "...
    ctl:ruleRemoveTargetById=..."

If a user adds ctl:ruleRemoveById=949110 into such rule then firewall as a whole is working but is disabled only on a specific part(s) of the application.

[azurit]

See:
#1
#2

[azurit]

This one is real fun. :)
#3

[azurit]

Few are also here:
#4

[dune73]

I agree it can happen, but any functionality test of the WAF will fail afterwards anyways.

It depends, most of the exclusion rules looks like this:

SecRule REQUEST_FILENAME "@streq /wp-admin/admin-ajax.php" \
    "...
    ctl:ruleRemoveTargetById=..."

If a user adds ctl:ruleRemoveById=949110 into such rule then firewall as a whole is working but is disabled only on a specific part(s) of the application.

You are right here, yes.

[dune73]

I am not convinced this is needed, but the example with the path constraint is really very hard to spot any other way.

Let's discuss this at the next meeting.