Chapter 3. ModSecurity Rules Making

Configuration Directives: The configuration directives for ModSecurity are similar to the Apache Server directives. Most of the ModSecurity directives can be used inside the various Apache Scope Directives. There are others, however, that can only be used once in the main configuration file. These rules, along with the Core rules files, should be contained in files outside of the httpd.conf file and called up with Apache "Include" directives. This allows for easier updating/migration of the rules. A full listing of configuration directives can be found in the reference section of this document:

ModSecurity primarily functions when the user creates custom rules. These custom rules dictate what Mod_sec checks for when running. The rules are implemented at any of the 5 phases for the Apache request cycle. The five phases and their syntax names are given below:

Request headers → REQUEST_HEADERS

Request body → REQUEST_BODY

Response headers → RESPONSE_HEADERS

Response body → RESPONSE_BODY

Logging → LOGGING

This section explains an example custom rule. The custom rule given checks whether or not history was changed by a request. Generally rules have 4 parts: a configuration directive, variable(s), operator(s), and action(s). For full listings of configuration directives, variables, operators, and transformations/actions, please refer to the reference section of this guide. The rule is given below:

SecRule REQUEST_URI "@streq /index.php" "id:1,phase:1,t:lowercase,deny"

The rule begins with SecRule. This is a configuration directive which creates a rule that will analyze the selected variables using the selected operator. Most of your rules will use this configuration directive.

The rule then continues with the variables: REQUEST_URI This variable holds the full request URL including the query string data.

Next, operators the operator is defined as "@streq /index.php". the @streq checks for string values equal to the /index.php file. However, before this occurs, our transformations/actions will take place. They are defined as "id:1,phase:1,t:lowercase,deny". From this command, the rule, during phase 1, will obtain the URI portion of the HTTP request, and transform the value to lowercase. it will then check the transformed value to see if it is equal to /index.php. If it is equal, Modsecurity will deny the request, and no further rules will be processed.

This section explains a more complex example rule. The custom rule given checks whether or not history was changed by a request. Generally rules have 4 parts: a configuration directive, variable(s), operator(s), and action(s). For full listings of configuration directives, variables, operators, and transformations/actions, please refer to the reference section of this guide. The rule is given below:

SecRule REQUEST_URI|REQUEST_BODY|REQUEST_HEADERS_NAMES|REQUEST_HEADERS "history.pushstate|history.replacestate" "phase:4,deny,log,msg:'history-based attacks detected'"

The rule begins with SecRule. This is a configuration directive which creates a rule that will analyze the selected variables using the selected operator. Most of your rules will use this configuration directive .

The rule then continues with the variables: REQUEST_URI|REQUEST_BODY|REQUEST_HEADERS_NAMES|REQUEST_HEADERS There are 4 variables here and each defines a different part of the request that the rule checks.

Next, operators are defined for the request. In this case, the rule checks for the JS methods history.pushstate() and history.replacestate(). Assuming these values are found, the last section will be executed.

The last section defines transformations and actions that will take place. In this case it first defines the processing phase in which the rule occurs. Then it runs the deny, log, and msg actions. Deny will stop the rule processing and intercept the transaction. Log will indicate that a log will need to be created. Msg will output a message with the log. the message is defined as 'history-based attacks detected'.