3. Adding Filtering Rules
mod-security can take two kinds of filters:
- Simple Filters: SecFilter directive
- Advance Filters: SecFilterSelective directive
Simple filter directives apply on any filters you turned on, so in our case, on GET and POST request.
the syntax of simple filter directive is:
SecFilter KEYWORD [ACTIONS]
KEYWORD can be a string or a regular expression,
ACTIONS is optionnal, if it is not defined, mod-security will use the
SecFilterDefaultAction value (log and return 500 error page as we defined earlier, in mod-security skeleton file).
Advance filters do filter specific streams. Its syntax is:
SecFilterSelective LOCATION KEYWORD [ACTIONS]
ACTIONS is optionnal,
LOCATION consist of a serie of location identifier separated by pipes (|). An advance filter looks like:
SecFilterSelective "REMOTE_ADDR|REMOTE_HOST" KEYWORD
Among the most important actions, we could highlight:
- pass: Allow request to continue on filter match. This action is useful when you want to log a match but otherwise do not want to take action.
- allow: This is a stronger version of the previous filter. After this action is performed the request will be allowed through and no other filters will be tried.
- deny: Interrupt request processing on a filter match. Unless the status action is used too, ModSecurity will immediately return a HTTP 500 error code
- status: Use the supplied HTTP status code when request is denied.
- redirect: On filter match redirect the user to the given URL.
- exec: Execute a binary on filter match. Full path to the binary is required
- log: Log filter match to the Apache error log.
- nolog: Do not log the filter match. This will also prevent the audit logging from taking place.
- chain: Rule chaining allows you to chain several rules into a bigger test. Only the last rule in the chain will affect the request but in order to reach it, all rules before it must be matched too.
- auditlog/noauditlog: Log/Do not log the transaction information to the audit log.
Now that’s said, it’s time for some examples.