SSH proxies vs. jump hosts—how to save time and spend less
Security practices are constantly evolving. What might have been considered a state-of-the-art approach ten or even five years ago is no longer defined as a best practice.
In the case of securing Remote Desktop Protocol (RDP), PAM practices have followed this pattern of evolution. What was once a common way of securing RDP—jump hosts—is still a valid approach some companies prefer. However, jump hosts don’t reflect a modern, efficient architecture. Microsoft recommends jump hosts because they are the safest RDP method for customers that do not own a PAM solution. In other words, jump hosts are the second-best way to secure RDP sessions.
The best method? Implement a PAM solution with the capabilities to directly manage and secure privileged sessions.
Use an SSH Proxy within a modern PAM solution
The state of the art when it comes to securing RDP connections is to use an SSH Proxy within a modern PAM solution. This approach capitalizes on the strengths of using a jump host, without a jump host’s downsides.
Let’s back up a bit and explain why RDP can be risky.
Why do I need an intermediary when using RDP? Why can’t I access any machine directly?
IT professionals agree. It can be dangerous to allow any computer on a network to communicate with any other computer without any type of monitoring and oversight. Allowing information to be passed freely can expose all machines on the network to malware, phishing, fake websites, and pass-the-hash attacks. A rogue program installed on a computer in such an open network can wreak havoc.
The same goes for allowing system administrators to have unfettered access to all machines in the network: they may unwittingly compromise a swath of machines or, if privileged credentials fall into the wrong hands, they can be used to navigate through the network and compromise the most critical pieces of infrastructure and data. Your goal is to protect the computers in your network from external infiltration and from spreading rogue material laterally to other machines on the network.
Limit the damage that can be done by minimizing the potential for contaminants to enter the network
This scenario is very similar to a cleanroom, where potential contagions need to be isolated from each other. In a cleanroom environment, workers need to be able to enter and exit without contamination. By stopping in the “gowning room” and passing through the airlock, pollutants are removed, and people are severely limited in what they are allowed to bring into the cleanroom.
An intermediary when using RDP serves the same purpose. It limits the damage that can be done by minimizing the potential for contaminants or pollutants to enter the network.
Why include Proxying within your PAM strategy?
It’s impossible to have 100% awareness of all privileged accounts at every moment. If we want to be sure that a host can only be accessed by authorized users, the best way to do so is by proxying authorized sessions through a comprehensive PAM solution like Secret Server.
With firewall rules or Group Policy, each host can be configured to reject any connection that does not originate from the Secret Server host.
If a user knows a privileged password and tries to bypass Secret Server by connecting directly to a host, the connection will be rejected. This includes any external attackers who may have stolen privileged accounts.
If your organization is concerned about malware, Secret Server can disable the use of the clipboard to prevent any malicious code from transferring back to the user’s host.
How can an SSH Proxy be used to secure RDP access?
Using Secret Server, you can route all RDP and SSH connections through the Secret Server host or a Distributed Engine. The Secret Server proxy uses an SSH tunnel to forward SSH and RDP (wrapped in SSH) traffic. Each target host can be configured to reject connections that don’t appear to originate from the Secret Server host or Distributed Engine.
An attacker with stolen credentials will be unable to access the target host without going through Secret Server, and malware cannot spread laterally between machines because firewall ports have been closed. For a further level of security, Secret Server can enable Session Recording on all connections, and the Advanced Session Recording agent can capture keystrokes as well.
Another advantage of using Secret Server as an SSH Proxy is streamlined upgrades. Without jump host software to worry about, upgrades are automated. Secret Server upgrades are often completed over the course of an hour with no professional services engagements. Secret Server also supports rolling upgrades with no downtime at all.
If SSH Proxies are a better solution, why are jump hosts still in use?
Jump hosts evolved as a preferred solution with RDP years ago, and some IT professionals and system administrators have grown to embrace their quirks and continue to use them out of habit.
On the plus side:
- Jump hosts were designed to be ultra-secure workstations that are used to RDP/SSH into other hosts.
- The jump host itself is hardened to repel malware, phishing, fake websites, and pass-the-hash attacks, and only a select allowlist of applications is permitted to run on a jump host. For example, software like MS Outlook is not allowed on jump hosts, so users can’t click bad links sent in an email.
- Since jump hosts are hardened, they often have unique permissions to access specific “high-risk environments” (HREs).
To use a jump host, users first RDP into the jump host, then they identify the target host they want to connect to, make the connection between the jump host and the target, then access the target machine. This can be a tedious process, which often involves typing in the IP address or hostname of the target machine you want to access.
On the minus side:
- Installation: Jump hosts are often time-consuming to configure initially because they require additional infrastructure and testing.
- Cost of additional components: Some jump hosts require you to purchase and maintain additional licenses for each user (such as Microsoft Remote Desktop Services Licenses).
- Scalability: Jump hosts can handle a limited number of concurrent sessions, so larger organizations need to deploy many servers dedicated to RDP and SSH traffic. This can lead to a resource-hungry installation that is difficult to manage at scale.
- Upgrades: Larger installations are difficult to upgrade, often requiring a multi-day professional services engagement. In addition to increasing costs, this can lead to the paradoxical situation where, due to the complexity of upgrading all your jump hosts, you delay implementing critical fixes or upgrades, thereby making the jump hosts less secure.
Can a customer who loves Secret Server but is still attached to a jump host approach satisfy both needs?
Yes. Secret Server’s architecture can be adapted to include jump host functionality if the situation warrants it. With this architecture, users will RDP into the jump host as a standard user, then log into Secret Server on the jump host.
We don’t recommend this approach because it’s not safer than the best practice achieved by modern PAM. In this setup, administrators will need to RDP into a separate host before they can do useful work, which may hinder productivity as adding more steps to the process leads to lower adoption. Users may look for ways to bypass the jump host to get their work done faster. In contrast, Secret Server has high adoption for this reason: an easier approach with the same level of security.
Bottom line: You can avoid the jump host “tax” and still secure Remote Desktop Sessions
A modern PAM solution using SSH proxies streamlines your architecture, increases adoption, and lowers your costs.
With this approach:
- All users need to pass a two-factor check and prove their identities before connecting to other hosts.
- All RDP and SSH traffic is audited and (if necessary) recorded.
- Users don’t know the passwords they are using, or passwords are changed each time they are used.
- Even if a cybercriminal gains access to a domain administrator account, they will be powerless to remote into any hosts on your network.
… all without requiring the installation, maintenance, and licensing costs of a large-scale jump host deployment.