Windows Client/Server Hardening Part 2: Securing Remote Desktop with Certificates.

Securing Remote Desktop with Certificates from your Internal CA.

Implementing Remote Desktop with Certificates

In this post I’m going to be following on from Part 1 located here, talking about further hardening the Windows Remote Desktop Protocol (RDP) with a certificate based system. The certificate is generated and signed by an internal Active Directory Certificate Authority (CA). The issue here being that you have no way of verifying the server or PC that you are trying to connect to via RDP. The machine that you are supposedly connecting to usually presents you with a certificate that is signed by itself, funnily enough known as a ‘self signed certificate’.

The Attack…

The play by an attacker here being that should they have exploited a vulnerability and been able to access your internal network (not for this discussion, however..), they could essentially respond to ARP request by modifying responses sent by an attackers machine. This is done by flooding the network with bad ARP responses, known as ARP poising, the whole attack is known as a Man In The Middle (MITM). There are many ways of carrying out a MITM attack, this just one of them. Once a MITM attack is in play and your arp cache is then poisoned you would essentially be connecting to an attackers machine. The attacker can then sniff the network traffic and all sorts of other rather bad things can happen, like stealing credentials.

A typical self signed certificate presented through RDP looks like the picture above, and clearly states the certificate is not from a trusted certificate authority. If your PC can trust the certificate that is presented by the machine you are connecting too, through the use of a bonafide signed certificate from your internal CA you would know whether or not the machine you are connecting to is genuine. More importantly, through the use of Group Policy you can specify that you are not able to connect to it unless you trust it. Thus preventing any bad MITM rdp sessions.

How do we fix it…

Carlos Perez has written up an excellent ‘how to’ guide from start to finish on how to setup this up. He walks through the certificate templates required for the RDP service. Also setting up group policy to deploy the certificate. This is a great guide so I’m not going to re-regurgitate his excellent work going through all the various screen shots, you can view it here at http://www.darkoperator.com/blog/2015/3/26/rdp-tls-certificate-deployment-using-gpo .

Facebooktwittergoogle_pluspinterestlinkedinmail

Windows Client/Server Hardening Part 1: Remote Desktop

We can harden the Windows Client/Server Remote Desktop Protocol (RDP) in several ways using either local settings or preferable through Group Policy. As a minimum we should harden RDP in the following ways:

  • Using Network Level Authentication (NLA).
  • Setting Terminal Services Encryption Level to High.
  • Force the use of TLS 1.0 protocol as a transport layer for the service.
  • Setting the local security policy of the either the server or client to use only FIPS-140 compliant cryptography.

This post will we go through how we can accomplish these tasks.

Network Level Authentication (NLA)

Network level authentication allows the client to authenticate earlier in the remote connection process rather than the normal process.  This option is most commonly seen in the Remote Desktop settings in the system properties as below:

RDP - NLA
Remote Desktop Settings – Network Level Authentication

However it is far easier to set this via Group Policy and distribute to all your Servers as below:

RDP- NLA GPO
Remote Desktop Services – Network Level Authentication GPO

This can be applied to both Servers and workstations from Windows Vista and above.

Setting Terminal Services Encryption Level to High

Setting the Encryption level to High encrypts data sent from client to server and server to clients using 128 bit encryption. Like with the above example we can set the Terminal Services Encryption level to High either locally on the server or via Group Policy. In a domain environment the GPO is the way to go. With windows server 2008 this could be set locally through the GUI by navigating from the start menu–>Administrative Tools–>Remote Desktop Services–>Remote Desktop Session Host Configuration, then double clicking on the ‘RDP-TCP’ connection in the middle of the screen. The Encryption level can be found on the General tab as below:

Remote Desktop Services - Encryption Level 'High'
Remote Desktop Services – Encryption Level ‘High’

Unfortunately Microsoft removed the  ‘RD Session Host Configuration’ options as standard with Server 2012 R2. Rather than adding in the whole RDS role to apply this option in the GUI you can apply it via GPO which will in turn apply to both 2008 and 2012 as below:

RDP - Encryption Level High GPO
Remote Desktop Services – Encryption Level High GPO

Force the use of TLS 1.0 protocol as a transport layer for the service

Forcing the use of TLS 1.0 mitigates the risks associated with SSL 3.0 protocol. Like with the previous option this can only be set in the GUI locally on Windows Server 2008. With this being said, and from a management perspective GPO is our preferred option, in order to apply this setting to both Windows Server 2008 and 2012.

This option is set in Windows Server 2008 locally by navigating from the start menu–>Administrative Tools–>Remote Desktop Services–>Remote Desktop Session Host Configuration, then double clicking on the ‘RDP-TCP’ connection in the middle of the screen as below:

RDP - TLS 1.0
Remote Desktop Services – Security Layer TLS 1.0

The GPO is located here:

RDP - TLS 1.0 GPO
Remote Desktop Services – Security Layer TLS 1.0 GPO

Setting the local security policy of the either the server or client to use only FIPS-140 compliant cryptography

This hardening technique can be accomplished by enabling the ‘System Cryptography’ through the Local computer policy editor or through GPO via the domain. It will force the use of FIPS-140 compliant cryptography for either the client or server across the system. This is windows system setting rather than an RDP setting, however by setting this you will be forcing the use of FIPS-140 compliant cryptography for Remote Desktop settings. If this setting is enabled only the FIPS-140 approved cryptographic algorithms are used: 3DES and AES for encryption, RSA or ECC public key for TLS key exchange and SHA256, SHA284 and SHA512 for TLS hashing. In the case of Remote Desktop it will only use 3DES.

Adding through the local computer policy can be achieved by opening a Microsoft Managment Console (MMC) adding a snap in; Group Policy Object Editor. As below:

RDP - FIPS-140
Remote Desktop Services – FIPS-140 ‘Enabled’

Setting via GPO can be achieved as below:

RDP - FIPS-140 GPO
Remote Desktop Services – FIPS-140 GPO

Hardening RDP – GPO Settings

Putting all these settings together in one GPO would look something like this:

Hardening RDP - GPO settings
Hardening RDP – GPO settings

It clearly goes without saying you should first test these methods out for yourself in a safe test environment first before diving into your main production domain or web servers. Adding higher grade encryption to your communications across the domain may have extra computation costs in terms of performance on your network.

Facebooktwittergoogle_pluspinterestlinkedinmail