This blog post will focus on the configuration of secure RDP (Remote Desktop Protocol) access for a jumphost/PAW (Privileged Access Workstation) to a DC (Domain Controller), such that the jumphost/PAW is the only computer which the DC will accept ingoing RDP connections from. Additionally, I will protect the RDP connection between the hosts with IPSec. This guide is designed for connections between a jumphost/PAW and a DC, but it can be used for any Windows computers of Vista/Server 2008 and later.
PAW (Privileged Access Workstation)
A physical workstation with maximal security hardening. It should only be used for management of critical servers like a DC, and daily activity as email and Internet browsing should be blocked, to prevent hackers to enter via these ways.Jumphost (or jump-server/jump-box)
A jumphost is the same as a PAW, however, the jumphost is usually a server shared amongst system administrators whereas the PAW is often a dedicated physical workstation assigned to each administrator. You will often log in to a jumphost over the network from your workstation and RDP to the critical server. PAW is a better solution security vice since the clean-source principal is broken with a shared server accessed by regular Tier 2 workstation. However, PAW is not necessarily the favored solution by system administrators, because of the need for an extra dedicated workstation.
Check out my colleague’s Nichlas Falk’s blogpost on PAW and jumphost for further details and how to deploy: https://improsec.com/tech-blog/paw
Content of this post:
What is IPSec?
a. IPSec protocols
b. Operation modes
c. Establishment of an IPSec connection
d. IPSec in Windows and Active Directory
Create GPOs
a. RDP IPSec GPO
b. Ingoing RDP restrictions GPO
Before deploying - a common problem when testing
Deploy GPOs
Confirm IPSec connection with WDFAS
Confirm IPSec connection with Wireshark
Skip to section 2, 3, and 4 if you only want to know how to set it up.
What is IPSec?
Internet Protocol Security (IPsec) is a secure network protocol implemented as an add-on in IPv4 to protect communication. It provides data confidentiality, data integrity, and data authentication between participating peers at the IP layer, which prevents impersonation, data tampering, eavesdropping, and replay attacks. IPSec is integrated into the Windows Defender Firewall.
IPSec protocols
IPSec consist of the following two protocols:
Authentication Header (AH)
AH provides authentication and integrity of the IP packet. The IP header and IP payload are hashed together and the hash is used to build an AH header, which is appended to the original packet. If the receiver will also hash the IP header and IP payload to check if it matches the AH header hash. If the hashes do not match, the header or data must have been tampered with. A few IP header fields like TTL are excluded from the hash, as they will change in legitimate traffic. The IP addresses in the IP header are not excluded from the hash, which is why Network Address Translation (NAT) invalidates the packet. Though, NAT-T (NAT traversal) for IPSec makes it possible to use transport mode and NAT without conflict. AH may also prevent replay attack, by requiring a sequence number in the header. It does not provide confidentiality, as the IP packet is not encrypted.
Encapsulating Security Payload (ESP)
ESP provides confidentiality, integrity, anti-replay, and optional authentication. The IP packet is encryption with symmetric-key encryption.
Operation modes
IPSec have two operation modes. Both modes can be used with AH, ESP, and AH combined with ESP.
Tunnel mode
The entire IP packet is encapsulated inside another IP packet. It is primarily meant for network-to-network or host-to-network communication (e.g. VPN) but can also be used for host-to-host as well.
Tunnel mode with AH:
Tunnel mode with ESP:
Transport mode
Transport mode is meant for host-to-host communication. ESP will only encrypt and authenticate the payload of the IP packet, not the IP header.
Transport mode with AH:
Transport mode with ESP:
(Tunnel / transport figures source: https://www.ciscopress.com/articles/article.asp?p=25477)
If AH and ESP are used in combination, the AH header comes on top of the ESP header, where “on top” is left in the figures above.
Establishment of an IPSec connection
Before two hosts can communicate with IPSec, they need to agree on three Security Associations (SAs). A SA is a set of security parameters; encryption algorithm, encryption key length, integrity (hash) algorithm, and more. The three SAs:
IKE SA: For a bidirectional secure channel, where IPSec SAs can be negotiated.
IPSec SAs: For IPSec data transfer. One secure channel for ingoing traffic and one for outgoing.
This happens in the Internet Key Exchange (IKE) protocol.
Internet Key Exchange (IKE)
IKE is used for the negotiation of IPSec SAs and the establishment of secure channels. IKE consists of two phases:
IKE phase 1: Main Mode or Aggressive Mode
Phase 1 authenticates peers with the ISAKMP protocol and negotiates IKE SA. When peers agree on an IKE SA, they establish a bi-directional secure, authenticated channel for phase 2. Phase 1 is resource-intensive and time-consuming. The main mode protects the identity of the peers and the hash of the shared key by encrypting them, the aggressive mode does not. Aggressive mode is, therefore, less resource-intensive.
IKE phase 2: Quick mode
Phase 2 uses the channel defined by the IKE SA to negotiate IPSec SA and exchange encryption keys. When the peers agree on an IPSec SAs, they establish at least two unidirectional, secure, authenticated channels, one for inbound data transfer and one for outbound. IPSec SAs are periodically renegotiated and new encryption keys are generated. After IKE phase 1 and 2, the IPSec connection is established.
After IKE phase 1 and 2, the IPSec connection is established.
IPSec in Windows and Active Directory
In Windows, IPSec peers can be authenticated using Kerberos (user or computer), NTLMv2, certificates, or pre-shared keys.
For IKE phase 1, Windows only supports the secure main mode and not aggressive mode.
IPSec can be configured locally in Windows in Windows Defender Firewall with Advanced Security (WDFAS) or deployed to multiple domain-computers with a GPO. There are two places for creating IPSec rules in Group Policy Management Editor: WDFAS or IP Security Policies on Active Directory (ISPAD):
It is simplest to configure and manage IPSec rules in WDFAS, where rules are created almost as normal firewall rules. But with simplicity comes limitations - IPSPAD allows you to setup IPSec rules in a more advanced and customized manner. I will only use WDFAS in this post.'
Create GPOs
First, we need to decide the specifications for the IPSec connection we want:
IPSec operation mode: Transport mode
Tunnel mode is the most secure operation mode of IPSec, but Windows can only set up a tunnel with endpoints defined by IP addresses. You can set endpoints with DNS name in transport mode, which makes management easier. Also, the only feature in tunnel mode, which is not possible in transport mode, is an encryption of the original IP header. This is not relevant for the jumphost/PAW to DC setup, as the extra unencrypted IP header in tunnel mode will contain the same information as the original IP header. Therefore, we choose the transport mode.
IPSec algorithm: ESP
Since we will require encryption for the RDP sessions ESP will be chosen, as ESP encrypts the IP payload. AH can additionally provide authentication and tamper-protection for the IP header, but that is needless for RDP connections with an encrypted IP payload. If internal network traffic was subject to inspection or a business requirement denying encryption existed, AH would be the preferred IPSec algorithm.
We want to control the configuration with GPOs. We need to create two:
RDP IPSec
Applied on both jumphost/PAW and DC to enable RDP communication with IPSec.
Ingoing RDP restrictions
Applied on DC to allow ingoing RDP from only the jumphost/PAW and require the connection to use IPSec transport mode with ESP.
RDP IPSec GPO
This GPO will request the computer to authenticate RDP connections with IPSec.
It should contain these two Connection Security Rules:
The steps to create the GPO:
Create a new GPO called RDP IPSec and open it in the Group Policy Management Editor.
Go to Connection Security Rules under Computer Configuration > Policies > Windows Settings > Security Settings > WDFAS > WDFAS.
Right-Click, and choose New Rule...
Set Rule Type to Custom.
5. Set Endpoint 1 and Endpoint 2 to Any IP address.
6. Set the authentication requirement to Request authentication for inbound and outbound connections.
If we choose Require instead of Request for inbound, we would not be able to RDP into the jumphost without having configured IPSec on our workstation. If we were to setup only a physical PAW and not a jumphost, we could choose the Require option. Be careful with that option. If you apply the GPO with Require on the DC before the PAW, you will not be able to RDP into the DC. The Ingoing RDP restrictions GPO will make sure that IPSec authentication will be a requirement.
7. Set the Authentication Method to Computer (Kerberos V5).
We want to be able to create firewall rules that allow only specific computers to RDP into the DC, why we choose the computer option. Users that should be able to RDP into a DC should also be restricted, which is possible with the Computer and user (Kerberos V5) option, however, I recommend using User Rights Assignment for this.
8. Set the Protocol type to TCP, Endpoint 1 port to Specific Ports, 3389 (default RDP port), and Endpoint 2 port to All Ports.
9. Set the rule to apply to all network profiles.
There is no reason to not include it in the Private and Public profile though the jumphost/PAW should be on the domain network.
10. Name the rule RDP IPSec (TCP), or whatever matching your naming conventions.
RDP over UDP was introduced in RDP version 8 which came with Windows 8 / Server 2012. To cover UDP as well, create another firewall rule under the Connection Security Rules with the same settings from step 2 - 10, with the exception of the Protocol type in step 8 which should be set to UDP, and the name of the rule in step 10 should be RDP IPSec (UDP).
Ingoing RDP restrictions GPO
This GPO will block normal ingoing RDP connections, but allow ingoing RDP with IPSec encryption from the jumphost/PAW.
The GPO will end up with these five firewall rules:
Note that the order in which the rules are listed does not influence the priority of the rules in WDFAS, as opposed to classic firewall software.
The steps to create the GPO:
11. Create a new GPO called Ingoing RDP restrictions and open it in the Group Policy Management Editor.
12. Go to Inbound Rules under Computer Configuration > Policies > Windows Settings > Security Settings > WDFAS > WDFAS.
13. Right-Click, and choose New Rule...
14. Set Rule Type to Predefined: Remote Desktop.
15. Select all three Predefined Rules.
16. Set Action to Block the connection.
That gives us the three block rules:
Now we need to create the inbound rules that allow RDP with IPSec from the jumphost/PAW. Instead of creating new rules with the New Inbound Rule Wizard, we will copy and paste the two Remote Desktop - User Mode rules, and then modify them. Why this way? Because there seems to be a bug that makes the Group Policy Management Editor crash when we try to create the rules the ‘normal’ way. RDP Shadow is used to remotely view and control other user’s active RDP sessions. This feature should not be available for this setup, as system administrators should not have other users interacting with their RDP session to the DC.
17. Mark Remote Desktop - User Mode (TCP-In) and Remote Desktop - User Mode (UDP-In), hit Ctrl+C, and then Ctrl+V to copy and paste the rules.
For both the copied rules:
18. Right-click and choose Properties.
19. Set Action to Allow the connection if it is secure and click Customize...
20. Select Require the connections to be encrypted, select Allow the computers to dynamically negotiate encryption, and select Override block rules.
This will require the ingoing RDP connection to be authenticated and encrypted. The block rules we created before will have higher precedence than allow rules, why we must choose the Override block rules option. To check and modify the IPSec algorithms (AH and ESP), encryption algorithms, and more, that are used when selecting this option, go to WDFAS > WDF Properties > IPsec Settings > IPsec defaults. The default for this option is ESP with AES-CBC 128 for encryption and SHA-1 as hash-algorithm.
21. Go to the Advanced tab and set Specify profiles to which this rule applies to Domain.
It happens that the Network Location Awareness (NLA) service cannot determine that the computer is on a domain when a computer boots, so it falls back to the public or private profile. If you choose the domain profile only and this happens, the RDP connection will not be allowed. If it happens commonly in your environment, you can consider enabling the connection for the public and/or the private profile. But then make sure you have another firewall between the environment and the Internet to block RDP. Such block rules for ingoing RDP from the Internet can be bypassed with RDP Tunneling, but the adversary still have to authenticate as the jumphost/PAW with IPSec before authenticating as a user with access rights.
22. Go to the Remote Computer tab, select Only allow connections from these computers, and add the jumphost/PAW.
Before deploying - common problem when testing
A common scenario is that the computer does not use the domain network profile after a reboot, as mentioned earlier. It happens because the Network Location Awareness (NLA) service cannot determine that the computer is on a domain, so it falls back to the public or private profile. If this happens in your environment you should review your configured DNS suffix, but a reboot solves the issue in most cases. For DCs, it is often enough to restart the NLA service.
Deploy GPOs
We can apply the RDP IPSec GPO on the DC and the jumphost/PAW by linking it on an OU for just these computers. But you will most likely not have such an OU, so we will instead change the scope of the GPO. The scope of a GPO is Authenticated Users by default:
23. Remove Authenticated Users from Security Filtering.
24. Read the warning and click OK.
25. Add the DC and the jumphost/PAW.
26. Go to the Delegation-tab and add Read permission for Authenticated Users.
27. For the Ingoing RDP restrictions GPO, repeat step 23-26 but add only the DC to scope.
28. Link the RDP IPSec GPO to domain (or an OU containing the jumphost/PAW and DC).
29. Execute gpupdate on the jumphost/PAW and DC to apply the GPO.
30. Reboot the jumphost/PAW and DC.
31. Confirm that you can still RDP from your workstation to the DC, and from your jumphost/PAW to the DC, and from your workstation to the jumphost.
You can view the applied rules on the computers in WDFAS.
32. Link the Ingoing RDP restrictions GPO to the Domain Controllers OU.
33. Execute gpupdate on the DC to apply the GPO.
34. Reboot the DC.
35. Confirm that you can RDP from the jumphost/PAW to the DC.
36, Confirm that you cannot RDP from your workstation to the DC.
Confirm IPSec connection with WDFAS
37. Start an RDP connection from the jumphost/PAW to the DC and log in.
38. Open WDFAS on either the jumphost/PAW or the DC.
39. Navigate to Monitoring > Security Associations > Main Mode.
We can see that the main mode SA has been agreed upon between the jumphost (10.190.190.2) and the DC (10.190.190.1).
40. Click on Quick Mode.
Four quick mode SAs have been agreed upon, two for TCP and two for UPD, two with encryption and two without. Wireshark can be used to verify that our connection utilizes the SAs with encryption.
Confirm IPSec connection with Wireshark
This is the traffic between the jumphost and DC, from the moment I started the RDP connection to where I had to fill-in user credentials.
The very first ISAKMP packet is called the main mode, and the following six ISAKMP packets are called Unknown 243. This is the main mode of IKE.
The first IP packet from the jumphost to the DC with ISAKMP:
The packet contains a SA. We open the SA:
The jumphost has two proposals for the IKE SA; AES-CBC 128 or 3DES-CBC, both with SHA as hash-algorithm.
The first reply over ISAKMP from the DC (no. 300) is a similar packet, but only containing the AES-CBC 128 proposal. The jumphost and DC have then agreed upon that SA, which were the SA we saw under Main Mode in WDFAS.
The next two packets are the Diffie-Hellman exchange to generate a shared secret key:
Afterwards, different protocols are utilized including Kerberos (KRB5) to authenticate the jumphost.
The last two packets of the main mode verify the identity of the two peers. The data is encrypted:
Main mode is followed by quick mode, which are the 6 ISAKMP Unknown 244 packets. Quick mode goes through a similar process as main mode, but with encrypted data. Quick mode is followed by the actual data transfer with IPSec, which is the ESP traffic:
We need to know how data is supposed to look like if not encrypted, to judge which of the listed channels in WDFAS quick mode is used. Here we have normal RDP traffic:
If we look-up the format for the UPD and TCP header we will find that for both are the source port and destination port the first four bytes. We check in Wireshark, we can see that 0d3d, which is hex for the port number 3389, appears in the bytes as expected:
If we jump into traffic of a connection configured with ESP null-encryption, which is the same as no encryption, we can see that 0d3d appear in the first four bytes of the “encrypted” data in each packet:
Now we know that ESP data with null-encryption will contain 0d3d as the first or second pair of bytes depending of the direction of the packet. If we go back to our original traffic, it is clear that it is not null-encryption, as 0d3d does not appear in the first two pair of bytes. Only the ESP packet just before the last four quick mode packets has null-encryption. Quick mode is used again to renegotiate IPSec SAs when the IPSec session expires. The ESP packet just before these quick mode packets has null-encryption as well:
We can conclude that the IPSec channel with null-encryption is related to quick mode negotiation, and our RDP session is indeed encrypted with AES-CBC 128. According to the article “IPSec support for client-to-domain controller traffic and domain controller-to-domain controller traffic” from support.microsoft.com, this should not even be possible: “... we do not support the use of IPSec to encrypt network traffic from a domain client or member server to a domain controller when you apply the IPSec policies by using Group Policy or when you use the Kerberos version 5 protocol authentication method.”. Well, we have now achieved the security-level: IMPOSSIBLE.
This configuration is between jumphost/PAW and DC, however, IPSec can be used to protect many critical connections in an Active Directory environment. For example, if your helpdesk/servicedesk is using RDP as remote management tool consider deploying a similar IPSec configuration organization wide between helpdesk workstations and regular production workstations. The IPSec policies can be based on security groups from Active Directory in combination with computer objects. This could also be utilized on other port and protocols than RDP, consider WinRM, SMB, WMI and other management protocols in your environment. Requiring IPSec and origin from helpdesk, to any inbound management ports on regular workstations could reduce the possibility for adversaries to move laterally in your network.