Book Image

ModSecurity 2.5

Book Image

ModSecurity 2.5

Overview of this book

With more than 67% of web servers running Apache and web-based attacks becoming more and more prevalent, web security has become a critical area for web site managers. Most existing tools work on the TCP/IP level, failing to use the specifics of the HTTP protocol in their operation. Mod_security is a module running on Apache, which will help you overcome the security threats prevalent in the online world. A complete guide to using ModSecurity, this book will show you how to secure your web application and server, and does so by using real-world examples of attacks currently in use. It will help you learn about SQL injection, cross-site scripting attacks, cross-site request forgeries, null byte attacks, and many more so that you know how attackers operate. Using clear, step-by-step instructions this book starts by teaching you how to install and set up ModSecurity, before diving into the rule language with examples. It assumes no prior knowledge of ModSecurity, so as long as you are familiar with basic Linux administration, you can start to learn right away. Real-life case studies are used to illustrate the dangers on the Web today ñ you will for example learn how the recent worm that hit Twitter works, and how you could have used ModSecurity to stop it in its tracks. The mechanisms behind these and other attacks are described in detail, and you will learn everything you need to know to make sure your server and web application remain unscathed on the increasingly dangerous web. Have you ever wondered how attackers figure out the exact web server version running on a system? They use a technique called HTTP fingerprinting, and you will learn about this in depth and how to defend against it by flying your web server under a "false flag". The last part of the book shows you how to really lock down a web application by implementing a positive security model that only allows through requests that conform to a specific, pre-approved model, and denying anything that is even the slightest bit out of line.
Table of Contents (17 chapters)
ModSecurity 2.5
Credits
About the Author
About the Reviewers
Preface
Directives and Variables
Index

Downloading


ModSecurity was originally developed by web application security specialist Ivan Ristic in 2002. He has also written the excellent book Apache Security (O'Reilly Media, 2005) which I highly recommend if you want a general book on hardening Apache. ModSecurity was acquired by Breach Security, a California-based web application security company, in 2006. The company chose to continue releasing ModSecurity as a free open source product (under the GPLv2 license), hiring Ivan and additional staff to work on the product, which is good news for all users of ModSecurity.

The ModSecurity source code is available at http://www.modsecurity.org/download/. The source is provided as a .tar.gz archive—to download it all you have to do is copy the link to the latest release and you will then be able to use wget to download the source archive to your server.

In the following text the name of the file used for the source archive is assumed to be modsecurity‑apache.tar.gz. Make sure you substitute the actual file name or web location (which usually includes the version number of the latest release) for this name when downloading or working with files.

$ wget http://www.modsecurity.org/download/modsecurity-apache.tar.gz
Resolving www.modsecurity.org... 216.75.21.122
Connecting to www.modsecurity.org|216.75.21.122|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://downloads.sourceforge.net/mod-security/modsecurity-apache.tar.gz?use_mirror= [following]
[...]
HTTP request sent, awaiting response... 200 OK
Length: 1252295 (1.2M) [application/x-gzip]
Saving to: `modsecurity-apache.tar.gz'
[...]
'modsecurity-apache.tar.gz' saved [1252295/1252295] ]

Checking the integrity of the downloaded source archive

Checking the integrity of the downloaded archive file is always a good habit. This ensures that the file has not been tampered with in any way. There are two ways to do this—a less secure and a more secure way. The less secure way is to use the md5sum tool to calculate the MD5 sum of the downloaded file and then compare this MD5 sum to the one published on the ModSecurity website.

MD5 is an algorithm of a type called "cryptographic one-way hash". It takes an input of an arbitrary size (the source archive, in this case), and produces an output of a fixed length. A hash function is designed so that if even one bit changes in the input data, a completely different hash sum is calculated. The hash function should also be collision resistant. This means that it should be very hard to create two files that have the same hash value.

Using the MD5 sum to verify the integrity of the archive is less than optimal for two reasons: :

  1. If anyone had the ability to alter the source code archive then they would also have the ability to alter the file that contains the calculated MD5 sum and could easily make the bad source distribution appear to have a valid checksum.

  2. The other, and less subtle reason to not use the checksum approach, is that it was recently discovered that the MD5 checksum function is not collision resistant. In 2008, a group of researchers used 200 Sony PlayStation 3 consoles (yes, really!) to create a falsified web server certificate using attacks on the MD5 function. All in all, this means that the MD5 checksum function is no longer considered secure.

The better way to verify the integrity of the downloaded source archive is to use public key cryptography. In public key cryptography, encryption and decryption are performed using different keys. Encryption is performed using a private key, which only the person encrypting a file or document has access to. Decryption is done using a public key, which anyone can access and which can be published online.

When a file is signed using public key cryptography, a checksum for the file is first calculated, just like with the MD5 algorithm described above. The calculated hash is then encrypted using the signer's private key. You can then verify the integrity of the signed file by decrypting the hash (using the signer's public key) and comparing it to the calculated hash value. All of this is done automatically using a program such as PGP or Gnu Privacy Guard (GPG).

The developers of ModSecurity have signed the source code archive using their private key, which allows us to verify its integrity in the manner just described. The first thing we need to do in order to verify the archive is download the file that contains the signature:

$ wget http://www.modsecurity.org/download/modsecurity-apache.tar.gz.asc

We can then use the open source program GPG to verify the signature. GPG comes pre-installed on most Linux systems; however should the program not be installed on your system you can get it at http://www.gnupg.org.

When we try to verify the signature of the source archive using GPG we will encounter a problem, as we don't have the public key of the person who signed the file:

Fixing this is however easy. All we need to do is download the public key file used to sign the file, as specified by the key ID in the output above. The key is available on the server pgp.mit.edu, which is a repository of public key files.

Tip

If you have a firewall controlling outbound traffic, you need to enable connections to remote port 11371 for GPG to be able to download the key.

The following command is used to download the key from the server:

Now that we have downloaded the public key, all the required elements to check the signature are in place. Running the verification command again produces this output:

The verification of the source archive using the public key we just downloaded has succeeded, as evidenced by the line starting with Good signature from. However, what about the ominous-looking message Warning: This key is not certified with a trusted signature?

Public key cryptography tools such as GPG work using a concept called web of trust. In the same way that you might trust that your best friend's parents are the people he introduces to you as his parents, a public key can be trusted if other people you trust have verified that the key belongs to the actual person it is issued to. This verification of another key is called signing the key, and this can be done by many people (to continue our analogy, this would be like other people verifying that your best friend's parents are the people he introduced you to).

If you don't already have public keys installed on your system that build a chain of trust and verify that the key you just used really does belong to Brian Rectanus, there is a (very small) chance that someone could have forged his public key. Fortunately, for those who are very paranoid, or are working on a project that has high security demands, it is possible to verify that a public key belongs to a person. This is done by taking the key's fingerprint, and asking someone who knows Brian (or even Brian himself) to verify that his key has the fingerprint shown on your copy. You can show the fingerprints of all the keys you have imported into GPG by executing gpg --fingerprint.