Getting Started with mod_security

What is more important than Web security? No matter how advanced your firewall, how compartmentalized your network and how strong your encryption, it all comes crashing down if your Web applications are vulnerable. On the one hand, there's no substitute for stringent user-input validation and other secure programming practices. But on the other hand, the stakes are too high to operate without some sort of safety net.

Ivan Ristic has given us just such a safety net: his excellent Apache module mod_security acts as an application-layer proxy between users and your Web applications. The mod_security module can stop SQL injection, cross-site scripting and other input-based Web attacks dead in their tracks, with only minimal effort on your part, and with no impact at all on either your Web developers or your users.

In this article, I tell you what you need to know to install and begin configuring mod_security on your own Apache-based Web server.

Space doesn't permit a comprehensive explanation of the entire range of threats that mod_security was designed to help mitigate. If you're new to Web security, your first stop should be the Open Web Application Security Project (OWASP) Web site (see the on-line Resources), home of the OWASP Top Ten Most Critical Web Application Security Vulnerabilities. A reasonable second stop is Chapter 10, “Securing Web Servers”, of my book Linux Server Security, 2nd edition, or Ivan Ristic's book Apache Security.

For our purposes here, suffice it to say that of the different types of vulnerabilities in Web servers, by far the most typical is poor or incomplete user-input validation. In fact, many of the items on the OWASP Top Ten list are really just subsets of this family of problems; command injection and cross-site scripting, for example, are types of user-input abuse. User input, of course, includes not only the URLs requested in HTTP GET requests, but also the data sent in POST commands.

The mod_security module gives your Apache Web server increased ability to inspect and process input from Web clients before it's acted on by the scripts or processes waiting for the input. The mod_security module even lets you inspect Web server output before it's transmitted back to clients. I love this feature: it allows you to watch out for server responses that might indicate that other filters have failed and an attack has succeeded!

The mod_security module also lets you automatically log events and session data that Apache wouldn't ordinarily log. This is useful not only for forensics purposes, but also for fine-tuning your mod_security rules. If you create stringent mod_security filters that you're worried may be triggered by legitimate traffic, you can set those filters only to log rather than actually dropping or redirecting the requests that trigger them.

But wait, there's more: mod_security works against encrypted Web traffic too! Because mod_security has access to transaction data before SSL encryption and after SSL decryption, mod_security can filter HTTPS traffic just as effectively as it filters HTTP.

Why wouldn't you need mod_security? Arguably, if you have a “brochure-ware” Web site that involves no databases or cgi scripts, serving up instead only static Web pages, mod_security might not be worth the trouble of setting up. I would suggest, however, that even on such a server, mod_security still might do some good for you, for example, in inhibiting certain types of information-gathering attacks. Read on, and decide for yourself.

The mod_security module runs on both Apache 1.3 and Apache 2.0. Although for most Linux distributions, you'll need to install mod_security from source, Debian has its own binary packages for mod_security.

If you run Debian, install the package mod-security-common, plus either libapache2-mod-security or libapache-mod-security, depending on whether you run Apache version 2 or 1, respectively. Although Debian's mod_security packages are for mod_security version 1.8.7, rather than the more-advanced version 1.9, this article is sufficiently basic to apply equally to versions 1.8.7 and 1.9.

If you run SUSE or Red Hat Enterprise Linux, you need to download the latest source code from www.modsecurity.org and compile it using the apsx or apsx2 command (part of SUSE's apache-devel and apache2-devel packages, respectively, and RHEL's httpd-devel package). All you need to do, once you've got apsx or apsx2 installed and have obtained the source code file mod_security.c, is issue one of these two commands from within the directory containing mod_security.c:

/usr/sbin/apxs -cia mod_security.c