Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 (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 (
  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 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?

share|improve this question
up vote 11 down vote accepted

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.

share|improve this answer
On the other hand MSFT, Amazon, and others are banking their Cloud business on the security of RDP. Almost very IAAS (Infrastructure as a service) I've seen exposes the OS via RDP exclusively. Backspace seems to be an exception. More recent developments allow this to be locked down by subnet, but this wasn't possible for the first few years of Azure (up to Azure deployment 2.0-ish) – LamonteCristo Feb 26 '15 at 5:05

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.

share|improve this answer

There are a few ways to protect RDP.

  • Don't use public port #3389.
  • Allow only certain IPs(or range of IPs) address to public IP.
  • Configure firewall to block any attempts to contact the server.
  • Use third party tools to block the traffic. A free tools is There are several more but I like this one.
share|improve this answer
it would be handy if you explained what bfguard did (without being a promotion or sales talk) – schroeder Jan 14 at 18:56

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.