Securing RDP with IPSec

Hi Everyone, this is Jerry Devore back with a follow-up topic from my previous post on Privileged Administrative Workstations (PAW) which is a hardened device configuration used to protect privileged credentials. In that post, I mentioned that it is possible to use IPsec to ensure an admin can only make a RDP connection to Tier 0 devices (domain controllers) from a PAW. By imposing this restriction, we limit the risk of exposing highly privileged credentials to a keyboard logger on a less trusted system such as an administrator’s standard workstation. An additional benefit is that we restrict how stolen credentials can be used unless an administrator’s PAW is also acquired.

Why IPSec?

When I explain this concept to customers I am often asked why not simply use firewall rules and avoid the complexity of IPsec. If your PAWs are going to always have the same IP address you could implement a firewall rule which restricts port TCP 3389 to a defined list source IP addresses. However, for most organizations the PAW is somewhat portable. Therefore, we need to combine firewall rules with the authentication protocols in IPsec which allows us to build “identity based firewall rules”.

Getting Started

If you have ever tried to get your head around Microsoft’s implementation of IPsec you know the learning curve can be steep. My goal in this post is not to make you an IPsec expert but rather help you quickly understand one way it can be used to improve your security posture. To get started, lets cover some basic concepts:

  • A prerequisite for Microsoft’s implementation of IPsec is that the Windows Firewall must be enabled. Some 3rd party AV products are not designed to coexist with the Windows Firewall so make sure that is not a show stopper for you.
  • Another prerequisite is UDP 500 which is used during the key exchange process (IKE) phase. We will not be tunneling or encrypting traffic so your security team will still be able to perform packet inspection if necessary. In fact, a network capture will pretty much look the same with the exception of the IKE handshake.
  • In order for two computers to establish an IPsec connection, they must agree on parameters such as IP address ranges, authentication methods and ports. Those parameters are configured on both sides of the connection using a Connection Security Rule (CSR).
  • Once two computers have successfully agreed on the parameters in the CSR, they establish a Security Association (SA) which involves authenticating each other, exchanging keying material and agreeing on encryption \ hashing algorithms.

Now that we have those basics down let’s take look at the steps required to set up a port restriction via IPsec. For this demo, I have set up two domain controllers in a lab along with a PAW workstation.

Connection Security Rule

While the configuration of the Connection Security Rule could be completed using just the Window Firewall with Advanced Security MMC, we are going work smart by creating a GPO. Once you have created a new policy browse to Computer Configuration \ Windows Settings \ Security Settings \ Windows Firewall with Advanced Security right click and select Properties.

Disclaimer: a misconfigured CSR is an excellent way to blow a Windows device off the network. If you use a GPO to deliver incorrect CSR settings, undoing the damage will require a console visit to each impacted device.

On properties page change the Firewall state to On (recommend) for the Domain Profile. Also set Inbound connections to Block (default) and Outbound connections to Allow (default). While these setting do not configure IPsec, configuring them will ensure that the Windows Firewall will be on.

Next right click Connection Security Rules and select New Rule.

As you can see from the wizard there are several ways to leverage Microsoft’s implementation of IPsec. Given we are only interested in implementing a port restriction, select Custom and we will save the other rule types for another blog post.

On the Endpoints page we identify sides of the network connection. It does not matter which side of the network you define as Endpoint 1 or Endpoint 2 until later in the wizard when we associate Endpoints with a port. My lab has two domain controllers. I have set their IP addresses for Endpoint 1. The address of my PAW is dynamic, so I set Endpoint 2 to Any IP Address.

The next page defines the authentication requirements. For this scenario select Request authentication for inboard and outbound connections. With that option the devices which share this connection agreement will attempt to negotiate IPsec but if the negotiation fails, the devices will continue to communicate. If you think that does not seem very secure keep reading until we get to the firewall rule section.

The next page of the wizard is where the Authentication Method is defined. Keep in mind we are leveraging IPsec so the identity of the Computer can be known when the connection is made. In order to have the option to also restrict the connection based on the user account, select Computer and user (Kerberos V5).

On the Protocol and Ports page scope the IPsec connection to port 3389 for Endpoint 1 port. While the solution will work if All Ports is selected, doing that would cause the domain controllers to attempt to negotiate IPsec for all connections which generates unnecessary overhead.

The PAW will use a random high source port for the RDP connection rather than 3389 so Endpoint 2 port should be set to All Ports.

The next page associates the CSR with Windows Firewall profiles. Under normal circumstances only the Domain profile is required. However, there are conditions which could cause the Network Location Awareness service to not select the Domain Profile. To error on the side of safety and stability, I suggest selecting all three profiles.

In the last page of the wizard give the rule a name and description then click Finish to save the settings.

That does it for the Connection Security Rule but we are not done yet. We still need to configure the inbound firewall rule for RDP to require IPsec and filter the connection based on security principles. Like the CSR, the inbound firewall rule can be configured directly on the server or in a GPO.

Inbound Firewall Rule

On the domain controller open the properties of the Remote Desktop – User Mode (TCP-In) inbound rule and select the General page. The Action setting is where the firewall rule is bound to IPsec. By selecting Allow the connection if it is secure, the firewall rule will not allow the inbound connection unless an IPsec connection has been successfully established. The use of this rule is why we’re able to set the Connection Security Agreement to Request authentication rather than Require.

Clicking the Customize button provides the ability to configure additional requirements for the IPsec connection. The first two options allow us to prevent the packets from being read (encrypted) or modified (integrity-protected) by a Man in the Middle (MITM). While enabling those features improves security, they also add network dependencies. Given this solution is targeted at securing the endpoint rather than the packets, I recommend selecting Allow the connection to use null encapsulation. This is the setting which will allow the security team to continue to perform network inspection if they have that requirement.

On the Remote Users page we can define users or groups of users which are allowed to pass through the rule. This might seem a little redundant since permissions should already be set on the Remote Desktop service. However, a key concept in security is “Defense in Depth” which means there should be multiple layers of overlapping defenses in case one fails.

The last item we need to configure is the Authorized computers on the Remote Computers page. This is a key setting because it ensures the Tier 0 admins can only use their PAW devices when making an RDP connection to the domain controller.

Before we test our solution lets run through a quick checklist:

  • Connection Security Rule GPO linked to the OU of the Domain Controller and PAW
  • Firewall enabled on the Domain Profile of both computers
  • Test client added to the PAW Computers domain group
  • User account has been added to Tier 0 Admin domain

If it has been configured correctly, testing the solution will not look any different than a normal RDP connection. So how do we know if it is working correctly? We do that by confirming the Security Associations where successfully created after a connection is made. Open Windows Firewall with Advanced Security MMC (wf.msc). Under Monitoring \ Security Associations you will see Main Mode and Quick Mode.

During the Main Mode phase of the Security Association the devices establish a secure channel and exchange keying material.

In the Quick Mode phase the devices negotiate how the data exchanged will be protected. Since we selected Allow the connection to use null encapsulation in the firewall rule, Quick Mode SA did not establish Integrity or Encryption values.

One last test of our solution is to confirm devices not in the PAW Computers group cannot make a connection. Given the firewall rule will block the connection, there will be no response on 3389 when the connection is attempted.

To quote Porky Pig … “That’s All Folks”. I hope this information helps in your journey to protect your privileged credentials. If this post has you thinking about giving the Windows Firewall a second look, I recommend you check out my friend Jessica’s Ignite presentation.