> ModSecurity Handbook: Getting Started: Chapter 2. Installation


Contents
Previous
Next

2 Installation

Before you can install ModSecurity, you need to decide if you want to compile it from source or use a binary version—either one included with your operating system or one produced by a third party. Each option comes with advantages and disadvantages, as listed in Table 2.1.

Table 2.1. Installation options

In some cases, you won’t have a choice. For example, if you’ve installed Apache from source, you will need to install ModSecurity from source too (you will be able to reuse the system packages, of course). The following questions may help you to make the decision:

Casual users should generally try to use binary packages when they’re available (and they are available in most distributions).

When we build dedicated reverse proxy installations, we tend to build everything from source, because that allows us access to the latest Apache and ModSecurity versions and makes it easier to tweak elements (by changing the source code of either Apache or ModSecurity) when we want to.

To download ModSecurity, go to its web site14 or the GitHub project page.15 You will need both the main distribution of the source code and its cryptographic signature:

$ wget https://www.modsecurity.org/tarball/2.9.1/modsecurity-2.9.1.tar.gz
$ wget https://www.modsecurity.org/tarball/2.9.1/modsecurity-2.9.1.tar.gz.asc

Verify the signature before doing anything else, to ensure the package you’ve just downloaded doesn’t contain a Trojan horse planted by a third party and that it hasn’t been corrupted during transport:

$ gpg --verify modsecurity-2.9.1.tar.gz.asc
gpg: Signature made Wed 09 Mar 2016 19:48:15 CET using DSA key ID E8B11277
gpg: Can't check signature: public key not found

Your first attempt may not provide the expected results, but that can be solved easily by importing the referenced key from a key server:

$ gpg --keyserver pgp.mit.edu --recv-keys E8B11277
gpg: requesting key E8B11277 from hkp server pgp.mit.edu
gpg: key E8B11277: public key "Felipe Zimmerle da Nobrega Costa ↩
<felipe@zimmerle.org>" imported
gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model
gpg: depth: 0  valid:   3  signed:   5  trust: 0-, 0q, 0n, 0m, 0f, 3u
gpg: depth: 1  valid:   5  signed:   5  trust: 2-, 0q, 0n, 2m, 1f, 0u
gpg: depth: 2  valid:   4  signed:   0  trust: 1-, 0q, 0n, 0m, 3f, 0u
gpg: next trustdb check due at 2018-09-26
gpg: Total number processed: 1
gpg:               imported: 1

Now you can try again:

$ gpg --verify modsecurity-2.9.1.tar.gz.asc
gpg: Signature made Wed 09 Mar 2016 19:48:15 CET using DSA key ID E8B11277
gpg: Good signature from "Felipe Zimmerle da Nobrega Costa ↩
<felipe@zimmerle.org>"
gpg:                 aka "Felipe Zimmerle"
gpg:                 aka "Felipe Costa <fcosta@trustwave.com>"
gpg:                 aka "Felipe Zimmerle (gmail) <zimmerle@gmail.com>"
gpg:                 aka "[jpeg image of size 7280]"
gpg:                 aka "[jpeg image of size 14514]"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 190E FACC A1E9 FA46 6A8E  CD9C E6DF B08C E8B1 1277

The warning in the previous snippet might look serious, but it generally isn’t a problem; it has to do with the way gpg expects you to verify the identity of an individual. The warning basically tells you that you’ve downloaded Felipe’s key from somewhere, but that you don’t really know that it belongs to him. The only way to be sure, as far as gpg is concerned, is to meet Felipe in real life, or to meet someone else who knows him personally. If you want to learn more, look up web of trust on Wikipedia.

If you want to be on the cutting edge, downloading the latest development version directly from the GitHub repository (the source code control system used by the ModSecurity project) is the way to go. When you do so, you’ll get new features days and even months before they make it into an official, stable release. Having said that, however, there is a reason we call some versions “stable.” When you use a repository version of ModSecurity, you need to accept that there is no guarantee whatsoever that it will work correctly.

Before you can install a development version of ModSecurity, you need to know where to find it. The repository, which is hosted with GitHub, can be viewed with a browser.16

The default view on GitHub is the master source code tree, which shows the most recent development version with the latest accepted changes. Proposed changes are accessible via pull requests or via their own separate branch. These active branches may sometimes contain a feature or a fix that has not been accepted into the master source code. If you want to download a release candidate or a tested release, you can access these archives via a separate submenu.

Once you’ve determined the location of the version of ModSecurity you want to use, you can get it using the clone command of Git, like this:

$ git clone https://github.com/SpiderLabs/ModSecurity.git modsecurity-master

What you’ll get in the modsecurity-master folder is almost the same as what you get when you download a release. Some files need to be generated via a special command first, though. Furthermore, the documentation might not be in sync. The master documentation is kept in a wiki, with copies of the wiki included with releases.

Before you can start to compile ModSecurity, you must ensure that you have a complete development toolchain installed. Refer to the documentation of the operating system you’re using for instructions. If you’ll be adding ModSecurity to an operating system–provided Apache, you’re likely to need to install a specific Apache development package too. For example, on Debian and Ubuntu you need to use apache2-dev.

In the next step, ensure that you have resolved all the dependencies before compilation. The dependencies are listed in Table 2.2.

If you already have Apache installed, you’ll only ever need to deal with libcurl, libxml2, Lua, ssdeep, and YAJL. With Apache compiled from source, you’ll also need the PCRE library. Apache no longer comes bundled with it. To work around this issue, install PCRE separately and then tell Apache to use the external copy; I explain how to do so later in this section.

If you’re installing from source, go to the packages’ web sites and download and install the tarballs. If you’re using managed packages, you just need to determine what the missing packages are called. On distributions from the Debian family, the following command installs the missing packages:

# apt-get install libcurl3-dev liblua5.3-dev libxml2-dev libfuzzy-dev libyajl-dev

Refer to the documentation of the package management system used by your platform to determine how to search the package database.

The process should be straightforward from here on. If you cloned the GitHub repository and did not download a release, then you need to generate the configuration script, which is used to prepare the compilation process:

$ ./autogen.sh

If you downloaded a release, then you can skip this step and execute the following commands directly in succession:

$ ./configure
$ make

This set of commands assumes that you don’t need any compile-time options. If you do, see the following subsection.

After ModSecurity is built, one more step is required to install it:

$ sudo make install

This command adds the module to your Apache installation but doesn’t activate it; you must do that manually. (While you’re doing so, confirm that mod_unique_id is enabled; ModSecurity requires it.) The command will also create a folder (/usr/local/modsecurity by default) and store the various runtime files in it. Here’s what you get:

bin/
    mlogc
    mlogc-batch-load.pl
    rules-updater.pl
lib/
    mod_security2.so

Using ModSecurity with a custom-compiled version of Apache is straightforward. With Apache 2.2, there used to be issues with PCRE and the mod_unique_id module not being enabled by default, but these were solved with Apache 2.4.

To configure ModSecurity, use the --with-apxs compile-time option to specify the location of your Apache installation. In the following example, I’m assuming Apache is installed in /usr/local/apache:

$ ./configure \
    --with-apxs=/usr/local/apache/bin/apxs

From here, install ModSecurity as described in the previous section.

After both Apache and ModSecurity are installed, you should confirm that both products link to the same PCRE library, using ldd:

$ ldd /usr/local/apache/bin/httpd  | grep pcre
        libpcre.so.3 => /lib64/libpcre.so.3 (0x00007ff2a11fd000)

You should get the same result when you compile ModSecurity:

$ ldd /usr/local/apache/modules/mod_security2.so | grep pcre
        libpcre.so.3 => /lib64/libpcre.so.3 (0x00007f85995c5000)

It is quite possible to have a configuration in which Apache uses its bundled PCRE and ModSecurity uses another PCRE version available on the system.

ModSecurity reports the detected library version numbers at startup (in the error log) and compares them to those used at compile time. One or more warnings will be issued if a mismatch is found. This feature is especially handy for troubleshooting various library collisions, which can happen in odd situations.

ModSecurity for Apache/2.9.1 (http://www.modsecurity.org/) configured.
ModSecurity: APR compiled version="1.5.2"; loaded version="1.5.2"
ModSecurity: PCRE compiled version="8.39 "; loaded version="8.39 2016-06-14"
ModSecurity: LUA compiled version="Lua 5.2"
ModSecurity: YAJL compiled version="2.0.4"
ModSecurity: LIBXML compiled version="2.9.1"

As previously discussed, using a binary version of ModSecurity is often the easiest option, because it just works. Unfortunately, what you gain in ease of installation you lose by sometimes being limited to an older version. Further, packagers often do not include mlogc, which is helpful for remote log centralization. In general, if you’re okay with the way the module was compiled, then you’ll be fine with binary packages.

ModSecurity was ported to Windows early on, in 2003, and has run well on the platform ever since. Windows binary packages of ModSecurity are maintained by Steffen Land, who runs Apache Lounge, a community for those who run Apache on Windows.18 In addition to ModSecurity, Steffen maintains his version of Apache itself, as well as many third-party modules you might want to run on Windows. The ModSecurity binary packages are consistently up to date, so you’ll have little trouble if you want to run the latest version. The download includes ModSecurity and mlogc.

The installation is quite easy. First, download the package and copy the dynamic libraries into the modules/ folder (of the Apache installation). Then, modify your Apache configuration to activate ModSecurity:

LoadModule security2_module modules/mod_security2.so

You will also need to activate mod_unique_id. This module may not be already active, but there should already be a commented-out line in your configuration. You just need to find it and uncomment it. If it isn’t there, just add the following:

LoadModule unique_id_module modules/mod_unique_id.so

It’s never been easier to install ModSecurity, now that it’s included with so many operating systems and distributions. Although installation from source code gives you guaranteed access to the most recent version, as well as access to the yet-unreleased code, it can be time-consuming if you’re not used to it; it’s not everyone’s cup of tea. There’s something to be said for using the provided version and not having to think about upgrading (and saving the time it takes to upgrade).

In the next chapter, I’ll explain each of the configuration options, teaching you how to set every single option, step by step, so that everything is just the way you like it.

[14] ModSecurity web site (SpiderLabs, retrieved 29 December 2016)

[15] ModSecurity GitHub page (GitHub, retrieved 29 December 2016)

[16] ModSecurity source code repository (GitHub, retrieved 29 Dec 2016)

[17] Extra Packages for Enterprise Linux (Fedora Project, retrieved 29 December 2016)

[18] Apache Lounge web site (Apache Lounge, retrieved 29 December 2016)