Safety optimization of Apache

[Lead Team]

The following suggestions and comments are notes that are designed to optimize the configuration of the Apache safety. But beware: These improvements created by no means a completely secure configuration. The tips are to make errors and necessary configuration work of the administrator after the installation of Apache and to the possible dangers of a general nature closely. Against this background the first to offer security enhancements to the basic configuration of Apache on the following pages have been possible. Some problem cases occur in the standard configuration of the current Apache version 2.2 does not recur, but there may be acquisition of the httpd.conf file for an older version have slipped through. A review is therefore appropriate in each case. Please note that the specified line numbers for Apache 2.2 are not valid any more.

Listen directives

By default Apache listens to the instructions of the installation from the Listen 80 (httpd.conf, line 218) to port 80 of all available IP addresses of the system. This creates the danger that a careless administrator shall ensure that the Apache can be addressed via an IP address from which usually no access to the system should be possible. It is therefore advisable to IP addresses that access control is possible on the local system to explicitly define a Listen directive in the configuration file of Apache. For example:

Listen 192.168.0.6:80

This statement of the Apache is only bound to port 80 of the network interface, the IP address is assigned 192.168.0.6. Please also note that the server on TCP port 443 (HTTPS) on all network cards also addressed, provided that SSL is enabled. The reason for this is that the file conf / ssl.conf is also loaded by the Apache (httpd.conf, lines 1040-1042) and then lists a corresponding statement is present. The above mentioned statements regarding the danger of a universal statement of course also for SSL.

[Lead Team]

User nobody

After installation of Apache, it is the responsibility of the administrator, look through the configuration file of Apache and then make various changes to the basic configuration. An important change is the correction of the information contained in lines 266-267 in which user and group ID used by Apache to run to default, provides this configuration for compatibility as follows:

User nobody
Group # -1

The user nobody is used here because of this on a variety of systems already exists and is happy to run system services with privileged not used, the rights there. For security reasons, you should create a separate user to run the server and enter their user ID in the configuration file of Apache. The standard used for compatibility group ID # -1 is very interesting since this is strictly speaking not valid and ensure that the Apache with a false and usually non-existent group ID is performed in (eg 5974967675). Therefore, for generating the implementation of the Apache, a separate group or set of input command id nobody proper identification by the group itself, which the user belongs to nobody and correct value of the group ID in the file httpd.conf. You can create inter alia, the following commands a separate group and a user of the implementation of Apache:

# Groupadd wwwuser
# Useradd-g wwwuser-d / nonexistent-s / bin / false www user

[Lead Team]

Configuration options for the root directory

In lines 316-319 of the httpd.conf file system configuration options for the root directory "/" the set. The agency said the configuration file looks like this:

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

I personally see no reason why the Apache, caused by disclosure of the FollowSymLinks option, the default symbolic links below. This behavior is particularly questionable, since this standard configuration is also such links or references are followed, which include the target file or directory does not target the same user that the link is real. This is a potential attacker is in principle possible to access files that are stored as the DocumentRoot defined list of outside. For this reason, I consider the following configuration makes more sense:

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

If you still can not do without symbolic links in the root directory, you should limit the pursuit of symbolic links, at least those in which the owner of the destination file or the destination directory with the owner of the reference is identical:

 
<Directory /> 
Options SymLinksIfOwnerMatch 
AllowOverride None 
</ Directory>

The previous version is still probably safer. It is also useful for safety reasons, access to the root file system ("/") also point to restrict this. The best configuration at this point in the httpd.conf file is probably why:

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

With this configuration are in part known as directory traversal, that is willful to prevent the entire directory tree of a server.

[Lead Team]

Customize options for htdocs

Furthermore, in lines 331-360 of the configuration file options for httpd.conf as DocumentRoot document directory called htdocs local Apache installation (eg. / Usr/local/apache2/htdocs) defined. Reduced the passage looks like this:

<Directory »/usr/local/apache2/htdocs«> 
Options Indexes FollowSymLinks 
AllowOverride None 
Order allow, deny 
Allow from all 
</ Directory>

Again, I think it is for safety reasons, not advisable to automatically generate directory listings and to follow symbolic links. Directory Listings by the contents of a directory will be presented in outline, if present in the respective directory file is not indexed. This creates the danger that directory content published unintentionally or can be viewed from the outside. Furthermore, there's the existing FollowSymLinks statement, the possibility that an attacker accesses a symbolic link to files and directories that are stored outside the DocumentRoot defined as a directory. I therefore recommend the following configuration change (abridged):

<Directory »/usr/local/apache2/htdocs«> 
Options None 
AllowOverride None 
Order allow, deny 
Allow from all 
</ Directory>

If you need these functions for a particular directory, you should explicitly for example using a Directory directive for the directory and activate.


The ServerTokens statement

The Apache 2 provides the ServerTokens statement, the possibility of the scope of the client transmitted to information (so-called "banner") with respect to the used version of the existing extensions and the underlying operating system in the head (header) of a server response to define. However, by default all the records are published, which in my opinion, too many sensitive data leaks through the general server configuration to the public. A not very experienced user of this line may perhaps attach little importance, but for an attacker it provides important information. For the server version of Apache 2, there is a vulnerability in the remote execution of arbitrary code, the resulting installed. In addition, there have been 21 December 2001, a newer version (0.9.6c) of the OpenSSL library, because several vulnerabilities have been discovered in the program, which currently is the version 0.9.7c-date. Furthermore, it is clear a child's game that on the appropriate server running Sun Solaris 8.

For these and other reasons, I recommend the following configuration, the amount of published information to reduce to a minimum:

ServerTokens Prod

This identifies the server only with the Apache code and therefore can not be directly traced back to the operating system and the existing extensions (eg OpenSSL) to. The identification as a kind of software (eg Microsoft IIS 5) is also possible by manipulation of the source code of the Apache, although this is a gimmick. Of course I understand that such actions pejoratively as "security by obscurity" are often referred to and the active safety of their own system (if any) increase only minimally.