3.3.1rc1 breaks Directory and Location in Apache2

Describe the bug

Using the 3.3.1rc1 breaks the ability to use SecRuleEngine/SecRuleRemoveById within the Directory/Location tags. Reverting back to 3.3.0 fixes the problems.

Steps to reproduce

Run an “attack” against Directory with ModSecurity disabled:

        <Directory /var/www/somecrappysite>
                SecRuleEngine Off
        </Directory>

Expected behaviour

The Directory/Location settings should be honored.

Actual behaviour

A block occurs untill the statement is moved out of the Directory/Location tags, which makes unblocking specific items problematic.

Your Environment

• CRS version: 3.3.1rc1
• Paranoia level setting: 1
• ModSecurity version: 2.9.3-3
• Web Server and version: Apache 2.4.46-2
• Operating System and version: Debian testing

[dune73]

I should do a blog post to explain it in detail… But it’s actually not so complicated.

Here is an example:

Virtual Host:

SecWebAppId     XXX

Server Context (Before CRS Inclusion):

SecRule WEBAPPID                        "@streq XXX"    "id:1000,phase:1,pass,nolog,chain"
   SecRule REQUEST_URI                  "@beginsWith /subfolder"        "ctl:RuleEngine=off"

Naturally, if you do your CRS Include in the VH, then you do not need this, but then you probably include CRS separately for several VHs and this can lead to memory problems with ModSec.

[GieltjE]

If I’m understanding correctly using the SecWebAppId would still not allow disabling of specific rules for certain Directory/Location directives? Or would they just trigger the logging bug not actually block the request?

Also do you have some examples? I seem to be getting lost in the documentation as how to achieve rule based actions in combination with the WEBAPPID variable.