Security Checklist

It is often said that security is a process, not a feature. To keep your Apache installation secure, you will need to keep up to date with Apache security advisories and monitor your error and access logs. Since Apache does not run isolated from its environment, you will need to do the same at the operating system and application level. In fact, most remotely exploitable problems with Apache are due to problems at the application level, such as vulnerable wiki, PHP libraries, and components.

Having said this, the following is a step-by-step list of measures you can take to secure a default Apache installation.

Disable Unneeded Modules

The first step is to disable all modules that you are not using. If you compiled Apache with loadable module support, you can comment out the directives that load specific modules. You may need to comment out other directives present in the configuration file that relate to the disabled module. Here is a short list of the most important modules that you should remove if you are not using them, roughly in order of importance:

• PHP, mod_python, mod_mono, mod_perl, and any other server side language modules. Of course, you should only disable PHP if you are not using Apache to run PHP-based applications.

• mod_include, which provides Server Side Includes support.

• mod_cgi, which provides support for invoking external programs.

• mod_ssl, used to provide SSL/TLS support for securing communications between the browser and Apache.

• mod_proxy, which, if incorrectly configured, can allow outsiders to use your server to relay requests.

• mod_deflate, an Apache 2 filter for compressing output on the fly.

• mod_suexec, used to execute external programs under user IDs different from the one Apache is running as.

• mod_userdir, which allows users in Unix systems to host their own pages.

• mod_rewrite, which allows arbitrary mapping and rewriting of incoming URLs.

Additionally, in Apache 1.3 you can explicitly disable specific compiled-in modules by using the ClearModuleList directive and then explicitly enable modules using the AddModule directive.

Remove Sample Scripts

Most web server-side software and development environments include sample applications and scripts for demonstration or testing purposes. While useful, these samples are usually not coded with security in mind, and can be vulnerable to several attacks, mostly related to the program not properly escaping user input. These flaws often result in an attacker being able to execute arbitrary system commands, revealing the contents of other files, or being able to modify the database.

Make sure you remove all sample scripts and demo accounts shipped with your application servers, as well as your development environment and other web-based software you may have installed.

Limit or Disable CGI Execution and SSI

If you do not require CGI-script support, you should disable mod_cgi. If you require CGI support, you should limit the ability to execute scripts to specific directories. For example, you should scan your configuration for ScriptAlias directives and Options directives with ExecCGI arguments and make sure they are properly configured. Make sure that directories marked as containing executable scripts are not writable by others. You may also consider using the suExec CGI wrapper, included with Apache.

The same rationale can be applied to Server Side Includes functionality, which is provided by mod_include and allows execution of external commands, unless disabled by Options -IncludesNoExec.

Check File Permissions

On Unix systems, Apache is usually started as root; does a certain number of operations, such as binding to the appropriate port; and then changes its user ID to the one specified with the User directive. Because there are certain operations performed as root, it is critical to make sure that the log and configuration files, as well as the directories containing them, are not writable by other users. Make sure directories being marked as containing executable scripts or that can contain PHP scripts are not world writable and are not accessible through FTP or WebDAV, for example.

Limit or Disable Proxy Functionality

As with CGIs, you need to disable or restrict proxy support in your Apache installation. Otherwise, an open proxy can be used to perform attacks targeted at other websites or even to relay mail spam. If you are running Apache as a reverse proxy, you can disable "regular" proxy (forward-proxy functionality) with

ProxyRequests off

Restrict Access to Your Server by Default

The server should be configured in such a way that by default it denies access to documents on the server unless access is explicitly enabled. The following configuration snippet, extracted from the Apache Documentation, does just that:

<Directory />     Order Deny,Allow     Deny from all </Directory> <Directory /usr/local/apache2/htdocs>     Order Deny,Allow     Allow from all </Directory>

See also earlier sections on how to disable directory listings.