ModSecurity in X Minutes

ModSecurityInXMinutes.md

ModSecurity In X Minutes

There are just a few fundamental pieces to learn in order to get started with ModSecurity.

• Phases
• Actions and Rules
• Collections

Phases

There are 5 phases of request processing in ModSecurity ¹. You can hook into any one these phases using the phase keyword when writing ModSecurity Actions and Rules. The 5 phases occur in this order:

1. Request Headers Phase
2. Request Body Phase
3. Response Headers Phase
4. Response Body Phase
5. Logging Phase

As you pass through the phases, you can still access the information from the previous phases. So, if you are not sure where to begin, start with Logging Phase 5.

Actions and Rules

ModSecurity configurations are built around Actions (SecAction) and Rules (SecRule). We'll start with SecAction since it is basically a SecRule but without a conditional. In other words, SecAction will always execute a list of actions, while a SecRule will only execute a list of actions if a certain condition is met.

Example

SecAction id:100,phase:1,deny

The SecAction above is about as simple as it gets. It denies a request, sending a 403 status to client.

The id:100,phase:1,deny is known as the action list. Every action must include an id and it must be unique amongst all your SecAction and SecRule². After the id is the phase:1 which means this rule will run in the first phase. So, the request will be denied as soon as possible by ModSecurity. Finally, the deny is the part that actually says this SecAction will send a 403 status.

Modified Example

If you want to send something besides the default deny status of 403, you can change it by using the status action like this:

SecAction id:100,phase:1,deny,status:451

The action above would deny the client access and send a "451 Unavailable For Legal Reasons" status.

Action List Order

The ordering of items in an action list is not always important. If you are using things like Transformation Functions ³\ (e.g. base64Encode, hexEncode, trim, etc) you need to pay attention to order, especially when you use multiple Transformation Functions in a single action or rule. The first Transformation Function will change the input for the following functions.

The example from the previous section does not have any actions that would change behavior due to their order in the list. For instance, the following would execute the exact same as in previous section:

SecAction status:451,deny,phase:1,id:100

Useful Example

In the previous sections we used an example that simply denies every request. This isn't very useful so we'll add a condition to the action, making it a SecRule. The condition will be: if someone requests the page and is from the IP address 192.168.100.200, then we want to deny them with the 451 status:

SecRule REMOTE_ADDR "192.168.100.200" id:100,phase:1,deny,status:451

The REMOTE_ADDR ⁴ is the value we are testing and the "192.168.100.200" is test itself. If the test passes then the action list is executed.

Collections

Collections (a.k.a. Persistent Storage) are an important feature of ModSecurity because they give you the ability to store information over many requests. For example, if you want to keep

Footnotes

1. https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Processing_Phases ↩

2. https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#id ↩

3. https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#transformation-functions ↩

4. https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#remote_addr ↩