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
# 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.
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;