ModSecurity-CRS config

LAMP stack refers to Linux, Apache, MySQL and PHP . With this bundle you can create web applications / services with Linux serving as the OS, Apache as the Web-Server, MySQL as the database server and PHP as the server-side programming language.

So what is ModSecurity?

ModSecurity is an open-source Web Application Firewall (WAF). It sits before your Web Server and so is able to monitor the incoming as well as the outgoing traffic. With this, we can, to some extent, prevent attacks, information leakage, etc..

Installation

Installing LAMP Stack:

Installing the LAMP Stack on Ubuntu is a breeze! You have this meta-package called lamp-serverthat lets you install all the required packages and configures them so that you're ready to start playing at the end of it.

So open up a terminal and type,

$ sudo apt-get update && sudo apt-get install -y lamp-server^

Supply your password upon prompt and it'll proceed with the installation. In between, you'll be prompted to set the MySQL root user's password. After that, when you get your terminal prompt back, you should have a fully working LAMP stack, ready to go!

Don't believe me? Check it out yourself by browsing to http://localhost/. You should be able to see the default Apache page.

Default locations:

• Apache Webroot: /var/www/html/
• Apache Config: 1/etc/apache2/
• Apache Log folder: /var/log/apache2/
• PHP config: /etc/php5/
• php.ini location for PHP Apps served by Apache: /etc/php5/apache2/php.ini

Installing ModSecurity

We are going to be installing ModSecurity as a module to Apache, so, please key in the following command in a terminal.

$ sudo apt-get install libapache2-modsecurity

Once that has finished installing, you can verify that ModSecurity has been installed and is running by running the following command:

$ apache2ctl -M | grep -i security

security2_module (shared)

Installing ModSecurity Core Rule Set

You might have noticed during installation that a package called modsecurity-crs got installed when you installed ModSecurity. That is the ModSecurity Core Rule Set, which is an OWASPproject of ModSecurity rules that you can use to defend yourself against common web application attacks.

Installing the Github version

Some people like installing the Github version, since it provides more flexibility in terms of fetching any updates, switching between branches, etc.. To install the ModSecurity CRS from its Github repo, we need to replace the /usr/share/modsecurity-crs directory and then clone the repo at that location.

  $ sudo rm -rf /usr/share/modsecurity-crs
  $ sudo apt-get install -y git
  $ sudo git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git /usr/share/modsecurity-crs

Finally, just copy/rename the example setup file to have a .confextension.

  $ sudo cp /usr/share/modsecurity-crs/modsecurity_crs_10_setup.conf.example /usr/share/modsecurity-crs/modsecurity_crs_10_setup.conf

Now we can continue with the following steps.

To set up the ModSecurity CRS, lets first switch to the /usr/share/modsecurity-crs directory.

$ cd /usr/share/modsecurity-crs

To activate the rules that you need, you need to place it in the activated_rules directory. First let's include the setup file by creating a soft link to it from the activated_rules directory.

$ sudo ln -s ../modsecurity_crs_10_setup.conf activated_rules/modsecurity_crs_10_setup.conf

Next, we'll include all the base_rules,

$ for f in `ls base_rules`; do sudo ln -s ../base_rules/$f activated_rules/$f; done

Now you're activated_rules directory should look something like this:

$ ll activated_rules/
total 20
drwxr-xr-x 2 root root 4096 Jun 26 14:15 ./
drwxr-xr-x 9 root root 4096 Jun 26 13:56 ../
lrwxrwxrwx 1 root root   44 Jun 26 14:07 modsecurity_35_bad_robots.data -> ../base_rules/modsecurity_35_bad_robots.data
lrwxrwxrwx 1 root root   42 Jun 26 14:07 modsecurity_35_scanners.data -> ../base_rules/modsecurity_35_scanners.data
lrwxrwxrwx 1 root root   49 Jun 26 14:07 modsecurity_40_generic_attacks.data -> ../base_rules/modsecurity_40_generic_attacks.data
lrwxrwxrwx 1 root root   42 Jun 26 14:07 modsecurity_50_outbound.data -> ../base_rules/modsecurity_50_outbound.data
lrwxrwxrwx 1 root root   50 Jun 26 14:07 modsecurity_50_outbound_malware.data -> ../base_rules/modsecurity_50_outbound_malware.data
lrwxrwxrwx 1 root root   32 Jun 26 14:15 modsecurity_crs_10_setup.conf -> ../modsecurity_crs_10_setup.conf
lrwxrwxrwx 1 root root   57 Jun 26 14:07 modsecurity_crs_20_protocol_violations.conf -> ../base_rules/modsecurity_crs_20_protocol_violations.conf
lrwxrwxrwx 1 root root   56 Jun 26 14:07 modsecurity_crs_21_protocol_anomalies.conf -> ../base_rules/modsecurity_crs_21_protocol_anomalies.conf
lrwxrwxrwx 1 root root   52 Jun 26 14:07 modsecurity_crs_23_request_limits.conf -> ../base_rules/modsecurity_crs_23_request_limits.conf
lrwxrwxrwx 1 root root   49 Jun 26 14:07 modsecurity_crs_30_http_policy.conf -> ../base_rules/modsecurity_crs_30_http_policy.conf
lrwxrwxrwx 1 root root   48 Jun 26 14:07 modsecurity_crs_35_bad_robots.conf -> ../base_rules/modsecurity_crs_35_bad_robots.conf
lrwxrwxrwx 1 root root   53 Jun 26 14:07 modsecurity_crs_40_generic_attacks.conf -> ../base_rules/modsecurity_crs_40_generic_attacks.conf
lrwxrwxrwx 1 root root   59 Jun 26 14:07 modsecurity_crs_41_sql_injection_attacks.conf -> ../base_rules/modsecurity_crs_41_sql_injection_attacks.conf
lrwxrwxrwx 1 root root   49 Jun 26 14:07 modsecurity_crs_41_xss_attacks.conf -> ../base_rules/modsecurity_crs_41_xss_attacks.conf
lrwxrwxrwx 1 root root   52 Jun 26 14:07 modsecurity_crs_42_tight_security.conf -> ../base_rules/modsecurity_crs_42_tight_security.conf
lrwxrwxrwx 1 root root   45 Jun 26 14:07 modsecurity_crs_45_trojans.conf -> ../base_rules/modsecurity_crs_45_trojans.conf
lrwxrwxrwx 1 root root   55 Jun 26 14:07 modsecurity_crs_47_common_exceptions.conf -> ../base_rules/modsecurity_crs_47_common_exceptions.conf
lrwxrwxrwx 1 root root   62 Jun 26 14:07 modsecurity_crs_48_local_exceptions.conf.example -> ../base_rules/modsecurity_crs_48_local_exceptions.conf.example
lrwxrwxrwx 1 root root   54 Jun 26 14:07 modsecurity_crs_49_inbound_blocking.conf -> ../base_rules/modsecurity_crs_49_inbound_blocking.conf
lrwxrwxrwx 1 root root   46 Jun 26 14:07 modsecurity_crs_50_outbound.conf -> ../base_rules/modsecurity_crs_50_outbound.conf
lrwxrwxrwx 1 root root   55 Jun 26 14:07 modsecurity_crs_59_outbound_blocking.conf -> ../base_rules/modsecurity_crs_59_outbound_blocking.conf
lrwxrwxrwx 1 root root   49 Jun 26 14:07 modsecurity_crs_60_correlation.conf -> ../base_rules/modsecurity_crs_60_correlation.conf
-rw-r--r-- 1 root root 5720 Jul 12  2013 README

You can include other rules found in other directories in the same way as well. Just remember to place all the rules you want activated in the activated_rules directory.

Now, let's head to the /etc/modsecurity/ directory to continue with the configuration.

$ cd /etc/modsecurity

Copy the recommended configuration file and name it modsecurity.conf

$ cp modsecurity.conf-recommended modsecurity.conf

Open the modsecurity.conf file and change the line that reads SecRuleEngine DetectionOnlyto SecRuleEngine On . This changes ModSecurity from a passive monitoring mode to an active blocking mode. The rest of the default configurations that ship with the modsecurity-crspackage on Ubuntu are more than sufficient. However, if you're interested in tweaking them, please refer to the ModSecurity Reference Manual. Here's the diff of the recommended file and the actual configuration file,

$ diff modsecurity.conf-recommended modsecurity.conf
7c7
< SecRuleEngine DetectionOnly
---
> SecRuleEngine On

One final configuration file to tweak - the /etc/apache2/mods-available/security2.conf . Add the line IncludeOptional /usr/share/modsecurity-crs/activated_rules/*.conf to it and so you're configuration file would read,

<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 /usr/share/modsecurity-crs/activated_rules/*.conf
</IfModule>

Finally, we reload Apache for all the changes to take effect.

$ sudo service apache2 reload

Testing if it all works!

We can test if it all works, by sending some typical malicious requests to our Web Server and see if the requests are being blocked.

## XSS
$ curl 'http://localhost/?q="><script>alert(1)</script>'
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /
on this server.</p>
<hr>
<address>Apache/2.4.7 (Ubuntu) Server at localhost Port 80</address>
</body></html>

## SQLi
$ curl "http://localhost/?q='1 OR 1=1"
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /
on this server.</p>
<hr>
<address>Apache/2.4.7 (Ubuntu) Server at localhost Port 80</address>
</body></html>

And yay! It works! If you're curious to know more, you can look in the ModSecurity Audit Log file at /var/log/apache2/modsec_audit.log

And that's it! We now have a working LAMP Stack with ModSecurity and the ModSecurity CRS installed. If you want to customize your ModSecurity installation further and fine-tune it or write your own rules or disable some of them, please refer to the ModSecurity Reference Manual.

Note: In the above post, we just discussed how to install the LAMP Stack, ModSecurity WAF with the ModSecurity CRS on Ubuntu 16.04. Please do NOT assume your server is magically secured because of this. Please do not use this in production.