Network Security

Any traffic that crosses a computer network is susceptible to being captured and viewed by unauthorized individuals. Because of this danger, the networks must be secured in one of two ways:

• Protect the physical network connections so that no one can access the network to compromise the data.

• Protect the logical data on the network so that if the data is compromised it is meaningless to the person who found it.

Protecting physical connections is not practical in today's world, especially over the Internet. When addressing network security, most people focus on protecting the data that crosses the network. The common approach is "I don't care if you actually capture my data, because if you do, it will be totally meaningless to you." The networks over which Terminal Server traffic flows are no different from other computer networks. To secure your Terminal Server network, you need to look at two components:

• Network data security (Encryption).

• Network perimeter security (Firewalls).

Let's begin by examining your Terminal Server network's data security.

Terminal Server Network Data Security / Encryption

In Terminal Server environments, there are multiple types of network communications that need to be secured. Figure 12.7 shows all of the various network communications that take place in a standard Terminal Server environment. As you can see when using Terminal Server, users are not just accessing resources on that server. Users will have to authenticate, access file and print resources and any other backend servers (such as Exchange, SQL, Oracle, etc) for application data. As we analyze the security of a Terminal Server network environment, keep in mind that more is involved than securing data between the client and the server.

Figure 12.7: Terminal Server network segments

As you can see in Figure 12.7, the front-end communication includes all of the traffic that travels between client devices and the Terminal server, and the back-end communication includes all of the network traffic that travels between the various server components. Let's analyze the security needs of each of these network communication links, starting with the front-end.

Segment 1. Client Device to Terminal Server

In many scenarios, RDP session communication will travel across both trusted (or internal) networks and untrusted (public) networks. When addressing the security of this RDP communication, you must look at two components: session creation and session use.

• Session creation When an RDP session is created, the user credentials are passed from the client device to the Terminal Server. This action poses a security risk because stolen user credentials could be used to invoke pirated sessions. Even worse, because many companies are consolidating their user directories, stolen user credentials from a session could most likely be used to access email or other network resources.

• Session use While an RDP session is in use, a packet sniffer could be used to capture the RDP session packets. Because these packets contain all the keystrokes that a user types, anything that the user types could be compromised, including passwords.

Incidentally, you'll notice that during an RDP session, we're only really worried about the keystrokes, not the screen display data. It is highly unlikely that an attacker could capture the screen shot information from RDP session packets. Screen shot captures would require that the attacker crack the binary RDP protocol. Of course, there are many hacker websites with dedicated sections for Terminal Server, so this risk could change in future.

Either way, RDP session traffic must be protected. As with any other type of traffic, the most effective way to accomplish this is with encryption. Encrypting RDP traffic does not make it any harder for an attacker to obtain, but it does render the data unreadable to an attacker. There are two methods by which to encrypt RDP session traffic:

• Create an encrypted tunnel (VPN) between the end user and the server, through which RDP session data flows.

• Encrypt only the RDP traffic with the standard Microsoft encryption.

Segment 1 Method 1. Encrypt RDP Traffic with a VPN Tunnel

Virtual Private Networking (VPN) software can be used to create a secure, encrypted "tunnel" from the client device to the Terminal Servers. In these scenarios, each user has VPN client software installed locally on his client machine. This software utilizes the user's local ISP and the Internet to connect to the corporate office. Once this secure connection is established, a private tunnel is created connecting the local user to the corporate network. The local user can access the corporate network as if he were attached to the network locally. In actuality, the VPN software on the user's client device connects to the VPN software at the corporate office via the Internet. All traffic that flows back and forth is encrypted by the VPN software. Through this VPN tunnel, the user can launch Terminal Server sessions. The RDP protocol itself is not encrypted directly; rather, it is encrypted by the VPN software automatically.

Figure 12.8: An RDP session encrypted via a VPN tunnel

Many companies choose to use VPNs for their users to access Terminal Server applications from remote locations. In most instances, VPN access to Terminal Server applications is chosen because the company already has an existing VPN solution in place for remote access to other applications. They can easily extend their existing VPN environment to support RDP session traffic from remote users.

The major downfall to using these types of VPNs is that the VPN client software must be installed on every single client device. The degree to which this affects a user depends on the VPN software being used. For example, Microsoft's Internet Security & Acceleration Server product offers VPN capabilities, and the client software for it is built in to every version of Windows since Windows 2000. However, other vendors' VPN client software may have to be downloaded to each client device before it can be used, and this can pose a problem on a guest computer.

Imagine you were at a friend's house when your pager went off, notifying you that there was an urgent work-related matter that needed to be addressed immediately. Fortunately for you, your company built Terminal Servers that will allow you to connect from home. You can go to your friend's PC, log on to the Internet, and begin accessing your Terminal Server hosted applications. But, because your company chose to secure their servers with a VPN, before you can connect you must first go to your company's intranet site to download and install the VPN software. Only after this is configured are you able to access your applications. When you are done, you uninstall the VPN software from your friend's computer.

Advantages of Using VPN Tunnels

• All traffic is encrypted.

• Users are not limited to accessing only Terminal Server applications.

• If the VPN is already in place, it can be easily extended to support Terminal Server.

Disadvantages of Using VPN Tunnels

• VPN software must be installed on every client device.

• VPN software must be configured before it can be used.

• Some clients are not compatible with VPN software.

• Many corporate firewalls block VPN traffic.

• The VPN software costs money, and may be very expensive.

• Some bandwidth is wasted by the VPN tunnel overhead.

Ultimately, VPNs are a good solution if you have users that will use the same computer over and over to remotely connect to your Terminal Servers. VPNs are a not good solution if remote users will need to connect from many different random computers.

Segment 1 Method 2. Encrypt RDP Traffic with Microsoft Encryption

Instead of encrypting the entire network stream between the client and server with a VPN solution, it's possible to encrypt just the RDP session traffic itself, as shown in Figure 12.9.

Figure 12.9: Encrypting the RDP session

One method that can be used to encrypt RDP traffic is Microsoft's native RDP encryption. Unlike other products, Microsoft's RDP session encryption is driven by the server's connection settings and not by the client. Microsoft currently has four different configurations available for the connection level. The four options listed below are found on the general tab of the RDP connection properties pages:

• Low: This setting encrypts data using 56-bit encryption. It secures data sent from the client to the servers (the keystrokes) but does not encrypt data that is sent from the server to the client. This option would only be used to secure credentials and other keystroke-type information on an intranet environment.

• Client Compatible This setting configures the client-to-server communication at the maximum key strength that the client supports. The latest RDP clients support 128-bit encryption. This option is useful if you want to use strong encryption without locking out users connecting with earlier versions of the RDP client.

• FIPS Compliant: This setting encrypts data traveling from client to server and from server to client with the Federal Information Processing Standard (FIPS) encryption algorithms by using the Microsoft cryptographic modules. Only RDC clients version 5.2 and higher can use this encryption setting. If configured at the minimum encryption level for a connection, older client connections will be denied.

• High: This level is the default used by Windows Server 2003 server. It encrypts the data in both directions (like FIPS) using a 128-bit key. It should only be used when the environment contains 128-bit clients only, since it will also deny connections to clients that don't meet the standard.

Since session encryption is configured at the connection level, people often wonder how the client knows which encryption type is being used.

The encryption level of the RDP session is negotiated when a connection is established. When the server is configured for a certain encryption level, it first determines if the connecting client supports this level. If so, a simple key negotiation takes place and the session is established via an encrypted pipe. If a user attempts to connect to a server with a level of encryption not supported by the client, the client connection is refused (Service Pack 1 for Windows 2003 changes this encrypted session negotiation. See www.brianmadden.com for details.).

The entire encryption process is transparent to the user. It does not add any overhead to the RDP network traffic, although it does add a touch of overhead to the server and client processor utilization as they encrypt and decrypt all RDP session data.

Advantages of Native RDP Session Encryption

• Works on any almost any client platform.

• Transparent to the user.

• Easy to configure.

• Can be configured at the server.

• Does not require an X.509 certificate.

The only real disadvantage to using native encryption is that you need to open a nonstandard port (TCP port 3389, for the RDP session) on your firewall to receive the RDP traffic from outside clients. This topic will be covered in greater detail in the "Perimeter Security" section of this chapter.

Disadvantages of Native RDP Session Encryption

• Requires nonstandard ports to be opened on the firewall when RDP clients connect across the Internet.

• Does not verify the identity of the Terminal Server like SSL does.

• The initial "handshake" is unencrypted.

Securing Back-End Network Communications

Thinking back to Figure 12.7, you can see that there are several backend servers that your Terminal Servers need to communicate with. Since this book is not about securing server-to-server communication but instead about Terminal Server, we're going to continue focusing on securing that environment. The purpose of Figure 12.7 is to point out that a Terminal Servers is not a standalone machine, and requires access to many resources.

Communication between the Terminal Servers and the backend servers can be secured in a number of ways. Database access connection between client and server can be secured easily. SQL connections can be encrypted with the native ODBC database tools and software. Connections to file and print servers can be secured with IPSec. All of your security options should be explored, but be aware of the servers with which your Terminal Servers need to communicate.

Fortunately, since back-end servers are usually all located on an internal network, encryption of that network is generally not as critical as encryption of the front-end network.

Network Perimeter Security / Firewall Configuration for Access from the Internet

In this section, we won't spend time talking about the importance of firewalls and why you need them. The truth is that most environments have them. Instead, we're going to focus on how firewalls relate to Terminal Servers. This leads to three questions:

• Where should I place my Terminal Servers in relation to the firewall?

• What ports do I need to open on the firewall?

• How do I make the Terminal Servers work if the firewall is using Network Address Translation (NAT)?

Terminal Server Placement in Relation to the Firewall

When deciding where to put the Terminal Servers that will provide RDP access to applications across the Internet, there are three basic options:

• Terminal Servers outside the firewall.

• Terminal Servers inside the firewall.

• Terminal Servers in a DMZ.

Option 1. Terminal Servers outside the Firewall

Figure 12.10: A Terminal Server outside the firewall

This configuration is primarily used when Terminal Server applications are standalone (they do not need to access any data from the inside of the firewall).

By putting Terminal Servers outside of the firewall, any Terminal Server application that accesses resources from servers on the inside of the firewall will need to have a port opened on the firewall. The more ports that are opened increase the likelihood that a breach of the firewall could occur.

Another point of worry is that Microsoft software is not known for being bulletproof. Very few organizations feel comfortable having unprotected Windows servers sitting on the Internet.

Putting Terminal Servers on the outside of the firewall raises complexities if you have users on the inside that need to access the Terminal Servers. Should they go through the firewall in the opposite direction? Should you have a Terminal Server environment with some servers on the inside and others on the outside? When users from both inside and outside need to access Terminal Server application hosts, the servers are usually not put on the outside of the firewall.

Advantages of Placing Terminal Servers Outside the Firewall

• Works well if no internal users will need to access the servers.

• If the Terminal Server is compromised, it may limit damage to the internal network.

Disadvantages of Placing Terminal Servers Outside the Firewall

• Application holes need to be opened in the firewall for access to internal applications.

• It can be difficult for some applications on the Terminal Server to get through the firewall to the resources they need on the inside.

• If the server is compromised, something like a keystroke logger could be installed to record passwords.

• Greater risk from automated scripts and Internet-based attacks.

• If users connect to the Terminal Servers with the same user accounts that they use on the inside, they must authenticate to the Terminal Server through the firewall.

Option 2. Terminal Servers inside the Firewall

Most companies choose to place their Terminal Servers inside the firewall. By doing this, they are leveraging the true definition of the "firewall," as it will take the brunt of all Internet traffic and attacks.

Figure 12.11: A Terminal Server behind the firewall

This tends to be the most secure of all possible configurations because the only holes that need to be opened on the firewall are for RDP traffic to the Terminal Servers. Most of today's firewalls also offer stateful packet inspection capabilities, meaning that they can validate certain types of traffic going to the internal servers.

Advantages of Placing Terminal Servers Inside the Firewall

• Only the Terminal Server addresses and ports need to be opened on the firewall.

• Reduces the complexity of the firewall configuration.

• Very Secure.

Disadvantages of Placing Terminal Servers Inside the Firewall

• If the Terminal Server is compromised, other servers behind the firewall could be compromised.

• The firewall must be configured to allow RDP traffic to flow to the Terminal Servers.

Option 3. Terminal Server in a DMZ

Some firewalls allow for the configuration of a DMZ (Demilitarized Zone). A DMZ can also be created with a pair of firewalls. This DMZ combines the above two methods. The Terminal Servers aren't totally exposed on the outside of the firewall, but they also do not have free access to devices on the inside of the firewall. In this configuration, no outside traffic has direct access to devices on the inside of the firewall. Instead, the firewall is configured so that outside clients can access only the Terminal Servers in the DMZ. Those Terminal Servers, in turn, can access (through the firewall) network resources on the inside.

Figure 12.12: A Terminal Server in the DMZ

Advantages of Placing Terminal Servers in the DMZ

• Most secure solution.

Disadvantages of Placing Terminal Servers in the DMZ

• Most complex firewall configuration.

Firewall Port Configuration for Terminal Server Environments

If you decide to put your MetaFrame XP server behind a firewall or in a DMZ, there are several TCP ports that must be configured on the firewall.

Port	Direction	Destination	Description
3389	Inbound	All Terminal Server	RDP port needed for Server-client communication
1024-65535	Outbound	RDP Client	Terminal Server will dynamically select a unique port for each RDP session in this port range. This configuration is standard practice on firewalls.
80	Inbound	Web Server	If you are using web launched RDP files, and your Web server is behind a firewall
443	Inbound	Web Server	If you are using web launched RDP files and you require authentication to the pages, it is best to secure this traffic with SSL to protect the user credentials and the RDP files

Figure 12.13: Firewall port usage

This list allows for basic communication between the end user and the Terminal Server through the firewall. If your Terminal Server is in a DMZ, the exact ports that need to be opened from the DMZ to the internal network can become a little more complicated. If your Terminal Server is a member of a domain, users will be required to authenticate. If the application being run on the server uses an SQL database on the internal network, port 1433 needs to be opened between this server and the SQL server. You'll also need to open ports for access to SMB shares, printers, and other network services and applications.

Network Address Translation at the Firewall

Most companies that use firewalls configure them for Network Address Translation (NAT). Internal servers can then be configured with private IP addresses that are not valid to the outside world. Because all network traffic between the inside servers and the outside world is channeled through the firewall, the firewall maintains two addresses for each server. One address is valid to the outside world; the other address is valid to the inside network. When a request for the server hits the firewall from the outside, the firewall translates the address to the internal address of the server before passing it on to that server. Just the same, when the internal server sends network data to an external address, the firewall changes the existing sender's address (the server's internal address) to the server's valid external address. The server has no idea that its address is not valid to the outside world. Using NAT allows servers on the inside to be protected from the outside world by forcing all communication to travel through the firewall.

Figure 12.14: Network address translation at the firewall

The advantage to using NAT is that because the internal IP addresses of the servers are not valid on the outside, it is technically impossible for an attacker to find a "back door" into the network. All traffic must flow through the firewall because the internal addresses are not valid to the rest of the world. Also, by using NAT, companies do not have to register the IP addresses for their internal devices.

In non-Terminal Server environments there are usually no issues with NAT because the internal server has no need of knowing that its IP address is being changed by the firewall. This is not the always the case in Terminal Server environments. To understand why, let's consider the following scenario.

An RDC client device connects to a Terminal Server via the Internet. The Terminal Server is accessible to the Internet via the IP address 128.242.82.212. A firewall running NAT sits between the Internet and the Terminal Server. The Terminal Server's IP address is configured to be 10.1.1.1. The firewall automatically translates between the two IP addresses for traffic going between the Internet and the MetaFrame XP server. This scenario is depicted in Figure 12.15.

Figure 12.15: The firewall translates the RDP client's request

If an RDP client on the outside of the firewall connects directly to the Terminal Server, there will be no issues. The firewall will use NAT to translate between the internal and external addresses of the Terminal Server. In this case, the RDP client and the Terminal Server do not know that the address is being translated. All translation occurs transparently at the firewall, and all is well.

However, if the Terminal Server is part of a cluster that's using Microsoft's Session Directory to reconnect users to disconnected sessions, the IP address returned to the client when they reconnect (after the Session Directory finds their existing session on another server) will be the server's internal address, not the NAT'd external address. The client would need to connect to the load-balanced external IP address, but the session that was found would be based on internal address. In this case, the client's traffic won't go anywhere since the 10.1.1.1 address is not valid from the outside. (Chapter 7 focused on clusters and load-balancing in-depth.)

In order for the RDP client to connect and be successfully reconnected to a session on a Terminal Server behind a firewall using NAT, one of two statements must be true:

• The terminal server MUST have a public IP address. The server is generally sitting in the DMZ or outside the firewall.

  OR

• A third party load balancing solution that has the ability to accept Session Directory tokens and acts as a router or gateway for the load balanced devices must be used.

The first solution would require that at least one network card on the server has a valid, routable, external Internet IP address. This address would be used as the Session Directory adapter for reconnecting disconnected sessions. The caveat here is that you have to make this server publicly available with a port 3389 open which is less secure than being behind the NAT firewall.

In the second scenario, the hardware load balancer also acts as a pseudo-router. All load balanced traffic is routed through it. When a user disconnects from a Terminal Server using this configuration, a Session Directory token is returned to the client instead of the server's IP address. This token contains the IP address and credentials and is handed off to the load balancer at connection for routing. In this case, the server would not need a routable internet IP that could be accessed from the Internet, but instead would only require that the load balancer be able to connect to them.