I have a sort of a conflict with my company's Security Lead Engineer. He says that Remote Desktop Protocol (RDP) is not secure enough and we should be using TeamViewer instead. We use RDP not only to access local resources inside our corporate network but also for the access to resources (running Windows 2012+) in cloud hosting.
In both the scenarios how secure is it to use RDP?
I believe that Teamviewer is a proxy service for tunnelled VNC connections. Hence, the first security consideration with regard to that service is that it is MITM'ed by design. There have been suggestions that the service was compromised a couple of months ago.
(Note that although VNC uses encryption, the entire exchange is not, by default, encapsulated - but it's trivial to setup a SSL/ssh/VPN tunnel).
Next consideration is that it means installing third party software on your systems - but then if you're running a Microsoft platform then you're already running software from multiple vendors which is probably not covered by your patch management software; keeping software up to date is one of the most effective means of protecting your systems.
As long as your RDP connection is using SSL, it should be at least as secure as Teamviewer, and IMHO, a lot more so.
Edit: According to the comments there seems to be combination of configuration options in the enterprise edition of TeamViewer which might reduce my concerns. Since I have never used those, I cannot give an assessment about those and how well they work. According to the comments it might to be a buggy solution.
I am a server admin (Windows and Linux) and I would block any attempt to install TeamViewer on the servers for following reasons:
To me, there are too many red flags.
Our servers are in an isolated subnet where the firewall/switch only allows preconfigured ports in and allows users to connect with VPN to this subnet with their username/password. We follow a defence-in-depth approach: only certain groups get privilege to connect to the VPN with their user. Inside the VPN, they can use RDP or SSH. If there should be a security vulnerability in RDP, the attacker would first need access to VPN or LAN. This would mean they would be either our IT staff (which a company must trust to some degree), get access to VPN or physical access or hack one of the servers. Physical access means breaking into the datacenter; if this happens, there are bigger worries. The same goes for someone of the IT staff going postal. If they breach one of the servers, they would also need a privilege escalation vulnerability to attack because they are locked down accounts. For VPN access, he would need a vulnerability in the VPN or get the account of someone with VPN privileges.
And all of this only in the case that there is an RDP vulnerability. Most likely only an attacker classified as an advanced persistent threat (APT), which is to say someone using sophisticated techniques to target your specific system in a sustained attack, would have a 0-day exploit for RDP and it is more likely that such an attacker would be able to use easier methods/vulnerabilities in other software.
In addition to the other great answers, TeamViewer offers less physical security because it requires that the screen is unlocked in order to facilitate a remote session.
That is, anyone walking past a keyboard and monitor of a remotely administered session can observe it and possibly take over the session should the remote user not be paying attention.
Note, it appears possible to blank the screen after installation of a display driver, however this has to be done on each connection leaving a window of opportunity.
Also, you are now trusting the security of the TeamViewer screen blanking rather than the security of the Windows lock screen - make sure that you are comfortable with that.
To begin, I know nothing about TeamViewer, so I won't attempt to comment on it.
Historical RDP servers used "RDP Security", which is indeed a broken protocol and vulnerable to MITM. Don't do that. Even 2003r2 can do TLS for RDP, so there is no modern reason you should be forced to use RDP Security.
Modern Servers will support TLS, so the security of RDP is directly related to the security of TLS. With registry tweaks you can enforce a subset of TLS that you like - force to 1.2, restrict to certain cipher suites, maybe other things.
Also, there is a RDP specific angle here in that the server can restrict connections to only those that support "Network Level Authentication". NLA still uses TLS, it is just a protocol change to perform the authentication earlier in the exchange. I believe this is intended to protect against a denial of service attack where unauthenticated users repeatedly attempt to connect without authenticating.
If you were to decrypt and trace a RDP TLS Sesssion using NLA, you would see the following:
Assuming that you're using a modern version of RDP and configure it correctly (e.g. enable NLA, sort out proper certificates) the main risk of exposing it directly to the Internet tends to be the problem of exposing a username/password authentication system to the Internet, which is that you're allowing attackers to attempt to brute-force Active Directory Accounts (assuming this is an AD environment and not a set of stand-alone servers).
This isn't great as you either end up with a DoS risk with account lockout set or a risk of unauthorised access with no account lockout set (someone will always choose a weak password, or use one that gets breached elsewhere), so if you are exposing RDP directly I'd recommend two-factor authentication on users that are allowed access via this mechanism.
As for TeamViewer, there isn't a risk of direct access but you are placing trust in them as an organisation and has been pointed out by other answers they have had security concerns recently.
I'll expand on Daniel Bungert's explanation of protocols involved and why they work together. Having written a MitM proxy for RDP, I'm very familiar with the inner workings of most protocols involved. (More than I'd like to be...)
You can configure it to only operate over TLS. This offers great security in it's own right, every message is wrapped with TLS encryption. There are group policies you can manage which will set the allowable TLS encryption protocols. You can use this to specify only the ones with key-lengths or algorithms that you deem fit. These are general windows settings and not rdp specific. Your only concern would be users accepting bad certificates, in which case a MitM attack is possible.
However, you can further configure it to only operate with NLA authentication. Specifically, this will use CredSSP with NTLM. This prevents MitM because the certificate used in the TLS layer is used (along with other things) to encrypt the password. You can then no longer just forward the encrypted password because the target rdp service will not authenticate a hash that was generated with a certificate other than it's own. The reason my mitm works is because we know the passwords that are being used to connect to the proxy, and with that we can extract information and generate a new hash for the target rdp service. A malicious rdp proxy will not have that advantage.
So with both TLS and NLA configured, rdp is safe from users that may accept bad certificates. This counters Overmind's concerns about mitm attacks.
I'd go with some kind of VPN from the user's remote computer to a firewall at work, and then run RDP over that encrypted link.
Problem with leaving a port open is that eventually it is found, and you'll have brute-force login attempts. Either that will just slow your environment down, or it will lead to accounts being locked out, or they find a username with a weak password (There's always that one user....)
You can explore 2 factor auth with smartphone apps, hardware tokens, or pre-printed one-time passwords.
Remember, security is the opposite of convenience.
This started as a comment.
It's important to point out the "Who's at fault question". If you use a third party service and they fail to provide it's their failure to provide. If you use something in house and it fails, now it's the house's fault. Such distinctions carry a lot of weight. It might not mean anything to actual security, but that can sometimes go to the sidelines.
For example if you need to gain certification for a contract, and that certification says something to the effect of:
You must use secure remote management methods, unencrypted remote management methods are not allowed. Contracting with a third party to provide services is allowed. Encryption must be foo strength and bar requirements. Common services that meet theses requirements are LogMeIn and TeamViewer. Common services that do not meet these requirements are GoToMyPC and plain VNC.
Then the decision could be made to use Team Viewer.
Then there is the risk to the business. It could be argued that Teamviewer is less risk, because your using a service in good faith that is supposed to be secure. At the same time RDP may be more of a risk because now your standing your team's knowledge up against random peoples understanding.
In the end, while this doesn't have any real connection to real security, it's important to remember that companies don't do security cause it makes them money (normally). They do it as Risk mitigation and because they have to to keep making money. Using a third party service may remove some of the risk for the company.
As mentioned you should use RDP + Encryption if possible. But, I have seen no mention of basic security measures against attacks (brute or otherwise) in answers provided.
ANY software/port(s) that is left open to public is going to be scanned/found. Period. RDP or not. Encryption or not. If public access is not needed why allow it?
Creating and admin'ing an 'allow' list based on IP Blocks may be time consuming and a pain (if many hosts accessing), but it should not be overlooked. Be it 1 IP or hundreds of separate network IP's.
You mentioned a 'cloud' based server. So for example, on AWS/ec2, one should be using an EC2 Security Group to allow some IP's or Admin network(s) and deny the rest. Most providers have similar methods.
Point is (and in addition to answers provided): RDP would be my choice, but nothings perfect. It becomes even more imperfect if you are not blocking unwanted networks.
On RDP you can perform a MiTM attack and then all traffic from RDP server to the RDP client and back will pass through our MiTM system. That is why it is not considered secure.
As for Teamviewer, you must put trust in a 3rd party, which is not the option many would go for.
As for a best-case scenario, you should setup your own certificate-based VPN.
