S 4.239 Secure operation of a server

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

The secure operation of a server depends on a number of factors. It is especially important that the administration of the server is performed with great care via secure access.

In the following, several general points that should be observed to securely operate a server are described. More specific information for individual operating systems is given in the corresponding safeguards of the applicable modules.

Administration accesses

There are different ways to access the server for administration purposes. Depending on the type of access used, a number of security precautions must be taken. With larger networks it is recommended to integrate the servers as well in a central network management system, because otherwise secure and efficient administration can hardly be ensured. The methods applied for administration should be specified in the security policy, and administration may only be performed in accordance with the security policy.

In general, it is crucial to gain an overview of which part of the administration of a server should normally be performed

• Locally via the console
• Remotely via the network, but using the default mechanisms of the operating system
• Via a central network-based administration tool.

It is advisable to draw up an overview of which administration tasks can be performed in which way for the different types of usage. It is especially important to lay down whether certain tasks must normally not be performed in a certain manner.

• Local administration
  
  On principle, a server should be set up in a server room or at least in a lockable server cabinet. For the part of the administration that still has to be performed locally via the console, appropriate specifications must be made as to who has access to the console, which type of authentication may be used for local access and which other specifications must be taken into consideration.

• Remote administration
  
  A server is usually not administrated locally at the console but from a workstation via the network. To prevent authentication information of the administrators or configuration data of the server from being intercepted or even manipulated by an attacker, administration should only be performed via secure protocols (e.g. not via Telnet, but via SSH; not via HTTP, but via HTTPS). As an alternative, an individual administration network can be set up that is separated from the rest of the network.
  
  Unprotected remote administration via external (unprotected) networks must never be performed. This must be taken into consideration when defining the security policy. No insecure protocols should be used in the internal network either.
• Administration via a central management system
  
  If a central management system is to be used to administrate the server, analogous considerations to those for remote administration should be made in regard to this access channel. First, it is important that the central management system itself is securely configured and administrated. You can find information on this in module S 4.2 Network and system management.

Routine administrative activities

It is advisable to draw up notes on the administrators' usual routine activities in accordance with the security policy for the server. This includes activities such as:

• creating and deleting users,
• installing and uninstalling programs,
• installing security updates and patches (see also S 2.273 Prompt installation of security-relevant patches and updates),
• installing other updates and patches,
• regular checks of the operating state of the system (e.g. load of the system, remaining free hard disk space),
• checking log data for unusual entries (see also S 5.9 Logging on the server),
• regular integrity checks using appropriate tools (see also S 4.93 Regular integrity checking and S 5.8 Regular security checks of the network).

Testing configuration changes

Various server programs provide the option of checking configuration changes at least in regard to their technological correctness before they take effect. This helps to avoid a server program not starting after an erroneous configuration change, thus leading to the loss of the service it offers. If such possibilities are available, administrators should be familiar with how to use them and also actually make use of them.

Documentation of work performed on the system

Changes to the system configuration or to the configuration of server programs must be documented. The documentation must be drawn up in such a manner that, if problems occur, the last change can be traced, as well as when it was and by whom it was made. It is important in this context that the documentation can not only be understood by the administrators, but also by an "expert third party", who has nothing to do with the daily operation of the system in question. The documentation should also allow the reproduction of an earlier configuration.

Auditing management systems suggest themselves for changes made to text-based configuration files. In addition, short comments on the effects of the new configurations and on the way they function should be directly added to the configuration files. There are similar tools for other configuration mechanisms, and the software in question often already provides corresponding functionalities by default. If a central administration system is used, the relevant functions should be available and also be used.

Review questions:

• Do the accesses (local access via the console, remote access via the network, access via a central management system) for administrative activities on the IT systems conform to the security policy?
• Do the protocols and paths of administration accesses used conform to the current state of the art in technology?