A bastion server—often called a “jump” server—is a special-purpose host on the edge of your network or cloud environment. It allows controlled access to internal systems that are not directly accessible from the internet. Because bastion servers must be internet-facing (typically via SSH on port 22), they are prime targets for malicious actors. In this post, we’ll explore essential strategies to prevent unauthorized access—including a new section on leveraging VPN or Zero Trust Network Access solutions like Cloudflare Access.
1. Restrict Incoming Traffic Using Network Controls
Key takeaway: Limit SSH (port 22) access to only necessary IP addresses or networks.
a. Use Security Groups, Firewalls, and Network ACLs
- AWS Security Groups or VPC NACLs: Whitelist the specific IP addresses or subnets that need SSH access.
- Host-based Firewalls: Tools like
iptablesorufwon Linux can limit SSH to predefined IP addresses.
By filtering traffic at the network layer, you ensure that unauthorized IPs can’t even attempt to connect.
2. Enforce Strong Authentication Policies
Key takeaway: Make it extremely difficult for anyone without the right credentials to gain access.
a. Disable Password Authentication
Use SSH key pairs exclusively and disable password-based logins:
nginxCopyEdit# /etc/ssh/sshd_config
PasswordAuthentication no
ChallengeResponseAuthentication no
This prevents attackers from brute-forcing passwords.
b. Use Multi-Factor Authentication (MFA)
- PAM modules (e.g., Google PAM): Require an additional verification code from an authenticator app.
- Duo Security: Provides robust 2FA integration for SSH.
Even if a private key is compromised, MFA can stop attackers from logging in without a second factor.
3. Harden the SSH Configuration
Key takeaway: Reduce your attack surface by disabling insecure protocols and ensuring up-to-date configurations.
a. Non-Standard Ports (Optional)
Switching SSH from port 22 to something like 2222 or 2022 can reduce automated scan traffic. However, this is not a replacement for proper IP restrictions.
b. Disable Legacy Protocols and Ciphers
- Disallow SSH v1 and weak ciphers.
- Regularly patch SSH and your operating system to eliminate known vulnerabilities.
c. Idle Session Timeouts
Configure sshd_config to drop idle connections after a certain period:
shellCopyEdit# /etc/ssh/sshd_config
ClientAliveInterval 300
ClientAliveCountMax 2
This closes idle connections after about 10 minutes (5 minutes x 2 intervals).
4. Intrusion Detection and Monitoring
Key takeaway: Be prepared for threats by detecting and blocking suspicious attempts quickly.
a. Fail2ban
- Fail2ban scans logs for repeated failed login attempts and bans offending IPs.
b. Centralized Logging
- Send SSH and system logs to AWS CloudWatch Logs, Splunk, or a SIEM solution.
- Set up alerts for unusual behaviors (excessive SSH failures, logins at odd hours).
5. Principle of Least Privilege
Key takeaway: Limit each user to the minimal access they need.
- No Shared Accounts: Each user has their own login, enabling traceability.
- No Root Logins via SSH: Disable root login; require
sudofor privileged actions. - Tightly Restrict Commands and Hosts: If certain users only need to manage specific resources, segment their access.
6. Automate Key Management and Rotation
Key takeaway: Keep an up-to-date inventory of SSH keys and remove outdated or unused ones.
- Use tools like Chef, Puppet, Ansible, or AWS SSM to manage, rotate, and revoke SSH keys.
- HashiCorp Vault can dynamically generate time-limited SSH credentials for ephemeral access.
Regular rotation ensures that even if a key is compromised, it won’t remain valid indefinitely.
7. Consider Zero-Port Alternatives (AWS Session Manager)
Key takeaway: Minimize exposed ports or eliminate them entirely if possible.
AWS Session Manager enables you to connect to instances without exposing SSH ports:
- No open inbound ports needed.
- Centralized Logging in CloudWatch or S3.
- IAM-based access control for starting sessions.
8. Frequently Patch and Audit
Key takeaway: Maintain a steady schedule of updates and security reviews.
- Apply OS and package updates promptly.
- Perform vulnerability scans to find and fix newly discovered issues.
- Audit logs to spot abnormal patterns (multiple login failures, unexpected login times, etc.).
9. Protect Access Via VPN or Zero Trust Solutions
Key takeaway: Rather than exposing SSH directly to the internet, wrap your bastion behind a VPN or a ZTNA solution like Cloudflare Access.
a. VPN-Based Access
- Corporate VPN: Place the bastion server in a private subnet accessible only over a secure VPN tunnel.
- Users must connect to the VPN first, at which point they can only SSH from an internal IP range.
- Reduces the public exposure of port 22 and moves it behind the VPN gateway.
This approach effectively hides your bastion from public networks—only those who have connected through the VPN can reach it.
b. Cloudflare Zero Trust Network Access (ZTNA)
- Cloudflare Access: A Zero Trust solution where each request to your bastion is evaluated and authenticated based on user identity, device posture, and context (e.g., location).
- Identity-Driven: Integrate with SSO providers (e.g., Okta, Azure AD, Google Workspace) so that only authenticated users with the correct roles can even see or connect to the bastion.
- Granular Policy Enforcement: Cloudflare can verify whether the user device has up-to-date security patches, antivirus installed, or meets other compliance requirements before allowing access.
- No Direct Exposure: Connections route through Cloudflare’s network; your bastion can be assigned a private IP that is never publicly visible. Cloudflare handles TLS termination, caching, and additional security checks.
With Cloudflare Access, you get a layer-7 approach to security, combining user identity, device posture, and network rules. This significantly lowers the risk of unauthorized connections—even if someone obtains a link or IP address to your bastion.
Putting It All Together
By combining network-layer restrictions, strong authentication (SSH keys + MFA), hardened SSH settings, proactive intrusion detection, least-privilege principles, and robust key management, your bastion server becomes significantly more secure. For even greater protection and a better user experience, consider placing your bastion behind a VPN or a Zero Trust solution like Cloudflare Access, minimizing or eliminating any direct public SSH exposure.
Key steps recap:
- Restrict incoming traffic (firewall, security groups, or Cloudflare Access).
- Use only SSH keys, and add MFA.
- Harden SSH (disable root, disable old ciphers).
- Proactively monitor and block threats (Fail2ban, logging/monitoring).
- Enforce least privilege (no shared accounts, no direct root).
- Automate SSH key management (rotate and revoke).
- Move to Session Manager or a Zero Trust approach (e.g., Cloudflare Access) to further reduce the attack surface.
- Patch, audit, and repeat the process on a regular schedule.
Securing a bastion server involves multiple layers of defense. Network restrictions (Security Groups or Firewalls), strong SSH configurations, and continuous monitoring form a solid baseline. Augmenting these measures with a VPN or a Zero Trust framework like Cloudflare Access can help ensure your bastion server remains invisible to unauthorized IPs or malicious scanners while providing convenient access to legitimate users.
