Introduction
Good practices and security improvements when setting up a jump host.
A jump host serves as a single point of entry between different segments of a network. Often privileged resources on the network are hidden behind a jump host, such that users cannot access the resources directly from their workstations. Instead, a user must connect to the jump host and then to the privileged resource.
This is of course a highly simplified model and most networks that utilize jump hosts are often much more complex. Some of the issues that can arise in more complex networks are touched upon later in this blog post.
Broadly spoken a jump host should only be used to facilitate access to specific resources on the network. The jump host should not have any other functions and services besides those that are needed to facilitate access to the desired resources. Because the jump host serves as a single point of entry to (privileged) resources it constitutes an increased security risk and a highly sought target by adversaries. Therefore, the jump host must be maximally secured, hardened, and monitored.
Strict physical access
The physical server hosting the jump host should be kept in a secure facility reflecting the strict level of security of the resources that it facilitates access to. The physical server should be secured against unauthorized access. Furthermore, the usage of encryption of disks, such as BitLocker, should be implemented to lower the risk of an adversary getting access to data in case the server is physically stolen, or the disk is removed.
Blocking Internet access
A jump host should not be permitted to access the Internet nor be able to browse the organization’s intranet. Additionally, it should not be possible to connect to the jump host from the Internet. Limiting the access to the jump host to originate from the network or specific addresses and trusted devices decreases the risk of an adversary being able to perform attacks against the jump host. Firewall rules and usage of VPN, VLAN, or proxies are examples of measures that can limit the connections made to the jump host.
Restricted use of software
Non-preapproved applications should be blocked. All unnecessary services and software should not be present on the jump host and should not be allowed to be installed or executed. Many adversaries use tools that can be run as scripts, so it is also vital to restrict the usage of scripts. In a nutshell, only tools that facilitate access to the servers in scope or are needed to keep the jump host secure should be allowed to run on the jump host.
Network and host restrictions
A jump host should be restricted to access only the servers in scope. Eg. Tier 0 servers. Connections to regular end users’ workstations should not be allowed. Connections to servers and resources outside the scope of the jump host should not be allowed. A jump host should not be allowed to connect to relatively unprotected devices, where there is an increased possibility that an exploit is being executed or picked up.
Effective patch and configuration management
There should be effective patch management of the OS, firewall, and software on the jump host ensuring the latest versions and security configurations. As described above, there should be a restriction on the usage of software on a jump host. Hence, the software needed to be patched should be fairly limited, and in most cases, it will also be out-of-box solutions, which can be managed automatically.
Multi-Factor Authentication
Multi-Factor Authentication (MFA) for logging onto the jump host should be utilized to increase the level of security. The jump host is the single access point to valuable and privileged resources, hence, something else than just a password should be needed to gain access. MFA or similar measures, such as smart cards or YubiKey, should be utilized in conjunction with a strong password policy. Using MFA effectively makes it more difficult for an adversary to gain access to the jump host.
Strong password policy
Because the jump host serves as a single-entry point for critical resources a strong password policy should be in place. Nowadays, several factors come into play when describing a strong password policy. Some of these factors are:
Length
Complexity
Lockout duration
Lockout threshold
Minimum age
Maximum age
History count
Encryption technique (reversible encryption)
Password rotation policy
Auditing
Comprehensive auditing and monitoring increase the chance of detecting, alerting, and reacting to malicious actions by an adversary. Monitoring which users and accounts access the jump and where they connect is essential to detect possible malicious behavior. This includes detecting inconsistent usage of user accounts. For E.g. a session on the jump host is established using user account A but originates from a workstation running as user B. Centralized log management, such as a SIEM solution that collects logs from workstations and jump hosts, could in conjunction with Sysmon detect such behavior.
Virtualization
Implementing per-administrator virtual machines on jump hosts and enforcing shutdown and resetting of the virtual machines to a known clean state after the administrative tasks are performed lowers the risk of credential theft because memory-cached credentials do not persist beyond a reboot.
Different administrative account
The accounts used to connect to the jump host and the accounts used to connect to the privileged resources on the network should not have administrative privileges on the jump host. If the administrators need to manage the jump host a specific account should be used to do so. This account should only have privileges needed for the administrative tasks on the jump host, and the account should not be used elsewhere nor have any privileges elsewhere.
Securing the jump host is not enough
While this blog post is about best practices for jump hosts it is worth mentioning that setting up a secure jump host itself does not necessarily increase the security posture of a network/system.
Expanding the illustration used previously in this blog post to include a non-privileged resource displays one of the problems. In the illustration, the user cannot directly access the privileged resource. However, if it is possible to access the privileged resource through other channels, eg. through a non-privileged resource bypassing the jump host, then the security is significantly decreased. An adversary that successfully compromised other parts of the network might be able to access the privileged resource without passing through the jump host.
The very same problem can arise if the privileged resources can connect to each other. Should one be compromised then the rest can be compromised since the adversary has already bypassed the jump host.
Therefore, to lower the risk of multiple resources being compromised connections to a privileged resource should be limited to originate from the jump host.
The Clean Source Principle
When building an environment using jump hosts it is a good idea to consider The Clean Source Principle [JK1] [JM2] which requires the source to be as secure as the object being accessed. This means that if an administrator’s workstation is compromised then the source is not clean thus the connection to the jump host, shared with other administrators, is potentially not clean (compromised, red.). Therefore, securing and hardening the workstations used to connect to the jump host must also be made.
Login Procedures
The procedure for logging on to a jump host and using the jump host to log on to resources on the network might be different depending on the setup.
According to the Microsoft Tiering Model, in the case of separation of a tier, an administrator should use the privileged account and the PAW to log onto a jump host and then use the privileged account to log on to the server in the tier in question. The administrator should then use a non-privileged account when logging on to a workstation for normal daily tasks.
If no such separation is in place, then the administrator should connect from the workstation to the jump host using a non-privileged account. The administrator can then use the privileged account to log on to resources on the network from the jump host.
End note
Because a jump host serves as an entry point to privileged resources it is a highly sought target by adversaries. Therefore, it is important to have an increased focus on security when it comes to jumping hosts. But as outlined in this blog securing a jump host is not exactly a simple operation.
Just like a chain, one strong link is not enough. Hardening the jump host itself is not enough. Hackers will always exploit the weakest link.
A secure jump host is only secure if all points of entry are secured; besides the jump host itself the network, the trusted resources, software, and user workstations, should also be taken into consideration. Additionally, considerations about the physical environment of the server, as well as human aspects such as strong passwords need to be taken into account.
Finally, the securing process is not a one-time process. Continual patch management, auditing, and reviewing are needed.
https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon
https://improsec.com/tech-blog/paw
https://improsec.com/tech-blog/setup-rdp-dc-jumphost-paw-ipsec