Use Windows Server 2016 to secure a jump server

When talking to customers about the security features in Windows Server 2016, a common question keeps coming up, how do I secure my jump server? Recently, I worked with a Microsoft internal team to deploy Windows Server 2016 on their jump server; I thought it is a good use case to share.

Why is it important to secure a jump server?

A jump server typically does not store any sensitive data; you may wonder do I really need to secure it? Although it does not have sensitive data on disk, it does have sensitive data in memory. Jump servers enable users to connect and manage servers/services in separate security zones. When establishing the connections, user credentials are stored in memory, and these credentials are attractive targets for credential theft attacks. In addition, if a malicious actor takes over your jump server, they can act on behalf of connected users to take control over the assets that are managed through that jump server.

There are additional protections by ensuring jump server access from a Privileged Access Workstation, you can find more details here. In this blog post, I would like to focus on leveraging the security features in Windows Server 2016 to better protect against attacks on this server.

Hardware requirement

Windows Server 2016 (along with Windows 10) introduced a number of security features which require hardware support. If you are considering purchasing new hardware, check the following:

• UEFI Secure Boot (optionally with non-Microsoft UEFI CAs removed from the UEFI database )
• Virtualization support enabled by default in the system firmware:
  • Virtualization extensions (for example, Intel VT-x, AMD RVI)
  • SLAT (for example, Intel EPT, AMD RVI)
  • IOMMU (for example, Intel VT-d, AMD-Vi)
  • UEFI configured to prevent an unauthorized user from disabling Device Guard–dependent hardware security features (for example, Secure Boot)
• Kernel mode drivers signed and compatible with hypervisor-enforced code integrity

In order to take advantage of the full set of security protections, the server hardware must support all of the above. However, there are some security features which do not require special hardware support, and you should enable these features on your existing hardware when you upgrade to Windows Server 2016:

Secure configuration

A jump server typically runs on dedicated hardware within a physically secure perimeter, running a specific workload. Once deployed, the workload does not change very much. This characteristic makes jump servers a good candidate to lock down the software it trusts.

In the Microsoft internal deployment example, the jump server is designed to enable users to manage services using JEA, and is protected by the following features in Windows Server 2016:

• Credential guard: Credential guard encrypts the domain credentials (i.e. Kerberos tickets and NTLM hashes) in memory and stores the encryption key in an isolated space which is secured by the hypervisor. By enabling it on the jump server, it can protect users’ domain credentials which are otherwise unencrypted and susceptible to pass the hash attack. For more details about this feature, see here.

Additional considerations:

Credential guard protects only Kerberos and NTLM credentials. If a user logs onto the jump server using a local account, those credentials will not be protected.

• Remote Credential Guard: In the past, when users RDP to a server, the client would send their credentials (username/password) to the RDP server in order to log them on. Since jump servers are a central point for many different users to logon, the jump server exposes a high risk if an attacker is able to compromise it.  With Remote Credential Guard, credentials aren’t actually sent to the jump server.  Instead, Remote Credential Guard protects the user credentials by logging on using Kerberos single-sign-on tickets greatly reducing the risk of credential theft. You can find more information here.

Additional considerations:

Remote Credential Guard only works with Kerberos. This means that if the jump server is in a workgroup, or if there is no trust relationship between the user’s logon domain and the jump server ’s domain, the connection will use NTLM and Remote Credential Guard will not protect those credentials. In addition, Remote Credential Guard is not supported when using an RDP gateway.

• Device guard: Device guard enables administrators to define what software is trusted to run on the system. There are two types of protections:
  • HVCI (Hypervisor Enforced Code Integrity) leverages Virtualization Based Security (VBS) to enforce kernel mode components to comply with the code integrity policy, and is protected against malicious intervention by admins on the OS.
  • Config code integrity allows admins to create a custom code integrity policy, and specify trusted software (both kernel mode and user mode).

Additional considerations:

If the jump server runs Windows Server Core edition, the FilePublisher policy is recommended.  FilePublisher white lists all the files allowed to run on the server. If the jump server runs Windows Server full desktop edition, the Publisher policy is recommended which uses only the signer certificates in the policy (i.e. the server will allow files to run as long as they are signed by the certificates in the CI policy).

Server Core has fewer files in the OS, which reduces the number of files that need servicing and, in turn, the likelihood of a required update to a CI policy that uses the FilePublisher rule.  The use of the Publisher policy rule is intended to reduce the policy update need. However, if your requirement is to do file level white listing on the jump server, you should use the FilePublisher rule.

You should always start with the code integrity (CI) policy in audit mode so you can evaluate the effectiveness of the CI policy without impacting the server’s ability to boot or the user experience. Once you are confident in the policy, you can change it to enforcement mode. Microsoft’s internal jump servers use full server with desktop experience and, therefore, use the Publisher CI policy   in audit mode.  Once we complete internal testing, it will be moved to enforcement mode.

I have written a separate blog on device guard in Windows Server 2016, which covers how to create, deploy and monitor CI policies.

• Security baseline: Aaron Margosis wrote a blog post on the new security baseline template for Windows Server 2016 and Windows 10. The download package includes GPOs, scripts and documentation on the settings it configures. The baseline template enables Credential Guard, Remote Credential Guard and Device Guard with HVCI.

Additional considerations:

1. If you are configuring JEA on the jump server, ensure it has the latest update of Windows Server 2016 first.
2. You should also configure JEA first before apply CI policy in enforcement mode.
3. If you need to configure trusted sites in Internet Explorer on the jump server, you must do so before applying the baseline. Once locked down, it will be hard to change the configuration.
4. Join the jump server to a trusted domain, so the RDP client can use Remote Credential Guard to RDP to the jump server.
5. The security baseline has a policy setting to prevent computers from connecting to both domain-based networks and non-domain-based networks at the same time. If the jump server is not joined to a domain, you may need to change this policy

• Network firewall ports: This configuration highly depends on the connection you want to allow. In our case, we configured the firewall ports to only allow inbound RDP and WinRM, which allows user to RDP to the jump server use JEA to remotely manage services, etc.

Conclusion

I hope by sharing the Microsoft internal jump server configuration, it gives you a good starting point on how you can leverage Windows Server 2016 to protect the jump servers in your environment. If you have any security tips to share, you can reach us by email at WinSecFeedback@microsoft.com.