Setting up the Core Rule Sets for Apache mod_security

Printer-friendly versionPDF version

After just about a year of hosting, I can tell you, this is one module that you should not host any website without. But configuring the module itself is not enough, without the OWASP ModSecurity Core Rule Set (CRS), the module is pretty much useless.

Again, I'm using Debian, so both these modules are availiable from the debian repositories. You can install them as below:

apt-get -install libapache2-modsecurity modsecurity-crs 

mod_security can be configured as mentioned in my previous article here. Now all we need to understand is how to start up using the core rule sets. For one lets create folder called "crs" under "/etc/modsecurity/". Now copy all the contents of the folder "/usr/share/modsecurity-crs" to this folder. The other way it to directly get the rules from github repository found at "https://github.com/SpiderLabs/owasp-modsecurity-crs". These rules will be newer than what Debian has.

Anyways on the github version, there will be a file "INSTALL" that will show you how to activate the rules. In the Debian version you copied over from "/usr/share/modsecurity-crs", there is file "/usr/share/modsecurity-crs/activated_rules/README" which shows you how to start using the core rule sets.

In essence you need to symlink every rule you think you need from the "/etc/modsecurity/crs/" folder, for your server to the folder "/etc/modsecurity/crs/activated_rules/". So first off symlink the modsecurity_crs_10_setup.conf to the "activated_rules" folder. Than start adding base_rules, optional_rules and slr_rules and so on. All along you need to be continually testing your web application. When  apache gives you an "Internal Server Error 500" for a genuine case you think, that should work, it probably means mod_security thinks it detected some foul activity. You need to check than the log file "/var/log/apache2/mod_security" for the request entry that caused the problem. It will have a rule id and the location of the rule file. Than you need to modify the rule to allow your usecase somehow or disable it if your comfortable with this option. And this exercise repeats till your have reached a relative equilibrium.

For Drupal the sql injection rules were really a huge pain. The "args" section of the request would have keywords from modules like "insert", "delete" or "update" and mod_security would kick in and block the request resulting in quite a few Internal Server errors. I winded up removing the ARGS parameter from this file for drupal on my server. My take on it was that php and drupal should be mature enough to handle sql injections at application layer, so I don't really need these checks at the front-line.

So happy configuring of your server rules. Though in my experience its anything but *HAPPY* the experience.

Top level category:

Comments

Nice article Ahsan the only info I found on this topic about Drupal. The base rule file is modsecurity_crs_41_sql_injection_attacks.conf. Can you explain how you managed to remove the ARGS parameter? Thanks.

Hi Konstantinos, I am not exactly happy with the way I resolved it. Its quick and dirty. But thats the amount of time I get for this. From the mod_Security log file find out your rule_id thats bothering you or blocking you. Than in that rule file, in your case "modsecurity_crs_41_sql_injection_attacks.conf", go to that rule. Lets say for example a rule reads like below: SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|!REQUEST_COOKIES:/_pk_ref/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML Remove the pipe and ARGS text from there i.e. so delete "|ARGS". In some cases you also need to delete "ARGS_NAME". mod_security is blocking these requests as it sees an incredible amount of inserts, selects, delete keywords in the requests, as the log may have already told you. I don't think we can ask drupal and its module owners to avoid using these keywords so the only option remains to tweak mod_Sec rules. This was my workaround, but I don't run a production server. In your case it might be worthwhile investigating the things mentioned in this section "Fixing False Positives - Traditional Mode" under this link https://www.trustwave.com/Resources/SpiderLabs-Blog/ModSecurity-Advanced-Topic-of-the-Week--(Updated)-Exception-Handling/ For one thing, only article submissions for me was causing problems, so I should have went the way of whitelisting IPs and or for particular rule ids manually excluding the ARG parameter by id instead of deleting the original rule. I will be cleaning up this mess on my server soon. But it is a tedious process. For regular access, I would prefer to keep everything active. Hope that helps.

Add new comment