Is there a secure way to have a publicly facing terminal server?

Question

TL;DR We are looking at opening port 3389 for a terminal server all the advice I’ve seen is that its suicidal but without good explanations as to why. Is it really that bad?

We are looking at setting up a terminal server for staff to access remotely. They are going to be using a bunch of devices including iPads, Android Divices, Windows (XP to 8), OSX, Linux, pretty much anything with an RDP client.

I want this to be stupid simple and work on everything. My plan is to setup remote.example.com (obviously with our real domain name) to point to our server then secure it by:

1. Firewall everything except port 3389.
2. Set there encryption level to highest (with a certificate) and not allow “Negotiate”
3. Lock accounts with more than 7 failed attempts and look at maybe some script to block based on IP addresses with failed logins (https://security.stackexchange.com/a/17354/22241)
4. Other obvious things such OS updates and anti-virus.

However when I talk about setting up a public facing RDP the responses are generally along lines of:

“Don’t open port 3389 put a VPN in front of it” – but as far as I can see the two main arguments for this are encryption (Doesn’t RDP already do this?) and better authentication because people will brute force RDP. We allready have a PPTP VPN setup but it just uses the same account username/password combo to authenticate as our Terminal server would so I don't see a terminal server adding to our attack surface. The only argument that I think holds any weight is setting up a VPN (such as Cisco) that supports two factor authentication, that sounds good but will massively reduce the number of devices that are supported.

"Don't do it, use an RD Gateway" As far as I can see reading http://technet.microsoft.com/en-us/library/cc731150.aspx the advantages of a RD Gateway are:

Manage multiple servers from a single entry point with fine grained control over who can connect to what and so on. - Sounds good but we only have one terminal server.

Uses port 443/HTTPS so people behind poorly configured outbound firewalls can connect – sounds great but RDP already offers encryption and changing the port doesn’t add security. Also for all the extra ease of not needing to deal with outbound firewalls comes the lack of support from most RDP clients (last I checked the OSX clients couldn’t connect to RD Gateway)

"Don't use RDP, use (Hamachi/Team Viewer/Jump Desktop/VNC … seriously/some other RDP tool) it's safer" To me any of these suggestions go from putting all your eggs in one basket (Microsoft) to putting all your eggs in another basket (Hamachi) but without tangible security benefit.

Am I just being dismissive? Is setting up a public facing RDP server a bad idea?

Answer 1

RDP is a complex protocol which requires complex implementations, and thus likely to contain bugs. The initial versions of the protocol did not include much encryption. Ulterior versions are better, and can use either a homemade encryption system (which may or may not use a certificate to embed the server public key), or SSL/TLS (which necessarily uses a server certificate). Note that, in the latter case, the TLS records are encapsulated into RDP-specific packets, so you cannot content yourself by saying "this is just SSL".

There is no conceptual reason which would make RDP inherently insecure; but the whole tower of inner protocols and the general lack of decent documentation is a problem. It is already hard to know what features will be supported by a given client. Microsoft's implementation had its lot of remote exploits, e.g. this one and that one.

Microsoft's own response is that if you want security, you need Remote Desktop Gateway, which adds yet another layer, but on the outside: a standard SSL/TLS, with user authentication, and RDP in it (so you end up with a SSL-RDP-SSL-RDP sandwich). The idea is that a public-facing SSL server is a known situation with code which has been thoroughly debugged, through years of exposition (in IIS, for HTTPS Web servers). RD Gateway won't prevent RDP holes, but exploits will be limited to people who can get through the outer SSL, i.e. people who can open a session on the server itself and already have a lot of power. Of course, RD Gateway is not free, so it is Microsoft's best interest to sell licenses for it.

Note that client support for RD Gateway is not a given, when the client software is not Microsoft's implementation.

To sum up, there is only one authoritative source for RDP (Microsoft) and they themselves have about given up the idea of claiming that their product is sufficiently bug free to be public-facing. This does not bode well. Some of the alarmist discourse on the subject might be prompted by the urge of selling RD Gateway licenses, but it makes sense that making Microsoft's RDP implementation secure is hard, because of the complexity and long history of the code.

Answer 2

There are a few ways to protect RDP.

• Don't use public port #3389. Is the best way to decrease brute force atemps.
• Allow only certain IPs(or range of IPs) address to public IP. Use smart routers. I use mikrotik (http://wiki.mikrotik.com/wiki/Bruteforce_login_prevention) or Cisco.
• Configure firewall blocking to many attempts. I use third party tools to block the traffic. A free tools is from http://www.bfguard.com. There are several more but I like this one because it free. This tool analyzes event logs for failed logins and then add IP to windows firewall for blocking.

Answer 3

You could use OpenVPN, which is separate from the Windows VPN methods. You can install an ssh server (like Bitvise WinSSHD) and tunnel all traffic over SSH. I can't tell you if this is more secure than the current situation though.