How do you secure RDP?

[teamhood]

Hey Guys,

 

I figured I would tap the collective knowledge of all the smart folks here

 

So I've been trying to figure out a way to secure RDP on my main Windows 7 machine at home. I like using RDP from my work laptop / my person laptop / ipad / iphone to access the data on it, or make sure it's doing things. But a big fear that I have is how secure is it to the outside world with port 3389 exposed? It freaks me out that someone could bruteforce my password and get onto my PC and delete my unRAID and whatever else they wanted to mess with.

 

Any thoughts how to beef up the security of RDP, but also keeping it easy to use?

 

As for router/firewall I recently built a pfSense box using the HP Micro Server that I found on sale from the forum here. It's a great firewall and I have installed and enabled Snort IDPS as well... Working great!

 

So any thoughts how I can beef up security on my LAN?

 

[aptalca]

VPN

[sureguy]

Or you could set up ssh tunneling, and use a public/private keys rather than a password.  Add a password to the keyfile and you're pretty safe. 

[Influencer]

I'd use Logmein, never liked MS's RDP. And its free, so thats always a plus.

[revco]

RDP does have some built in 128bit encryption, so it's considered relatively safe to use over the public internet by itself.  That said, encrypting the traffic within a VPN tunnel (either LAN to LAN or client based) will provide that much more security.  A VPN means you don't have to have port 3389 open to the outside internet.

 

If VPN won't work, I do STRONGLY suggest locking down the IP addresses that can access the RDP session via your firewall.  (e.g. Deny all IP's except the one's you'll use to connect)  If that's not practical (e.g. you connect from hot spots, DHCP sites, etc.) then it's paramount that you secure your box with strong passwords.  Also, removing any common administrator usernames is also considered best practice.  The above will prevent exhaust pretty much all the commonly used RDP password crackers out there.  You're still at risk for brute force, but that's such a slow process over the internet that it's not very common to see in use, except for high value targets.

[StevenD]

If you also have a Windows 2008 server, you can use Remote Desktop Gateway.  It uses SSL and works great.

[teamhood]

Thanks for all the help folks! I am trying to configure OpenVPN through pfsense now and I'm hopeful that I can figure it out.

 

Thanks again for the input.

[Nyago123]

Another vote for Remote Desktop Gateway here; I prefer jumpbox style implementations to VPN because I don't like the idea of bridging networks when the encryption for RDP is sufficiently strong, but it's a matter of personal taste and where you want to make maintenance tradeoffs.

 

Really, your workplace should be closing outbound connections on 3389 (well, any port that isn't necessary for the viability of the business), so with RDG you'll be on 443.

 

If you change your mind and ever want to go a step further with RDP:

 

I have a Cisco ASA 5505 with Security Plus- i.e. full DMZ, with outside, DMZ, and inside interfaces, and a decent Hyper-V server with multiple NICs.  I think you can do the same with pfSense for much cheaper that what I have.

 

The model I use is basically the one in Section 3.2 here:

http://blogs.msdn.com/b/rds/archive/2009/07/31/rd-gateway-deployment-in-a-perimeter-network-firewall-rules.aspx

 

The DMZ has a standalone Windows domain.  My inside network has a separate Windows Domain and a PKI.  I set up a one way trust (DMZ trusts inside but not vice versa) between the domain controllers using Group Policy on both sides to specify that only the DCs may talk to each other via IPSec authenticating with a certificate derived from my PKI's root CA.  That means to cross the DMZ-inside boundary, I open only UDP port 500 + protocol 50 (esp) + protocol 51 (ah).  Unlike what the above MSDN article says, I do not have to open cross forest authentication ports or RADIUS ports.

 

The use of IPsec for cross DC authentication is covered here:

http://technet.microsoft.com/en-us/library/bb742429.aspx

Yes, it's Windows 2000 era but it works - what's more amazing to me is how few enterprises probably use this 11+ years later (well, and how many allow traffic on 3389 outbound  ).

 

In the DMZ I have set up Remote Desktop Gateway with an SSL cert again signed by my PKI and a Network Policy Server on the inside.  The gateway is also given authorization via GP to talk to the inside DCs for the purpose of credentials verification.  This means I only open port 443 to the outside and 3389 exclusively from the DMZ gateway server to the inside workstation (actually, I probably should go a step further and change the default port).  When you RDP, you specify the use of a gateway, the FQDN of the inside machine, your inside domain credentials, and you are forwarded over HTTPS via the gateway to the inside.  Nothing else is on the RDG server, significantly reducing attack surface.

 

In the worst case, if you somehow got into the RDG server using DMZ domain credentials (again, only 80 & 443 is open there and there are no web apps other than RDG), you'd still need inside credentials to get in.  If you have inside credentials, I'm screwed but you really didn't need to hack my RDG server if so.  I guess if I was really paranoid, the first inside domain RDP machine would just be a jumpbox with specific inside-domain user-only-login-from-outside rights credentials, then you'd have to RDP to other machines on the inside using admin credentials.

 

Now if I could just get two factor authentication for any RDP use on inside machines, I'd be satisfied.