A jump server, jump host or jump box is a system on a network used to access and manage devices in a separate security zone. A jump server is a hardened and monitored device that spans two dissimilar security zones and provides a controlled means of access between them. The most common example is managing a host in a DMZ from trusted networks or computers.
In the 1990s when co-location facilities became more common there was a need to provide access between dissimilar security zones. The jump server concept emerged to meet this need. The jump server would span the two networks and typically be used in conjunction with a proxy service such as SOCKS to provide access from an administrative desktop to the managed device. As SSH-based tunneling became common, jump servers became the de facto method of access.
Jump servers are often placed between a secure zone and a DMZ to provide transparent management of devices on the DMZ once a management session has been established. The jump server acts as a single audit point for traffic and also a single place where user accounts can be managed. A prospective administrator must log into the jump server in order to gain access to the DMZ assets and all access can be logged for later audit.
A typical configuration is a hardened Unix (or Unix-like) machine configured with SSH and a local firewall. An administrator connects to a target machine in the DMZ by making an SSH connection from the administrator's personal computer to the jump server and then using SSH forwarding to access the target machine.
Using SSH port forwarding or an SSH-based tunnel to the target host allows the use of insecure protocols to manage servers without creating special firewall rules or exposing the traffic on the inside network.
A typical configuration is a Windows server running Remote Desktop Services that administrators connect to, this isolates the secure infrastructure from the configuration of the administrator's workstation.[1] It is also possible to enable OpenSSH server on Windows 10 (build 1809 and later) and Windows Server editions 2019 & 2022.[2]
Newer, more advanced cybersecurity technology, such as SSH-fueled tunneling and privileged access management solutions, have diminished the popularity of jump servers. Still, jump servers can be valuable in organizations that lack the resources to upgrade their IT infrastructure.
A jump server is an intermediary device responsible for funneling traffic through firewalls using a supervised secure channel. By creating a barrier between networks, jump servers create an added layer of security against outsiders wanting to maliciously access sensitive company data. Only those with the right credentials can log into a jump server and obtain authorization to proceed to a different security zone. Administrators can also use a jump server for auditing traffic and user activity for real-time surveillance.
This connection can also move the opposite way. Virtual network computing servers, or VNC jump servers, support cross-platform screen sharing, allowing a privileged account to access a device remotely with their own mouse and keyboard controls. Those working in IT, or who have needed IT assistance, may be the most familiar with this service, where clients grant access to an authorized user to troubleshoot hardware and software issues.
However, before any employee or administrator can start work, the main network must ensure that only authenticated users are entering it. Usually, at least one firewall is set up as a foundational security measure, with a jump server housed between it and an untrusted public network, such as the internet.
Before being implemented, jump box servers are hardened, meaning they have very few touchpoints. This makes it difficult for hackers to discreetly install malware or infiltrate jump box servers through brute force attacks. By their nature, jump box servers separate internal workstations from the private servers they work on so that device-related breaches can remain isolated from the entire system. Additionally, jump box servers never house sensitive data, although leaked access credentials, such as keys or passwords, can compromise the whole private network it aims to protect.
Jump box servers also improve productivity by eliminating the need to constantly log in and out of separate security zones to access certain assets and resources. Instead, authorized users can seamlessly utilize what they need without interruptions.
Jump servers also require coding expertise to configure and set up, making it difficult for those unfamiliar with script writing to install the appropriate safety precautions. This can ultimately lead to human error and vulnerabilities that cybercriminals can harness.
We at SSH secure communications between systems, automated applications, and people. We strive to build future-proof and safe communications for businesses and organizations to grow safely in the digital world.
So, if one is to implement a jump server, is there any advantage to logging in with a user account, then running something like RSAT as different user or would it be best just to have the user log directly into the jump server using the credentials that they would use to run RSAT?
I have a few aliases. Some are for me to allow 2 factor from a vendor. Also, if I log in with my admin user and may have multiple admin accounts for least privilege. I may login with one account to manage AD and another to manage Exchange.
If your RDP sessions still use the self-signed certificates they came with, then those are just as weak. In fact there is a chance that if someone was on your network, they could also obtain the passwords of anyone using RDP.
In previous security audits, it was recommended that our VPN accounts not actually have admin access. For several years now we have use stripped down VPN accounts to log in and then use a different account to log into whatever remote machines are used. With contractors however, there are cases that when we set up a jump box for them to hit, it just uses the AD account we have made them but that is a very stripped down account access wise as it is.
Segregation of roles: Users are logged in with a regular account and then escalate privileges when running RSAT, which can help separate normal activities from administrative tasks.Additional layer of security: Two-factor authentication (2FA) provides an added security layer.
Extra steps: Users need to log in twice (once as a regular user and then as an admin user) which could be inconvenient.Management: Managing multiple sets of credentials and user access can be complex.
Simplified experience: Users directly log in as a user with AD permissions, reducing the need for multiple logins.Easier management: Managing fewer user accounts and access permissions can be less complicated.
Ensure that the jump server is properly hardened and secured, following security guidelines.Implement proper access controls to restrict who can log in and what actions they can perform.Regularly review and audit user access and permissions.If using 2FA, consider how it impacts usability and the number of aliases available.
Based on your concerns I recommend you jump host and disable RDP password saving with Do not allow passwords to be saved .
Remote user token is not saved on client PC you are connecting from. Your biggest risk is keylogger on that PC.
The idea is to put anyone that touches AD to be behind a 2FA. That does bring up the question that if any credentials can access AD, they can do it from any machine. So, even if I have a jump host and 2FA the credentials could be compromised and used anywhere via something like Powershell to access AD. The idea behind doing it on a jump host means those credentials are not used on a workstation which would keep them a bit more secure.
This credential is solely for the purpose of managing AD. No local admin. The risk is the same yes, but my question is what is the attack surface. If they use that credential daily on their workstation, the token is there for grabs all the time. If they are channeled through a jump host, the attack surface is smaller because the credentials are only entered on a box that has lower risk of being compromised. The only way a bad actor could ever get that token is from that box. They would have to somehow get onto it, which involves 2 factor.
Thank you! So, if the token is not stored on the client machine, then I agree, a keylogger is the biggest threat. So, can you think of any added security by requiring logging into the jump host as a regular user, or does that actually add security risk because the credentials to access the jump host have a larger attack surface??
Jump boxes were a big part of what enabled me to switch from Windows to Mac over a decade ago and continue to work happily there today. I get way less nervous about updates to my client machine when I know that the only stuff installed there is productivity applications. Worst case scenario, if my entire desktop or laptop blows chunks, I can still just remote into my jump box and keep right on working.
Same is true for me.. we all have VMs here for development. If I lose a laptop I am up and running in 2 minutes after getting the new laptop.. since all I have on the laptop is office, outlook and a browser. To get to a production DB we need to use a VM that can connect to production, these are restricted machines and only a handful of people have access to these
Another benefit besides keeping all ports closed on pfSense is that the home network WAN IP address is dynamic therefore accessing the VPS with a fix IP could potentially simplify the setup of the remote clients.
Thank you for the suggestion. I heard about Streisand, but I had the impression that it was a set of scripts to install different types of VPN access to a server, so your remote clients are not restricted to only OpenVPN.
7fc3f7cf58