Working with Web Vulnerabilities and Web Application Firewalls [Part 5 - Mod Security]

[Note: this is part five of a multi-part series of posts detailing my experiences with securing web applications, creating test environments for practicing and installing and operating a web application firewall. Web security is an extremely important part of IT security since almost every major organization has a "web face." I will be exploring XSS, mySQL injection, and the use of web application firewalls to protect against these attacks.]

When we last left off in the series, I was demonstrating that Damn Vulnerable Web App is actually... vulnerable. But now it's time to move on and actually detect (and stop) hacking attacks through the use of a web application firewall known as Mod Security.

Intro to Mod Security

Mod Security is essentially a firewall module that can be added to an Apache web server to help detect, filter, and even block web attacks. It uses a complex set of rules based on signatures and regular expressions to determine whether or not a particular input is malicious. Unlike a traditional firewall, which merely analyzes source/destination addresses and perhaps port numbers or services, Mod Security is able to analyze the HTTP traffic that is passing over port 80 to the web server and determine the exact payload. This is extremely important because it enables us to block attacks that are entirely web-based.

Installation

Before installing mod_security, make sure you stop your server by running:

service httpd stop

Mod Security can be downloaded from http://modsecurity.org/download however, the simplest method is to issue:

 yum install mod_security

Mod Security has a default set of rules and pattern matching techniques that it uses to detect attacks. For right now, we will be using the default rules. Hopefully in a future addition to this series I will delve more into the intricate settings to create a custom-tailored firewall. For now, I'll demonstrate Mod Security's features out-of-the-box.

Testing

Restart your Apache server:

service httpd start

And now, return to your DVWA homepage and login. For this demo, I will be attempting the same SQL injection attack that was performed in part four of this series. Watch what happens this time...

Remember from before that the attack had succeeded, returning a list of every user account in the system. From a security standpoint, it's pretty obvious that the page you see above is a much-preferred response to an attack.

The Logs

Mod Security is extremely useful because, as shown above, it blocked the attack from occurring. However, it's also great to have logs of which events were blocked. Luckily, Mod Security does that as well.

The logs are stored in /var/log/httpd/modsec_audit.log. Looking at the logs immediately after attempting our OR '1' = '1 attack, the following log is shown:

This log message reveals why our attack was stopped. The attack matched a pattern that was outlined in the mySQL injection ruleset. The log entry also details the response that Mod Security took - in this case, displaying a 403 access denied error.

More to Come!

This example only scratches the surface (and barely, at that) of what Mod Security can do. The configuration and rules can be changed and modified as needed to fit the needs of any web application. I hope to explore a lot more of the functionality behind Mod Security and perhaps write some custom rules. Stay tuned!