S 4.360 Secure configuration of a web server

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

After a web server service has been installed on a web server, secure basic configuration must be established. For example, this concerns how additional modules can be integrated and how directories within and outside of the file system area containing the published information can be accessed, but also to settings influencing the performance of the server.

Assignment to an unprivileged user

When a web server application is started, it is normally provided with the same access rights as the user who started the application. For example, if an administrator authorised to read and write all information in the IT system's file system starts the application, the web server process is also granted read and write access to this information. Therefore, the web server process should be assigned to an unprivileged user account. The access rights in the file system of the IT system should be granted restrictively so that this user account and therefore the web server process is only allowed to access necessary information.

Nevertheless, the web server service must often be started as a privileged user ("root"). In this case, the process should be assigned to an unprivileged user subsequently, if possible. For example, it is possible to specify a user ID with the help of a user directive in the configuration file for the Apache web server causing the server process to be executed as unprivileged user.

Server directories

Depending on the web server application used, the file system paths the web server is granted access to must be specified. For example, these include the file system path for the directory containing the information the web server is to provide the clients with ("web root directory") and the path to the log files.

When defining the web root directory, it must be taken into consideration that the directory must only contain information to be made available to all potential users. The access range for users of the web servers should not be selected too generously. For example, users should not be granted any access to the root directory ("/") of a Unix system or the system partition of a Windows system. The directory containing the retrievable files should be stored on a separate partition or slice of a hard disk in order to make the recovery of the files easier after a hard disk failure.

The web server services should generally only be allowed to access information located within the web root directory. Any read and particularly write access to information outside of the web root directory should be prevented. Therefore, file system cross-references ("links") to areas outside of the web root directory should be avoided. If possible, the web server service should be configured in such a way that information outside of the web root directory may not be accessed, for example with the help of a limit section for the Apache server.

Write privileges

The process of the executed web server service should only have those rights necessary for operation. The data access rights of the web server process are normally derived from the data access rights of the user who started the web server process. Normally, a web server process does not require any write privileges for operating system directories and should therefore not be granted such privileges. If log files are transmitted to a dedicated logging server, no local write privileges are required in the file system of the IT system the web server was started on (exception: information must be buffered if the logging server is no longer available). All files that should not be changed any more, e.g. static HTML sites, should be equipped with write protection. If the web server service is able to automatically generate directory lists, this function should be disabled.

Restriction of the processes

A web server service should be operated in a restricted process environment, e.g. using "chroot" for Unix systems. A chroot environment is an isolated area within the computer system, like a so-called sandbox, which makes it more difficult for an attacker to gain data access to the entire system after having compromised the web server service. More detailed information regarding this can be found in S 4.198 Installation of an application in a chroot cage.

Information on the server

Standard error messages often entail the risk of disclosing too many details. Attackers often use the HTTP header lines of responses to requests or error messages in order to obtain information on the version of the server software used and other details. This information may possibly be used in order to select certain attack methods and to compromise the server quicker this way. Therefore, these "auxiliary channels" should provide as little information as possible by configuring error messages informing the users about the occurred error, but not disclosing any details.

Authentication

There are different options for configuring access restrictions on web servers or for individual areas of the website, some of which are already integrated in the web server service itself or which can be integrated with the help of extension modules. Often, access is controlled by restricting the access to certain IP address ranges or domains (in the intranet, for example) or by the users having to authenticate before being allowed to access certain resources, e.g. by entering a user name and a password (see also S 4.176 Selection of an authentication method for web offerings).

Depending on the users (e.g. only internal employees, customers, or users who must register first, but are otherwise unknown) who are allowed to access the web server and the protection requirements of the information provided, the access rights should be limited to a minimum. In general, the users should only be allowed to access the necessary information. Exceptions include public web servers, the web content of which is often accessible to all interested users such as a public web server on the internet, for example.

Encryption of the data transmission

Normally, the information is transmitted using HTTP between a web server service and the clients. HTTP is a plain text protocol where all transmitted data such as passwords and web content may be read by a potential attacker. Therefore, it is strongly recommended to protect the integrity and confidentiality of sensitive information between web server service and client, e.g. by using encryption protocols such as Transport Layer Security (TLS) or Secure Sockets Layer (SSL). More detailed information can be found in S 5.66 Use of TLS/SSL.

Administration

Web server services are often administrated with the help of configuration files or graphical interfaces, locally or using a network connection. If the IT system containing the web server service is administrated using a network connection, the network access and the exchange of information between the web server and the IT system the web server is administrated from must be protected. This includes restricting administration access, for example, by having packet filters reject all connection requests, except for those coming from defined IT systems of the administrators, to the port number of the remote administration service (see S 4.238 Use of local packet filters). In order to prevent the exchange of information from being intercepted or modified, it must be encrypted, for example, using SSH (see S 5.64 Secure Shell).

If applications of web interfaces facilitating the configuration are used, these must also be protected against being accessed by unauthorised persons.

Disabling unneeded services

The default installation of a web server service may comprise a host of network services not always required that may constitute a source of security gaps for this very reason. An example includes a web interface for web server configuration that is not needed if the web server service is configured using different mechanisms. Therefore, it should be checked which network services are installed and enabled on the IT system containing the web server service. Unneeded network services should be disabled or uninstalled entirely.

Restricting the connectivity

Although web servers are normally IT systems accessed by a large number of users, the communication should be allowed as restrictively as possible nevertheless. If network services only to be used by selected IT systems with fixed IP address ranges are operated on the server, it is recommendable to restrict the access to certain IP addresses with the help of packet filters. In general, any access to administration accesses should be restricted to the IT systems of the administrators with the help of packet filters. If databases or application servers are used, this communication must be restricted as well. More detailed information about packet filters can be found in S 4.98 Restricting communication to a minimum with packet filters and S 4.238 Use of local packet filters.

If only internal employees are allowed to use the web servers, the web servers should be operated in a network segment that is only accessible from the LAN. If external and/or third party users are to be allowed to retrieve information from the web server as well, it is recommendable to operate the web server in a demilitarised zone.

Logging

Accesses to the web server service and the IT system the web server service is installed on should be logged to the extent required in order to be able to promptly detect and possibly trace attacks, attempted attacks, and security violations. Therefore, it must be decided which information is to be logged, how and when the logged data is to be evaluated, and when the logged data must be deleted. The web server service and the IT system must be configured accordingly. Personal data must only be logged to the extent admissible in accordance with the applicable legislation. Therefore, the Data Protection Officer should be involved in order to clarify the general conditions.

Deletion of exemplary documents

The installation of web servers often also includes installation of exemplary documents. For example, the administrator is able to access a web server using a browser directly upon completion of the installation procedure without having created his/her own web content before. If an existing exemplary index file is displayed, the administrator may see at one glance whether or not the web server has been installed properly. An exemplary index file also often contains information on the web server used, the version number, for example.

There often also are server-side programs (CGI, Perl, or PHP scripts) that are also installed. When the administrator activates the corresponding modules allowing for these scripts to be executed, it can be checked directly whether or not the module works immaculately.

All exemplary documents and scripts should be deleted upon installation.

Expansion with modules

The scope of functions of some web server services can be expanded by so-called modules. Functions not designed by the developers of the web server services can be added subsequently this way. For example, expansion modules can be used to directly execute applications on the web server and so generate site content dynamically. Examples include PHP and Perl, where the applications are not executed on the client of the user, as opposed to "active content" (see also S 5.69 Protection against active content).

If the functionality of the web server service is expanded with the help of modules, these must meet the same requirements as the web server service itself. Furthermore, modules must be selected according to the minimum principle. Modules installed by the web server as examples that are not needed should be deleted.

Both web server services and the modules are normally subject to continuous further development and published as stand-alone versions. A version of a module, which ran without any errors on a given version of a web server service may cause problems when running on a successor version of the web server service. Even a more up-to-date version of a module may react differently when compared to an older version on a web server service. Therefore, the specific version of the module must be tested in addition to the version of the server service to be used.

For some web server services, there are specific security frameworks (e.g. mod_security for Apache) that can be used to implement different security functions, for example, to filter input. Some individual security functions can also be implemented with other expansions for web server services. For example, the mod_rewrite module can be used to forward and thus filter requests based on rules. It must be decided whether and which security frameworks are to be used.

Active content

Interactive features in web offers may also be implemented by active content executed on the client system. As far as possible, these features should be provided with dynamic or static content.

The different technologies summarised by the generic term "active content" differ in the way they are integrated into an HTML site, amongst other things. Code of script languages such as JavaScript, JScript, or VBScript is integrated directly into the HTML code in text format or stored to a file retrieved from the HTML code. As another alternative, executable code can be integrated into an HTML site by being referenced in the HTML code and retrieved using pre-compiled program modules such as Java applets or Active-X-Controls.

A new technology in the field of active content is called AJAX (Asynchronous JavaScript and XML), which is based on JavaScript and XML. Often, flash is also classed among active content, since the scope of functions of flash in the later versions exceeds the representation of pure animations, which is why it must no longer only be considered to be a plug-in.

Due to the fact that "third party" code is executed on the client system, active content entails a host of security problems. Browser manufacturers and plug-in providers are trying to limit these problems with the help of measures such as restricted rights for Java applets, Active-X-Controls, or other plug-ins, but basic threats in the context of active content are currently amongst the ones most frequently encountered. A website provider should take into consideration these basic threats when using active content in his/her site.

Operating system

A secure configuration of the operating system the web server service was installed on is a basic requirement for being able to provide information on web servers in a secure manner. As a matter of principle, only those services and applications actually required for operations should be installed on an IT system. This means that numerous unneeded applications (such as compilers or editors, for example) should be deleted. From the outside, only those services absolutely required for operations should be visible (see S 5.95 Secure e-commerce using Internet PCs).

In order to disclose as little information about the operating system and the services contained on it as possible, banner spoofing may be used. With this, the services operated on the servers do not return their proper program name and version number, but substitute these with incorrect information. This makes it more difficult for an attacker to draw conclusions about the programs actually used by the system. All default user accounts must also be removed and/or renamed. An example includes the guest account often present in Windows operating systems. Privileged user accounts such as "Administrator" or "root" should be disabled and individual users with the corresponding administrative privileges should be created instead.

Review questions:

© Federal Office for Information Security. All rights reserved.