Mod Security is ON in the server and why is it important
Mod_Security is an important web application firewall that gets installed as an Apache module. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring, logging and real-time analysis.
It is used to block commonly known exploits for CMS’s by use of regular expressions and rule sets.
Mod_Security can potentially block common code injection attacks which strengthens the security of the server.
When coding a dynamic website, sometimes users forget to write code to help prevent hacks by doing things such as validating input.
Unfortunately, sometimes Mod_Security rules block valid transactions as well, below you can find some steps to white-list, configure or delete some rules.
What Can ModSecurity Do?
ModSecurity is a toolkit for real-time web application monitoring, logging, and access control. I like to think about it as an enabler: there are no hard rules telling you what to do; instead, it is up to you to choose your own path through the available features. That’s why the title of this section asks what ModSecurity can do, not what it does.
The freedom to choose what to do is an essential part of ModSecurity’s identity and goes very well with its open source nature. With full access to the source code, your freedom to choose extends to the ability to customize and extend the tool itself to make it fit your needs. It’s not a matter of ideology, but of practicality. I simply don’t want my tools to restrict what I can do.
Back on the topic of what ModSecurity can do, the following is a list of the most important usage scenarios:
- Real-time application security monitoring and access control
At its core, ModSecurity gives you access to the HTTP traffic stream, in real-time, along with the ability to inspect it. This is enough for real-time security monitoring. There’s an added dimension of what’s possible through ModSecurity’s persistent storage mechanism, which enables you to track system elements over time and perform event correlation. You are able to reliably block, if you so wish, because ModSecurity uses full request and response buffering.
- Virtual patching
Virtual patching is a concept of vulnerability mitigation in a separate layer, where you get to fix problems in applications without having to touch the applications themselves. Virtual patching is applicable to applications that use any communication protocol, but it is particularly useful with HTTP, because the traffic can generally be well understood by an intermediary device. ModSecurity excels at virtual patching because of its reliable blocking capabilities and the flexible rule language that can be adapted to any need. It is, by far, the activity that requires the least investment, is the easiest activity to perform, and the one that most organizations can benefit from straight away.
- Full HTTP traffic logging
Web servers traditionally do very little when it comes to logging for security purposes. They log very little by default, and even with a lot of tweaking you are not able to get everything that you need. I have yet to encounter a web server that is able to log full transaction data. ModSecurity gives you that ability to log anything you need, including raw transaction data, which is essential for forensics. In addition, you get to choose which transactions are logged, which parts of a transaction are logged, and which parts are sanitized.
- Continuous passive security assessment
Security assessment is largely seen as an active scheduled event, in which an independent team is sourced to try to perform a simulated attack. Continuous passive security assessment is a variation of real-time monitoring, where, instead of focusing on the behavior of the external parties, you focus on the behavior of the system itself. It’s an early warning system of sorts that can detect traces of many abnormalities and security weaknesses before they are exploited.
- Web application hardening
One of my favorite uses for ModSecurity is attack surface reduction, in which you selectively narrow down the HTTP features you are willing to accept (e.g., request methods, request headers, content types, etc.). ModSecurity can assist you in enforcing many similar restrictions, either directly, or through collaboration with other Apache modules. They all fall under web application hardening. For example, it is possible to fix many session management issues, as well as cross-site request forgery vulnerabilities.
- Something small, yet very important to you
Real life often throws unusual demands to us, and that is when the flexibility of ModSecurity comes in handy where you need it the most. It may be a security need, but it may also be something completely different. For example, some people use ModSecurity as an XML web service router, combining its ability to parse XML and apply XPath expressions with its ability to proxy requests. Who knew?
Guiding Principles
There are four guiding principles on which ModSecurity is based, as follows:
- Flexibility
I think that it’s fair to say that I built ModSecurity for myself: a security expert who needs to intercept, analyze, and store HTTP traffic. I didn’t see much value in hardcoded functionality, because real life is so complex that everyone needs to do things just slightly differently. ModSecurity achieves flexibility by giving you a powerful rule language, which allows you to do exactly what you need to, in combination with the ability to apply rules only where you need to.
- Passiveness
ModSecurity will take great care to never interact with a transaction unless you tell it to. That is simply because I don’t trust tools, even the one I built, to make decisions for me. That’s why ModSecurity will give you plenty of information, but ultimately leave the decisions to you.
- Predictability
There’s no such thing as a perfect tool, but a predictable one is the next best thing. Armed with all the facts, you can understand ModSecurity’s weak points and work around them.
- Quality over quantity
Over the course of six years spent working on ModSecurity, we came up with many ideas for what ModSecurity could do. We didn’t act on most of them. We kept them for later. Why? Because we understood that we have limited resources available at our disposal and that our minds (ideas) are far faster than our implementation abilities. We chose to limit the available functionality, but do really well at what we decided to keep in.
There are bits in ModSecurity that fall outside the scope of these four principles. For example, ModSecurity can change the way Apache identifies itself to the outside world, confine the Apache process within a jail, and even implement an elaborate scheme to deal with a onceinfamous universal XSS vulnerability in Adobe Reader. Although it was I who added those features, I now think that they detract from the main purpose of ModSecurity, which is a reliable and predictable tool that allows for HTTP traffic inspection.
Deployment Options
ModSecurity supports two deployment options: embedded and reverse proxy deployment. There is no one correct way to use them; choose an option based on what best suits your circumstances. There are advantages and disadvantages to both options:
- Embedded
Because ModSecurity is an Apache module, you can add it to any compatible version of Apache. At the moment that means a reasonably recent Apache version from the 2.0.x branch, although a newer 2.2.x version is recommended. The embedded option is a great choice for those who already have their architecture laid out and don’t want to change it. Embedded deployment is also the only option if you need to protect hundreds of web servers. In such situations, it is impractical to build a separate proxybased security layer. Embedded ModSecurity not only does not introduce new points of failure, but it scales seamlessly as the underlying web infrastructure scales. The main challenge with embedded deployment is that server resources are shared between the web server and ModSecurity.
- Reverse proxy
Reverse proxies are effectively HTTP routers, designed to stand between web servers and their clients. When you install a dedicated Apache reverse proxy and add ModSecurity to it, you get a “proper†network web application firewall, which you can use to protect any number of web servers on the same network. Many security practitioners prefer having a separate security layer. With it you get complete isolation from the systems you are protecting. On the performance front, a standalone ModSecurity will have resources dedicated to it, which means that you will be able to do more (i.e., have more complex rules). The main disadvantage of this approach is the new point of failure, which will need to be addressed with a high-availability setup of two or more reverse proxies.
Is Anything Missing?
ModSecurity is a very good tool, but there are a number of features, big and small, that could be added. The small features are those that would make your life with ModSecurity easier, perhaps automating some of the boring work (e.g., persistent blocking, which you now have to do manually). But there are really only two features that I would call missing:
- Learning
Defending web applications is difficult, because there are so many of them, and they are all different. (I often say that every web application effectively creates its own communication protocol.) It would be very handy to have ModSecurity observe application traffic and create a model that could later be used to generate policy or assist with false positives. While I was at Breach Security, I started a project called ModProfiler [http://www.modsecurity.org/projects/modprofiler/] as a step toward learning, but that project is still as I left it, as version 0.2.
- Passive mode of deployment
ModSecurity can be embedded only in Apache 2.x, but when you deploy it as a reverse proxy, it can be used to protect any web server. Reverse proxies are not everyone’s cup of tea, however, and sometimes it would be very handy to deploy ModSecurity passively, without having to change anything on the network.
How To Set Up mod_security with Apache on Debian/Ubuntu
Prelude
Mod security is a free Web Application Firewall (WAF) that works with Apache, Nginx and IIS. It supports a flexible rule engine to perform simple and complex operations and comes with a Core Rule Set (CRS) which has rules for SQL injection, cross site scripting, Trojans, bad user agents, session hijacking and a lot of other exploits. For Apache, it is an additional module which makes it easy to install and configure.
In order to complete this tutorial, you will need LAMP installed on your server.
Installing mod_security
Modsecurity is available in the Debian/Ubuntu repository:
apt-get install libapache2-modsecurity
Verify if the mod_security module was loaded.
apachectl -M | grep --color security
You should see a module named security2_module (shared) which indicates that the module was loaded.
Modsecurity’s installation includes a recommended configuration file which has to be renamed:
mv /etc/modsecurity/modsecurity.conf{-recommended,}
Reload Apache
service apache2 reload
You’ll find a new log file for mod_security in the Apache log directory:
root@droplet:~# ls -l /var/log/apache2/modsec_audit.log
-rw-r----- 1 root root 0 Oct 19 08:08 /var/log/apache2/modsec_audit.log
Configuring mod_security
Out of the box, modsecurity doesn’t do anything as it needs rules to work. The default configuration file is set to DetectionOnly which logs requests according to rule matches and doesn’t block anything. This can be changed by editing the modsecurity.conf file:
nano /etc/modsecurity/modsecurity.conf
Find this line
SecRuleEngine DetectionOnly
and change it to:
SecRuleEngine On
If you’re trying this out on a production server, change this directive only after testing all your rules.
Another directive to modify is SecResponseBodyAccess. This configures whether response bodies are buffered (i.e. read by modsecurity). This is only neccessary if data leakage detection and protection is required. Therefore, leaving it On will use up droplet resources and also increase the logfile size.
Find this
SecResponseBodyAccess On
and change it to:
SecResponseBodyAccess Off
Now we’ll limit the maximum data that can be posted to your web application. Two directives configure these:
SecRequestBodyLimit
SecRequestBodyNoFilesLimit
The SecRequestBodyLimit directive specifies the maximum POST data size. If anything larger is sent by a client the server will respond with a 413 Request Entity Too Large error. If your web application doesn’t have any file uploads this value can be greatly reduced.
The value mentioned in the configuration file is
SecRequestBodyLimit 13107200
which is 12.5MB.
Similar to this is the SecRequestBodyNoFilesLimit directive. The only difference is that this directive limits the size of POST data minus file uploads– this value should be “as low as practical.”
The value in the configuration file is
SecRequestBodyNoFilesLimit 131072
which is 128KB.
Along the lines of these directives is another one which affects server performance:SecRequestBodyInMemoryLimit. This directive is pretty much self-explanatory; it specifies how much of “request body” data (POSTed data) should be kept in the memory (RAM), anything more will be placed in the hard disk (just like swapping). Since droplets use SSDs, this is not much of an issue; however, this can be set a decent value if you have RAM to spare.
SecRequestBodyInMemoryLimit 131072
This is the value (128KB) specified in the configuration file.
Testing SQL Injection
Before going ahead with configuring rules, we will create a PHP script which is vulnerable to SQL injection and try it out. Please note that this is just a basic PHP login script with no session handling. Be sure to change the MySQL password in the script below so that it will connect to the database:
/var/www/login.php
<html>
<body>
<?php
if(isset($_POST['login']))
{
$username = $_POST['username'];
$password = $_POST['password'];
$con = mysqli_connect('localhost','root','password','sample');
$result = mysqli_query($con, "SELECT * FROM `users` WHERE username='$username' AND password='$password'");
if(mysqli_num_rows($result) == 0)
echo 'Invalid username or password';
else
echo '<h1>Logged in</h1><p>A Secret for you....</p>';
}
else
{
?>
<form action="" method="post">
Username: <input type="text" name="username"/><br />
Password: <input type="password" name="password"/><br />
<input type="submit" name="login" value="Login"/>
</form>
<?php
}
?>
</body>
</html>
This script will display a login form. Entering the right credentials will display a message “A Secret for you.”
We need credentials in the database. Create a MySQL database and a table, then insert usernames and passwords.
mysql -u root -p
This will take you to the mysql> prompt
create database sample;
connect sample;
create table users(username VARCHAR(100),password VARCHAR(100));
insert into users values('jesin','pwd');
insert into users values('alice','secret');
quit;
Open your browser, navigate to http://yourwebsite.com/login.php and enter the right pair of credentials.
Username: jesin
Password: pwd
You’ll see a message that indicates successful login. Now come back and enter a wrong pair of credentials– you’ll see the message Invalid username or password.
We can confirm that the script works right. The next job is to try our hand with SQL injection to bypass the login page. Enter the following for the username field:
' or true --
Note that there should be a space after -- this injection won’t work without that space. Leave thepassword field empty and hit the login button.
Voila! The script shows the message meant for authenticated users.
Setting Up Rules
To make your life easier, there are a lot of rules which are already installed along with mod_security. These are called CRS (Core Rule Set) and are located in
root@droplet:~# ls -l /usr/share/modsecurity-crs/
total 40
drwxr-xr-x 2 root root 4096 Oct 20 09:45 activated_rules
drwxr-xr-x 2 root root 4096 Oct 20 09:45 base_rules
drwxr-xr-x 2 root root 4096 Oct 20 09:45 experimental_rules
drwxr-xr-x 2 root root 4096 Oct 20 09:45 lua
-rw-r--r-- 1 root root 13544 Jul 2 2012 modsecurity_crs_10_setup.conf
drwxr-xr-x 2 root root 4096 Oct 20 09:45 optional_rules
drwxr-xr-x 3 root root 4096 Oct 20 09:45 util
The documentation is available at
root@droplet1:~# ls -l /usr/share/doc/modsecurity-crs/
total 40
-rw-r--r-- 1 root root 469 Jul 2 2012 changelog.Debian.gz
-rw-r--r-- 1 root root 12387 Jun 18 2012 changelog.gz
-rw-r--r-- 1 root root 1297 Jul 2 2012 copyright
drwxr-xr-x 3 root root 4096 Oct 20 09:45 examples
-rw-r--r-- 1 root root 1138 Mar 16 2012 README.Debian
-rw-r--r-- 1 root root 6495 Mar 16 2012 README.gz
To load these rules, we need to tell Apache to look into these directories. Edit the mod-security.conffile.
nano /etc/apache2/mods-enabled/mod-security.conf
Add the following directives inside <IfModule security2_module> </IfModule>:
Include "/usr/share/modsecurity-crs/*.conf"
Include "/usr/share/modsecurity-crs/activated_rules/*.conf"
The activated_rules directory is similar to Apache’s mods-enabled directory. The rules are available in directories:
/usr/share/modsecurity-crs/base_rules
/usr/share/modsecurity-crs/optional_rules
/usr/share/modsecurity-crs/experimental_rules
Symlinks must be created inside the activated_rules directory to activate these. Let us activate the SQL injection rules.
cd /usr/share/modsecurity-crs/activated_rules/
ln -s /usr/share/modsecurity-crs/base_rules/modsecurity_crs_41_sql_injection_attacks.conf .
Apache has to be reloaded for the rules to take effect.
service apache2 reload
Now open the login page we created earlier and try using the SQL injection query on the username field. If you had changed the SecRuleEngine directive to On, you’ll see a 403 Forbidden error. If it was left to theDetectionOnly option, the injection will be successful but the attempt would be logged in themodsec_audit.log file.
Writing Your Own mod_security Rules
In this section, we’ll create a rule chain which blocks the request if certain “spammy” words are entered in a HTML form. First, we’ll create a PHP script which gets the input from a textbox and displays it back to the user.
/var/www/form.php
<html>
<body>
<?php
if(isset($_POST['data']))
echo $_POST['data'];
else
{
?>
<form method="post" action="">
Enter something here:<textarea name="data"></textarea>
<input type="submit"/>
</form>
<?php
}
?>
</body>
</html>
Custom rules can be added to any of the configuration files or placed in modsecurity directories. We’ll place our rules in a separate new file.
nano /etc/modsecurity/modsecurity_custom_rules.conf
Add the following to this file:
SecRule REQUEST_FILENAME "form.php" "id:'400001',chain,deny,log,msg:'Spam detected'"
SecRule REQUEST_METHOD "POST" chain
SecRule REQUEST_BODY "@rx (?i:(pills|insurance|rolex))"
Save the file and reload Apache. Open http://yourwebsite.com/form.php in the browser and enter text containing any of these words: pills, insurance, rolex.
You’ll either see a 403 page and a log entry or only a log entry based on SecRuleEngine setting. The syntax for SecRule is
SecRule VARIABLES OPERATOR [ACTIONS]
Here we used the chain action to match variables REQUEST_FILENAME with form.php,REQUEST_METHOD with POST and REQUEST_BODY with the regular expression (@rx) string(pills|insurance|rolex). The ?i: does a case insensitive match. On a successful match of all these three rules, the ACTION is to deny and log with the msg “Spam detected.” The chain action simulates the logical AND to match all the three rules.
Excluding Hosts and Directories
Sometimes it makes sense to exclude a particular directory or a domain name if it is running an application like phpMyAdmin as modsecurity and will block SQL queries. It is also better to exclude admin backends of CMS applications like WordPress.
To disable modsecurity for a complete VirtualHost place the following
<IfModule security2_module>
SecRuleEngine Off
</IfModule>
inside the <VirtualHost> section.
For a particular directory:
<Directory "/var/www/wp-admin">
<IfModule security2_module>
SecRuleEngine Off
</IfModule>
</Directory>
If you don’t want to completely disable modsecurity, use the SecRuleRemoveById directive to remove a particular rule or rule chain by specifying its ID.
<LocationMatch "/wp-admin/update.php">
<IfModule security2_module>
SecRuleRemoveById 981173
</IfModule>
</LocationMatch>
Further Reading
Official modsecurity documentation https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual
Official modsecurity website http://www.modsecurity.org/