Using ModSecurity Web Application Firewall: To Prevent SQL Injection and XSS using Blocking Rules

In the other post we show how to install and configure ModSecurity in Detection Only mode , where we configure the tool to write several logs of possible attacks generated by SQL Injection , XSS errors among others. In this tutorial, I’ll be demonstrating how to configure the ModSecurity security engine to adopt only rules relevant to offensive security, blocking common attacks at application level. I know it may seem redundant, but I will address the ModSecurity installation one more time, to leave both this tutorial and Detection Only complete.

Installing ModSecurity in Debian:

If you are not ready yet:

 # sudo apt-get install apache2 php5 php5-mysql mysql-server

Now let’s install the packages for using ModSecurity:

 # sudo apt-get install apache2-threaded-dev libxml2-dev libcurl4-gnutls-dev liblua5.1-0 liblua5.1-0-dev build-essential php5-cli libghc-pcre-light-dev

Let’s Download Source:

 # apt-get install zip libapache2-mod-security2 libxml2 libxml2-dev libxml2-utils libaprutil1 libaprutil1-dev


Parameterizing the recommended ModSecurity settings:

 # mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Now restart Apache:

 # service apache2 restart # ou # systemctl restart apache2

Configuring ModSecurity in the Scope of Security Engine

Edit the ModSecurity configuration file and change the SecRuleEngine to DetectionOnly

 # vim /etc/modsecurity/modsecurity.conf
 SecRuleEngine On SecRequestBodyAccess On

Making the ModSecurity Rules Downloads:

Download and extract the configuration files from the ModSecurity rules:

 # wget https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/master.zip # unzip master.zip # cp -R owasp-modsecurity-crs-master/* /etc/modsecurity/

Copy the rules files to the directories and create the symbolic links to the ModSecurity active rules folder.

 # mv /etc/modsecurity/modsecurity_crs_10_setup.conf.example /etc/modsecurity/modsecurity_crs_10_setup.conf # cd /etc/modsecurity

Edit the security2.conf file and add the highlighted line pointing to the folder where the rules we just installed are:

 # vim /etc/apache2/mods-available/security2.conf
 <IfModule security2_module> # Default Debian dir for modsecurity's persistent data SecDataDir /var/cache/modsecurity # Include all the *.conf files in /etc/modsecurity. # Keeping your local configuration in that directory # will allow for an easy upgrade of THIS file and # make your life easier IncludeOptional /etc/modsecurity/*.conf IncludeOptional /etc/modsecurity/base_rules/*.conf </IfModule>

Now enable the headers of the new apache settings and restart apache:

 # a2enmod headers # service apache2 restart

Configuring the ModSecurity Rules

Now let’s delete the Base Rules and recreate the contents of the folder with only the modules that we want to activate:

 # rm -r /etc/modsecurity/base_rules/*

In this example we will be installing SQL Injection , XSS rules, a database for scanners and a basic hardening file from the rules file that we extracted earlier.

 # cp owasp-modsecurity-crs-master/base_rules/modsecurity_crs_41_sql_injection_attacks.conf /etc/modsecurity/base_rules/ # cp owasp-modsecurity-crs-master/base_rules/modsecurity_crs_41_xss_attacks.conf /etc/modsecurity/base_rules/ # cp owasp-modsecurity-crs-master/base_rules/modsecurity_crs_42_tight_security.conf /etc/modsecurity/base_rules/ # cp owasp-modsecurity-crs-master/base_rules/modsecurity_35_scanners.data /etc/modsecurity/base_rules/

Taking the tests:

I uploaded an application vulnerable to the SQL Injection attack on the server we are configuring. Before I go up the rules we can see that the application is vulnerable to attack. I ran a basic injection and saw that the server responded to Query. After raising the rules, the server presented a new response, giving a Forbidden Error when I tried to inject. Let’s try exploring via SQLmap to see how the server reacts to Automated Attacks.

SQLmap response:

First let’s test the SQL Injection response analyzer without Hardening done in ModSecurity. We can see that the application has usually reacted to the successive queries we inject through SQL Map.

After the Hardening done on the server, using the same Script, we can notice that all the SQLinjection entries were denied by ModSecurity, accusing the vulnerable parameter ‘id’ as not injectable in the eyes of the script;

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s