Comments on: Allowing Remote Access to RDP Connections is Hazardous to Your Network’s Health http://blogs.isaserver.org/shinder/2007/04/10/allowing-remote-access-to-rdp-connections-is-hazardous-to-your-networks-health/ Written by Dr Thomas W Shinder, consultant to Microsoft, HP and many Fortune 500 companies on ISA firewall and Web proxy deployments this blog is where administrators get information about ISA Server Universal Threat Management firewalls. Topics include how to manage, deploy, and troubleshoot ISA Server as a network firewall, Web proxy/Web cache, remote access VPN server and VPN gateway to provide a high level of network security for all corporate computers. Wed, 7 Jan 2009 22:09:36 +0000 http://wordpress.org/?v=MU by: Mario Acosta http://blogs.isaserver.org/shinder/2007/04/10/allowing-remote-access-to-rdp-connections-is-hazardous-to-your-networks-health/#comment-160265 Thu, 14 Feb 2008 22:24:29 +0000 http://blogs.isaserver.org/shinder/2007/04/10/allowing-remote-access-to-rdp-connections-is-hazardous-to-your-networks-health/#comment-160265 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) 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)

]]> by: Bill Miller http://blogs.isaserver.org/shinder/2007/04/10/allowing-remote-access-to-rdp-connections-is-hazardous-to-your-networks-health/#comment-90854 Thu, 26 Apr 2007 22:57:33 +0000 http://blogs.isaserver.org/shinder/2007/04/10/allowing-remote-access-to-rdp-connections-is-hazardous-to-your-networks-health/#comment-90854 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 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

]]> by: Thomas Shinder http://blogs.isaserver.org/shinder/2007/04/10/allowing-remote-access-to-rdp-connections-is-hazardous-to-your-networks-health/#comment-90354 Wed, 25 Apr 2007 18:46:41 +0000 http://blogs.isaserver.org/shinder/2007/04/10/allowing-remote-access-to-rdp-connections-is-hazardous-to-your-networks-health/#comment-90354 There are applicatino layer inspection filters for POP3, SMTP and others, just none for RDP. Tom There are applicatino layer inspection filters for POP3, SMTP and others, just none for RDP.

Tom

]]> by: pie8ter http://blogs.isaserver.org/shinder/2007/04/10/allowing-remote-access-to-rdp-connections-is-hazardous-to-your-networks-health/#comment-90352 Wed, 25 Apr 2007 18:38:58 +0000 http://blogs.isaserver.org/shinder/2007/04/10/allowing-remote-access-to-rdp-connections-is-hazardous-to-your-networks-health/#comment-90352 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 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

]]> by: Jeff Wonderly http://blogs.isaserver.org/shinder/2007/04/10/allowing-remote-access-to-rdp-connections-is-hazardous-to-your-networks-health/#comment-87319 Thu, 19 Apr 2007 05:24:02 +0000 http://blogs.isaserver.org/shinder/2007/04/10/allowing-remote-access-to-rdp-connections-is-hazardous-to-your-networks-health/#comment-87319 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 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

]]> by: Stefaan Pouseele http://blogs.isaserver.org/shinder/2007/04/10/allowing-remote-access-to-rdp-connections-is-hazardous-to-your-networks-health/#comment-86314 Wed, 11 Apr 2007 13:10:02 +0000 http://blogs.isaserver.org/shinder/2007/04/10/allowing-remote-access-to-rdp-connections-is-hazardous-to-your-networks-health/#comment-86314 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 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

]]> by: Thomas Shinder http://blogs.isaserver.org/shinder/2007/04/10/allowing-remote-access-to-rdp-connections-is-hazardous-to-your-networks-health/#comment-86189 Tue, 10 Apr 2007 18:57:57 +0000 http://blogs.isaserver.org/shinder/2007/04/10/allowing-remote-access-to-rdp-connections-is-hazardous-to-your-networks-health/#comment-86189 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 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

]]> by: Stefan Pouseele http://blogs.isaserver.org/shinder/2007/04/10/allowing-remote-access-to-rdp-connections-is-hazardous-to-your-networks-health/#comment-86186 Tue, 10 Apr 2007 18:45:21 +0000 http://blogs.isaserver.org/shinder/2007/04/10/allowing-remote-access-to-rdp-connections-is-hazardous-to-your-networks-health/#comment-86186 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 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

]]> by: Ian Banyard http://blogs.isaserver.org/shinder/2007/04/10/allowing-remote-access-to-rdp-connections-is-hazardous-to-your-networks-health/#comment-86158 Tue, 10 Apr 2007 15:33:50 +0000 http://blogs.isaserver.org/shinder/2007/04/10/allowing-remote-access-to-rdp-connections-is-hazardous-to-your-networks-health/#comment-86158 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!!!! 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!!!!

]]>