Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 844
  • Last Modified:

Secure RDP Sessions to Windows Server 2003 with SSH like key?

Is it possible to set up a public / private key arrangement to secure Windows terminal services, much like Linux secures ssh connections?
0
JP_TechGroup
Asked:
JP_TechGroup
1 Solution
 
dmarinenkoCommented:
Unfortunately not by defualt or a simple setting, here is how RDP works on the encryption side http://www.oxid.it/downloads/rdp-gbu.pdf
What you can use is a VPN or you can implement an RDP/SSH combo
http://www.softwaresecretweapons.com/jspwiki/windowsremotedesktopoverssh
0
 
JP_TechGroupAuthor Commented:
OYE! and OYE again.
Heaven forbid it should be easy!
Unfortunately, my users are doing well if they can remember which icon to click on and what their password is. Adding another layer of user interactive security is not an option. Thus, I was hoping for a public/private key setup that need only be configured once on each machine.

Are there other commercial alternatives that are seamless or at least more seamless the ssh or vpn? Google isn't bringing up much. Thanks.
0
 
kevinhsiehCommented:
The latest version of the RDP client allows the client to authenticate the server via standard certificates over TLS. This is if you are concerned about man in the middle attacks over your LAN. If you are connecting over the Internet, you should be using Remote Desktop Gateway, which wraps the RDP traffic inside SSL/TLS and uses computer certificates to authenticate the servers and encrypt the connections. This only works with Windows XP SP3 clients and better and Windows 2008 Servers or better.

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

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

http://blogs.technet.com/b/askperf/archive/2008/02/16/ws2008-network-level-authentication-and-encryption.aspx
0
Threat Trends for MSPs to Watch

See the findings.
Despite its humble beginnings, phishing has come a long way since those first crudely constructed emails. Today, phishing sites can appear and disappear in the length of a coffee break, and it takes more than a little know-how to keep your clients secure.

 
JP_TechGroupAuthor Commented:
In title:
Secure RDP Sessions to Windows Server 2003...
:)
0
 
kevinhsiehCommented:
Sorry, I missed that. Use TS Gateway or IPSec.
0
 
JP_TechGroupAuthor Commented:
Ok, riddle me this. How is vpn any more secure against brute force attacks? The MITM attacks are less of a concern then this much more real threat, which we are currently dealing with. What am I missing?
0
 
Aaron TomoskyTechnology ConsultantCommented:
VPN is easy to configure with certs. That's how. Also with multiple rdp hosts you increase your points of entry but with VPN you have a single point to monitor
0
 
kevinhsiehCommented:
What exactly is the threat model that you are concerned with?

RDP is encrypted to begin with, but is subject to MITM because the client doesn't normally authenticate the end point, and you can't authenticate it with Windows 2003. RDP uses 128 bit RC4 or TLS, so crptographic attack against the data stream isn't practical. If you connect to TS Gateway (available on  SBS 2003 or Windows 2008, can be used with 2003 TS server), the RDP protocol in tunneled inside an SSL session, which is authenticated via computer certificates just like SSL in your browser. That is very secure from an authenticated endpoint and data privacy standpoint.
0
 
Dave HoweSoftware and Hardware EngineerCommented:
It is possible to use client certificate authentication with recent versions of MSTSC - you need to have a corporate CA, but that's standard as well these days.
0
 
JP_TechGroupAuthor Commented:
Kevin,
We are experiencing a prolonged brute force attack on our terminal server from multiple IPs which change every 24 hours or so. Ideally, I would like to prevent anyone that does not have a key or certificate installed on their PC which matches a corresponding key or certificate from even being able to connect.

0
 
kevinhsiehCommented:
So if I understand correctly, you have a Windows 2003 terminal server that has TCP 3389 directly exposed to the Internet, and you are seeing connections from the Internet that are trying to brute force passwords against your servers. Is that correct?

If the above is correct, I do not see any native way in Terminal Services 2003 to require additional client authentication. I think that you can require smart cards if you have them, or some other 2 factor authentication mechanism.

If you installed a firewall or VPN that authenticated connections before you hit the terminal server that may help. ISA can do this; but again you really are looking for something that requires more than a username + password.

Setting up IPSec if the Internet endpoint are part of the domain should work, but I have never dealt with it.

If you have Windows 2008/R2 available, you can use a Remote Desktop Gateway which indicates that you can require that the client machine be a member of a specific group, but there are little details on how that works.
http://technet.microsoft.com/en-us/library/cc753324.aspx

Long story short, there is no easy way. You should make sure that all user passwords are strong. You can also have this same problem against VPN servers, SMTP servers, OWA, and anything else that accepts a logon.

My firewall filters out all inbound traffic that originates from IP blocks that are assigned outside of the United States. I can post that if you want. It cuts down on a lot of garbage traffic.


0
 
kevinhsiehCommented:
remark Block traffic from International Networks and invalid networks
 deny   ip 0.0.0.0 0.255.255.255 any
 deny   ip 1.0.0.0 0.255.255.255 any
 deny   ip 2.0.0.0 0.255.255.255 any
 deny   ip 5.0.0.0 0.255.255.255 any
 deny   ip 10.0.0.0 0.255.255.255 any
 deny   ip 23.0.0.0 0.255.255.255 any
 deny   ip 27.0.0.0 0.255.255.255 any
 deny   ip 31.0.0.0 0.255.255.255 any
 deny   ip 36.0.0.0 0.255.255.255 any
 deny   ip 37.0.0.0 0.255.255.255 any
 deny   ip 39.0.0.0 0.255.255.255 any
 deny   ip 42.0.0.0 0.255.255.255 any
 deny   ip 57.0.0.0 0.255.255.255 any
 deny   ip 58.0.0.0 0.255.255.255 any
 deny   ip 59.0.0.0 0.255.255.255 any
 deny   ip 60.0.0.0 0.255.255.255 any
 deny   ip 61.0.0.0 0.255.255.255 any
 deny   ip 62.0.0.0 0.255.255.255 any
 deny   ip 77.0.0.0 0.255.255.255 any
 deny   ip 78.0.0.0 0.255.255.255 any
 deny   ip 79.0.0.0 0.255.255.255 any
 deny   ip 80.0.0.0 0.255.255.255 any
 deny   ip 81.0.0.0 0.255.255.255 any
 deny   ip 82.0.0.0 0.255.255.255 any
 deny   ip 83.0.0.0 0.255.255.255 any
 deny   ip 84.0.0.0 0.255.255.255 any
 deny   ip 85.0.0.0 0.255.255.255 any
 deny   ip 86.0.0.0 0.255.255.255 any
 deny   ip 87.0.0.0 0.255.255.255 any
 deny   ip 88.0.0.0 0.255.255.255 any
 deny   ip 89.0.0.0 0.255.255.255 any
 deny   ip 90.0.0.0 0.255.255.255 any
 deny   ip 91.0.0.0 0.255.255.255 any
 deny   ip 92.0.0.0 0.255.255.255 any
 deny   ip 93.0.0.0 0.255.255.255 any
 deny   ip 94.0.0.0 0.255.255.255 any
 deny   ip 95.0.0.0 0.255.255.255 any
 deny   ip 100.0.0.0 0.255.255.255 any
 deny   ip 101.0.0.0 0.255.255.255 any
 deny   ip 102.0.0.0 0.255.255.255 any
 deny   ip 103.0.0.0 0.255.255.255 any
 deny   ip 104.0.0.0 0.255.255.255 any
 deny   ip 105.0.0.0 0.255.255.255 any
 deny   ip 106.0.0.0 0.255.255.255 any
 deny   ip 109.0.0.0 0.255.255.255 any
 deny   ip 110.0.0.0 0.255.255.255 any
 deny   ip 111.0.0.0 0.255.255.255 any
 deny   ip 112.0.0.0 0.255.255.255 any
 deny   ip 113.0.0.0 0.255.255.255 any
 deny   ip 114.0.0.0 0.255.255.255 any
 deny   ip 115.0.0.0 0.255.255.255 any
 deny   ip 116.0.0.0 0.255.255.255 any
 deny   ip 117.0.0.0 0.255.255.255 any
 deny   ip 118.0.0.0 0.255.255.255 any
 deny   ip 119.0.0.0 0.255.255.255 any
 deny   ip 120.0.0.0 0.255.255.255 any
 deny   ip 121.0.0.0 0.255.255.255 any
 deny   ip 122.0.0.0 0.255.255.255 any
 deny   ip 123.0.0.0 0.255.255.255 any
 deny   ip 124.0.0.0 0.255.255.255 any
 deny   ip 125.0.0.0 0.255.255.255 any
 deny   ip 126.0.0.0 0.255.255.255 any
 deny   ip 175.0.0.0 0.255.255.255 any
 deny   ip 176.0.0.0 0.255.255.255 any
 deny   ip 177.0.0.0 0.255.255.255 any
 deny   ip 178.0.0.0 0.255.255.255 any
 deny   ip 179.0.0.0 0.255.255.255 any
 deny   ip 180.0.0.0 0.255.255.255 any
 deny   ip 181.0.0.0 0.255.255.255 any
 deny   ip 182.0.0.0 0.255.255.255 any
 deny   ip 183.0.0.0 0.255.255.255 any
 deny   ip 185.0.0.0 0.255.255.255 any
 deny   ip 186.0.0.0 0.255.255.255 any
 deny   ip 187.0.0.0 0.255.255.255 any
 deny   ip 189.0.0.0 0.255.255.255 any
 deny   ip 190.0.0.0 0.255.255.255 any
 deny   ip 193.0.0.0 0.255.255.255 any
 deny   ip 194.0.0.0 0.255.255.255 any
 deny   ip 195.0.0.0 0.255.255.255 any
 deny   ip 197.0.0.0 0.255.255.255 any
 deny   ip 200.0.0.0 0.255.255.255 any
 deny   ip 201.0.0.0 0.255.255.255 any
 deny   ip 202.0.0.0 0.255.255.255 any
 deny   ip 210.0.0.0 0.255.255.255 any
 deny   ip 211.0.0.0 0.255.255.255 any
 deny   ip 212.0.0.0 0.255.255.255 any
 deny   ip 213.0.0.0 0.255.255.255 any
 deny   ip 217.0.0.0 0.255.255.255 any
 deny   ip 218.0.0.0 0.255.255.255 any
 deny   ip 219.0.0.0 0.255.255.255 any
 deny   ip 220.0.0.0 0.255.255.255 any
 deny   ip 221.0.0.0 0.255.255.255 any
 deny   ip 222.0.0.0 0.255.255.255 any
 deny   ip 223.0.0.0 0.255.255.255 any
0
 
JP_TechGroupAuthor Commented:
Accurate answer, just not the answer I wanted... and frankly Microsoft, not the answer I should have to accept.
0

Featured Post

Managing Security & Risk at the Speed of Business

Gartner Research VP, Neil McDonald & AlgoSec CTO, Prof. Avishai Wool, discuss the business-driven approach to automated security policy management, its benefits and how to align security policy management with business processes to address today's security challenges.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now