S 5.164 Secure use of a terminal server from a remote network

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

If the terminal server and their clients connect using an insecure network, effective protection of the network gateways by means of security gateways must be ensured above all. In addition, precautions must be taken to ensure that communication cannot be listened in on, modified or impaired. The following procedures depend on the selection of the types of connection differentiated below.

Several terminal server systems offer protocol-internal encryption. In the default configuration, this encryption, however, is usually designed for the requirements in local networks. Therefore, short key lengths that could be sufficient for a controllable network are generally preset as default settings. In many cases, the bidirectional encryption between terminal and terminal server is also dispensed with in favour of a resource-efficient connection. Only the user input, but not the screen output returned by the server, is then encrypted in this case. Furthermore, it is possible to embed additional data streams (virtual channels), for example, for the connection of local data media, interfaces or printers of the client, in unencrypted form within the log.

To protect communication via an insecure network, it must be checked in advance which cryptographic procedures and key lengths can be used in the configuration to be operated and to which communication elements encryption is applied. Secure communication can only be guaranteed if the entire data stream including authentication is protected in both the direction of the sender and the direction of the recipient. In this respect, suitable procedures of protocol-internal encryption currently use Secure Socket Layer (SSL) or Transport Layer Security (TLS) with a key length of at least 128 bits.

In the examination, both the settings of the server and those of the client must be included. Here, the settings of the server and those of the client must match to administratively force a connection being established in a secure manner.

If, as in the case of the X-Window system, there are no protocol-internal encryption mechanisms available, the connection can also be protected by means of a cryptographically secured tunnel. For the X-Window system, the X11-Forwarding method by means of the Secure Shell (S 5.64 Secure Shell) has established itself. Moreover, NX is a modified alternative to the X11 protocol which allows secure authentication and encrypted transport of terminal server sessions using X-Window, RDP and VNC.

In order to protect terminal server sessions, it is also possible to use a virtual private network (VPN) (see also S 4.4 VPN). The advantage of this approach is the automatic encapsulation of all elements of the data stream by the VPN. Here, it is not necessary to analyse the security of the terminal server log further, since secure login and encryption is ensured by the VPN.

When using a VPN, however, it must be taken into consideration that access of the remote client can also extend to other services than that of the terminal server. In addition, protocol-internal procedures are optimised to the technical particularities of the respective terminal server environment and can thus use the available bandwidth more efficiently than virtual private networks.

Beyond the protection of the perimeter and the transmission route, the respective client systems must be taken into consideration. In particular, access using computers in public areas, such as internet cafés, is a high security risk, since information such as the user name and the password might be read by third parties. It is also difficult to control mobile IT systems and stationary telecommuter workplaces. They might deviate from their originally authorised software version.

Therefore, particularly high requirements must be placed on the login process if access using insecure clients is to be permitted. In this scenario, at least two-factor authentication could thus be used. Here, an identifier (ID) that is only valid once, also referred to as one-time password (OTP), for example, is required during the authorisation process in addition to user name and password. This ID can be generated using a mobile device (token). In this case, possessing the device and knowing the user name and password are complementary security features counteracting the misuse of an overseen user login. Especially if services of the terminal server can be accessed using portal solutions, such as the web interface via the Internet, two-factor authentication in should be considered.

Moreover, it makes sense to introduce different levels in the authorisation concept for accessing different possible information channels, depending on the security of the client. IT systems accessible to the public should be refused the exchange of files between terminal server and terminal as well as access to interfaces. In addition, the users should not be allowed to transfer contents of the clipboard of the server to the client.

Various terminal server solutions offer an analysis of the client during the login process. Here, the hardware and software versions as well as the currency of the virus protection are queried and compared to the policies stored. In this manner, it is possible to differentiate between secure and insecure clients by means of a technical safeguard.

Review questions:

© Federal Office for Information Security. All rights reserved.