From Debian Clusters

Securing Apache has been the subject of many books and tutorials and will continue to be as security is an ever-changing field. By no means is this short page meant to be exhaustive. The steps below are basic recommendations for beginning to protect a web server; however, much more strenuous measures are needed to begin to truly secure one. Please use the information below as a starting place only.

If you haven't yet set up with the web server, you may want to look at that first.

Configuring Apache

Tweaking Defaults

One of the first things to do after installing Apache is to configure where it will serve files from, and to limit the options that people accessing the web server have. This is done by editing /etc/apache2/sites-available/default. Look for this section:

<Directory />
        Options FollowSymLinks
        AllowOverride None
</Directory>

This section controls how Apache treats the root directory of the file system (and by inheritance, all the files within the file system). This is somewhat secure, but a more secure configuration is better. Change the section to read like this:

<Directory />
        Order Deny,Allow
        Deny from all
        Options None
        AllowOverride None
</Directory>

This tells Apache not to serve any files at all from the file system, and also to allow no special options (such as symlinking, includes, or cgi scripts), and not to allow this to be overridden by .htaccess files in the directories. This is used to protect files that Apache shouldn't have access to. However, since we do want Apache to access files from within the /var/www directory, we need to edit the section below it to look like this:

<Directory /var/www/>
        Options FollowSymLinks MultiViews
        Order allow,deny
        Allow from all
</Directory>

The allow from all is what allows Apache to serve pages from within /var/www. Also, removing Indexes means that web users will not be able to see the contents of web directories.

You'll need to restart Apache in order for this to take effect. Restart Apache with apache2ctl restart.

Hiding Server Version

If you open up a web browser and visit http://www.yourserver.com/nonexistant.html, you'll see an error page like the one shown below. That gives away an awful lot of information to someone interested in attacking the system!

To obfuscate this information, open /etc/apache2/apache2.conf. Look for the line

ServerTokens Full

and change it to

ServerTokens Prod

You'll need to restart Apache in order for this to take effect. Restart Apache with apache2ctl restart. Afterward, server error pages should look something more like this:

Installing Mod_Security

Getting all the Pieces

The security module, or mod_security, is an Apache module that can be installed for closer monitoring of HTTP requests and responses as well as easy denial of packets that look suspicious. Unfortunately, due to licensing differences, mod_security is not available through the Debian repository, and so it can't be apt-gotten. Still, the module isn't terribly difficult to install.

Before obtaining the source code, there are a few other parts that can be installed through apt. These are libxml2-dev and apache2-prefork-dev. To install these, run

apt-get install libxml2-dev apache2-prefork-dev

To get the source code for mod_security, you must first create a user account with Breach Security, the developers of mod_security. After logging in, navigate to Downloads and then modsecurity-apache/. Find the latest version of modsecurity-apache...tar.gz and right-click it to save the download location. From where you keep your source code, run

wget <download location> --no-check-certificate

Untar the file with tar xvzf and then cd into the new directory. From there, cd into apache2. Mod_security follows the typical source installation paradigm, so no surprises there. Run ./configure --help to see all available options. In most cases, none will be necessary. Go ahead and run ./configure (with any options) and then make. If it finishes without an error, it's safe to make install.

Configuring Apache

Now that the files for mod_security have been installed, Apache needs to be told to use them. Cd into /etc/apache2/mods-available. A new file needs to be created to tell Apache to load the mod_security module. Call this file modsecurity2.load and enter the following contents:

LoadFile /usr/lib/libxml2.so
LoadModule security2_module /usr/lib/apache2/modules/mod_security2.so

Now move up one directory and then into mods-enabled (cd ../mods-enabled). Here, a symlink to the file needs to be created. This is done with

ln -s ../mods-available/modsecurity2.load

While we're here, mod_security also requires mod_unique_id to be running, so create a symlink to enable that one, too:

ln -s ../mods-available/unique_id.load

After this, it's time to restart Apache and make sure it loads the new file. Run apache2ctl restart and then look at the bottom of the Apache log with tail /var/log/apache2/error.log. You should see something like this:

[Sun Apr 06 18:54:25 2008] [notice] ModSecurity for Apache/2.5.2 (http://www.modsecurity.org/) configured.

If you don't, or you see any errors, double check the above and make sure you're error-free before continuing.

Configuring Mod_security

At this point, mod_security is loaded but isn't actually accomplishing anything because it hasn't yet been configured. First, it needs some rules to tell it what to look for while it's watching the web traffic. A core set of these rules can be downloaded from Breach Security, so log back into their downloads section and copy the location of the tar file containing the latest rules. From your source directory, run

wget <file location> --no-check-certificate

Untarring it won't put the contents into a directory, so don't untar it and make a mess just yet. First, create a directory to become a new home for the rules, like mkdir /var/lib/modsecurity. Remember this location because you'll need to reference it a few more times. Next, untar the file with

tar xvzf modsecurity-core-rules*.tar.gz

and then move all the new files into the directory you just created:

mv modsecurity_crs_* /var/lib/modsecurity/

You'll also want to tweak the location where the log files are kept. Open modsecurity_crs_10_config.conf and search for SecAuditLog and SecDebugLog. Change these so that they point to a file under /var/log/apache2.

Next, Apache needs to be told where the rules are at. Create the file /etc/apache2/conf.d/modsecurity2.conf and give it these contents:

<ifmodule security2_module>
   Include /var/lib/modsecurity/*.conf
</ifmodule>

Testing Mod_security

At this point, it would be nice to test mod_security and make sure it's really filtering through the traffic. This can be done with a simple wget test. Wget can be configured to identify itself as something other than wget, so all we need to do is change it to something that should trigger mod_security. You'll probably want to do this from somewhere other than the web server itself. If you followed my firewall services tutorials, for instance, it won't work unless running this command from somewhere outside of the firewall.

wget -O - -U "webtrends security analyzer" http://<your server>

If mod_security is working, the machine you issued the command from should receive a 404 error:

kwanous@cassowary:~$ wget -O - -U "webtrends security analyzer" http://myserver.goes.here/
--19:13:17--  http://myserver.goes.here/
           => `-'
Resolving myserver.goes.here... X.X.X.X
Connecting to myserver.goes.here|X.X.X.X|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
19:13:17 ERROR 404: Not Found.

From your webserver, if you run

tail /var/log/apache2/debug.log

or

tail /var/log/apache2/audit.log

you'll see why!

[06/Apr/2008:19:13:17 --0500] [myserver.goes.here/sid#855d8f0][rid#87357f8][/][1] 
  Access denied with code 404 (phase 2). Pattern match "(?:\b(?:m(?:ozilla\/4\.0 \
  (compatible\)|etis)|webtrends security analyzer|pmafind)\b|n(?:-stealth|sauditor|
  essus|ikto)|b(?:lack ?widow|rutus|ilbo)|(?:jaascoi|paro)s|webinspect|\.nasl)" at 
  REQUEST_HEADERS:User-Agent. [file "/var/lib/modsecurity/modsecurity_crs_35_bad_robots.conf"]
  [line "19"] [id "990002"] [msg "Request Indicates a Security Scanner Scanned the Site"] 
  [severity "CRITICAL"] [tag "AUTOMATION/SECURITY_SCANNER"]

Because the user agent string in the HTTP request matched the above regular expression, which includes "webtrends security analyzer", the request for the file is denied. This shows that mod_security is working!

To further crack down, additional rule sets can be downloaded from the Got Root website. Be sure to place them in the same directory as the other rules (for instance, /var/lib/modsecurity/) and if you put them in a subdirectory, update /etc/apache2/conf.d/modsecurity2.conf.

Occasionally, rules in mod_security will be tripped over harmless traffic, or traffic you'd like to allow through. You can always look at audit.log or debug.log to identify the id of the rule and disable it if necessary. (Make sure to restart Apache - apache2ctl restart - for changes to take effect.)

Additional Mod_security Rules

The Got Root website releases periodically updated mod_security rules freely available for download. These can be used in addition to the core rules package. After downloading them and placing them in /var/lib/modsecurity/gotrootrules (or wherever you put them), you'll need to update /etc/apache2/conf.d/modsecurity2.conf to point to the additional files as well as the previous ones.

References

• Ristic, Ivan. Apache Security. 1st ed. Sebastopol, CA: O'Reilly Media, Inc., 2005.