Jump Server: The Guide to Amplify Your Security — How to Build, Protect, and Not Turn Your Bastion Into the Back Door How a small dedicated server can be the difference between organized support and the next ransomware headline. And how, if misconfigured, it can be the exact door through which the attacker enters.
How a small dedicated server can be the difference between organized support and the next ransomware headline. And how, if misconfigured, it can be the exact door through which the attacker enters.
If you read the previous post about secure remote access, you already know the golden rule: never expose RDP, SSH, or any administrative service directly to the internet. But then the practical question arises: how do the support team, DBAs, sysadmins, and vendors access servers when they need to?
The traditional answer is the jump server — also called bastion host, stepping stone server, jump box. It's a concept that's been around for over 30 years and remains relevant because it solves a fundamental problem: centralizing and controlling all administrative access to an infrastructure.
But here's the paradox: a misconfigured jump server is worse than having no jump server at all. Why? Because it creates a false sense of security. You think you're protected because you have "that bastion", when in reality it became exactly what you should avoid — a single point, known, exposed, and full of privileges.
A jump server is a dedicated machine, hardened to the maximum, positioned as the only point of passage between the external world and critical internal resources.
Instead of each server exposing SSH or RDP, only the jump server accepts connections. Anyone who needs to administer anything must first enter the jump server, and from there reach their destinations.
The analogy: if your infrastructure is a building, the jump server is the front desk with a turnstile. Nobody enters directly into the rooms — everyone passes through the front desk, shows their badge, gets registered.
What is NOT a jump server:
Why it exists:
Internet → [Firewall] → [Jump] → [Servers]For small teams. Limitation: single point of failure and compromise.
Internet → [FW ext] → [Jump 1 DMZ] → [FW int] → [Jump 2 internal] → [Servers]For regulated environments. Attacker needs to compromise two servers.
Broker validates everything, retrieves temporary credentials from the vault, establishes the session without showing the password. Solutions: CyberArk, BeyondTrust, Delinea, HashiCorp Boundary, Teleport.
Centralizes access to multiple clients. Beware: becomes the dream target. Ideally, each client should have their own segregated jump.
Jump server is not a workstation. No Office, no browser, no application, nothing non-essential.
# Ubuntu/Debian minimal
sudo apt install --no-install-recommends openssh-server ufw fail2ban auditd rsyslog
sudo apt purge -y telnetd rsh-server xinetd nis ypbind tftp tftpd talk talkd snmpd
sudo apt autoremove -y
sudo ss -tulpn
sudo systemctl list-units --type=service --state=runningWindows: use Server Core whenever possible.
Typical Linux jump has: OpenSSH, RDP client (xfreerdp), mysql/psql client, nmap, dig, traceroute, tcpdump, vim, tmux, ansible.
Typical Windows jump has: mstsc, PuTTY, RSAT, PowerShell modules, SSMS.
What it should NOT have: browser, email, Office, Adobe Reader, Java client, personal software, compilers.
Rule: if you can't justify it, it doesn't need to be there.
Inbound:
Outbound:
If the attacker compromises the jump, the first thing will be to download tools and connect to C2. By blocking outbound, you break the chain.
# /etc/ssh/sshd_config
Port 52281
AddressFamily inet
ListenAddress 0.0.0.0
PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM yes
PubkeyAuthentication yes
AllowGroups jump-users
X11Forwarding no
AllowAgentForwarding no
AllowStreamLocalForwarding no
GatewayPorts no
PermitTunnel no
AllowTcpForwarding yes
MaxAuthTries 3
MaxSessions 4
MaxStartups 10:30:60
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
LogLevel VERBOSE
SyslogFacility AUTH
Banner /etc/ssh/banner.txtLegal banner:
*****************************************************************
RESTRICTED AND MONITORED ACCESS
This system is for the exclusive use of authorized personnel.
All activities are logged and monitored.
Unauthorized use may result in disciplinary action
and/or criminal prosecution.
By continuing, you agree to these conditions.
*****************************************************************No exceptions. For everyone. Always.
Linux with Google Authenticator:
sudo apt install libpam-google-authenticator
google-authenticator
# /etc/pam.d/sshd
auth required pam_google_authenticator.so
# /etc/ssh/sshd_config
ChallengeResponseAuthentication yes
KbdInteractiveAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactiveThe AuthenticationMethods publickey,keyboard-interactive directive forces key and TOTP.
FIDO2 hardware tokens (more secure):
ssh-keygen -t ed25519-sk -f ~/.ssh/id_ed25519_skThe private key stays inside the physical token (YubiKey). Even malware on the machine cannot extract it.
dba-mysql, sysadmin-linux, support-tier1, vendor-acme)ALLrbash, lshell)Example /etc/sudoers.d/dba-mysql:
%dba-mysql ALL=(root) NOPASSWD: /bin/systemctl restart mysql
%dba-mysql ALL=(root) NOPASSWD: /bin/systemctl status mysql
%dba-mysql ALL=(root) NOPASSWD: /bin/journalctl -u mysql *
%dba-mysql ALL=(mysql) /usr/bin/mysqlDon't use local accounts. Integrate with AD/LDAP/Azure AD/Okta/Google Workspace.
Advantages:
# Linux with AD via SSSD
sudo apt install sssd realmd adcli krb5-user samba-common-bin
sudo realm join dominio.empresa.local --user=adminUser doesn't have permanent access. Requests, justifies, is approved, expires.
Solutions: CyberArk, Teleport, HashiCorp Boundary + Vault, Azure PIM, AWS Session Manager.
Simple version with script:
#!/bin/bash
USER=$1
HOURS=$2
usermod -a -G jump-users $USER
echo "gpasswd -d $USER jump-users" | at now + $HOURS hoursLinux with auditd:
sudo apt install auditd audispd-plugins
# /etc/audit/rules.d/jump-server.rules
-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/sudoers -p wa -k sudoers_changes
-w /etc/sudoers.d/ -p wa -k sudoers_changes
-w /etc/ssh/sshd_config -p wa -k sshd_config
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=4294967295 -k privileged_exec
-a always,exit -F arch=b64 -S connect -k network_connect
-a always,exit -F arch=b64 -S execve -k command_exec
sudo systemctl enable auditd
sudo systemctl start auditdCentralize everything to a SIEM (Wazuh, Graylog, ELK, Splunk). Local logs don't help if the attacker deletes them.
The most powerful feature of a well-built jump server. Record everything every admin does.
Why it's powerful:
tlog (Red Hat, open-source):
sudo apt install tlog
# /etc/tlog/tlog-rec-session.conf
{
"shell": "/bin/bash",
"notice": "\nWARNING: This session is being recorded for audit purposes.\n",
"writer": "journal",
"log": {
"input": true,
"output": true,
"window": true
}
}
sudo usermod -s /usr/bin/tlog-rec-session usuarioReplay with:
tlog-play -r journal -M TLOG_USER=usuarioOther tools:
Important:
Local logs are disposable logs. Attacker deletes them first.
# /etc/rsyslog.d/forward.conf
*.* @@siem.empresa.local:6514 # TCP with TLSForward in real-time, not in batches.
Periodic rebuilding: every 3-12 months, destroy and rebuild from scratch via Ansible/Terraform/Packer. Eliminates drift, accumulated garbage, any undetected backdoors. It's like changing your front door lock periodically.
wget or curl (attempt to download payload)/tmp, /var/tmp, /dev/shm/etc/passwd, /etc/shadow, /etc/ssh/sshd_configImmediate notification (pager, SMS) for critical events. Not next-day reports.
Runbook ready for "jump server was compromised":
Cloudflare One, Tailscale, Twingate, Teleport replace traditional jump server. No exposed port, application-based access, centralized controls.
CyberArk, BeyondTrust, Delinea, HashiCorp Boundary + Vault. Go beyond: manage passwords, rotate credentials, just-in-time, record sessions, SIEM, compliance dashboards.
Cloud provider maintains the bastion for you.
OPERATING SYSTEM
[ ] Minimal installation
[ ] Only strictly necessary tools
[ ] Patches up to date
[ ] Snapshot/backup before changes
[ ] Golden image documented
[ ] Periodic rebuild scheduled
NETWORK
[ ] Dedicated segment
[ ] Whitelist of source IPs
[ ] Geographic blocking
[ ] Outbound to internet blocked
[ ] Outbound to internal restricted
[ ] Trusted internal DNS
SSH
[ ] Non-standard port
[ ] PermitRootLogin no
[ ] PasswordAuthentication no
[ ] ED25519 or FIDO2 keys
[ ] AuthenticationMethods publickey,keyboard-interactive
[ ] AllowGroups restrictive
[ ] X11/Agent forwarding disabled
[ ] Limits configured
[ ] Modern algorithms
[ ] Legal banner
[ ] fail2ban active
WINDOWS
[ ] Server Core
[ ] NLA enabled
[ ] SMB v1 disabled
[ ] Defender + Credential Guard + Device Guard
[ ] AppLocker / WDAC
[ ] LAPS
[ ] PowerShell Constrained Language Mode
[ ] CIS Benchmark via GPO
AUTHENTICATION
[ ] Mandatory MFA
[ ] Central identity provider
[ ] No local accounts (except break-glass)
[ ] Least privilege
[ ] Granular sudo
[ ] Just-in-time where possible
[ ] Quarterly review
LOGS AND AUDITING
[ ] auditd / Audit Policy
[ ] Real-time forward to SIEM
[ ] Session recording
[ ] Retention defined (≥1 year)
[ ] Logs encrypted in transit
[ ] Restricted access
MONITORING
[ ] SIEM receiving events
[ ] Alert rules
[ ] Immediate notification
[ ] Health dashboard
[ ] Drift detection
INCIDENT RESPONSE
[ ] Documented runbook
[ ] Isolation procedure tested
[ ] Rebuild plan
[ ] Communication defined
[ ] Postmortem after incident
GOVERNANCE
[ ] Documentation updated
[ ] Inventory of who has access
[ ] Formally approved policy
[ ] Periodic reviews scheduled
[ ] Administrator trainingJump server seems simple until you start doing it right. The "quick" version — VM with SSH open that everyone uses — takes half an hour. The "right" version — complete hardening, MFA, session recording, SIEM, segmentation, JIT — takes weeks and requires ongoing processes.
But the right version is the only one that actually protects. The quick version is just another exposed server with elevated privileges.
Start with essentials: basic hardening, MFA, centralized logs, segmentation. Keep evolving. Each control reduces the attack surface a bit more.
And monitor continuously. The jump configured perfectly today can regress tomorrow when someone "just to quickly fix a problem" reopens a port. Without continuous monitoring, hardening is a photo, not a movie.
SentinelHub does exactly this: monitors your public IPs, identifies exposed ports and services (including the jump server), alerts when something new appears, identifies vulnerable versions, in English. If your jump reappears with standard port 22 tomorrow because someone forgot, you'll know.
Found it useful? Share with your infrastructure team. Especially that guy who said "oh, jump server is just frills".