What's New in ModSecurity
Pages: 1, 2, 3, 4

Rule Inheritance

Once you have the unique rule ID, you can use it for other purposes, too. For example, imagine you have a default configuration that does not work well with one particular aspect of your website. Using the unique rule ID, you can choose to go with the default configuration, removing just the rule that does not work:

<Location /subcontext/>
   SecFilterRemove 1001
</Location>

You can do it the other way around, too; not inheriting anything from the parent context but only importing a rule or two:

<Location /subcontext/>
   SecFilterInheritance Off
   SecFilterImport 1002 1003
</Location>

To help you further, it is now even possible to mark a rule as mandatory (using the action mandatory). It is also possible to mark all rules in a given context mandatory (using the SecFilterInheritanceMandatory directive). Mandatory rules can resist the SecFilterInheritance and SecFilterRemove directives.

Increasing the Flexibility of Rule Actions

Serious users of ModSecurity will be happy to learn that it is now possible to specify custom actions for several rules at once. To preserve backward compatibility, I introduced a new directive: SecFilterSignatureAction. Here is one example of its use:

# Warning-only rules
SecFilterSignatureAction log,pass
SecFilter KEYWORD1
SecFilter KEYWORD2

# Blocking rules
SecFilterSignatureAction log,deny,status:403
SecFilter KEYWORD3
SecFilter KEYWORD4

SecFilterSignatureAction affects all rules that follow in the configuration file. Rules that do not specify custom actions will simply use the action list verbatim. Rules that do specify custom actions will have their actions merged with the actions specified in SecFilterSignatureAction. This allows you to separate rule meta-data from security policy while still being able to override the default setting.

SecFilterSignatureAction log,deny,status:403
SecFilter KEYWORD5 id:1
# Respond with 404 instead of 403
SecFilter KEYWORD6 id:2,status:404

Of course, increasing rule action flexibility is not a desirable feature at all times, especially when you are considering whether to include a rule set produced by a third party. For example, what if the set contains a bad rule that will start rejecting legitimate requests? What if you don't want to reject requests at all but the set contains a rule that does? A new directive, SecFilterActionsRestricted, helps with this problem. When enabled, it restricts which actions can appear in all of the rules that follow in the configuration file. Only a selected few actions, namely the meta-data actions, will be allowed. Others will be silently ignored. Now you can safely do the following:

SecFilterActionsRestricted On
Include conf/modsecurity-thirdparty.conf

Still, you need to make sure the included file contains only SecFilter, SecFilterSelective, or SecFilterSignatureAction directives.

Pages: 1, 2, 3, 4

Next Page