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
Installation type | Advantages | Disadvantages |
---|---|---|
Operating system version | ||
Third-party binary | ||
Source code |
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
$ 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.
Table 2.2. ModSecurity dependencies
Dependency | In Apache? | Purpose |
---|---|---|
Apache Portable Runtime (APR)a | Yes | Various |
APR-Utilb | Yes | Various |
mod_unique_id
| Yes, but may not be installed by default | Generate unique transaction ID |
libcurlc | No | Remote logging (mlogc ) |
libxml2d | No | XML processing |
Luae | No | Writing complex rules in Lua (optional) |
Perl Compatible Regular Expressions (PCRE)f | Yes, but cannot be used by ModSecurity | Regular expression matching |
ssdeepg | No | Perform fuzzy hash matching |
YAJLh | No | JSON processing and JSON format logging |
[a] Apache Portable Runtime (Apache Portable Runtime Project, retrieved 29 December 2016) [f] Perl Compatible Regular Expressions (PCRE, retrieved 29 December 2016) |
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.
Libcurl, which is used for remote logging, can be compiled to
use OpenSSL or GnuTLS. You are advised to use OpenSSL because there have been
complaints about remote logging problems when GnuTLS was used. APR-Util is
usually compiled without support for cryptographic operations. If you want to
use the directive SecRemoteRule
with the parameter
crypto
, you’ll need to compile APR-Util yourself.
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.
Running additional tests after compilation (make
test
and make test-regression
) is always a good
idea and is an especially good idea when using a development version of
ModSecurity. If you’re going to have any problems, you want to have them before
installation, rather than after.
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
The configuration example from the previous section assumed
that the dependencies were all installed as system libraries. It also assumed
that the configure
script will figure everything on its
own. It may or may not do so, but chances are good that you’ll occasionally need
to do something different; this is where the compile-time options listed in
Table 2.3 come in
handy.
Table 2.3. Main compile-time options
Option | Description |
---|---|
--disable-request-early | Shift the first processing phase of ModSecurity to a later position in the lifecycle of an Apache request. The default is to run the phase early. |
--with-apr
| Specify the location of the Apache Portable Runtime library. |
--with-apu
| Specify the location of the APR-Util library. |
--with-apxs
| Specify the location of Apache through the location of the
apxs script. |
--with-curl
| Specify the location of libcurl. |
--with-libxml
| Specify the location of libxml2. |
--with-pcre
| Specify the location of PCRE. |
--with-ssdeep
| Specify the location of ssdeep. |
--with-yajl
| Specify the location of YAJL. |
There are a few additional options dealing with the audit log format of ModSecurity. They are rarely used in practice, but take a look at the configure script to get an overview.
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)
Mac OS X does not have ldd
, but you can
obtain the equivalent functionality by running otool
with
option -L
. If you really get stuck, consider using
install_name_tool
to change library dependencies
after ModSecurity is compiled.
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.
If you’re a Fedora user, you can install ModSecurity directly from
the official distribution, using yum
:
# yum install mod_security
On CentOS and Red Hat Enterprise Linux, you have to use the packages from Extra Packages for Enterprise Linux (EPEL), a volunteer effort that’s part of the Fedora community.17 The installation process is the same as for Fedora.
Debian was the first distribution to include ModSecurity. Alberto Gonzalez Iniesta has been a long-time supporter of ModSecurity on Debian, supporting ModSecurity in his own (unofficial) repository and later becoming the official packager.
If you are running a version of the Debian family, the installation is easy:
# apt-get install libapache2-mod-security2
This single command will download the package and install it, then activate the module in the Apache configuration.
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
.
Although it might be possible to run Steffen’s ModSecurity binaries with a version of Apache produced elsewhere, you really should use only the packages from a single location that are intended to be used together. Otherwise, you may encounter unusual behavior and web server crashes.
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)