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 ModSecurity Reference Manual: Processing Phases 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 ModSecurity Reference Manual: Configuration Directives 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 Note Most 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 Note The 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 Note Most 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() and history.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 4.6. Additional resources (or steps) ModSecurity Reference Manual: Actions ModSecurity Reference Manual: Configuration Directives ModSecurity Reference Manual: Operators ModSecurity Reference Manual: Transformation functions ModSecurity Reference Manual: Variables

Commands: