Debian/Ubuntu Tips and Tricks

Debuntu

Debian/Ubuntu Tips and Tricks

Secure your Apache2 with mod-security — page 2

Posted by chantra on August 13th, 2006

This entry is part 2 of 3 in the series Secure your Apache2 with mod-security

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]

Same here, 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

you can get the full list of keywords from mod-security site . For actions, you might want to refer to mod-security documentation action page.

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:

Series Navigation<< Secure your Apache2 with mod-securitySecure your Apache2 with mod-security — page 3 >>

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>