Jump servers (aka bastion hosts)
One of the challenges with having network segmentation is that it not only prevents attackers from accessing private networks and private resources, but it also prevents your own administrators from accessing those resources as well.
Our IT admins need to be able to access those resources to update them, change policies, etc…and we also need our IT automation to be able to communicate with these resources for log management, path management, and policy enforcement.
How can we enable this in a way that’s also secure and doesn’t counteract the benefits we get from segmentation?
One way is to use what’s known as either a jump server or bastion host. Let’s talk about what that is and how it works.
Jump server (aka Bastion Host)
In our Security+ course, we talk about how you can have both public and private subnets in the cloud. You can even create DMZs, and those DMZs or public subnets can be accessed from the Internet, while private subnets cannot.
To access those private subnet resources, we can create a jump server in a public subnet, and then we can use that jump server to connect to an internal resource.
This is a server that’s usually designated as having the singular purpose of letting us connect through it, which means that we can harden this server and completely lock it down.
Then, we can use what’s called an SSH tunnel. SSH tunneling, also known as SSH port forwarding, is when we connect to one system via SSH simply to have our information forwarded to another system.
So it would look like this:
- User A connects to the Bastion Host via SSH
- Port forwarding is established between the Bastion Host and internal private server
- User A can now issue commands and receive responses from the private server through the Bastion Host via an SSH tunnel
Here’s an example of using a bastion host to connect to a remote database from our local system:
ssh -N -L 3306:database-cluster.rds.amazonaws.com:3306 -p 22 ec2-user@IP.ADDRESS.HERECode language: CSS (css)This would connect your local port 3306 to the remote database port 3306 through the bastion host EC2 instance using port 22 for SSH.
Once a connection like this is established, we can use that tunnel to run remote commands, transfer files, etc…from our local computer to the database.
Securing the Bastion Host
A bastion host should be designed for this singular purpose, that way we can disable all other services, and we can turn off all unnecessary ports.
We can create firewall rules that prevent anyone except approved locations to even be able to communicate with this server, and we can enable strict monitoring that alerts anytime someone attempts accessing it.
Conclusion
While bastion hosts and jump servers have been used for a long time, there are some more recent alternatives available on cloud platforms. AWS, for example, offers a service called Systems Manager that allows you to remotely execute commands without having to have a bastion host.
A host-based agent runs and checks in with Systems Manager to see if there are any commands that need to execute, and if so, it will automatically run those commands.
Regardless of what you use, having a secure entry point to access internal resources is important, and that’s what jump servers aim to do.
Responses