10 tips for securing Apache

One of the reasons that Apache powers over half 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 your server.

In this article, I will provide you with 10 tips that will help you keep your Apache Web server 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.

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 kept current.

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

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.

Less disclosure equals 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 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.4 server, this is the default Directory directive:


Options Indexes FollowSymLinks
AllowOverrride None
Order allow,deny
Allow from all



Remove the Indexes reference so that this reads:

Options FollowSymLinks
AllowOverrride None
Order allow,deny
Allow from all


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.

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 (), 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. Follow the link above to visit the mod_security Web site for a more thorough overview of this module.

Run Apache as a non-privileged user

Under Apache 2.2.4, 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. 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.

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?

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.4 server, this is the Directory directive:


Options Indexes FollowSymLinks
AllowOverrride None
Order allow,deny
Allow from all



Remove the FollowSymLinks reference so that this reads:

Options Indexes
AllowOverrride None
Order allow,deny
Allow from all


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

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 port 80.

Depending on your environment, this may not be important.

Don't allow users near the root directory

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


Options FollowSymLinks
AllowOverride None
Order Deny,Allow
Deny from all




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



Options None
AllowOverride None
Order Deny,Allow
Deny from all


Remove the default comments from httpd.conf

Apache 2.2.4'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.

Protect Apache from Denial of Service (DoS) attacks

While you can never completely protect yourself 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.

Table A

Directive	Apache 2.2/2.3 default	Advice/Description
TimeOut	300 seconds	Should be lowered on sites that are subject to DoS attacks. Setting this to as low as a few seconds may be appropriate, but could pose problems for some CGI scripts.
KeepAliveTimeout	5 seconds	May be also lowered or even disabled (not recommended) on sites that are subject to DoS attacks.
LimitRequestBody	0 bytes (unlimited)	Restricts the total size of the HTTP request body sent from the client. If DoS attacks are occurring as a result of large requests, limit request size.
LimitRequestFields	100 fields	Limits the number of HTTP request header fields that will be accepted from the client. If DoS attacks are occurring as a result of too many HTTP request headers, lower this number.
LimitRequestFieldSize	8190 bytes	Limits the size of the HTTP request header allowed from the client.
LimitRequestLine	8190 bytes	This directive sets the number of bytes that will be allowed on the HTTP request-line.
MaxClients	256 requests	Sets the limit on the number of simultaneous requests that will be served.