Jump Server: La Guía para Amplificar tu Seguridad — Cómo Construir, Proteger y No Convertir Tu Bastión en la Puerta Trasera Cómo un servidor pequeño y dedicado puede ser la diferencia entre soporte organizado y el próximo titular sobre ransomware. Y cómo, si está mal configurado, puede ser también la puerta exacta por donde entra el atacante.
Cómo un servidor pequeño y dedicado puede ser la diferencia entre soporte organizado y el próximo titular sobre ransomware. Y cómo, si está mal configurado, puede ser también la puerta exacta por donde entra el atacante.
Si leíste el post anterior sobre acceso remoto seguro, ya sabes la regla de oro: nunca expongas RDP, SSH o ningún servicio administrativo directamente en internet. Pero entonces surge la pregunta práctica: ¿cómo acceden el equipo de soporte, los DBAs, los sysadmins y los proveedores a los servidores cuando lo necesitan?
La respuesta tradicional es el jump server — también llamado bastion host, stepping stone server, jump box. Es un concepto que tiene más de 30 años y sigue siendo relevante porque resuelve un problema fundamental: centralizar y controlar todo el acceso administrativo a una infraestructura.
Pero aquí está la paradoja: un jump server mal configurado es peor que no tener jump server. ¿Por qué? Porque crea una falsa sensación de seguridad. Crees que estás protegido porque tienes "ese bastión", cuando en realidad se convirtió exactamente en lo que deberías evitar — un único punto, conocido, expuesto, y lleno de privilegios.
Un jump server es una máquina dedicada, endurecida al máximo, posicionada como único punto de paso entre el mundo externo y los recursos internos críticos.
En lugar de que cada servidor exponga SSH o RDP, solo el jump server acepta conexiones. Quien necesita administrar cualquier cosa, primero entra en el jump server, y desde allí alcanza los destinos.
La analogía: si tu infraestructura es un edificio, el jump server es la portería con torniquete. Nadie entra directo a las salas — todo el mundo pasa por la portería, muestra su credencial, se registra.
Lo que NO es jump server:
Por qué existe:
Internet → [Firewall] → [Jump] → [Servidores]Para equipos pequeños. Limitación: punto único de fallo y comprometimiento.
Internet → [FW ext] → [Jump 1 DMZ] → [FW int] → [Jump 2 interno] → [Servidores]Para ambientes regulados. El atacante necesita comprometer dos servidores.
El broker valida todo, obtiene credenciales temporales del cofre, establece la sesión sin mostrar la contraseña. Soluciones: CyberArk, BeyondTrust, Delinea, HashiCorp Boundary, Teleport.
Centraliza acceso a múltiples clientes. Cuidado: se convierte en el objetivo de los sueños. Idealmente, cada cliente debería tener su propio jump segregado.
Jump server no es una estación de trabajo. Sin Office, sin navegador, sin aplicación, sin nada no-esencial.
# 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: usa Server Core siempre que sea posible.
Linux jump típicamente tiene: OpenSSH, cliente RDP (xfreerdp), mysql/psql client, nmap, dig, traceroute, tcpdump, vim, tmux, ansible.
Windows jump típicamente tiene: mstsc, PuTTY, RSAT, PowerShell modules, SSMS.
Lo que NO debe tener: navegador, correo, Office, Adobe Reader, cliente Java, software personal, compiladores.
Regla: si no puedes justificarlo, no necesita estar allí.
Entrada:
Salida:
Si el atacante compromete el jump, lo primero será descargar herramientas y conectarse a C2. Bloqueando la salida, rompes la cadena.
# /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.txtBanner legal:
*****************************************************************
ACCESO RESTRINGIDO Y MONITOREADO
Este sistema es para uso exclusivo de personal autorizado.
Todas las actividades se registran y monitorean.
El uso no autorizado puede resultar en acciones disciplinarias
y/o proceso penal.
Al continuar, aceptas estas condiciones.
*****************************************************************Sin excepción. Para todos. Siempre.
Linux con 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-interactiveLa directiva AuthenticationMethods publickey,keyboard-interactive fuerza clave y TOTP.
Hardware tokens FIDO2 (más seguro):
ssh-keygen -t ed25519-sk -f ~/.ssh/id_ed25519_skLa clave privada está dentro del token físico (YubiKey). Incluso malware en la máquina no puede extraerla.
dba-mysql, sysadmin-linux, support-tier1, vendor-acme)ALLrbash, lshell)Ejemplo /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/mysqlNo uses cuentas locales. Integra con AD/LDAP/Azure AD/Okta/Google Workspace.
Ventajas:
# Linux con AD vía SSSD
sudo apt install sssd realmd adcli krb5-user samba-common-bin
sudo realm join dominio.empresa.local --user=adminEl usuario no tiene acceso permanente. Solicita, justifica, se aprueba, expira.
Soluciones: CyberArk, Teleport, HashiCorp Boundary + Vault, Azure PIM, AWS Session Manager.
Versión simple con script:
#!/bin/bash
USER=$1
HOURS=$2
usermod -a -G jump-users $USER
echo "gpasswd -d $USER jump-users" | at now + $HOURS hoursLinux con 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 auditdCentraliza todo en un SIEM (Wazuh, Graylog, ELK, Splunk). Los logs locales no sirven si el atacante los borra.
La característica más poderosa de un jump server bien hecho. Graba todo lo que hace cada admin.
Por qué es poderoso:
tlog (Red Hat, open-source):
sudo apt install tlog
# /etc/tlog/tlog-rec-session.conf
{
"shell": "/bin/bash",
"notice": "\nADVERTENCIA: Esta sesión está siendo grabada para auditoría.\n",
"writer": "journal",
"log": {
"input": true,
"output": true,
"window": true
}
}
sudo usermod -s /usr/bin/tlog-rec-session usuarioReproduce con:
tlog-play -r journal -M TLOG_USER=usuarioOtras herramientas:
Importante:
Los logs locales son logs desechables. El atacante los borra primero.
# /etc/rsyslog.d/forward.conf
*.* @@siem.empresa.local:6514 # TCP con TLSForward en tiempo real, no en lotes.
Reconstrucción periódica: cada 3-12 meses, destruye y reconstruye desde cero vía Ansible/Terraform/Packer. Elimina drift, basura acumulada, cualquier backdoor no detectada. Es como cambiar la cerradura de la puerta delantera periódicamente.
wget o curl (intento de descargar payload)/tmp, /var/tmp, /dev/shm/etc/passwd, /etc/shadow, /etc/ssh/sshd_configNotificación inmediata (pager, SMS) para eventos críticos. No reportes al día siguiente.
Runbook listo para "jump server fue comprometido":
Cloudflare One, Tailscale, Twingate, Teleport reemplazan el jump server tradicional. Sin puerto expuesto, acceso por aplicación, controles centralizados.
CyberArk, BeyondTrust, Delinea, HashiCorp Boundary + Vault. Van más allá: gestionan contraseñas, rotan credenciales, just-in-time, graban sesiones, SIEM, dashboards de compliance.
El proveedor de cloud mantiene el bastión por ti.
SISTEMA OPERACIONAL
[ ] Instalación minimal
[ ] Solo herramientas estrictamente necesarias
[ ] Patches al día
[ ] Snapshot/backup antes de cambios
[ ] Imagen de oro documentada
[ ] Reconstrucción periódica programada
RED
[ ] Segmento dedicado
[ ] Whitelist de IPs de origen
[ ] Bloqueo geográfico
[ ] Salida a internet bloqueada
[ ] Salida a interna restringida
[ ] DNS interno confiable
SSH
[ ] Puerto no-estándar
[ ] PermitRootLogin no
[ ] PasswordAuthentication no
[ ] Claves ED25519 o FIDO2
[ ] AuthenticationMethods publickey,keyboard-interactive
[ ] AllowGroups restrictivo
[ ] X11/Agent forwarding deshabilitados
[ ] Límites configurados
[ ] Algoritmos modernos
[ ] Banner legal
[ ] fail2ban activo
WINDOWS
[ ] Server Core
[ ] NLA habilitado
[ ] SMB v1 deshabilitado
[ ] Defender + Credential Guard + Device Guard
[ ] AppLocker / WDAC
[ ] LAPS
[ ] PowerShell Constrained Language Mode
[ ] CIS Benchmark vía GPO
AUTENTICACIÓN
[ ] MFA obligatorio
[ ] Identity provider central
[ ] Sin cuentas locales (excepto break-glass)
[ ] Menor privilegio
[ ] Sudo granular
[ ] Just-in-time donde sea posible
[ ] Revisión trimestral
LOGS Y AUDITORÍA
[ ] auditd / Audit Policy
[ ] Forward en tiempo real al SIEM
[ ] Grabación de sesión
[ ] Retención definida (≥1 año)
[ ] Logs encriptados en tránsito
[ ] Acceso restringido
MONITOREO
[ ] SIEM recibiendo eventos
[ ] Reglas de alerta
[ ] Notificación inmediata
[ ] Dashboard de salud
[ ] Drift detection
RESPUESTA A INCIDENTES
[ ] Runbook documentado
[ ] Procedimiento de aislamiento probado
[ ] Plan de reconstrucción
[ ] Comunicación definida
[ ] Postmortem después del incidente
GOBERNANZA
[ ] Documentación actualizada
[ ] Inventario de quién tiene acceso
[ ] Política aprobada formalmente
[ ] Revisiones periódicas agendadas
[ ] Entrenamiento de administradoresJump server parece simple hasta que comienzas a hacerlo correctamente. La versión "rápida" — VM con SSH abierto que todos usan — toma media hora. La versión "correcta" — hardening completo, MFA, grabación de sesión, SIEM, segmentación, JIT — toma semanas y requiere procesos continuos.
Pero la versión correcta es la única que efectivamente protege. La versión rápida es solo otro servidor expuesto con privilegios elevados.
Comienza con lo esencial: hardening básico, MFA, logs centralizados, segmentación. Ve evolucionando. Cada control reduce la superficie de ataque un poco más.
Y monitorea continuamente. El jump configurado perfectamente hoy puede tener regresiones mañana cuando alguien "solo para resolver un problema rápido" reabre un puerto. Sin monitoreo continuo, hardening es foto, no película.
El SentinelHub examina exactamente esto: monitorea tus IPs públicas, identifica puertos y servicios expuestos (incluyendo el jump server), alerta cuando algo nuevo aparece, identifica versiones vulnerables, en español. Si tu jump reaparece con el puerto 22 estándar mañana porque alguien olvidó, te enteras.
¿Te pareció útil? Comparte con tu equipo de infraestructura. Especialmente con ese tipo que dijo "ah, jump server es floritura".