Securing RDP, How?

[narzy]

I use programs like Logmein and Teamviewer but their performance doesn't match RDP and VNC for remote support. But...I don't like opening ports in my firewalls to get them to work (seems like a really bad idea from a security standpoint to me) I've thought about setting up a VPN but I was wondering if there was a way to really lock down RDP to make it safe enough to use on the open web? Can it support Certificate authentication? I'm thinking that would be a huge PITA though...any ideas?

I've also though about SSH tunneling but I don't know enough about securing SSH and I know it has a pretty big attack footprint so I am hesitant to use it.

 

[sourceninja]

VPN is the way to go for this.

 

[theevilsharpie]

But...I don't like opening ports in my firewalls to get them to work (seems like a really bad idea from a security standpoint to me) I've thought about setting up a VPN but I was wondering if there was a way to really lock down RDP to make it safe enough to use on the open web?

In order to connect to Remote Desktop, you need to authenticate with the system you're connecting to. The authentication process and all subsequent traffic is encrypted. I'm not sure what additional security you would gain from a VPN.

Can it support Certificate authentication?

Yes.

 

[narzy]

In order to connect to Remote Desktop, you need to authenticate with the system you're connecting to. The authentication process and all subsequent traffic is encrypted. I'm not sure what additional security you would gain from a VPN.



Yes.

VPN would prevent the RDP port to be directly exposed to the internet in case there is a vulnerability in RDP. In terms of Cert Authentication, thanks for the heads up.

 

[sourceninja]

VPN would prevent the RDP port to be directly exposed to the internet in case there is a vulnerability in RDP. In terms of Cert Authentication, thanks for the heads up.

Exactly, imagine if you need to RDP into a hundred desktops. Each one would need a publicly exposed IP or port. Now use VPN. You have one publicly exposed machine (the vpn endpoint). Everything else is just like your sitting there on your network.

 

[theevilsharpie]

VPN would prevent the RDP port to be directly exposed to the internet in case there is a vulnerability in RDP.

That may be true, but instead of exposing RDP (which may have a potential vulnerability) directly to the Internet, you're exposing a VPN (which may have a potential vulnerability) directly to the Internet.

In other words, you really haven't gained anything.

Exactly, imagine if you need to RDP into a hundred desktops. Each one would need a publicly exposed IP or port. Now use VPN. You have one publicly exposed machine (the vpn endpoint). Everything else is just like your sitting there on your network.

Consolidating all potential connections to one address/port would definitely be a good reason to use a VPN (or some other type of connection broker), and is one of the reasons why I use VPNs. However, while that makes managing RDP much more convenient, it doesn't necessarily make it more secure.

 

[sourceninja]

It makes it more secure because it is easier to manage. If there is an exploit in the VPN you have one thing to patch and one attack vector. If RDP has an exploit you have dozens of machines to patch and multiple places for the attack to target.

 

[WobbleWobble]

You can deploy a 2-factor authentication system with VPN, something that isn't built into RDP.

 

[sourceninja]

Not to mention my VPN server does not contain sensitive information. If it was compromised I'd not lose things like if the CFO's desktop was compromised or even worse a enrollment management persons computer.

Yea it would suck, but without my private keys you cant ssh into any servers, and without certs/passwords you cant remote into any desktops. So they would need to find a exploit in my VPN, then find a way to steal my private keys/passwords or find exploits in RDP/SSH. Otherwise all they have access to is a small virtual machine that I can revert to snapshot and patch.

 

[gsellis]

You can deploy a 2-factor authentication system with VPN, something that isn't built into RDP.

This. 2-factor for employees and vendors. Employees then can be in a permissions group to get to RDP internally. Vendors, anything they RDP to is in a DMZ so that then they cannot RPD back through the firewall at the VPN connection to sets internally (RDP inside RDP). And even with employees, you want to limit where. SSH is treated with the same policies. And you just remove telnet because anyone in the middle after the tunnel can see user id and password.

 

[spikespiegal]

Yeah, like VPNs are never set up poorly and never require patches. Personally I'm more afraid of walking into a VPN environment where the prior network admin did a flaky job and thinks blinking firewall boxes are 100% secure than just finding port 3389 open to world.

Since RDP access restrictions and policies are actually work.....

Obviously RDP inside a VPN involves a double authentication, and this placates the extra authentication need. The biggest reflex fear with an open port 3389 is that it TELLS the universe, "hey, it's RDP, and likely full administrator rights if you can hack it". Again, I shouldn't be reminding you guys you can't hack a port. You hack the services listening behind the port.

I've been setting up Citrix boxes since the mid-90s, and the biggest fear from open RDP and ICA ports isn't some kid from the Ukraine breaking in, it's an ex-employee (or current employee) getting in off the company lot. Or, even more scary, your head developer's smart alec kid logging in as them at 2am and resetting system accounts. The VPN stops this how?

This is why the biggest way to secure RDP is have everything internally kosher in the first place. All the VPN is going to do is extend the lunacy out beyond the company walls. Don't have common accounts like Administrator enabled for RDP, and and don't assume an RDP connection outside the office is always playing nice. Personally I've always found 'work at home' a waste of company payroll, but that's just me.

At the least, change port 3389 to something more obscure so it doesn't give the kid in Ukraine a clue what it is, or what's behind it. The VPN is obviously frosting on the cake, and otherwise I'm just being cynical about it because that's what's most of my client do. It's just that we find most tampering is done by current/ex-employees or their passwords. The VPN doesn't matter.

So they would need to find a exploit in my VPN, then find a way to steal my private keys/passwords or find exploits in RDP/SSH.

And who watches YOU may I ask? That's the question 99% of CIOs ask me. When you get canned and have 4 minutes to leave the building, what happens to all of this?

 

[sourceninja]

And who watches YOU may I ask? That's the question 99% of CIOs ask me. When you get canned and have 4 minutes to leave the building, what happens to all of this?

Well, my ldap account would be disabled the moment my boss decides to fire me when he fills out the 'terminate employee' workflow. That for the most part locks me down hard.

At that point a whole huge series of events go into motion. First the lost of my ldap privs would disable my access to email, desktop login's around campus, VPN, Databases, etc.

Next the workflow would notify all everyone required. People in my department would then move to do each individuals jobs. Our software specialist would come to my office to reclaim any software I have checked out, Our PC admin would come reclaim my notebook and other hardware. One of the three guys with access to the same stuff I have such as the vpn/tunneling server would revoke my keys (even though access would already be disabled via ldap). Even the network jacks in my room are placed into a 'dead end' vlan automatically. Finally our security admin would disable my ID and forward my extension to where ever the workflow says it should go. Lastly, security would remove me from the premise and take my badge.

About the only thing that could be bad is the fact I know the root passwords. However our servers are behind a firewall on a vlan with very restrictive acls. We have not had to fire an IT person yet, but the last time we had a network admin leave we did change all of those passwords with in 3 days of his departure. I'd have to not just be on campus, but be plugged into a jack on the right vlan to even make use of the root password. (I've also been trying to move all of our systems to all sudo and a disabled root account).

Eventually, someone would then go though and do an audit on my machines in preparation for the replacement. Because our only public facing ssh server would have my account revoked and because my cert for vpn is revoked (and account disabled) anything non-standard I setup would be useless to me anyway. They would also need to go though my computer and read the source code of any checked out projects I may be working on (and if I was fired so rapidly probably read the code of any project I worked on). They would also need to pry my iPad out of my hands.

We have a minimum of 2 people for every critical system. Most systems have 3. We do audits at least twice a year and try to hit them quarterly. Things have come a long way from a single know it all admin and a bunch of support staff when I started. I'm proud of what I've helped build.

Their biggest problem wouldn't be a security concern. It would be how do we find a guy who can handle all this shit for what we can afford to pay.

Yes RDP can be secured and it's probably fine if you only have a handful of computers you need to expose to the internet. Yes, no one should ever be running as admin even locally. However the biggest use of RDP for us is not home workers (who have notebooks and a vpn), but IT staff who need to do administrative functions from off campus. This means using an admin account at some point.

Further more we are obviously only talking about off campus here because you would never use a VPN on campus (vpn from your lan into your lan?). We are also not talking about VDI because there are even better clients for handling that. The VPN really makes sense even with security taken out of the equation. We have probably 50 heavy VPN users. Are you really suggestion that if we wanted to give them RDP access to a desktop we NAT 50 public IP addresses? I have over 80 servers, if I was going to ssh or vnc/rdp into them again I'd need to waste another 80 ip's. Instead I have only 2 public addresses to worry about. The ssh server and the vpn server. We would have just one, but I need that ssh server in case the vpn breaks (I don't want to drive 30 minutes).

I'm more worried about a intern writing a bad piece of code that exposes company data then I am a ex-employee getting access after they are fired.

This is turning out to be a far better discussion then I expected.