There have been a number of vulnerabilities published for the Remote Desktop Services protocol stack over the last little while. The catch with all of them is to have a RDP listener open to the Internet on any port with Network Level Authentication disabled or not available as it was not built-in to earlier Windows operating systems.
Except if a RDP listener is exposed to the Internet with Network Level Authentication (NLA) disabled!
Now, we are not doing that right?
Microsoft has had the Remote Desktop Gateway (RD Gateway) feature built-in to the Windows Server operating system since Server 2008 RTM.
In the case of RDS endpoints with RD Gateway positioned in front, an attacker would already need a foothold on the internal network in order to exploit any of these vulnerabilities.
Add in Two Factor Authentication (2FA), Multi Factor Authentication (MFA), into the mix and things get even more difficult.
Trinder?!?
We don’t publish RDP Listeners to the Internet and have not since the Server 2003 days when we were introduced to Trinder (Bing search) when a Terminal Server we had set up was seemingly grinding down throughout the day. It took a bit to figure out what was happening but eventually we managed to watch the authentication requests hitting the server at an incredible rate via the Internet connection.
In Server 2003, there was no limit on failed logons nor a lockout period for same. So, on and on it would go until we closed TCP Port 3389 and moved the RDP Listener to another port. It wasn’t long before the server started grinding down again.
We ended up closing the publishing rule and setting up a client to site VPN on the firewall. Lesson learned.
RD Gateway
With the advent of RD Gateway in Server 2008 RTM, thus Small Business Server 2008, we ended up building out a lot of Remote Desktop Farms within short order. It was a business boom for us to do so knowing that both RD Gateway and NLA provided an excellent layer of protection for the RD Endpoints on the production network.
Our last accounting firm finally got on board with setting up a farm for their users in their Server 2012 R2 refresh cycle in conditional mode. They stuck with it when they saw how convenient it made their day to day work.
The long and short of this post is this:
Close that RDP Listener port forwarding rule STAT!
If you are publishing RDP Listeners to the Internet get a RD Gateway setup going STAT!
Setting up RD Gateway is not that hard. All that’s needed is TCP 443 forwarded to the RD Gateway server, we put RD Broker, Gateway, and Web on the same VM, and a quick configuration in Server Manager. A trusted third party SSL certificate rounds out the setup.
That’s it.
The internal RD Endpoints are now as secure as they can be behind a forced credential prompt. With 2FA/MFA they are even more secure.
Or, just put a SSL VPN setup on the edge, we use SonicWALL, and call it a day with users connecting via VPN first.
That being said, make sure all Windows endpoints are current with their updates.
Philip Elder
Microsoft High Availability MVP
MPECS Inc.
www.s2d.rocks !
Our Web Site
Our Cloud Service
