S 5.163 Restrictive granting of access rights on terminal servers

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

Within multi-user environments, e.g. terminal server systems, separating the users from each other and from risky system functions is of critical importance. In order to guarantee trouble-free operations and in order to protect the confidentiality of the data processed within individual user sessions, the rights must be granted restrictively.

For this, the terminal server service, e.g. in Microsoft Windows Server 2003, offers options for establishing diverse protective safeguards in the operating system during installation. These settings are also effective if Citrix Presentation Server is used as a terminal server solution.

The more secure basic installation must always be used as a starting point for further protective safeguards. It is selected by the Full-Security option instead of Relaxed-Security. Relaxed-Security must be viewed as compatibility mode in this context, allowing for operating applications which were not developed for current terminal server environments. However, using this mode results in security-critical file authorisations in system directories and wide-ranging access options to the registration database (Windows Registry).

Therefore, using the "Relaxed-Security" mode should only be considered in reasonable exceptional cases and upon an in-depth evaluation of the individual threat scenario. In any case, the rights for applications and their users must be reduced subsequently to the absolutely required extent. In this regard, diverse tools monitoring file operations of the software and logging accesses to the registration database may be used.

Furthermore, no additional applications should be provided on the same terminal server as the application requiring this insecure mode.

Applications on terminal servers may be used differently. Along with the access to a complete user interface (desktop) using terminal software, it is possible to transmit a list of authorised applications. In this case, the user may only use these applications within the terminal server client or on a web server.

This publication mechanism prevents accidental operation and facilitates the fulfilment of tasks for the users, but does not prevent deliberate accesses to programs outside of the approval list. For example, unauthorised applications may be executed without any further precautions using user dialogues in admissible applications.

In order to successfully protect terminal server systems, further items must therefore be taken into consideration. Terminal server systems must be installed on dedicated, possibly virtualised systems in order to limit the complexity of the system and data access options to other services. For example, it is necessary to grant the users of terminal servers in Microsoft Windows Server 2003 local login rights. If the terminal server is simultaneously also used as domain controller, this causes an extension of the users' rights to all administration servers, even those that are not terminal servers. Services installed in the default configuration, but not required, should be disabled as a consequence. This also applies to any existing routing functions.

Newly installed application servers must be updated to the respective latest software version prior to commissioning and it is strongly recommended to disconnect these from the network beforehand. Moreover, unneeded user accounts or groups must be removed or disabled.

Anti-virus products should be installed on all terminal server systems.

Applications with different levels of protection and security should be provided on different terminal servers. If this is not possible or impracticable for organisational reasons, all applications must be handled like the software with the highest protection requirements.

A file system differentiating access rights on a user level must be used, e. g.:

• Write and read accesses to unneeded files must be prevented (e.g. by simply deleting the obsolete file or by setting corresponding authorisations).
• If possible, no links should be used within the file system (e.g. symbolic links, NTFS joins, etc.).
• Administration tools must only be executed by authorised administrators.
• The authorisation to install software subsequently must only be granted to the administrators.
• In terminal server environments, the option of executing software in a third party user context, e.g. by commands such as "runas" or "sudo", should be disabled.
• Authorised programs should be maintained in a positive list, particularly on systems with high protection requirements. Then, the operating system will only execute software that is approved. For Windows operating systems, this may be implemented with Appsec, for example. For Linux, extensions such as SELinux and AppArmor may be used; and RBAC (Role based access control) and Privileges for Solaris systems. Furthermore, there are some further solutions from third party providers, some of which exceed the scope of functions of the operating system options.

Session mirroring, also referred to as shadowing, means to view a third party user session. The screen output of the user is displayed on one or several additional clients and the control of the input devices may be taken over. This procedure is predominantly used for training courses or for administration purposes. Sessions must not be mirrored without the acknowledgement or consent of the user. This must be enforced by administrative means in the configuration of the terminal server.

In order to protect downstream systems such as systems for data storage or additional processing systems, further safeguards focussing on the communication of the application with its backends must be implemented.

The application scenarios specialised applications and general applications are intended to illustrate this.

Figure: Separation of downstream services

Specialised applications

Specialised applications are defined as software without a freely configurable backend in this document.

The program may neither be used to communicate with a downstream system that is not provided for, nor is the user able to access a different inadmissible backend using an authorised service.

In this case, the methods already presented are sufficient to protect the environment.

An example includes an application which has access to a fixedly defined database. Moreover, the user does not have any possibility to enter the access parameters, except for the login data for the foreground application (frontend).

General applications

Here, non-specialised, i.e. general applications such as SQL consoles or browsers are significantly more security-critical. This is particularly applicable to terminal server environments, since the terminal servers must be granted access to all backends required due to the requirements of the users.

Operating such programs on separate terminal servers and isolating the servers against the prohibited background systems by means of individual demilitarised zones constitute one possible solution to this problem.

If the number of applications to be provided is very high, this approach very quickly becomes complex, confusing, and inefficient. Moreover, the advantages of a centralised architecture when compared to the classic client/server application quickly vanish.

Alternatively, a security gateway may possibly be used between the terminal server and the downstream services allowing for communication links on the basis of rules linking the user login, the application, and the backend.

The figure Separation of downstream services illustrates this approach. The user is only granted access to backend A and is denied access to backend B using the Prog-A program.

Review questions:

• Are the access rights of the users for resources of the terminal servers granted restrictively?
• Are the access rights of the users of terminal servers for downstream services (backends) granted restrictively?
• Is only one application provided on one terminal server for terminal servers operated in the insecure "Relaxed-Security" mode?
• Are terminal server services only installed on dedicated systems, which are virtualised if necessary?
• Have all services, user accounts, and groups on terminal servers installed in the default configuration, but not required been removed or disabled?
• Have anti-virus products been installed on all terminal server products?