Jump Box Security

Special Thanks: This article was made possible by support from Linux Professional Institute

A jump box is a system set up with multi-factor authentication (MFA) usually placed in a network DMZ with very restricted access to the corporate network and no returning Internet access for any protocol. In other words, the jump box has only one path in via SSH ,and no other protocols are allowed outbound to the Internet or into the corporate network. Figure 1 shows a simplified diagram of a jump box and where and how it is positioned within your network.

Figure1: The jump box showing access into the corporate network.

A secure jump box is an excellent out-of-band (OOB) remote access method for system administrators. It ensures that your network has 24x7x365 support and is a reasonable solution when some of your users either have no direct office or data center access.

Internet Access

The jump box should be set up with MFA, as should all systems attached to the corporate network. No user should be in the sudoers group or be allowed to become the root user on this system. When the jump box system requires maintenance, a system administrator should use a console login either via an onboard access controller or through a directly attached keyboard, video, and mouse (KVM) apparatus.

Since the jump box resides in the DMZ or another network that can be accessed via the Internet, great care should be taken to ensure its security by applying patches and updates as soon as they are made available. Additionally, the jump box shouldn’t host any protocols except for SSHD. The jump box has a single purpose as an SSH gateway into the corporate network. The only exception is for MFA purposes. Some MFA solutions require Internet access or at least some method of communicating with an authentication service inside the network. Time-based solutions are more secure, but any MFA solution is more secure than simple passwords alone.

MFA

It’s hard to stress the MFA requirement enough. No accounts on the jump box system should be accessible without using MFA unless it is a console login. The most secure type of MFA is to require that each user have a physical token such as a hardware token, which is a device that generates random numbers or alphanumeric sequences.

To use a hardware token, the user supplies a username, a passcode, and a random number or sequence from the token. The random number that is generated is usually only active for 60 seconds. This security principle is based on “something you know plus something you have” that a remote hacker couldn’t gain access to or spoof.

Additional Security

To further secure your jump servers, you should follow these suggestions:

• Disable or remove unnecessary protocols, daemons, and services.
• Never store SSH private keys on the jump server.
• Configure internal hosts with /etc/hosts.allow and /etc/hosts.deny files to control access.
• Create at least one secondary /backup jump box in case of failure.
• Use a restrictive, host-based firewall for all Linux systems.
• Set up a service such as Fail2Ban to resist brute-force attacks.
• Install a minimal distribution option.
• Set up NAT forwarding to your jump box.

Remember that there’s no such thing as too much security when it comes to protecting your data, your customer base, and your intellectual property. Internet-accessible systems will come under attack; they need to be secure, and convenience should never be a factor in selecting security measures.

Some network administrators also place a firewall between the Internet and the DMZ and use NAT port forwarding for all services. Leaving systems wide open on all protocols is not a good practice. It makes more sense to secure the DMZ by limiting the incoming and outgoing protocols from that network.

VMs as Jump Boxes

Administrators prefer to use virtual machines (VMs) as jump boxes, because of their low cost, ease of deployment, and ease of maintenance. Virtualization makes creating such services almost trivial. If your team already has a security VM template created, deploying a new jump box only takes a few minutes. Further configuration and setup that is jump box specific will be far less of a hassle if an administrator can deploy a system, set the appropriate VLAN ID, create user accounts, set up MFA, and allow users to connect within a few hours of initial deployment.

A quick Internet search for “jump box” yields quite a few results for deploying jump boxes for Amazon Web Service (AWS) environments. Some of these even outline best practices and caveats for secure setups for AWS.

An additional layer of security is to limit the amount of time the jump box is available for use. For example, if your entire staff is local, then you can restrict access until after regular business hours for a limited window for maintenance. This restriction can be pushed even further by only allowing access during maintenance events rather than every day from 6PM to 7AM.

Summary

A jump box’s sole purpose is provide an SSH gateway into your internal network for administrators, and it should be made as secure as possible. MFA greatly increases security for all systems, not just jump boxes. It’s an added pain for administrators, but the added security layer is worth the few extra seconds required to work with an MFA solution.

Even the largest enterprises use jump boxes and other OOB network access protocols, so there are resources available to help you work through any security issues or configurations. Jump box deployment requires careful planning and close adherence to security best practices for firewalls, operating systems, networks, and users.