What is a Bastion Host?

What is a bastion host and why is it used?

A bastion host is a special-purpose computer on a network specifically designed and configured to withstand attacks. It typically serves as the single point of entry into a private network from the public internet, acting as a secure gateway that administrators can use to access systems within a secure perimeter.

Bastion hosts are most commonly used in cloud and enterprise network environments where internal systems should not be exposed directly to the internet. Instead, access to internal resources (e.g., databases, application servers) is tightly restricted and only permitted via the bastion host. This limits the attack surface significantly.

These hosts are intentionally exposed to potential threats and are therefore “hardened”—they run minimal software, have strict firewall rules, and undergo regular patching and monitoring. Admins typically connect to the bastion host using SSH (Secure Shell) or RDP (Remote Desktop Protocol), then pivot into the private network to manage internal systems.

In summary, a bastion host provides a secure, auditable, and controlled access point for administrative tasks on sensitive systems without exposing the entire network to external threats.

How do you set up a bastion host in AWS / Azure / GCP?

Setting up a bastion host varies slightly across cloud platforms, but the core steps are consistent. Here’s a general approach, with notes on AWS as an example:

1. Provision a Virtual Machine (VM): Launch an EC2 instance (in AWS), a Compute Engine VM (GCP), or a Virtual Machine (Azure) in a public subnet with a public IP address.

2. Secure the Instance:

   • Limit inbound traffic: Only allow SSH (port 22) or RDP (port 3389) from specific IP addresses (e.g., your office network).

   • Disallow root login and disable password authentication; use SSH key pairs or platform-specific IAM-based login.

   • Enable logging and monitoring: Use tools like AWS CloudTrail or Azure Monitor to track access attempts.

3. Set Up Internal Connectivity:

   • Ensure the bastion host can reach private subnets via routing and security group rules.

   • Use internal DNS or private IPs to connect from the bastion to target systems.

4. Add Jump Configuration (Optional):

   • Use the ProxyCommand directive in your SSH config to make jumping through the bastion host seamless.

5. Regular Maintenance:

   • Patch regularly.

   • Rotate SSH keys.

   • Enable session recording and log forwarding for audits.

Each cloud provider offers unique features, such as AWS Session Manager, that can eliminate the need for a bastion altogether, so consider native alternatives depending on your security posture.

What are the security best practices for bastion hosts?

Security is paramount for bastion hosts since they are directly exposed to the internet. Here are best practices to follow:

• Limit Access: Only allow access from specific IP addresses using firewall rules or security groups. Never leave it open to the world.

• Use Key-Based Authentication: Avoid password authentication. Instead, use SSH key pairs or integrate with IAM roles and policies for authentication.

• Enable Multi-Factor Authentication (MFA): Add an extra layer of security using MFA, particularly for RDP-based bastions.

• Logging and Monitoring: Enable detailed logs of all login attempts and session activity. Use centralized logging (like AWS CloudWatch or GCP Logging).

• Session Auditing and Timeout: Consider tools that record sessions or enforce session timeouts to minimize risk from abandoned or compromised sessions.

• Patch and Harden Regularly: Keep the operating system and any software up to date. Remove unnecessary services and software to reduce the attack surface.

• Use One-Time Access: Some environments use ephemeral bastion hosts that are spun up temporarily and destroyed after use.

• Consider Jump Hosts and Session Managers: Where possible, leverage alternatives like AWS Systems Manager Session Manager to remove the need for a persistent bastion altogether.

Following these practices helps ensure your bastion host doesn’t become a backdoor for attackers.

What’s the difference between a bastion host and a jump server?

The terms bastion host and jump server are often used interchangeably, but there are subtle differences depending on context.

A bastion host is traditionally a hardened server exposed to the public internet that provides secure access to a private network. It’s specifically designed for external access and is placed in a DMZ or public subnet.

A jump server, on the other hand, is a broader term referring to any intermediary machine that allows administrators to “jump” into more secure or isolated environments. Jump servers can exist within internal networks and may not always be publicly accessible.

Think of it this way:

• All bastion hosts are jump servers.

• Not all jump servers are bastion hosts.

Another distinction is in the tools used. Bastion hosts are often minimalistic and configured for secure, direct SSH or RDP connections. Jump servers may offer advanced tooling—such as session management, command restrictions, or directory integrations—especially in regulated or high-security environments.

Ultimately, both serve the purpose of securing administrative access, but “bastion host” implies internet exposure and external access control, while “jump server” may include broader, internal access use cases.