MSTSC RDP over the public internet

Question

My first question so please be gentle :)

I have a client who is insisting that they have to let their third party vendor support access to there server directly from the internet via RDP.

Our policy does not allow direct access to the infrastructure from outside of the data centre for administration except from an approved VPN connection and then virtual desktop there on to the servers.

I am now in the situation where I must give good reasons why it is dangerous to use RDP over the public internet.

any help would be appreciated

Thanks in advance

Stuart

Answer 1

Don't forget that an intruder that compromises that server could also use it as a springboard to attack other customers' facilities behind the firewall. Thus, security risk is not solely confined to the first customer's assets.

Get some justification from the vendor as to why they can't use the VPN. If there is genuinely no alternative to RDP connection direct to the server then they need to take responsibility for any security breaches through that connection. Bear in mind that the vendor has just admitted to security flaws in their application architecture by stating that there is something about the application that precludes the use of the VPN.

Make the access conditional on their signing an agreement indemnifying you against any damage caused by a security breach through the RDP connection. In addition you should require them to obtain suitable professional indemnity or liability cover or provide proof of existing cover with terms that would cover this situation.

In short, make the vendor prove that they can afford to pay for any damages and make their access conditional on a contractual obligation to do so.

Answer 2

Most people that have a problem with allowing RDP directly from the internet have a specific set of concerns around the idea that intruders are directly querying your directory / SAM for authentication. Without proper auditing this often goes un-noticed. Once they've successfully obtained a single logon pair they have uninhibited access to your environment. Microsoft's response to this came with Windows 2008 in the form of TS-Gateway. TS-Gateway services create a tunnel point not all that dissimilar to establishing an SSL VPN tunnel. The TS-Gateway service while it still is sharing the same directory or SAM for authentication provides a separate set of authorization rules that didn't exist before. Both user and computer level rules can be set to control what resources you have available to you once authenticated to the TS-Gateway. So 1 you don't have to set up external dns name mappings to all of your internal servers and 2 you can restrict specific users (groups of users) to specific systems.

I have also done implementations where TS-Gateway access users are a separate account from those that have access to the internal servers. With a much higher password expiration and lockout on the TS-Gateway accounts. This provides one more layer for those paranoid about direct pass through authorization. It also works well for groups with specific business policy regarding DMZ systems being a member of an internal domain.

My biggest problem (as with others) with TS-Gateway thus far is it's lack of support for two-factor auth options for the initial gateway connection. The second biggest being the lack of client support for TS-Gateway.

However in your case assuming your external vendor agrees to use a 6.1 compliant RDP client and you take care in your setting up of a proper TS-Gateway server there should be little reason why the request should pose a threat.

Answer 3

Even if RDP is configured to use encryption, you still allow a direct access to your server. If you have a firewall and only allow your vendor IP to connect to the RDP port it could be Ok but if you leave it open from any IP it's dangerous if there is a security problem a day on RDP.

I recommand to use a VPN Gateway like an Cisco ASA with an WEB SSL VPN access. The Web portal then allow to forward port to remote server, or even better you can run an RDP applet (directx or java) on the portal. This solution is more secure, and work without any vpn client installed on the vendor computer. It just need a browser that support SSL and Java or DirectX

Answer 4

I know the question is answered, but here's some guidance if you are required to go through with it. First, if you have the option, consider the use of a TS gateway. Info here in this KB article:

Remote Desktop Connection (Terminal Services Client 6.0)

Another option is to map the port using your firewall so that it's not TCP/3389, a well known port. You want to avoid the well known ports which will be hit by typical scans.

How to change the listening port for Remote Desktop

Answer 5

I heard that there is a new technology just for Windows 2008 R2 what is called "Direct Access" it is essentially a VPN over SSL build into the OS, i think it requires Windows 2008 R2 and Windows 7 as a client, but it is another option and may be cheaper than investing in another solution like F5, or Cisco.

Technical Overview

Answer 6

As far as you're using at least RDP 6.0, i see no bad in it. Some of my TS servers are openly accessible from internet, but only allow 6.0+ security (with TLS also on XP).