Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Background: Currently, we manage our servers through an IP KVM, but we're slooooowly migrating to VMWare ESXi. The KVM interface is clunky and user management is a little cumbersome and I'd like to keep people away from the VIC Console if possible. RDP is not allowed on our network, as all traffic must funnel through the VIC or KVM, which have certificates from an internal CA.

Question: I'm using this transition to push toward RDP for internal management of servers. I'd like to make my case for RDP, but security (even though these servers are not Internet-facing) is still a concern. I've looked at TS Gateway, but it seems that it is for Internet to remote server, not from internal client to internal server. I know this is pretty broad, and please feel free to ask for clarification, but what is the best way to securely implement RDP on internal servers.

share|improve this question

3 Answers 3

up vote 5 down vote accepted

As with any technology -- limit your surface area. Do not leave plain jane RDP open to the world. Require a VPN, or some other sort of pass-through authentication from a trusted vendor (web-ssl gateway, etc).

For internal use -- standard password management policies should be in place with lockout's configured. Configure RDP to use the highest level security (Force RDP to use 128-bit encryption via GPO). RDP is atleast as secure as VIC or most KVM's. Millions of people use Citrix or Terminal Services daily. VIC and a KVM simply don't have this number of installed devices, or people attempting to exploit them. Given two competing mature technologies with no known exploit, I would consider the one with many magnitudes the installed base more secure than the one with a limited installation base typically shrouded inside a private network with proprietary one-vendor tools.

For external clients I would consider a 3rd party secure SSLVPN gateway with client certificate authentication if you want that level of security.

If you seriously don't trust RDP, but do trust, say SSH... there is a commercial RDP over SSH application called WiSSH that can implement two factor authentication along with two separate layers of security.

RDP has been an option on every installation of Windows XP Professional and Windows Server since 2000. It is the remote access management tool for Windows Servers, and has seen very few vulnerabilities in the past 9 years. Even WindowsSecurity.com's list of suggestions are banal in their complexity, and mirror any other management system's best practices.

share|improve this answer
    
These servers are not exposed to the Internet. We already have a secure certificate-based VPN in place for remote management that needs to be done. There is nothing you would recommend besides enforcing the password complexity and lockout policy (which we already do) and enforcing 128-bit via GPO which is point-and-click easy? –  MDMarra Aug 19 '09 at 1:51
    
+1 for this. Terminal Service complains if you don't have a cert installed anyway (at least in 2008), so generating an internal certificate of mega-huge encryption and forcing the correct authentication protocols via GPO is easy, quick, and as secure as any banking website (and they're open to the internet). –  Mark Henderson Aug 19 '09 at 1:58
    
Mark - No offense was implied -- but remote access is by definition less secure than not allowing access. Do you have a specific security concern that strong passwords, password expirations, and lockout policies won't address? Are you concerned with the RDP protocol itself? I don't know your internal justification for not using RDP. There is only so much brute force damage you can do with a 3-tries-your-locked out policy and passwords that expire. –  SirStan Aug 19 '09 at 2:20

As far as using RDP itself you are pretty much limited by what the client and server support and there are only a few versions. With Win2008, Windows 7, Vista, (and apparently XP SP3 as well now) http://technet.microsoft.com/en-us/library/cc732713.aspx, network-level authentication has improved the security of RDP, but as far as securing the protocol itself, your only option is requiring NLA on both the client and server.

Stepping outside of RDP itself you use your network architecture to restrict access to your servers. Put your servers in their own subnet, put your admin PCs in another, and put regular users in yet another. Only allow the admin subnet to get to the server subnet over RDP on your firewall/router and allow the regular user subnet to access the server subnet on only required ports (or everything except RDP). It is a good idea to have your servers in a separate subnet anyway to limit broadcast crosstalk between clients and servers.

share|improve this answer

Most of this has been mentioned, but I thought I would clarify a few things. NLA has been supported (under a different name) for RDP since at least one of the service packs of Windows 2003. Running RDP in "high security" configuration coupled with running RDP over TLS is arguably equally secure to most of the alternative remote management solutions available for windows. I've been securing my RDP sessions over TLS for many years and the XP client has definitely supported connecting to RDP over TLS for an equally many years.

I've also used the TS-Gateway as a way to further secure access between office networks and internal server networks. It generally requires firewall / routing rules between the two networks, but if you are looking to further secure your environment to add an additional authentication requirement, and tunneled entry point, TS-Gateway can still be very useful. But unlike RDP over TLS, TS-Gateway support is very limited from the client perspective.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.