Configuring the ModSecurity Firewall with OWASP Rules

In today's world, over 70% of all attacks carried out over are done so at the web application level, so we need to implement security at multiple levels, as organizations need all the help they can get in making their systems secure. Web application firewalls are deployed to establish an external security layer that increases security and detects and prevents attacks before they reach the web application. One of the more commonly used application layer firewalls is ModSecurity, which is an open source intrusion detection and prevention system. In order to make ModSecurity more useful, it must be configured with rules. These rules can be created by us according to need, or we can use the Open Web Application Security Project (OWASP) rules.

OWASP is a group of security communities that develops and maintains a free set of application protection rules, which is called the OWASP ModSecurity Core Rules Set (CRS). You can think of OWASP as an enhanced core rule set that the ModSecurity will follow to prevent attacks on the server.

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

So, in this article we will configure the ModSecurity Firewall with the OWASP Core Rule Set. We will also learn how we can customize the OWASP Core Rule Set according to need or create our own customized rule set in later articles. We are assuming that you have basic knowledge about the Linux commands and the Apache server.

The process of getting started in ModSecurity with OWASP rules might seem like a lot of work, but it's actually quite simple. Let's look at the installation and configuration process in a CentOS environment. This can be done through the following steps:

Step 1

Login into your server as a root user. We can use Putty or any other SSH client for the log in. After login, we have to install some dependency packages before the installation of mod security. This package can be installed through the following command:

yum install gcc make libxml2 libxml2-devel httpd-devel pcre-devel curl-devel –y

Step 2

After installing the dependency packages, we will install ModSecurity, which is the main package required for the firewall. We can install it by running the following command in the terminal:

yum install mod_security –y

Now the ModSecurity package has been successfully installed in the system.

Step 3

After installing ModSecurity, we need to restart the Apache server to apply affected changes. For that we will have to restart the HTTPD service, which is the default service for RHEL/CentOS/Fedora, and it is located in the /etc/httpd folder. We can do this by the following command.

Services httpd restart

OR

/etc/init.d/httpd restart

The message [ OK ] is displayed, which means that HTTPD is restarted without having any errors.

Now we have successfully installed ModSecurity in the server, and the next step is to download and configure the OWASP ModSecurity rules. In order to do that, we have to change the current working directory to /etc/httpd. This can be done through the cd command.

cd /etc/httpd.

Step 4

As we mentioned at the top of the article, our ModSecurity installation is good enough, but we will need to enhance our rule set with the help of the OWASP Core Rule Set. This can be done through the Github website. Github is an open source platform where many developers share their projects and applications. To download any content from the Github server, the git command is used with the clone option. So, we will import predefined OWASP ModSecurity rules by SpiderLabs to our server. We can do this through the following command.

git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git

After executing the command, OWASP ModSecurity rules will be downloaded in the owasp-mod security-src directory. It can be checked by the ls command as follows.

Now, we have to rename owasp-mod security-crs folder to mod security-crs. This can be done by the mv command.

mv owasp-modsecurity-crs modsecurity-crs

We can verify that by running the ls command.

Step 5

We have to change the working directory to mod security-crs. This can be done by the cd command.

cd modsecurity-crs

Modsecurity_crs_10_setup.conf is the main configuration file for ModSecurity to work. By default it comes with .example extension. To initialize ModSecurity, we have to rename this file. We can rename it by the mv command.

mv modsecurity_crs_10_setup.conf.example modsecurity_crs_10_setup.conf

Affected changes can be seen by the ls command.

Step 6

After that, we have to add the module in the Apache configuration file. The Apache server loads modules on every start-up with it. So, to add ModSecurity to work with the server, we have to add this module in the httpd.conf file, which is defaultly located in the /etc/httpd/conf directory. We will use VI Editor to edit ascii text files on the server.

We need to type the following command in the terminal.

vi /etc/httpd/conf/httpd.conf

Copy/paste the following to the end of the file and save the file.

<IfModule security2_module>

Include modsecurity-crs/modsecurity_crs_10_config.conf

After saving the file we will have to restart the Apache server.

Step 7

Now ModSecurity has been successfully configured with OWASP rules, but to make it work according to our choices, we will have to make a new configuration file with our own rules, which is called the whitelist file. Through this file we can control the whole Mod- Security firewall as well as create own rules for ModSecurity. We will create this in modsecurity.d directory. Open/Create this file through the following command.

Vi /etc/httpd/modsecuirty.d/whitelist.conf

And copy the following rules in the file and save the file.

#Whitelist file to control ModSec

<IfModule mod_security2.c>

SecRuleEngine On

Now, we save the file and restart the Apache server. Each line meaning is described below.

1. SecRuleEngine is the security rule engine which accepts all the rules from modsecurity-crs directory. So we can set different rules according to requirements. To set the different rules are the following.

   SecRuleEngine On: Will activate the ModSecurity firewall for the server. It will detect and block any malicious attack on the server.

   SecRuleEngine Detection Only: If this rule is set in the whitelist.conf file, it will only detect all the attacks and generate errors according to the attacks, but it will not block anything on the server.

   SecRuleEngine Off: It will deactivate the ModSecurity firewall on the server.

2. SecRequestBodyAccess: It will tell ModSecurity whether it will check the body of the request or not. It plays a very important role when a web application is configured in way where all data go in POST request. It has only two parameters, ON or OFF. We can set that according to the requirement.
3. SecResponseBodyAccess: If this parameter is set to be On in the whiltelist.conf file, then ModSecurity will analyse the server response and do the appropriate action accordingly. It also has only two parameters, ON or Off. We can set it according to the requirement.
4. SetDataDirectory: In this section we will have to define the ModSecurity working directory. This directory will be used by the ModSecurity for temporary purposes.

ModSecurity is now successfully configured with the OWASP rules. Now we will test the ModSecurity firewall against some of the most common web application attacks and will verify weather ModSecurity is blocking the attacks or not.

In order to do that, we will try to launch the reflected Cross Site Scripting (XSS) attack on the website in which we have configured ModSecurity. The most common XSS vulnerable field in a website would be the search box, in which a user could search anything on the website. If a malicious user tries to inject Java Script or HTML script in the search box, it will execute in the browser. We can type <script>alert(123)</script> in the search box. In a normal scenario (when we do not have any kind of application firewall on the server) it will show a popup message on the website if the website is vulnerable for XSS.

If ModSecurity has been configured on the server, it will block the XSS attack and redirect the user in a different place according to the server configuration as well as generate the error logs.

We can check the ModSecurity error logs in the following file.

/var/logs/httpd/error_logs

We can check the last updated lines in the file through the following command.

tail –f /var/logs/httpd/error_logs

The OWASP ModSecurity Core Rule Set (CRS) provide protections against the following category of attacks.

• HTTP Protection - detectsviolations of the HTTP protocol and a locally defined usage policy.
• Real-time Blacklist Lookups - utilizes 3rd Party IP Reputation.
• HTTP Denial of Service Protections - defence against HTTP Flooding and Slow HTTP DoS Attacks.
• Common Web Attacks Protection - detects common web application security attacks.
• Automation Detection - detects bots, crawlers, scanners and other surface malicious activity.
• Integration with AV Scanning for File Uploads - detects malicious files uploaded through the web application.
• Tracking Sensitive Data - tracks credit card usage and blocks leakages.
• Trojan Protection - detects access to Trojans.
• Identification of Application Defects - alerts on application misconfigurations.
• Error Detection and Hiding - disguises error messages sent by the server.

References

• https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
• http://spiderlabs.github.io/owasp-modsecurity-crs/
• http://www.modsecurity.org/demo/crs-demo.html
• http://www.atomicorp.com/wiki/index.php/Mod_security
• https://github.com/SpiderLabs/owasp-modsecurity-crs
• https://www.owasp.org/index.php?title=Projects/OWASP_ModSecurity_Core_Rule_Set_Project/Releases/ModSecurity_2.0.6/Assessment&setlang=es