S 4.432 Secure configuration of server applications

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

Upon installation and configuration of the server's operating system (see S 2.318 Secure installation of an IT system), the actual server service must be configured. Server services are executed processes providing the clients with certain functions. Examples include web, email, and directory services.

Server services can be divided into two different categories. Server services of the first category provide their function for free in the network without requiring any user authentication. Examples include DNS, DHCP, or NTP servers. The second category, on the other hand, requires user authentication before the service can be used, e.g. in order to protect confidential information against unauthorised access. Examples include file, email, SSH, or RDP servers. Whether and which type of authentication is required for using a server service depends on the type of service, the configuration of the respective service, and the protection requirements of the data.

As a matter of principle, all existing, but not required server services should be uninstalled; the server should only provide the absolutely necessary services. Along with the actual server service, a server service for administration on the IT system is usually required in addition. More detailed information on this can be found in S 4.97 One service per server.

Before the new server service is installed, e.g. from packet administration or other sources, its documentation should be examined if this has not already been done In this connection, it should be determined, amongst other things, which files are required for operating the service and which processes are started. Only then, the process of configuring the actual server service should be started.

Restrictive granting of rights

For a server to be able to provide the clients with certain information or functions, the server service normally requires a good deal of information that must be stored in the file system of the server. This includes:

The rights to this information must be granted as restrictively as possible. Only processes and users requiring access to this information should be able to actually access it. Data access should be restricted to the minimum. In order to grant the data access rights to numerous users in a resource-conserving way, it is recommendable to establish groups or roles. However, rights may also be granted to individual user accounts or based on pre-defined IP addresses or address ranges for authentication.

For a server service to be able to offer functions, a process must be started that is allowed to access the required information and other resources. The data access rights of the process are normally derived from the data access rights of the user who started the process. Normally, a process does not require any write permission for operating system directories and should therefore not be granted such permission. However, it is often the case that a privileged user with write permission must start the process in operating system directories in order to open TCP or UDP ports, for example. If possible, it must be ensured in this case that the process is transferred to an unprivileged user upon start.

If only a privileged user is allowed to start the process and therefore the server service, the process should be "locked" in a chroot environment, sandbox, or similar environment. A chroot environment is an isolated area within the computer system making it more difficult for an attacker to gain data access to the entire system after having compromised the server service. However, a chroot environment requires all files required by the server service to also be stored to the directory of the server service and therefore to the isolated area. More detailed information regarding this can be found in S 4.198 Installation of an application in a chroot cage.

Dependencies on libraries, operating system retrievals, external resources

The installation packs for server services contain a host of files copied to the target system during installation. Furthermore, further files are often normally required in order to be able to execute the server service. For example, this includes applications and libraries of third party developers or from the operating system. Although whether all required files are present is generally checked automatically while the server being installed, it should additionally be checked manually in advance whether these are actually present.

For example, if an existing server service is replaced by a more up-to-date version, it must be ensured that all files required in order to use this service are still present. As a consequence of an update, the server service may also require data access to additional files that were not required before the update. An update may also result in later versions of a library being absolutely required. In general, not only the server service, but also all related applications and libraries should be updated in the course of an update. For example, if the server service uses a library known to be characterised by weaknesses, the server service may also be susceptible to attacks.

Operating system retrievals by the server service should be avoided whenever possible. If these are required, it must be ensured that no compromising statements are executed on the server due to command injection attacks, for example. These statements should be filtered as restrictively as possible.

Server services are often not self-contained, but depend on external resources. These include, for example:

In the event of a failure of such server services or the connection to such services, the server service accessing them may also fail. It may be required to provide a redundant connection or to redundantly design the downstream server services, particularly in the event of higher protection requirements in the field of availability.

Availability restrictions

Many server services providing information in a network may be configured in such a way that they only eavesdrop at one or a few network interfaces and/or that they are "bound" to these. Network interfaces may include physical network cards or logical links such as virtual network cards or loop-back interfaces. If an IT system has several interfaces and if the network server service is only connected to one interface, the network server service does not accept any connection requests to another network interface, unless port forwarding or similar is performed. This way, the access to network server services can be restricted in such a way that only users from certain areas of the network are granted access. Therefore, a network server service should be bound to as low a number of network interfaces as possible. If a network server service is to be used within the local IT system, this service must only be bound to the loop-back interface. Examples for local network services may include super (such as inetd), X, printing, and time servers.

Access to a network service may also be restricted with the help of packet filters. In general, only authorised IT systems should be able to access a network service. If the IT system the network service is operated on is only allowed to accept connection requests from certain IT systems using specified port numbers, the connection establishment can be regulated using packet filters. For example, access to a backend server can be restricted using packet filters in such a way that only the related application server may access it. Normally, packet filters can be configured in such a way that they log all or selected connection requests. More detailed information on packet filters can be found in S 2.74 Selection of a suitable packet filter and S 4.98 Restricting communication to a minimum with packet filters.

Encryption of the authentication and user data

Depending on the server service and the provided resources, the differentiation as to whether this should be made available to all users or only a selected group of users can be made. Depending on the protection requirements, authentication procedures appropriate for this must be selected. Typical authentication procedures include (forgeable) IP addresses, user name and password, or certificates, amongst other things. In general, all information required for authentication to the server service should be transmitted in an encrypted manner.

If user data is transmitted using insecure networks, it should be checked whether this data should also be transmitted in an encrypted manner. Normally, DNS, routing, or NTP information is not encrypted during transmission, for example; HTTP or IMAP/POP3 information, on the other hand, is often encrypted in order to protect its confidentiality. Therefore, it must be decided which user data is to be encrypted. In general, it is recommendable to encrypt whenever possible, because the time required is only insignificantly higher.

More detailed information on encryption can be found in the safeguard S 5.68 Use of encryption procedures for network communications, amongst others

Restriction of version information

Standard error messages often entail the risk of disclosing too many details. For example, an attacker may use disclosed version information in order to search for server services with weaknesses and exploit these weaknesses.

For this reason, all system messages should be configured in such a way that they do not allow for any conclusions regarding the used software version or configuration, if possible. Self-created error messages should also inform the users about occurred errors, but not disclose any details.

Data backups

All information required for data recovery must be backed up at regular intervals so that the server service can be re-commissioned promptly in the event of a hardware fault or if control data has been deleted accidentally, for example. This includes, at least:

For many types of server services, the availability of the user data plays a special role. For file, email, or web servers, this includes information that, unlike configuration files, cannot be easily recovered.

For some server services, it is not sufficient to only copy the files to be backed up. Particularly if the information to be backed up is stored in databases, alternative backup procedures must be used. An example includes TDB files in Samba, the contents of which are often cached by the server services for extended periods of time and not always updated on the hard disk during operation (see also S 6.135 Regular backup of important system components of a Samba server). Therefore, the documentation of the server service must be consolidated for proper data backup.

Updates

The server service used should always be up to date. If weaknesses of the software used were discovered and if these were eliminated by means of a later version, switchover to an errorless version should be performed promptly. Before a new version is rolled out, it should be tested. Not only the actual server service, but also downstream server services, the operating system, and any other installed applications should be updated regularly. More detailed information can be found in S 2.273 Prompt installation of security-relevant patches and updates.

Logs

Security-relevant activities on server services should be logged for many reasons. On the one hand, when logging is activated it can be used for early detection and elimination of potential weaknesses. On the other hand, logging can be used to promptly detect violations against security specifications or to obtain more information about a security incident.

Logging of the server service should be integrated into the logging concept (see S 2.500 Logging IT systems).

Depending on the server service, at least the following events should be logged:

Review questions:

© Federal Office for Information Security. All rights reserved.