Securing Your Terminal / Remote Desktop Server

We’ve recently had a few questions around securing Terminal / Remote desktop servers both in the cloud and on-premise. As I started to write the copy for this blog I came across an article previously written that covered off everything perfectly. Instead of re-inventing the wheel, I’ve provided a simplified version of that article below. It’s a little text heavy but covers off what you need to know.

To read the original article, please find the link at the bottom of the blog post.

Summary

Remotely accessing your servers and workstations through terminal services or RDP is an easy method of doing your job from a remote location, or gaining access to specific published applications that have been published on your servers. However, without properly investing in securing these types of RDP connections, you could be compromising the security and integrity of your servers, the data on them, and the services they’re providing.

Usage Scenarios

When planning for terminal server and RDP security we must take the terminal server usage scenario into consideration. While some terminal server and RDP deployment scenarios are created to allow full remote desktop capabilities, some allow full remote administration capabilities, while others only allow access to a specific list of line of business applications. Every scenario might pose additional security risks and thus require us to make additional changes to our security design.

Usage scenarios include:

• Publishing Users’ Desktops – In this scenario, the Terminal Server is used to publish the users’ entire desktop, and bring all the desktop and application capabilities of the server to the remote users. The users log on to the remote desktop through RDP, use applications that are installed on the server, surf the Internet, and generally feel as though the desktop is their full personal workspace. This remote connection can be accomplished by using an RDP client (also known as an RDC client), or by using a thin client hardware. In this scenario you will need to purchase TS CALs for each concurrent connection to the server.
• Publishing selected applications – In this scenario, the Terminal Server is used to publish a few selected applications such as Microsoft Office, an ERP or CRM application, Internet Explorer windows for “Internet sharing”, and generally speaking – any application that you want to be made available for the remote users. Users click on their published application shortcut (which can be a desktop icon or an Internet shortcut, depending on the method used to publish the applications). After logging on, users gain access to the published application and only to that application. There is not full desktop capability, and when the application is closed, the session ends. Here too, remote connections can be established by using RDP/RDC clients, or by using thin client hardware. Here too, you will need to purchase TS CALs for each concurrent connection to the server.
• Remote administration – Another scenario for using Terminal Server/Remote Desktop is for remote administration purposes. In most cases, passing the RDP protocol (TCP port 3389) through the corporate firewall is a lot easier than having to allow Microsoft Management Console snap-ins (MMC) or other types of management tools that use RPC and other protocols through the firewall. In this scenario, the remote administrator initiates the RDP/RDC connection and gains access to the server’s entire desktop, where they can use any locally installed application to manage the server’s services and functionality. Also, this scenario does not require purchasing TS CALs, as the RDP connection is limited to only 1, 2 or 3 concurrent connections (the number depends on the version or operating system you’re running: Windows 2000 and Windows Server 2008 only allow 2 concurrent connections, while Windows Server 2003 has 3. Windows XP and Vista only allow 1 concurrent connection).

Security Guidelines

Here are some points that you need to take into consideration when designing your terminal server security. Keep in mind that some are specific for published application usage, while others are general and should be applied to all the usage scenarios. Read through these guidelines and see which ones apply to your situation.

Note: These guidelines are listed in no particular order.

• Change the TCP Port for the terminal server listening port – Utilising your router and NAT, you can setup a port forward on your router using a custom port. An example of this would be port forwarding Port 1450 > 3389 and then configuring your client software to connect over this custom port.
• Do not implement terminal services on a domain controller – This is one of the basics. Doing so means that you will need to allow users the “Log on locally” user right. Also, doing so means that in order to delegate management tasks for specific users on the TS servers, these users will automatically become administrators for the entire domain’s domain controllers, which is obviously a wrong thing to do.
• Design a good Organization Units (OUs) structure in Active Directory for the computer objects of the terminal servers – Using a good OU design makes it easier to link specific Group Policies (GPOs) to these OUs and have them effect all servers within these OUs. This consideration is mostly beneficial when looking at the published applications usage scenario, where it’s most likely that you’ll be using more than one TS which will be dedicated to running that role.
• Implement “Loopback Processing” on GPOs to control settings for users that are not in the same OU as the terminal server computer objects – This is most important when you have users from different OUs accessing terminal servers that are in another OU. When using this configuration, because user accounts log on to the servers after the servers are booted, there may be inconsistencies between the terminal server-linked GPOs and the GPOs for the user accounts. In this case, you can use the GPO loopback feature to apply Group Policy Objects that depend only on which computer the user logs on to.
• Use Group Policies to control many terminal servers – Instead of separately configuring each server, use GPOs that are linked to the OU where the server objects are located.
• If possible, publish a single application on each terminal server – While not always possible, this will allow you to better fine tune for security (and performance) issues that are related to specific applications.
• For specific published applications, consider pre-configuring the startup application – In order to pre-configure exactly what application is started when the user logs on to the terminal server. This setting is only useful in specific application publishing scenarios and NOT for remote administration, but using it will increase security for the terminal server.
• Consider implementing IPSec between the client and the terminal server – If the protection of the traffic between the clients and the terminal server is important, use IPSec to add an extra layer or security and encryption to the traffic.
• Implement data encryption on the terminal server – For Terminal Services connections, data encryption can protect your data by encrypting it on the communications link between the client and the server. Encryption protects against the risk of unauthorized transmission interception on the link between server and client. By default, Terminal Services connections are encrypted at the highest level of security available (128-bit). However, some older versions of the Terminal Services client do not support this high level of encryption. You can select the level of encryption, with higher encryption offering better security, but adding extra CPU cycles to the server.
• Use a mechanism to configure IP Address filtering on the terminal server – This will allow only specific IP Addresses to connect to the terminal server. To do that, you can either use the built-in Windows Firewall (depending on the version of Windows that you’re using), or a 3rd-party firewall that is installed on the servers. You can also use IPSec to implement blocking filters (In Windows Server 2008 IPSec blocking filters is a part of the Windows Firewall with Advanced Security).
• Properly configure your corporate firewall to only allow specific computers to connect to the terminal server – Needless to say, properly configuring your corporate firewall to block all unnecessary traffic to and from the terminal server is one of the first steps you should take to protect it. While your mileage may vary, it’s worth noting that RDP communication uses TCP port 3389, and all firewalls, routers and NAT devices between the remote clients and the terminal servers should be configured to properly allow (or block) traffic based upon your design.
• Unless required for published applications, require user credentials when logging on – The logon process can be made easier by storing the user credentials on the client’s computer as part of the RDP/RDC program. However, this means that anyone that double-clicks on the RDP/RDC shortcut will be automatically logged on to the terminal server. While useful in some cases (such as kiosk environments where casual users do not have a user name and password they can type in), it will lower your security level.
• Restrict RPC management access to the terminal server by requiring security – For management purposes, restrict RPC access to the TS. This is done through either a GPO linked to the OU where the TS computer accounts are located, or by using local policies.
• Consider limiting the active user session length – While not strictly security-related, this can add some security to a terminal server session. Be careful not to limit the active session to a time that is shorter than what your users need to perform their job.
• Limit the idle session and disconnected session time – Idle sessions should not be left open for ever, and they should be automatically terminated after 15 or 30 minutes. Disconnected sessions, on the other hand, are harder to control because of the possibility that a user’s connection has terminated due to network issues, and killing that session will result in lost un-saved data on the user’s session. I use 3 hours for application or desktop sharing, and 24 hours for remote administration scenarios.
• Disconnect from session – Should be enabled, in order to put a user’s session into “disconnect” state when a session limit is reached.
• Restrict reconnections of a disconnected session to the client computer from which the user originally connected– This makes it easier to prevent session hijacking, but might prove a bit of an annoyance if clients lose Internet connectivity temporarily, and when they come back online they get a different IP address than the one used in the disconnected session.
• Restrict the number of client sessions that can remain active on the server – This makes it easier to keep track of who is connected.
• Override user settings in the terminal server Configuration console – This will allow the administrator to centrally configure user session settings from one place, and not need to configure these settings on each user’s user account properties.
• Do not enable remote control on users’ sessions – Terminal server allows you to “shadow” or view users’ sessions when logged on to the server via RDP/RDC. While useful for training and help desk scenarios, this also means that administrators can view users’ sessions, possibly exposing themselves to private and confidential information.
• Use granular permissions to control who can connect to the terminal server – Typically, default settings are adequate for regular TS deployments, however in order to increase security you should consider manually changing the scope of users and groups that are allowed to log on to the TS, and what they can do. For example, who can reset a connection, who can remote control another session, and who can send messages to other concurrent sessions.
• Limit users who can log on remotely – Only allow certain users remote desktop access, even when using RDP on a regular workstation. Make sure that you only allow the users who you want to be able to log in remotely.
• Possibly prevent administrators from logging on through RDP – In some cases, when remote users only need to run specific applications, you might want to configure the local policy of the server/workstation to prevent administrators from logging on through RDP/RDC.
• Consider limiting the applications that a user can access on the terminal server – Especially useful for full desktop access, you can use Group Policy to limit the list of applications that can be opened by a user on the terminal server. Also consider preventing access to some of the command-line tools found in the %systemroot%’system32 folder – applications such as subst.exe, xcacls.exe, xcopy.exe, cmd.exe, format.exe, regini.exe, reg.exe and similar.
• Set an account lockout policy – There are tools that will use brute-force to guess passwords and log-on remotely. You cannot totally stop this, but you can minimized it by setting an account lockout policy. If someone tries to guess the password, then after a few guesses they will be locked out for a period of time.
• Consider implementing a secure remote access infrastructure by using VPN to protect the transmitted data and prevent Man In The Middle attacks – Regular RDP connection provides encryption for the data that is sent between the terminal server and the client computer. However, this kind of connection does not provide authentication for the terminal server. In order to mitigate some of the security issues, you should consider implementing a VPN tunnel between the clients and the terminal server.
• Consider enabling Transport Layer Security (TLS) to authenticate the terminal server and to encrypt the data – As noted in the above item, regular RDP connection does not provide authentication for the terminal server. Instead of using a VPN tunnel, you may want to make sure that your terminal server is correctly authenticated before you connect to it. Furthermore, you cannot verify the identity of the terminal server you’re connecting to. By using Windows Server 2003 Service Pack 1 or higher together with Transport Layer Security (TLS) you can increase terminal server security.
• When using Windows Server 2008 Terminal Server, consider using TS Gateway – Using the new capabilities of Microsoft Windows Server 2008 TS Gateway provides further protection of RDP traffic by encapsulating it into SSL packets – much like SSL VPN, but without the need to deploy special VPN servers. The benefit of using the TS Gateway capabilities of Microsoft Windows Server 2008 is that remote users will only be granted access to the internal servers based upon a strict policy that can be enforced on the TS Gateway, and when combined with the NAP capabilities of the system, will only allow connection of computers that fully meet the security requirements set by the administrator.
• Monitor Log Files – The Event Viewer logs failed login attempts and account lockouts. Monitor the event log for such events.

Conclusion

Without properly securing terminal server connections you could compromise the security and integrity of your servers, the data on them, and the services they’re providing. By following the above guidelines you will be able to protect your data and applications.

Click here to view the original blog post.