One of the reasons that Apache powers close to seventy
percent of the world’s domains is its track record when it comes to being a
safe and secure web operating environment. The Apache group has done a great
job at keeping its product safe and, at the times when the product has been
found to have a defect related to security, the Apache group gets a patch out
as quickly as possible.

However, even with Apache’s focus on producing a secure
product, the web server can still be vulnerable to any number of attacks if you
fail to take some security precautions as you build you server.

In this article, I will provide you with ten tips that will
help you keep your Apache web server fit and healthy and protected from
predators. Bear in mind that you need to carefully evaluate each of these tips
to make sure that they are right for your organization.

Tip #1: Harden your operating system and keep it current

If your operating system is not properly installed and
secured, or you have failed to keep current on OS security releases, your
Apache installation could be compromised through an avenue totally unrelated to
the web server itself. Keep up to date on all security patches and services
packs.

Further, take recommended steps to harden your operating
system. In most cases, this means only installing services that are absolutely
necessary for your system, turning off unnecessary protocols, using ACLs to
define what kind of traffic can get to the system and from where that traffic
can originate.

Also make sure your server runs antivirus and antispyware
software and that these software packages are also kept current.

Beyond the OS, make sure that your network is well-protected
with a firewall and appropriate intrusion detection systems are in place.

Tip #2: Install only what you need

One of Apache’s greatest strengths–its flexibility and
sheer number of installable modules–can also be a great weakness when it comes
to security. The more you install, the larger attack surface you create for a
would-be hacker. A standard Apache install includes more than twenty modules,
including CGI capability, and some authentication mechanisms. If you don’t plan
to use CGI, and you’re only going to use a static site and don’t need users to
authenticate, you may not need any of the services offered by either of these
modules, disable these modules at the time you install Apache.

If you’ve inherited a running Apache server and do not want
to reinstall it, go through the httpd.conf configuration file and look for
lines that start with LoadModule. Check the Apache documentation (or Google) to
find information about the purpose of each module and comment out the modules
that you don’t need. Afterwards, restart Apache.

Tip #3: Less disclosure = less information for a hacker

You know by now that Apache is helpful. After all, it’s easy
to install, and fairly easy to administer. Unfortunately, many Apache
installations tend to be too helpful
by providing perfect strangers with information about your server, such as the
Apache version number and information related to your operating system. With
this information, a potential hacker can go after specific exploits that may
affect your system, particularly if you haven’t been able to stay current with
all patches. Now, instead of a hacker’s exploit attempt being handled by
trial-and-error, he knows exactly what you’re running and he can tailor his attack.

To help keep your server from broadcasting sensitive
information, make sure the “ServerSignature” directive in httpd.conf
is set to “off”. As a note, a default Apache installation sets this
directive to off by default, but many administrators enable it. Figures A and B
below show you the result of changing this directive.

Figure A
This is a sample 404 page when you have ServerSignature set to ‘on’.

Figure B
This is the same page, but the ServerSignature directive is set to ‘off’.

Likewise, it’s a good idea to disable directory browsing. When
directory browsing is enabled, users that browse to a directory that does not
contain a default document are instead provided with a complete list of the
contents of that directory. While you shouldn’t store sensitive materials in
plain text on a web server, unless you have to, you shouldn’t allow people to
see more than they need.

Directory browsing is enabled by default. To disable this
feature, edit the httpd.conf file and, for each “Directory”
directive, remove the “Indexes” reference.

For example, on my lab Apache 2.2 server, this is the
default Directory directive:

<Directory "/usr/local/apache/htdocs">

Options
Indexes FollowSymLinks

AllowOverrride None

Order allow,deny

Allow from all

</Directory>

Remove the Indexes reference so that this reads:

<Directory "/usr/local/apache/htdocs">

Options
FollowSymLinks

AllowOverrride None

Order allow,deny

Allow from all

</Directory>

You can also leave the Indexes directive and precede it with
a dash to disable the directive. I.e. “-Indexes”.

Figures C and D show you the results of this change.

Figure C
This is a sample folder on a server for which directory browsing is
allowed.

Figure D
This is the same folder with the Indexes directive removed.

Tip #4: Run mod_security

Mod_security,
an Apache module written by Ivan Ristic, provides Apache with a front-end
firewall through which all incoming requests are filtered before being sent on
to other web server modules. Among other features, mod_security includes:

  • As
    indicated above, powerful request filtering that also works for HTTPS
    traffic.
  • Anti-evasion
    techniques, such as the removal of null bytes (%00), multiple slashes, etc.
    from URLs.
  • Identity
    obfuscation. The identity of the web server can be changed to thwart
    hackers.
  • Full
    audit logging for future analysis if necessary.

Among the reasons that mod_security was developed was to
protect servers prone to SQ injection attacks from being compromised and
databases lost. Under a SQL injection attack, SQL code is passed to a database
process via a URL. If proper precautions aren’t taken, an Internet miscreant
could send a command such as “DROP DATABASE” through a URL string and
render a web site useless in a matter of seconds.

Mod_security does much more than what I’ve outlined here. Click
the link above to visit the mod_security website for a more thorough overview
of this module.

Tip #5: Run Apache as a non-privileged user

Under Apache 2.2, the default Apache installation sets the
User and Group directives in httpd.conf to “daemon” (a good change). In
older versions of Apache, these values were often set to “nobody”,
which, under certain situations can have significant security implications,
particularly since other services often run as this user as well. Depending on
who you talk to, use of the Nobody account for running services and for owning files
can go either direction.

So change it.

Generally, administrators that decide to take this step
create a user and group on their Apache server named “Apache” and the
Apache service runs under this account and files related to the web site are
then made readable by this account.

To make this change, open the httpd.conf file and change the
contents of the User and Group directives to “Apache”, or the account
name you have selected.

You will likely need to also make changes to the file permissions
and ownership of the files in your Apache directory as well.

Tip #6: Disable the following of symbolic links

If you’re the only person proving web content to the world
and you rarely make mistakes when you create new symbolic links, you may not
have to worry about this step. If, however, you have many people adding content
directly to your site, and they are not as savvy as you, there is a risk that a
user may accidentally create a symbolic link to a part of your file system that
you really don’t want people to be able to see. For example, what would you do
if someone, in your Apache server’s document root directory, created a symbolic
link to the “/” folder? Hello,
filesystem!

To disable the ability for Apache to allow users to follow
symbolic links in their requests, remove the “FollowSymLinks”
directive on your Directory commands.

For example, on my lab Apache 2.2 server, this is the
Directory directive:

<Directory "/usr/local/apache/htdocs">

ptions
Indexes FollowSymLinks

AllowOverrride None

Order allow,deny

Allow from all

</Directory>

Remove the FollowSymLinks reference so that this reads:

<Directory "/usr/local/apache/htdocs">

Options
Indexes

AllowOverrride None

Order allow,deny

Allow from all

</Directory>

If some users need the ability to follow symbolic links,
consider the use of the SymLinksIfOwnerMatch
directive instead.

Tip #7: Be specific on the Listen directive

When you first install Apache, the httpd.conf file is
populated with a directive that reads “Listen 80”. Shore things up
and change this to “Listen ww.xx.yy.zz:80”, where the “ww.xx.yy.zz”
is the IP address on which you want Apache to listen for requests. This is
especially important if you have Apache running on a server with multiple IP
addresses. If you don’t take this precaution, the default “Listen 80”
directive tells Apache to listen to every IP address on pot 80.

Depending on your environment, this may not be important.

Tip #8: Don’t allow users near the root directory (read: keep them in the Web
area)

Under no circumstances should you allow users (or Apache)
access to files and directories higher up the folder hierarchy. Apache 2.2
includes a restrictive option that achieves most of the goal, but still leaves
the FollowSymLinks option available for the root (“/”) folder.

<Directory />

Options
FollowSymLinks

AllowOverride
None

Order
Deny,Allow

Deny
from all

</Directory>

It’s better to turn this option off. Change your httpd.conf
to reflect the following:

<Directory />

Options
None

AllowOverride
None

Order
Deny,Allow

Deny
from all

</Directory>

Tip #9: Remove the default comments from httpd.conf

Apache 2.2’s default httpd.conf file exceeds 400 lines. Of
these 400 lines, only a fraction are actually Apache directives. The rest are
nothing but comments designed help you place appropriate directives into
httpd.conf. In my experience with Apache, I’ve found that the comments
seriously get in the way to such an extent that you may leave dangerous
directives in the file. One of the first things I’ve done on many Apache
servers I’ve managed is to copy the httpd.conf file to something else (say,
httpd.conf.orig) and then totally strip out the superfluous comments. The file
becomes much more readable and you’re
less likely to overlook a potential security problem or make a mistake with
your configuration.

Tip #10: Protect Apache from Denial of Service (DoS) attacks

While you can never protect yourself 100% from DoS attacks,
Apache provides you with a number of directives that you should consider
manipulating to help protect your server from these kinds of affronts. Table A lists the directives recommended for review by the Apache group for
servers that may become the subject of a DoS attack.