Properly Securing Microsoft’s Remote Desktop Gateway

The Challenge of Securing Microsoft’s Remote Access Solutions

For decades, Microsoft’s Remote Desktop Protocol (RDP) has been used to connect to Windows computers remotely. We covered in detail many of the reasons that RDP itself presents such a high risk when exposed directly to the internet. Microsoft provided a solution to the numerous RDP-related security woes by releasing a service called Remote Desktop Gateway (RDG). Introduced in Windows Server 2008 and Windows Home Server, RDG addresses some of these concerns by enabling organizations to keep their RDP endpoint servers behind a firewall by exposing just the RDG server to the internet in order to forward the RDP connections. It also incorporates (optionally) Multi-Factor Authentication (MFA) and encrypts RDP traffic using Transport Layer Security (TLS).

OK, sounds great. What’s the catch?

Implementing RDG alone does not solve any of the previously mentioned risks. Organizations and their IT professionals must ensure that security and implementation best practices are followed, if the benefits of RDG are to be realized. Even when properly implemented, RDG can still be vulnerable to attack. Many of the troubles with RDP and RDG stem from two key factors:

RDG (and RDP) are easy to turn on and use, but not easy to properly secure

RDG is developed by Microsoft and as such is a common high value target for hackers.

I turned RDG on, am I secure now?

Hopefully you also put your RDG server behind a VPN with MFA, enabled MFA directly on RDG, implemented a least privilege authorization scheme, properly segmented your network, put all RDP-enabled servers behind a properly configured firewall, and centralized logging and alerting. If you did – well done, you. If not, RDG just isn’t doing a whole lot for you other than giving attackers one convenient place to go when attacking all of your servers.

Ideally, only authenticated users of your VPN would be able to connect to your RDG server at all. In this scenario, users would have no direct visibility to other windows systems without first connecting to the VPN, then connecting through RDG to their ultimate destination. Having MFA enabled on both the VPN and RDG ensures the best possible verification that an incoming connection belongs to the user you’re expecting. Using both levels of authentication and authorization enables a fine level of control over specifically who can access which parts of your network, from where, and at what times. This is one of the key tenets of the Least Privilege concept. At a minimum, RDG exposed directly to the internet must have MFA enabled or you will be vulnerable in many of the same ways you were before you had RDG in place.

Proper segmentation is also critical. The concept of Layered Security dictates that should one control be compromised or otherwise fail, other controls are in place that work together to limit the exposure. Segmenting your network means using a firewall to restrict traffic from one group of systems to another, permitting only specific connections required for the business to function. For example, the RDG server itself probably doesn’t need to access your file shares. Users of RDG will, but only once they’re connected to their ultimate destination. Restricting traffic in this way can greatly reduce an attacker’s ability to move around in your network once they are in. In addition, since you’re implementing RDG, you almost certainly don’t need the RDP services on your other windows systems to be accessible from anywhere other than the RDG server.

While it’s a very good thing to put these controls in place, you also need to be vigilant about monitoring their success. When attackers come knocking, and if you’re on the internet they definitely will, the systems impacted most likely have the ability to generate records of this activity via log files. These log files can and should be aggregated in a central location, so the whole picture can be seen at once. There is an entire genre of network security tools designed to ingest these logs and alert on suspicious activity. You should consider a Security Information and Event Management (SIEM) application or a similar mechanism that enables your security personnel to be aware of these threats, even if they aren’t readily apparent. Your SIEM should be customized to your environment and have enough capacity to process all the log data you generate and store it for a reasonable amount of time. It should have the visibility to expose threats across your entire environment. While a SIEM or other security product won’t just solve a problem on its own, it can be a very valuable tool in the right hands.

Is Microsoft software insecure?

Microsoft’s history aside, their more modern products can actually be quite good. They come with a ton of features and options to give you a really secure and tailored computing experience. You just have to make sure to configure them properly since many of the key security features are not enabled by default. You need to make intelligent decisions about which parts are appropriate for your use case and configure all of these features accordingly. RDG is no different. Right after initial setup, RDG will look like it’s doing what it said on the tin. Be methodical about your planning and vigilant about verifying that the new control you just implemented is actually doing its job well.

Due to their market share, Microsoft remains the most targeted software company in the world. Hackers who spend their days digging to find new ways to exploit systems tend to spend most of their time focused on Microsoft. This is just good business for them – Microsoft products are common, easy to implement poorly, and difficult to secure properly. The good news is that companies like Lodestone are vigilant about identifying new vulnerabilities before they become a major problem for our clients. We publish these findings via the Common Vulnerabilities and Exposures (CVE) system maintained by Mitre. When companies like us report these new vulnerabilities, they are independently verified and the affected vendors are notified. According to Mitre, a total of three new CVEs have been identified for RDG so far in 2020, in addition to the four identified for RDP. Microsoft has released patches for these CVEs, but a software patch is only valuable if it’s actually applied. It can be an overwhelming task to keep up with new CVEs and the implementation of their associated patches.

What do I do?

Following best practices established by the information security community is a great start. If you want to use RDG, Lodestone can help you implement it properly. If you already put it in place but want to verify that it meets these best practices, we can help there too. If you’re just unsure of how to best approach remote access to your network – we got ya covered. Please use the Contact Us link above or simply send an email to info@lodestone.com if you would like to discuss how Lodestone can help improve your security posture.