Chapter 4. Creating ModSecurity rules
ModSecurity primarily functions based on custom user-defined rules. These rules determine the types of security checks that ModSecurity performs.
4.1. ModSecurity rules in the Apache request cycle
You can apply rules to any of the five ModSecurity processing phases of the Apache request cycle:
- Request headers
-
Apply a ModSecurity rule to this phase by specifying a
REQUEST_HEADERS
variable in the rule syntax. - Request body
-
Apply a ModSecurity rule to this phase by specifying a
REQUEST_BODY
variable in the rule syntax. - Response headers
-
Apply a ModSecurity rule to this phase by specifying a
RESPONSE_HEADERS
variable in the rule syntax. - Response body
-
Apply a ModSecurity rule to this phase by specifying a
RESPONSE_BODY
variable in the rule syntax. - Logging
-
Apply a ModSecurity rule to this phase by specifying a
LOGGING
variable in the rule syntax.
Additional resources
4.2. Structure of ModSecurity rules
A ModSecurity rule typically consists of four main parts:
- A configuration directive
- One or more variables
- One or more operators
- One or more actions
4.3. ModSecurity configuration directives
A ModSecurity rule starts with a configuration directive. The configuration directives for ModSecurity are similar to the Apache HTTP Server directives. You can use most ModSecurity directives within the various Apache scope directives. However, you may only use some ModSecurity directives once in the main configuration file.
You must store these rules and the core rule files outside of the httpd.conf
file. You can use Apache Include
directives to call these rules. This facilitates the upgrade and migration of the rules.
Additional resources
4.4. Example of a simple ModSecurity rule
You can define the following simple ModSecurity rule, for example, to check if the URI portion of a request equals a specific lowercase value:
SecRule REQUEST_URI "@streq /index.php" "id:1,phase:1,t:lowercase,deny"
The preceding ModSecurity rule consists of the following compoonents:
SecRule
A configuration directive that creates a rule to analyze the specified variables by using the specified operator
NoteMost ModSecurity rules use this configuration directive.
REQUEST_URI
- A variable that holds the full request URL including the query string data
"@streq /index.php"
-
An operator where
@streq
checks for string values that are equal to/index.php
"id:1,phase:1,t:lowercase,deny"
Actions or transformations that the rule performs
NoteThe rule performs the
lowercase
action first before the rule implements the preceding operator instruction.
Based on the preceding example, during phase 1 of the Apache request cycle, the rule obtains the URI portion of the HTTP request and transforms the value to lowercase. The rule then checks if the transformed value equals /index.php
. If the value does equal /index.php
, ModSecurity denies the request and does not process any further rules.
4.5. Example of a complex ModSecurity rule
You can define the following complex ModSecurity rule, for example, to check if a request has changed history:
SecRule REQUEST_URI|REQUEST_BODY|REQUEST_HEADERS_NAMES|REQUEST_HEADERS "history.pushstate|history.replacestate" "phase:4,deny,log,msg:'history-based attacks detected'"
The preceding ModSecurity rule consists of the following components:
SecRule
A configuration directive that creates a rule to analyze the specified variables by using the specified operator
NoteMost ModSecurity rules use this configuration directive.
- `REQUEST_URI|REQUEST_BODY|REQUEST_HEADERS_NAMES|REQUEST_HEADERS `
- A pipe-separated list of variables that define different parts of the request that the rule checks
"history.pushstate|history.replacestate"
-
A pipe-separated pair of operators that check for the JavaScript
history.pushstate()
andhistory.replacestate()
methods "phase:4,deny,log,msg:'history-based attacks detected'"
- Actions or transformations that the rule performs if the specified operator values are found
Based on the preceding example, during phase 4 of the Apache request cycle, the rule checks different parts of the request cycle for history.pushstate()
and history.replacestate()
methods. If the rule finds these methods in the request URL string, request body, request header names, or request headers, the rule performs the following actions:
deny
Stops the rule processing and intercepts the transaction
log
Logs a successful match of the rule to the Apache error log file and the ModSecurity audit log
msg
Outputs a message defined as
history-based attacks detected
with the log