Remote Desktop Gateway Security Considerations

March 16, 2020 - Remote Desktop Security

Hello everyone! My new book on Remote Desktop Security has now been released, and I’m posting some excerpts/topics from the book here on my blog.  Please click here if you’d like to purchase the Amazon Kindle edition.

The COVID-19 outbreak has many organizations scrambling to establish or expand their teleworking infrastructure for their employees.  Some companies are simply allowing direct RDP traffic to their servers and workstations over port 3389 – not a good idea as you will see below.  Other companies are more wisely choosing to deploy a Windows Server running the Remote Desktop Gateway service.  That RD Gateway deployment may either be part of a full RDS deployment with Web Access and a Connection Broker, or used as an easy way to route users directly to their individual workstations located within the corporate firewall.  While this is a much better approach than just opening RDP over 3389, there are still security implications of doing so that you need to think about.  Read on below…

Do Not Leave Standalone Remote Desktop Servers Exposed Over the Internet – Place Them Behind a VPN or a Remote Desktop Gateway

If you leave any of your Windows servers directly connected to the Internet with the RDP service open, you’re tempting fate. Do not think that changing the default port from 3389 to a non-standard port offers you any protection. It is trivial for modern botnets and banner scraping tools to scan all open ports on a host, and see if any of the ports respond to an RDP connection sequence. Once the port that RDP is running under is determined, the dictionary attacks and unpatched vulnerability probes will begin in earnest. It only takes one user account with a weak password to be compromised, and then they’re inside your system(s) looking for ways to escalate their privileges.

This warning is doubly important if your remote desktop hosts have been deployed to a large public cloud provider like Azure, AWS, or Google Cloud. Attackers, especially APT (Advanced Persistent Threat) actors, know the IP address ranges assigned to these providers and will preferentially target them first, understanding that RDP will be open on many of the systems for convenience of administration or teleworking.

If your users must connect through a VPN first before gaining access to remote desktop resources, this will prevent direct dictionary attacks over RDP, and hackers will need to target the VPN first. The other option is to place a Remote Desktop Gateway in front of your remote desktop servers, which will authenticate incoming connections over port 443 and then route traffic to/from the remote desktop servers you authorize.

It’s a popular misconception that you have to stand up a full Remote Desktop Services deployment – with the other roles like the Connection Broker and Remote Desktop Web Access deployed – in order to leverage the Remote Desktop Gateway service. If you have a small to medium sized deployment, you can stand up one or more servers running the Remote Desktop Gateway service, connect them to the Internet, and then define connection authorization policies (CAPs) and resource authorization policies (RAPs) that control 1.) the users that can connect in and 2.) the session host servers or personal workstations they in turn can access. Then, all you need to do is reference the public domain name of the Remote Desktop Gateway server, and the internal name of the target session host server or workstation in the RDP files that you distribute to your users.

The principal advantage of using a Remote Desktop Gateway server instead of a VPN is performance; RD Gateway servers set up a TCP and UDP channel for communication between the client devices and the internal remote desktop server, which leads to better performance for clients with higher latency or lossy connections into your environment. Another advantage is that unlike some VPN solutions, you can limit access to only terminal servers in the environment via only the RDP protocol.

Lock Down Your Remote Desktop Gateway Servers With CAPs and RAPs

As discussed in Chapter 8, I much prefer using Microsoft’s Remote Desktop Gateway over a standard VPN to provide external access to a Remote Desktop Services deployment. That being said, most organizations forget to tweak the two most important access features on their Remote Desktop Gateway servers after deploying them to tighten up security in the environment.

Those two features are called Client Authorization Policies (CAPs) and Resource Authorization Policies (RAPs). Put briefly, CAPs control who can log in and access the RDS environment through the Remote Desktop Gateway, and RAPs control what systems they can access once they are successfully authenticated.

By default, a Gateway’s CAP and RAP polices are wide open. Specifically, all Domain Users are granted the ability to attempt an RDP connection on ANY computer account in the domain! Definitely not a good security posture. Do not accept these defaults when setting up a new RDS environment – instead, change the CAP to point to only the group in Active Directory that contains users you want to allow to connect to the RDS collection. Likewise, change the RAP to only permit connections to actual RDS servers or user workstations, not every server that can be accessed via port 3389.

You can always create a different CAP/RAP pair (e.g. allowing RDS administrators to connect to RDS servers and another subset of servers on your network), but you should also consider layering in an additional level of security like Multi-factor Authentication for privileged account access.

For more information on how to set up CAPs and RAPs on your gateway servers, please review this great blog article written by my friend and fellow Microsoft MVP, Freek Berson.

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

Leave a Reply

Your email address will not be published. Required fields are marked *