Bastion Hosts and Jump Servers

A bastion host is a specialized computer intentionally exposed to an untrusted network (typically the internet) to serve as the sole entry point to a private network. It is hardened against attacks—meaning it runs only essential services, applies all security patches, uses strong authentication, and is heavily monitored. The term originates from medieval fortifications where a bastion was a projecting part of a fortress that allowed defenders to cover the approaches. In networking, the bastion host is the 'gateway' that all external users must pass through to reach internal resources.

A jump server (also called a jump box or jump host) is a bastion host specifically used by administrators to access and manage systems in a separate security zone (e.g., a production network or a DMZ). The key difference is that a bastion host may serve multiple roles (e.g., web server, mail relay, VPN endpoint), while a jump server is dedicated to administrative access. In practice, many use the terms interchangeably, but the SY0-701 exam expects you to recognize that a jump server is a type of bastion host focused on management access.

Consider a typical enterprise with a web server in a DMZ and a database server in the internal network. Without a bastion host, an administrator might configure the firewall to allow RDP (port 3389) from the internet directly to the internal database server. This is a huge risk—any vulnerability in RDP or weak credentials could expose the entire internal network.

With a bastion host:

This two-step process ensures that:

Attackers target bastion hosts because compromising them gives access to the entire internal network. Common attack vectors include: - Credential theft: Brute-forcing SSH passwords, phishing for MFA codes, or exploiting weak SSH keys. - Vulnerability exploitation: Unpatched SSH vulnerabilities (e.g., CVE-2018-15473 for OpenSSH user enumeration) or RDP vulnerabilities (e.g., BlueKeep CVE-2019-0708). - Session hijacking: If the bastion host is compromised, attackers can piggyback on existing connections to internal systems. - Log tampering: Attackers may delete or modify logs to cover their tracks.

Defenders deploy bastion hosts with: - Fail2ban or similar tools to block IPs after multiple failed login attempts. - SSH key-only authentication (password authentication disabled). - MFA enforcement for all logins. - Network segmentation so that even if the bastion is compromised, lateral movement is limited. - Honeypot accounts on the bastion to detect attackers.

Linux Bastion Host Setup (SSH):

1. Install OpenSSH server:

sudo apt-get install openssh-server

2. Harden SSH configuration in /etc/ssh/sshd_config:

PermitRootLogin no
   PasswordAuthentication no
   PubkeyAuthentication yes
   AllowUsers adminuser
   Port 22
   Protocol 2
   MaxAuthTries 3
   ClientAliveInterval 300
   ClientAliveCountMax 0

3. Restart SSH:

sudo systemctl restart sshd

4. Configure firewall to allow only SSH from specific source IPs (if possible):

sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp
   sudo ufw enable

5. Enable logging and monitoring:

sudo apt-get install auditd
   sudo auditctl -w /var/log/auth.log -p wa -k auth_log

Windows Bastion Host Setup (RDP):

Jump Server Usage (SSH ProxyJump):

An administrator can use the -J flag to jump through the bastion:

ssh -J admin@bastion.example.com admin@internal-server.example.com

This establishes an SSH connection to the bastion first, then from there to the internal server. The traffic between the client and bastion is encrypted, and the bastion relays the connection.

Logging Example:

On the bastion, /var/log/auth.log would contain entries like:

Mar 10 14:23:01 bastion sshd[1234]: Accepted publickey for admin from 203.0.113.5 port 54321 ssh2: RSA SHA256:abc...
Mar 10 14:23:05 bastion sshd[1234]: Received disconnect from 203.0.113.5 port 54321:11: disconnected by user

Scenario 1: SOC Analyst Investigating Unauthorized Access

A SOC analyst at a financial institution sees an alert from the SIEM: multiple failed SSH logins to the bastion host from an IP in a hostile country. The analyst pulls up the bastion host's auth.log and sees 100 failed attempts in 5 minutes. The analyst checks the firewall logs and confirms the source IP is not in the allowed list (the firewall should have blocked it). Investigation reveals the firewall rule was misconfigured to allow any source. The analyst blocks the IP, corrects the firewall rule, and escalates to the network team. The correct response is to immediately block the IP, verify the firewall rule, and scan for any successful unauthorized access. A common mistake is to ignore the alert because it's 'just brute force'—but the misconfigured firewall is a critical vulnerability.

Scenario 2: Engineer Deploying Jump Server for Cloud Migration

A cloud architect is moving workloads to AWS. They deploy a jump server (EC2 instance) in a public subnet with a security group allowing SSH only from the corporate VPN IP range. The jump server is hardened: no SSH passwords, only key pairs, MFA via AWS IAM, and CloudTrail logging enabled. All internal instances are in private subnets with security groups that allow SSH only from the jump server's private IP. The architect tests by SSHing to the jump server, then from there SSHing to an internal instance. Logs show both connections. A common mistake is to allow SSH from the jump server to all internal instances (0.0.0.0/0) instead of specific IPs, which would allow lateral movement if the jump server is compromised.

Scenario 3: Incident Response After Bastion Host Compromise

An attacker gains access to a bastion host via a stolen SSH key (from a developer's laptop). The attacker uses the bastion to SSH into a database server and exfiltrates data. The IR team identifies the breach when the SIEM alerts on unusual outbound data transfer from the database server. The team isolates the bastion host (disconnects it from the network), revokes the compromised SSH key, and reviews logs to determine the scope. The correct response includes preserving logs, identifying the initial access vector, and implementing key rotation and MFA. A common mistake is to simply rebuild the bastion host without analyzing how the key was stolen, leaving the same vulnerability.