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.
|This is a sample 404 page when you have ServerSignature set to 'on'.|
|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:
Allow from all
Remove the Indexes reference so that this reads:
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.
|This is a sample folder on a server for which directory browsing is allowed.|
|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:
Allow from all
Remove the FollowSymLinks reference so that this reads:
Allow from all
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.
It's better to turn this option off. Change your httpd.conf to reflect the following:
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.