Bastion hosts provide remote access to private networks from an external network. Commonly used as SSH proxy servers to support system administration, bastions provide a convenient, securable path through a protected network perimeter. As with VPN and RDP, however, the bastion host is an old remote access technology that does not work well in today’s decentralized computing environment.

In this article, we will introduce the bastion host concept, why companies use it, and how bastions work. We will also explain how bastions — especially those providing SSH proxy services — create new security risks.

What is a bastion host?

A bastion host is a dedicated server that lets authorized users access a private network from an external network such as the internet. Placed outside the firewall or within a DMZ, the bastion host becomes the only ingress path to those internal resources. Access control becomes easier to manage while minimizing the potential attack surface.

Technically, any single-purpose server providing access control could be a bastion host. This includes DNS, web, or mail servers. These systems face the internet, so they need to be on the public side of a firewall or DMZ. At the same time, they may provide authorized users access to certain internal resources.

Network administrators often use bastion hosts to remotely manage networked assets. In this scenario, the bastion’s sole purpose is to provide SSH proxy services. Remote administrators sign into the bastion and then sign into the subnet or resource they need to maintain.

Bastions simplify security administration. The internal network can be configured to block all internet-bound traffic and only allow SSH communications with the bastion host. With all external traffic channeled through the bastion, administrators can focus their security efforts on protecting a single asset.

At the same time, user management becomes simpler. When an employee leaves, administrators do not need to revoke access to each private network and subnet. Revoking the former employee’s access to the bastion cuts them off from everything else.

How do bastion hosts work?

To understand how a bastion host works, we will look at a simple scenario in which a company’s administrators need access to Linux instances connected on a subnet within a virtual private cloud. Exposing a port in each instance to the public internet would give administrators the access they need. But the security implications make that approach too risky.

Instead, a bastion host is used as a bridge between the public internet and the private subnet. The bastion runs as a locked-down, single-purpose system — in this case, an SSH proxy server. Administrators strip the bastion of all unnecessary applications, ports, processes, user accounts, and protocols. Everything that does not serve the bastion host’s single purpose as an SSH proxy gets disabled or deleted.

The bastion host resides on its own subnet with an IP address that is accessible from the public internet. The bastion only accepts SSH connections from a limited range of IP addresses in the IT department. ACLs, allowlists, and other network-level access controls limit access from the bastion to its protected subnets.

When authorized users need to access a resource on the private subnet, they must first use their SSH keys to establish a connection with the bastion host. Once authenticated, they can then use another set of SSH keys to connect with the private network.

What are the security risks of using a bastion host?

Because bastion hosts are publicly visible and widely used to provide SSH proxy services, they have become a target for cyberattacks. SSH itself is the problem. Designed as a more secure alternative to TELNET and other early communications protocols, SSH added authentication and encryption. However, this thirty-year-old protocol has not kept up with enterprise networking’s rapid evolution. Aspects of SSH that undermine security include:

• SSH keys grant elevated, even root-level, access.

• Private SSH keys do not expire automatically.

• Old, vulnerable SSH hashing algorithms are still in use.

• SSH has no built-in integration with Identity Providers or other security systems.

• Key management features are not part of the SSH protocol.

In effect, SSH is a personal productivity tool that is used at enterprise scale. Without centralized management features or security integrations, SSH leaves key management to individual users. Unless everyone in the organization follows best practices perfectly all the time, SSH inevitably creates an extended attack surface.

A recent study combining an analysis of millions of client and host keys with a survey of CIOs around the world found:

• On average, each server had 2.5 root access keys, at least one of which was orphaned.

• On average, each server had 2 duplicate and 1 shared private key.

• Despite the acknowledged risk, 40% of enterprises had no automated tools to remove unused SSH keys.

Without security system integration, authentication is left to SSH’s trusting approach to authentication. The lack of centralized management makes de-provisioning more difficult. Former employees could retain access to private systems for months or years. In addition, SSH is easy to misconfigure due to its deep feature set.

Advanced threat actors can now spend less than $50,000 to compromise OpenSSH’s SHA-1 hashing algorithm. That investment is worth it. Compromised SSH keys can give attackers elevated or root access to the bastion host and the networked resources it protects.

What are the best practices for securing bastion hosts

Given the bastion’s role as a portal through a secure perimeter, bastion host best practices focus on defending the server from attack.

Harden the bastion host

A bastion server must have the smallest possible attack surface. As mentioned earlier, it should be stripped of everything that does not directly support the bastion’s operation. All other daemons, processes, protocols, and applications need to go. Guest and other extra user accounts should be disabled.

Tighten network controls

Access to the bastion host must be limited to authorized users. Network-level access controls should restrict incoming SSH connection requests from a known range of IP addresses. Private subnets should be configured to only accept SSH connections from the bastion. Depending on the use case, the network can prevent traffic from passing out through the bastion.

Secure SSH

Although difficult at scale, there are ways to manage SSH keys. Adding multi-factor authentication helps protect against compromised privileged accounts. Periodically resetting SSH keys reduces the risk of orphaned keys. Regular audits help to identify overly permissive keys.

What alternatives exist for securing company resources other than bastion hosts?

Many of the cybersecurity risks enterprises face every day are generated by decades-old remote access security systems. SSH, RDP, VPN, and similar technologies were developed in the 1990s. Back then, the secure perimeter was the dominant network security paradigm. Trusted users accessed on-premises resources from their desktop computers. Security infrastructure defended the private network from external threats.

Today, computing and its associated risks have become much more complex. Users are no longer sitting in the office — and they may not be employees. The devices they use, no longer tethered to a desk, may access resources from anywhere. And the resources themselves are increasingly hosted in the cloud. In this environment, relying on a bastion host for access control can be just as risky as a VPN.

Zero Trust Network Access is a modern approach to secure access control that meets today’s challenges. Rather than protecting networks, Zero Trust protects each resource by assuming that any connection request is an attack. Every user must verify their identity explicitly regardless of who they are, what device they use, or where they are located. Once authenticated, the user only receives the least amount of access they need to do their work.

Twingate’s Zero Trust solution can replace bastion hosts and the security weaknesses they create. Unlike bastion hosts, Twingate does not require public-facing IP addresses. All private resources and networks are rendered invisible to the internet by software-defined perimeters.

Decentralizing access control reduces the threat surface further. Bastion hosts channel all external traffic which makes them targets for attack. Twingate establishes direct, encrypted tunnels between the user’s device and the specific resource they need to use.

Twingate integrates with Identity Providers, multi-factor authentication systems, and other elements of an existing security stack. Simple administration consoles make it easier to change permissions as users’ roles evolve — or remove permissions entirely when a user departs.

Finally, Twingate is fully compatible with SSH so administrators can use the tools they know to manage their systems. Twingate handles the authentication and authorization functions more securely than SSH ever could.

Replace your bastion hosts with Twingate’s remote access solution

Bastion hosts have become pervasive elements of enterprise networks. They provide a single remote access path to protected network resources. Locking down the bastion host and designing network infrastructure to control access lets companies focus security resources on a single asset. The bastion’s value as an SSH proxy makes it a popular way to manage network resources remotely.

Nevertheless, the bastion’s public IP address makes it an attractive target for cybercriminals. Widespread reliance on SSH is a particular weakness that makes the bastion a critical vector for attacks.

Twingate’s Zero Trust Network Access solution makes remote access security easier to deploy and manage in today’s cloud-centric computing environment. Administrators can use SSH to remotely manage private resources, whether in the cloud or on-premises, more securely and efficiently.

Contact Twingate to learn more about replacing bastion hosts with our Zero Trust remote access solution.