Avoiding mod security false positives with white-listing

We have already discussed in my previous articles how to configure Mod Security Firewall with OWASP rules and also analysed the different types of logs which Mod Security generates. While analysing the logs, we have seen that the OWASP rules generate a lot of false positive results, as these rules are standard and not application-friendly. We need to edit the default rules in order to eliminate the false positive results. We can do this by creating the white-list rules according to the application's requirement. So, in this article we will discuss different types of techniques for writing the white-listing rules for Mod Security.

We will write all the white-list rules in the whitelist.conf file, as we have already configured this file with Mod Security in previous articles, so we don't need to create another file. Just open the whitelist.conf file in any editor. The path of the whitelist.conf file is following.

/etc/httpd/modsecurity.d/whitelist.conf

NOTE: The path of the white-list file is not same in all cases. It depends on the configuration of Mod Security. You can read the previous articles for the configuration details. The URLs of the previous articles are given below:

• /configuring-modsecurity-firewall-owasp-rules/
• /analyzing-mod-security-logs/

White-list or remove the rule on the basis of the rule ID

Every rule in Mod Security is identified by the Rule ID. We will use this ID to white-list the rule. Let's look into the rule ID for the following error log which was generated by Mod Security.

In the above screenshot, we can see the Rule ID. Now, we can create the rules on the basis of this ID. This can be done by adding the rule in the whitelist.conf file. Open the whitelist.conf file in VIM editor.

After the above step, we can see the following details in the file.

These are the white-list configuration settings of Mod Security. We are not discussing the settings, as we have already discussed this in a previous article. Now, we will add the following lines in the end of the file for white-listing the rule.

[plain]

# Remove Mod Security Rules

<LocationMatch .*>

<IfModule mod_security2.c>

SecRuleRemoveById 960017

</IfModule>

</LocationMatch>

[/plain]

Now, save this file and restart the Apache server. Every time we make any changes in the configuration of Mod Security, we must restart the Apache service to start the rules with Mod Security. The meaning of each marked line is explained in the below section.

• The LocationMatch directive creates a location specific configuration context. As of now we are using ".*" which means this rule will work in the entire application. We can also give a particular file name for creating the rule. For example, we have file name auth.php which is generating the error and the rule ID of the error is 45345. So, the white-list rule of the error is:

[plain]

<LocationMatchauth.php>

<IfModule mod_security2.c>

SecRuleRemoveById 960017

</IfModule>

</LocationMatch>

[/plain]

So we can create rules on the basis of the rule ID according to the requirement.

• This is the Mod Security module. All rules will be created inside this tag.
• The SecRuleRemoveById directive is used to remove a rule according to rule ID. The rule ID can be seen in the Mod Security error log. We can also define the multiple rule IDs separated by a comma, or we can also give the rule range. For example, if we want to white-list all the rules that fall between 400 and 500, we can write SecRuleRemoveByID "400-600".

White-list or remove the rule on the basis of error messages

We can also white-list the rules on the basis of error messages. Let us look into the following error.

We can see the message "Host Header is a Numeric IP Address" in the error log. Thos type of error message comes when the website is accessed through the IP address. Let us white-list this rule.

We can white-list this rule by the SecRuleRemoveByMsg directive. It will white-list the rule according to the error Message. Add the following lines in the whitelist.conf file.

[plain]

<LocationMatch .*>

<IfModule mod_security2.c>

SecRuleRemoveByMsg "Host header is a numeric IP address"

</IfModule>

</LocationMatch>

[/plain]

Each marked line in the above screenshot is explained in the below section:

• <LocationMatch .*> means this rule will disable Mod Security throughout the application. We can add this rule on a particular path also.
• In the double quote we can give the message which will be whitelisted by the firewall.

Hence, there are the so many directives which can be used to whitelist the rules. We need to carefully read the error logs, then we can easily create the white rules. We can see all directive details on the SpiderLags Website.

Let us consider the example given below:

Disable Mod security firewall on a URL

Sometimes there are situations in which we need to disable the firewall on a particular URL. Let us suppose in a website we have a file upload.php in the upload folder. We can white-list this file by adding the following lines of code.

[plain]

<LocationMatch /upload/upload.php>

<IfModule mod_security2.c>

SecRuleEngine Off

</IfModule>

</LocationMatch>

[/plain]

These lines are explained below:

• LocationMatch is the directive which is used to match the particular location file or folder location on the server. Here, we are defining the location /DVWA/setup.php file.
• This directive is used to disable Mod Security in the location which is defined in the above line. Here, we have set it as off. It means that whatever functionality is working on this file, it will not be blocked or logged into the Mod Security error log. We can also set other options as per the requirement with the directive.

There are so many other rules which can be created according to the requirement.

Sources

• Mod Security Hand Book
• Mod security
• FAQs
• Reference Manual