S 2.174 Secure operation of a WWW server

Initiation responsibility: Head of IT Section, IT Security Management

Implementation responsibility: Administrators

WWW servers are attractive targets for attackers and therefore have to be very carefully configured so that they can be operated securely. The operating system and the software must be configured in such a way that the computer is given optimum protection against attacks. The computer must not be connected to the network until such time as it is appropriately configured.

A WWW server that offers information on the Internet should be installed in accordance with the following stipulations:

• Only a minimum of programs should be installed on a WWW server, i.e. the operating system should be reduced to those functionalities that are absolutely essential and otherwise, too, only programs that are really necessary should be installed on the WWW server (see S 4.95 Minimal operating system).

• In particular, a WWW server should not include any unnecessary network services; different services should be installed on different computers (see S 4.97 One service per server).

• Access to files or directories must be protected (see S 4.94 Protection of WWW files).

• Communication with the WWW server should be restricted to a minimum through the use of a packet filter (see S 4.98 ).

• Administration of the WWW server should always be performed via a secure connection; this means that administration should be performed directly on the console, with strong authentication (if access is from the LAN) or via an encrypted connection (if access is from the Internet).

• Furthermore, the WWW server should be secured from the Internet by a firewall proxy or at least by a packet filter (see S 4.98 ). This must not be located between the firewall and the internal network, because an error on the WWW server could otherwise allow access to internal data.

There are various possible methods of providing protection, depending on the type of WWW server. A common feature of all of these methods, however, is that only a restricted set of rights should be assigned to the WWW server's actual server process, namely the http daemon. Usually it must be started with root privileges, but after being started it should continue operating as quickly as possible with the rights of a less privileged new user. A separate user account, such as wwwserver, should be created for this purpose. It is important that this user should not have any rights to write to the log files. Otherwise an intruder could manipulate these files using the rights of the HTTP server by exploiting an error.

If an intruder does exploit a weak point in the http daemon, therefore, he will not have access to the operating system as such. If possible, the http daemon should be restricted to part of the file tree. Under Unix, this can be done with the chroot program, for example. Besides this, the cgi programs supplied with the system by the manufacturer should be entirely removed, because errors have repeatedly appeared in these programs in the past.

The directory in which the retrievable files are stored should be located on a separate partition of a hard disk so as to make it easier to restore it after a hard disk defect. Moreover, the subdirectories and files should belong to a specific user (for example wwwadmin) and be protected against unauthorised access by being given minimum access rights.

During configuration of an HTTP server, a number of options should be taken into account which are relevant to security. These include, for example:

• Listing directory contents

This option should be deactivated. If the complete contents of a directory are disclosed to the outside, it is often the case that too much information is divulged. This is dangerous in particular if the directory contains files whose existence is not supposed to be made known externally, i.e. password files, for example, or files that are not generally accessible. It is better to use index files in order to make the contents of directories known externally.

• Use of symbolic links

This option should be deactivated, because symbolic links can be used to gain access to files outside the approved Web directory. During the configuration of the server, the area which the server is allowed to access in order to disseminate files via HTTP is specified as the DocumentRoot. Files outside the DocumentRoot and the cgi-bin directory are not disseminated, even if the HTTP daemon possesses read rights.

If it is necessary to make the same document accessible via various URLs, it is more advisable to use the route via a Redirect in the .htaccess file.

• Anonymous use of the server

Even if user-defined access protection is set up on a WWW server, it is often also desirable to grant access to new, as yet unknown users, i.e. to new customers, for example. Provision can be made for anonymous access for this purpose. To gain access, a user can either not log in at all or log in with his or her e-mail address as the password. If this is wrongly configured, however, the entire contents of the server may be freely available as a result. This option should therefore be used with particular caution.

The following checklist is recommended:

1. Are only necessary components installed? It is advisable to compile the http daemon yourself; in that way, unnecessary functions will not be compiled in the first place.

2. Is the http daemon configured to be as restrictive as possible? Either cgi programs should be entirely disabled, therefore, or the cgi programs should be restricted to their own directory. File access by the http daemon should be limited to part of the directory tree. Separate, unprivileged user rights should be used for administration and operation of the server.

3. Have all superfluous cgi programs and WWW pages been deleted?

4. Is the HTTP port (usually port 80) the only accessible port on the computer (see S 4.97 One service per server)?

5. Is appropriate regular backing up of the stored data ensured (see Chapter 3.4 Data backup policy)?

6. If cgi programs are used, are these programmed sufficiently securely? It is not permitted to accept any input values unchecked. It must be ensured that buffer overflows and race conditions are ruled out. The taint check should be activated in all Perl scripts.

7. Is there a functioning routine for a regular integrity check (e.g. Tripwire; see S 4.93 Regular integrity checking)?

Example: Setting up a simple WWW server

On a WWW server of this type the contents of individual pages change only rarely; no cgi programs are used and there is no particular access protection. The individual WWW documents are loaded onto the WWW server via a data medium. On a server like this, all system files and also all HTML pages can be given write protection. Although an attacker is able to modify temporary files and log entries in a setup of this kind, he cannot make any changes to the system itself. Access protection in this form should be implemented by a physically write-protected medium, for example one or more CD-ROMs or a write-protected removable hard disk. At the very least, however, regular integrity checks should be performed (see S 4.93 ).

Functionalities in the http daemon that are not required should be deactivated, i.e. those such as the possibility of executing cgi scripts. Whatever the case, cgi programs supplied with the system should be removed.

In one frequently encountered variant of a simple Web server, the documents can be modified interactively on the WWW server with corresponding authorisations. In this case, protection against unauthorised changes and a regular integrity check at short intervals are especially important.