Good midday, 54.81.185.16.
Today is sunday the 30th of April 2017. The time is 11:00:21 and it's week number 17.

(2013-07-05) Modsecurity_head_ache ? ... Here's how to cure it!

Don't get me wrong, modsecurity is a very competent security “application firewall”. I recently set it up on a server and downloaded the OWASP Core Rule Set (CRS). The base rules are a bit rudimentary, so I recommend that you get the OWASP CRS as well. As soon as it was setup, modsecurity started issuing warnings and blocking access. I pretty soon had to start creating exceptions for some files and directories. From there on I spent hours to test everything, scanning the logs with grep to find the errors. And then deciding on how to handle them.

Modsecurity is not something that you can just “setup” and the let it run. But if you spend time with it, you can add another layer of security to your system.

Here are a few tips, that you can probably find somewhere else as well, on how to setup exceptions. I hope you find them useful.

First, create a file in base_rules and call it modsecurity_00_custom_exclusions.conf. Create a link to this file from activated_rules with ln -s. Then open it for write in your favorite file editor.

If you want to totally disable modsecurity on a specific path, add this to modsecurity_00_custom_exclusions.conf:

<LocationMatch /folder/file.php>
<IfModule mod_security2.c>
SecRuleEngine Off
</IfModule>
</LocationMatch>

This rule with disable modsecurity for the file /folder/file.php.

It at also works fine for a folder (and its files and subfolders with their files)

<LocationMatch /folder/folder-to-omit/>
<IfModule mod_security2.c>
SecRuleEngine Off
</IfModule>
</LocationMatch>

You really should avoid totally disabling files or folders. Normally, you can use your logs to pinpoint why the lock down is triggered.

Example from Apache's error log:

[Fri Jul 05 17:36:06 2013] [error] [client xx.xx.xxx.xxx] ModSecurity: Access denied with code 403 (phase 2). String match "bytes=0-" at REQUEST_HEADERS:Range. [file "/etc/modsecurity/activated_rules/modsecurity_crs_20_protocol_violations.conf"] [line "248"] [id "958291"] [rev "2.2.5"] [msg "Range: field exists and begins with 0."] [data "bytes=0-"] [severity "NOTICE"] [tag "RULE_MATURITY/5"] [tag "RULE_ACCURACY/7"] [tag "https://www.owasp.org/index.php/ModSecurity_CRS_RuleID-958291"] [tag "PROTOCOL_VIOLATION/INVALID_HREQ"] [tag "http://www.bad-behavior.ioerror.us/documentation/how-it-works/"] [hostname "www.test.com"] [uri "/folder/file.php"] [unique_id "xxxxxxxxxxxxxxxx"]

The important thing to note here is that access was denied. The key is the text “ModSecurity: Access denied with code 403(...)”. Now, the perfect solution should be reading up on WHAT this error means and and make sure it's not a false positive and then change the web application script that triggers it. In this case its “file.php” under /folder/. But you may have no way of rewriting it or have decided the error is in fact … uhm... in error. If so, disabling this exact rule for this exact file is simple. First find the rule number. It's called id and in this case, [id "958291"] is where you find it.

With this knowledge, all you have to do is to add an exception to modsecurity_00_custom_exclusions.conf:

<LocationMatch /folder/file.php>
<IfModule mod_security2.c>
SecRuleRemoveById 958291
</IfModule>
</LocationMatch>

Is this particular file generating more than one error or warning? No problem, just add this instead:

<LocationMatch /folder/file.php>
<IfModule mod_security2.c>
SecRuleRemoveById 958291 958292
</IfModule>
</LocationMatch>

The official documentation suggests that rule ids can be specified in many different ways:

SecRuleRemoveById 1 2 5 10-20 "400-556" 673

This translates to: remove ids 1, 2, 5, ids between 10 and 20, ids between 400 and 556 and please don't forget 673.

Links:

http://www.modsecurity.org/documentation/modsecurity-apache/2.5.6/modsecurity2-apache-reference.html#N1096A

http://www.modsecurity.org/documentation/modsecurity-apache/2.5.6/modsecurity2-apache-reference.html


Posted: 2013-07-05 by Erik Zalitis
Changed: 2013-07-05 by Erik Zalitis

News archive