Controls

Protecting Critical Systems with Isolation and Jump Boxes

Managing hardened systems without exposing them to unwanted attack vectors is difficult. Jump boxes are one way to do it—learn why and how.
September 21, 2021
6 min. read

Introduction

One of the core principles of information security is the concept of least privilege. One of the areas where it’s important to implement least privilege is administrator access because it can have such profound effects. Zero Trust is ideal but it can be a real challenge. One step on that journey is using jump boxes to contain the risk around administrator authorizations.1

A jump box is a hardened machine for segregating administrator access. Many significant breaches begin by harvesting administrator credentials through phishing, either using malware or by obtaining credentials with a spoofed authentication prompt. While jump boxes alone aren’t going to solve the problems that phishing and ransomware present, they will help limit their impact if you are compromised.

Another is for compliance. Not only do jump boxes provide required isolation and network segmentation practices that are part of many standards, but they are also one of the best interconnections to monitor and log.

The significance of administrator credentials and lateral movement to attackers is detailed in the 2021 Application Protection Report. The two highest-priority security controls in that report were privileged account management and network segmentation. This reflects how jump boxes could potentially mitigate the most dangerous vectors we observed in 2020.

Securing Administrator Access with Jump Boxes

The first thing you need to figure out is what functions and components are good candidates for this setup.

Step 1: Choose What to Isolate

The ideal environment to access through a jump box is an isolated system providing a mission-critical service. This means systems like databases, application servers, and any systems that hold or run critical data or functions as well as segmenting any assets from which an attacker could move laterally to the processing environment, such as management systems.

Things become more complex in the cloud, where systems scale up elastically on demand. In the cloud, remote management doesn’t mean connecting through SSH to a server somewhere—it means web-based management tooling. Implementing least privilege around administrative accounts in such an environment might take a drastically different form, but the same principles apply, particularly because visibility in these environments might be more difficult.

Step 2: Define Boundaries

Once you know what systems require this extra layer of protection, you can define the shape of the trust boundary. The most common tools for this are network security devices like firewalls or virtual LANs (VLANs). Either way, these devices are also part of the assets that fall in scope for management through the jump box. Figure 1 below gives a simple example of how this looks.

Figure 1. A simplified network diagram showing how jump boxes sit in relation to both sensitive production subnets and the user workstations used to connect to them
Figure 1. A simplified network diagram showing how jump boxes sit in relation to both sensitive production subnets and the user workstations used to connect to them

You also need to restrict administrative access at the application level. This can mean that only certain individuals have administrative privileges in the app, or it can mean that administrators can only access the control surfaces from specific subnets. Data sources for the application, whether internal or external, need to be treated to the same role-based access controls as human users.

Business and operational processes will also cross the trust boundary, and several of these functions are core to why we need jump boxes. Two key processes to examine are change control (such as pushing a patch to production) and authorization (such as granting someone administrator privileges). These must be separate roles, and both must be logged and set up with alerts so that attackers’ attempts to move laterally are more difficult to execute and easier to identify.

To the greatest degree possible, segregate third-party access from critical systems. Physical access control is also crucial as well as cabling and power connections.

Step 3: Define Ingress Access Control

Now you can set up the rules for who passes through the gates. This can be tricky, especially when you think about everything just scoped in and how porous the boundary will be. Personnel, data, and requests for service will all need to traverse this boundary, so every gateway needs access control.

Authentication systems need to be segregated on either side of this trust boundary, which is easier said than done. Safely segregating permissions on the same Active Directory tree for both administrators scoped into these sensitive systems and normal everyday users is arduous. It’s easier and safer to maintain separate domains or Active Directory branches for each trust zone. For the sensitive zones, we strongly recommend stronger authentication measures, like multifactor authentication.

Step 4: Set Up and Configure Jump Workstations at the Border

The purpose of the jump boxes is to provide administrators with a low-risk proxy for managing sensitive assets, since administrators’ everyday workstations can’t be trusted. To be really low risk, jump boxes need proactive, careful configuration management.

Access control

Allow administrators to authenticate to the jump box only from a specific subnet or VPN. It is a bad idea to make the jump box visible from anywhere in the corporate environment, and it is a really bad idea to make the jump box accessible from the Internet.

Jump boxes need strong authentication, both in terms of authenticating to the jump box and authenticating through it to the assets behind it. We’ll get to this in a moment, but all authentication surfaces need to be heavily logged for compliance and audit purposes.

Authorization

It’s best to think of the jump box as a single-use machine, so limit what it can touch, see, and do:

  • Network Access: Limit access for hosts and subnets to managed assets in the trusted zone. If an attacker compromises the jump box, this constrains their ability to move laterally.
  • Internet Access: In a best-case scenario, do not allow the jump box to be freely accessible from the Internet. If it absolutely must have some Internet access, use allow lists to constrain which external sites it can connect to.
  • Applications: Minimize the application footprint on the jump boxes. Application control policies can limit available programs and functions.2
  • Logging: Monitoring administrative activity at the jump box is important for situational awareness, audit preparation, and forensic capabilities. Store these logs off the jump box so that an attacker can’t wipe them.

Special Cases/Cloud Configurations

Configuration management and automation tools can help in these scenarios, particularly around complex or heavily virtualized environments. If you use a configuration management tool, be sure to employ the same standard of access control and logging as you do for the rest of the jump box infrastructure.

We have largely been talking about these systems in reference to on-premise environments, but all these principles apply for cloud environments as well. Most cloud management services offer multifactor authentication and robust logging capabilities.

Step 5: Roll-Out Policy

Roll out your jump boxes slowly and carefully. Integrate procedures around the new infrastructure into change control and operations processes, but leave existing systems in place for cover during the transition. Get feedback from stakeholders, paying particular attention not to make life too hard for administrators—they’re the boots on the ground here.

Once you have a sense of how well things are working, you can decommission the old access methods. Don’t forget to set up a recurring log review to ensure everything is as it should be.

It’s Not New or Easy but it Works

We know this isn’t easy. In fact, it is exactly the kind of interdisciplinary hydra of a problem that makes security tricky. In our experience, starting small is good—it maximizes the likelihood of success.

Jump boxes are not a new idea, but they remain important for managing hardened assets. Nobody wants to inadvertently architect the demise of their own servers! Even if the literal implementation suggested here doesn’t align with your environment, the principle of segmenting managed assets from daily workstations is crucial, particularly considering the havoc that ransomware is wreaking on organizations big and small.

But Wait, There’s More

There is a much longer, more detailed version of this article available to F5 Labs email newsletter subscribers. Sign up today. We promise we’ll only email you once a week and only about F5 Labs happenings.

Join the Discussion
Authors & Contributors
Raymond Pompon (Author)
Sander Vinberg (Author)
Threat Research Evangelist, F5 Labs
Footnotes

1https://en.wikipedia.org/wiki/Jump_server

2For Windows, configure application control through Windows Defender. For Linux, many tools can serve the same purpose. https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control

Read More from F5 Labs

2023 Identity Threat Report: The Unpatchables
Top Risks
2023 Identity Threat Report: The Unpatchables
11/01/2023 report 80 min. read
Sensor Intel Series: Top CVEs in February 2024
Top Risks
Sensor Intel Series: Top CVEs in February 2024
03/28/2024 article 5 min. read
2024 Bad Bots Review
Bots and Automated Attacks
2024 Bad Bots Review
03/14/2024 article 15 min. read