Whenever a filter catches a request, then an action, or better, a list of actions is performed. The general syntax for action lists is (no spaces are allowed between actions):

"primary_action,secondary_actions,flow_action or parameter:value action"

For example:

SecFilterDefaultAction "deny,log,status:406"

Action lists can be defined in three places:

1. SecFilterDefaultAction directive: Whenever a user-defined rule, which follows this directive, is matched, then these default actions are performed, unless they are overridden by a per-ruleset or per-rule action list (see below).
2. SecFilterSignatureAction directive: This directive may appear several times in the configuration and is used in order to specify a per-ruleset action list. A ruleset consists of all the rules that immediately follow the SecFilterSignatureAction directive. Action lists that are defined in this directive are merged with the default action list. Note that this merging procedure may result in action overriding. It depends on the type of the actions used. See the documentation for more information on this. Also, note that this action list will not be inherited by child contexts.
3. SecFilter and SecFilterSelective directives: These directives accept an optional action list to be performed whenever the rule is matched. These are per-rule actions. Actions defined in these directives are merged with the actions that are defined in the other two directives above. Note that this merging procedure may result in action overriding. It depends on the type of the actions used. See the documentation for more information on this.

Another action-related directive is SecFilterActionsRestricted. When it is set to On, all the per-rule actions, except for the metadata actions (id, msg, rev, severity), are ignored. This is particularly useful when importing 3rd party rules, which also contain per-rule action lists, but you want to define your own action-list to be performed when any of these rules is matched.

In short, the most commonly used actions and what they actually do on a filter match are outlined below:

pass

Do nothing and continue on with the next rule. Useful when running ModSecurity in detect-mode.

allow

Allow the request, but do not continue the request or server-response analysis.

deny

Deny the request and return the error document which corresponds to the defined status code (see below).

log

Log to the Apache error log and to the adit log if the audit engine is enabled.

nolog

Log nothing to the Apache error log or to the audit log.

status

(status:CODE): Specifies the HTTP error code that will be returned if the request is rejected.

redirect

(redirect:URL): Redirect to specified page. Always overrides the status and deny actions.

exec

(exec:/path/to/script): Execute the specified script. This action is always performed in addition to the primary action (if one is defined). The script must write its output to stdout.

Also, a flow action, which affects the order in which the rules are processed, may be defined:

skipnext

(skipnext:N): Skips next N rules on filter match.

chain

Combine two or more filters together. The last filter is the one that will affect the request, but in order to reach the last filter, all previous chained filters must be matched.

One of the most useful features of ModSecurity is that metadata (rule id, revision number, a text message, severity information) may be defined for each filter. This metadata is defined as parameter:value, where action can be one of id, rev, msg, severity. For example:

SecFilter ".*admin.*" id:3,severity:1

Finally, a filter or a chain of filters can be explicitly marked for inheritance in child contexts with the mandatory action. For example:

SecFilter ".*admin.*" mandatory

or

SecFilter ".*admin.*" mandatory,chain
SecFilter ".*login.*"

For more information refer to the ModSecurity documentation.

Tags: ModSecurity