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..
Installing the LAMP Stack on Ubuntu is a breeze! You have this meta-package called
lamp-server that 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.
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)
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 OWASP project 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-crsdirectory 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
$ 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
$ 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
$ for f in `ls base_rules`; do sudo ln -s ../base_rules/$f activated_rules/$f; done
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
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
modsecurity.conf file and change the line that reads
SecRuleEngine DetectionOnly to
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-crs package 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
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
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.