Network Access Control

Now that we have taken a closer look at connection options and Terminal Services clients , let us focus on the network connection itself. What are the basic options for making the data transfer via RDP even more secure than with internal encryption alone?

Firewalls

A common means of controlling terminal server access is through a firewall ”for example, Microsoft Internet Security and Acceleration Server (ISA Server). A firewall controls data traffic between computers in an unsafe zone and in a target system, and it defines source IP addresses, source ports, target IP addresses, and target ports. These are used to establish filter rules that control data traffic. If, for instance, you want to make a terminal server available from the Internet without exposing the terminal server to direct accesses , the firewall could be set up in the following configuration:

• Source IP address: All (that is, each IP address)

• Source port: All ports above 1024

• Target IP address: IP address of the terminal server

• Target port: 3389, the RDP port

When a terminal server session is established, the client uses any local port over 1024. The client uses that port and the target IP address to connect to the target port (3389). All other ports in the direction of the terminal server should be blocked to avoid attacks on the ports of other services. On Windows Server 2003 with Terminal Services activated in application mode, there are fewer ports than on any of its predecessors, which reduces the risk significantly. However, external communication should be allowed only through that one channel.

Nevertheless, a firewall does not provide complete protection! It only reduces the scope for attack. If a Windows service on a terminal server has a weakness, it could still be exploited despite the firewall. To avoid this effectively, additional authentication on the firewall can be required from the user attempting access ”for example, by using RSA SecurID. Only after successful authentication does the port open up for a user session to be established. This gives the terminal server much more protection because it is invisible to anonymous users on the Internet. The terminal server is thus no longer a direct target for attack. Regrettably, this method is not suitable for all application scenarios.

Virtual Private Networks

An advanced method of protecting terminal servers is to use a virtual private network (VPN). A VPN is the extension of a private network into the normally unsafe public network connections or the Internet. However, data can be exchanged between computers via the public network or the Internet if a virtual, secured point- to-point connection is established. This secure connection is also called a tunnel .

There are several solutions for VPNs, either hardware-based (for example, by Cisco or Nokia) or software-based (for example, Smartgate by V-One or mVPN by PortWise). Hardware-based VPNs often work with firewalls; they require a special software to be installed on the local client. Software-based VPNs normally use port 443 (HTTPS). This port is open under most firewalls because it is needed for access to secure pages on the Web.

The following two examples describe possible scenarios where VPNs are used with terminal servers.

Hardware-Based VPNs

In this scenario, the terminal server is behind a firewall. If a user wants to connect to the server, he or she needs to pass through authentication at the VPN server (firewall) first. The software installed on the client connects to the firewall and in this way constructs a tunnel that is strictly limited to the client session. The data stream in the tunnel is often encrypted as well. Depending on the VPN server settings, the user might have access to the entire internal network or only to certain IP addresses and services. Terminal server access is transparent. Users do not notice that the server is not physically part of the local network.

Software-based VPNs

In this scenario, the terminal server and VPN server are behind a firewall. If an external client user wants to access the internal network with the terminal server, the user logs on to, for instance, a Web server with the relevant user name /password, smart card, or another authentication method. If the attempt is successful, tunnel software is downloaded in the form of an ActiveX control or Java applet and is locally installed on the client. The tunnel software then uses port 443 (HTTPS) to connect to the VPN server through the firewall, thereby establishing an encrypted tunnel.

The tunnel software modifies the communication path so that the Terminal Services client no longer communicates directly with the terminal server, but with the local tunnel software. The tunnel software packs the data stream in a HTTPS tunnel and directs it to the VPN server. The VPN server unpacks the data stream and establishes a connection to the terminal server. In this way, communication takes place through several stations . This method prevents direct terminal server access and guarantees that the identity of the user session remains the same. One possible bottleneck is the VPN server, specifically when it needs to manage all tunnels for many simultaneous user sessions.

Software-based solutions can usually be fine- tuned in terms of configuration and integrated into existing directory services. Depending on the user role, target systems can be allowed or blocked at the server, services, or user levels. As the tunnel software can be installed on the client later, this solution is universally applicable . For example, it is possible to access applications on the corporate network from an Internet caf or Internet terminal at the airport, even though the target device does not usually allow installation of a VPN client.

Important  

When looking at a VPN in detail, do not forget that secure communication requires a secure client. Software and hardware can be installed on a terminal in an Internet caf that logs user entries (such as keyboard key strokes or mouse moves). No VPN concept can protect these logs from unauthorized evaluation.

Public Key Infrastructure

A public key infrastructure (PKI) comprises the policies, standards, and software relating to certificates, and public and private keys. It includes a system of digital X.509 certificates, certification authorities, and other registration authorities that verify and confirm the validity of individual origin and destination points during an electronic transaction. If required, the Windows Server 2003 certification services and certification management tools can provide an independent public key infrastructure. This would be the basis for logon using smart cards, client authentication via Secure Socket Layer (SSL), or Internet Protocol Security (IPSec).

Smart Cards

Windows Server 2003 makes it possible to log on to a terminal server session using a smart card. Two conditions must apply: The client must recognize the smart card (Windows XP, Windows 2000, and Windows CE .NET), and smart card logon must be enabled on the server. All this requires a public key infrastructure, either by Microsoft or a third party.

For a third-party PKI, it is advisable to verify that the relevant root certificates are known in the Active Directory. A Microsoft CA (Certificate Authority) is already integrated in the Active Directory and does not require this verification. However, it is still necessary to integrate the relevant certificate templates for smart card logon into the certification point so that valid certificates can be generated for smart cards.

Secure Socket Layer

Secure Socket Layer (SSL) is a suggested and open standard for setting up a secure communication channel that aims to prevent unauthorized persons from intercepting critical information. This service is particularly suitable for transactions on the Web, but it can be used for other services as well. An X.509 certificate forms the basis for the transmission of user, device, or service identity. The public key for encryption of the data transmitted is linked to that certificate. The integrated encryption of the RDP protocol is very similar to the SSL concepts.

IPSec

Another option for defending your system against network attacks is Internet Protocol Security (IPSec). IPSec protects the contents of IP packages through encryption, package filtering, and enforcing trusted communication. All this is achieved through encryption technologies that are based on security services, security protocols, and dynamic administration of public and private keys. IPSec implementation comes with Windows 2000, Windows XP, and the Windows Server 2003 product family, based on established standards. IPSec is integrated through certification services and the Active Directory, and it uses Kerberos V5 for mutual authentication of the computers involved.

Note  

If the IPSec data traffic is directed through a firewall, you might need to perform additional configuration tasks .

In addition to encrypting and generating checksums, IPSec offers several filters that are relevant to Terminal Services. These filters serve to control data traffic ”for example, allowing only certain IP addresses or subnets to communicate with the server. Furthermore, you can determine ports for exclusive server communication. In this way, you can define rules that allow communication with the server only from a certain subnet via port 3389. This could be useful for remote server administration using Terminal Services. It is, of course, also possible to determine dedicated clients that access a terminal server running in application mode. If the clients are set up in a certain subnet and if communication with the terminal server is allowed from there only, illegal client connections are almost impossible .

IPSec is an excellent alternative to the integrated encryption of the RDP protocol. RDP encryption uses an RC4 library by RSA. This library is based on the Secure Socket Layer concepts, but it is not an official industry standard. IPSec, on the other hand, is used in many companies and is often a preferred corporate solution because it is an industry standard.