Allowing Remote Access to RDP Connections is Hazardous to Your Network’s Health
I was talking to a few MS security guys last week about the number of methods Microsoft provides for remote access to corporate resources. It was an interesting exercise to come up with a list of products and technologies that Microsoft has to provide remote access, and sometimes even secure remote access.
Some examples remote access of these products and technologies include:
- ISA Firewall Web Publishing
- ISA Firewall Server Publishing
- ISA Firewall VPN server
- IAG 2007 SSL VPN Gateway
- RRAS PPTP and L2TP/IPSec VPN server
- Longhorn RRAS SSTP VPN server
- RRAS Reverse NAT
- Windows Dial up RAS Server
- Remote Desktop Web Connection (RDP)
Of all of these methods of remote access to resources on the corporate network, which one do you think is the least secure? When I said that RDP was by far the least secure method, I was surprised to hear several of the others ask me why I thought that was the case, because it never occurred to them that RDP would be least secure, much less unsecure.
The answer if actually quite easy and the reasons transparent when you try to live your life by principles. And as a security specialist, which principle do you think would be the most overarching? The answer is the principle of least privilege. When you think of security as a method of applying least privilege to all connections to your network, you’ll see why RDP is the least secure option and in fact should be banned from all remote access schemes.
For example, think of secure Exchange RPC publishing and RPC/HTTP. Both these methods can be deployed through the ISA Firewall make it possible to get full Outlook MAPI client connectivity without requiring a VPN connection. Network security admins realized that requiring full network level connectivity through a VPN connection was ridiculous when only Outlook MAPI connectivity was required, so solutions such as secure Exchange RPC and RPC/HTTP publishing were implemented.
Now think about RDP publishing. This is the opposite of the principle of least privilege. In fact, when you provide remote access to RDP connections to corporate desktops or RDP servers you’re actually implementing the principle of maximum privilege, which puts your network at significant risk.
Consider the situations of secure Exchange RPC publishing and RDP publishing from a hacker’s point of view. When the attacker tries to compromise the RPC publishing solution, the target of the attack is going to be limited to what he might be able to do to the Exchange Server through the secure Exchange RPC connection. Since there are no reported exploits or flaws with the secure Exchange RPC publishing solution, the attacker is stopped in his tracks. Good guys one, bad guys zero.
Now consider the scenario when the attacker is able to hack into an RDP session. When the attacker has connected to the desktop or server over RDP, that hacker will own the box. There will be very little effort required on the attacker’s part to reconnoiter the network, place a network sniffer to capture user names and passwords moving over the network, and work with great stealth with a full complement of hacker tools that will enable him to steal, change and destroy data on the network, all with the credentials of a legitimate user.
Enabling remote access to corporate networks over RDP is a recipe for disaster, as you needlessly expose your network to the worst case scenario — a machine completely owned by a malicious user. In contrast, with the ISA Firewall and IAG 2007 publishing — users are provided restricted access to specific services and that access is controlled via strong application layer intelligence to slow or stop hackers from compromising the service made available to the users.
Even VPN is more secure, as you can configure the ISA Firewall’s VPN server to provide per user/group access to specific servers and protocols and apply both stateful packet and application layer inspection to those connections to help insure that they’re clean. With RDP, you provide a nice clear channel for intruders to not only own the machine that the RDP connection is made to, but to the entire network, because you gave them full access to a machine to launch the attack and provided no security measures to stop them.
Some might argue that strong authentication will mitigate the RDP security problem. While authentication and authorization are important aspects of security, they are not complete in and of themselves. A comprehensive security solution takes into account authentication, authorization, access control, packet inspection, application inspection, monitoring and reporting. With RDP connection you have no application inspection, no monitoring and no reporting. You have no idea what is being done on the RDP server to which the user or attacker is connected to, and you have no control over what that user can do over the RDP channel.
Bottom line: Providing remote access to RDP servers on your corporate network is hazardous to your company’s health. Remote access to RDP servers is a ticking time bomb that should be defused by removing all remote connections to RDP and applying least privilege by allowing access only to specific services that might be required and by applying application layer inspection to those connections.
HTH,
Tom
Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

Ian Banyard Says:
April 10th, 2007 at 9:33 am
I guess you could go somewhere with protecting RDP with client certs. By not making a higher level (root) cert available you could restrict access to clients… however not infallible as you only need an older version of the TS client to bypass!!!!
Stefan Pouseele Says:
April 10th, 2007 at 12:45 pm
Hi Tom,
and what if only Terminal Services Remote Programs (Longhorn) are available and *not* complete desktops. That’s similar to the Citrix application publishing.
Thanks,
Stefaan
Thomas Shinder Says:
April 10th, 2007 at 12:57 pm
Hi Stefaan,
Yes, that would go a long way at protecting RDP connections, since you’re not providing a complete desktop environment to the attacker. However, the attacker may be able to leverage weaknesses in the appilcation to gain desktop access, which would put us in the same position as before. There still needs to be a gateway that ensures that “known good” communications are only allowed to the destination and that application layer inspection is done before reaching the destination. This is really problematic for RDP, although I suppose theoretically it could be done.
Tom
Stefaan Pouseele Says:
April 11th, 2007 at 7:10 am
Hi Tom,
on the other hand application layer inspection is not available for general client/server applications. So, in practice we can enforce application layer inspection only to web based traffic.
Moreover, a lot of general client/server applications can only run happily over a WAN infrastructure when they are delivered through a TS/Citrix infrastructure. This has all to do with bandwidth constraints. Thus, there is no way to thoroughly inspect those communications and the only thing we can do is trying to pre-authenticate the connection in a strong way.
Any suggestion to solve such problems… ?
Thanks,
Stefaan
Jeff Wonderly Says:
April 18th, 2007 at 11:24 pm
I use a Checkpoint edge appliance on my set-up. The user has to establish the tunnel to the Checkpoint first, using the Checkpoint VPN-1 SecureClient. Then the rule in the Checkpoint says Allow and Forward only if the connection is encrypted and only if it comes in on the specific TCP high port(50000+) I assigned them. I pass that straight through to ISA, where I have a listener for each published desktop. ISA then redirects it to port 3389 on the published machine. Now they have 3 chances to present the correct username and secure password before they are locked out. Even if they did make it through to that machine, the user accounts are restricted, so they would then need a new exploit to get admin privledges.
I don’t lose any sleep over the few desktops I have published.
Jeff
pie8ter Says:
April 25th, 2007 at 12:38 pm
Stefaan,
Are you saying that application layer inspection is not available for client/server protocols like SMTP and POP?
Then what does the SMTP filter in ISA do? I thought filters, among other things, inspect packets at layer 7.
Thanks
Thomas Shinder Says:
April 25th, 2007 at 12:46 pm
There are applicatino layer inspection filters for POP3, SMTP and others, just none for RDP.
Tom
Bill Miller Says:
April 26th, 2007 at 4:57 pm
Tom;
I am glad to see your discussion On RDP and the emails below. My question is very simple. As a network Support industry — we definately utilize RDP to remotely support our clients quickly and efficently.
We just use very difficult usernames (Min 10 characters of Mix Cased, numbers and symbols, as well as highly exotic password accounts — again min 10 characters, mixed cased, numbers and symbols) and these accounts are limited to 1 single user having RDP access to the public firewall. Access is restricted to 2 strikes and Lock for 24 hours. This just means that we need to be extremely careful when logging on. Ususally copy and paste works best for this, when making the first mistake. I believe, It would take over a Millenia to break this combination with over a 1000 Cray computers working continously.
I believe your premus to be true and correct - but what you can’t try to hack you can’t get in to expoit.
After all we must keep our customers 1st (and usually this means their $ budgets as well).
You maybe able to avoid the $$ Cost and expense of Utilizing a Checkpoint Edge Firewall. But many of the Small to Mid size business’s can not.
RDP can be successfully and securely implemented — and I also sleep well.
Please comment. or Suggest and improvement with what is available on ISA 2004 or 2006.
Thanks
Mario Acosta Says:
February 14th, 2008 at 4:24 pm
Hi Tom:
what do you think about what IAG 2007 offers for publishing remote desktop?
It offers 1) Microsoft XP Terminal Services client and 1) Terminal Services Web Client (single and multiple server)