RDP vs. SSH/SSL/VPN for Security

As a Network Consultant and Security Analyst, I often have the responsibility to either setup or audit Remote Administration tools of various sorts. I have my own ‘bag of tricks’ when it comes to securing these, but I always wonder where the best balance is between Security and Usability – it’s the age old question of Security – just how much inconveniance is it worth?

For the benefit of my clients and colleagues, I thought I’d lay out a few of my personal thoughts and experiences on the subject. The topic has been covered many times by many people, many of whom carry more qualifications on the subject than I myself do. But, for those that value my opinion, or would simply like another point of view, here are my thoughts on Security related to Remote Administration platforms.

First up, you have the ubiquitious (in the Windows Networking world) RDP protocol, coupled with Remote Desktop/Terminal Services. Easy to use. Easy to configure. Easy to hack…?

That’s what everyone says. But the reality of it’s actually quite secure. With proper configuration, RDP (Remote Desktop Protocol) / Remote Desktop is capable of 128-bit RC4 encryption, virtually any port or set of port allocations, and even (since Windows Server 2003) TLS (Transport Level Security). RDP has proven to be relatively bug-free, with only extremely minor flaws ever discovered (I think two or three in it’s history) and no known exploits of those flaws ever successfully executed.

RDP’s main weakness has always been Man-in-the-middle attacks. While alternate configurations (any VPN, SSL/SSH)  require authentication of endpoints, RDP does not, and is vulnerable to attacks that would reroute traffic through a malicious machine (a “sniffer”) to capture data. While all data is encrypted (at varying levels), there was never any way to ensure that someone was not capturing all session data (including encryption keys) and performing decryption to recover passwords and other sensitive data.

Enter TLS.

TLS (Transport Level Security) institutes certificate-based Authentication of the Terminal Server (computer serving the session). With TLS enabled, endpoints are validated via Security Certificates to assure both Client and Server are communicating securely and directly, with no “sniffers” in between.

Some of my favorite “tweaks” to beef up my RDP access security are:

Next up: SSH/SSL.

I have to confess, my experience with SSH/SSL and variants is a little limited – most of my handling has been WINSSHD. Which I like. Great software, very robust, configurable, and secure. I guess. But it has it’s quircks.

SSH servers (such as OpenSSH, WinSSHD, etc) provide SSH (Secure SHell) encapsulation for all communications, using Digital Certificates for Client and Server Authentication (similar to TLS). SSH supports much higher standards of encryption than RDP, specifically support for Blowfish, DES and IDEA algorithms. The Certificate based Authentication provides secure recognition before transmission of any (encrypted) data, even passwords for Domain authentication.

The problem I have run into with most SSH implementations is, quite simply, the complexity of it. SSH servers such as WinSSHD provide a host of options, the like of which would never be required by anything short of an international Conglomerate. This poses a problem for the “little guy”, who really needs to access a few work files from home, but has no idea about security, but DOES know that someone somewhere told him that “SSH” is really good for security. Beyond that, even the small-office techie who can fiddle his way through a relatively secure RDP setup is left scratching his head over SSH configurations.

Once configured, a lot of the same common sense rules apply – use non-standard ports if possible, don’t leave sessions idle forever, don’t use bad passwords, control your access lists, and CHECK YOUR SECURITY LOGS.

I’ve seen clients who get hundreds of hits a day in their logs from guys who’ve stumbled upon their IP and found port 22 open, and seem to get kicks from “hacking” a SSH server by password guessing. Badly.
But you never know… someone might be smart and guess a password, or someone on the inside might be stupid enough to use an easy password… you never know.

The bottom line in either case is the intelligence of the setup. Nothing is secure out of the box. Nothing.

For simplicity, use RDP and Google for a good setup guide (contact me through my web form for suggestions) to enact some of the measures I’ve suggested. For maximum security, if you’re willing to take the plunge, SSH (or an SSL equivalent) will provide a tighter solution. Just be ready to maneuver pages of settings and troubleshooting.

And either way, check your logs.