Deja de exponer el puerto 22 a internet

Deja de exponer el puerto 22 a internet

Cualquier servidor Linux con el puerto 22 abierto recibe intentos de intrusión en cuestión de minutos. Los escáneres automáticos lo encontrarán a los pocos minutos y no van a parar de probar combinaciones de usuario y contraseña. La mayoría de los administradores lo asumimos como ruido de fondo — hasta que aparece una vulnerabilidad como regreSSHion (CVE-2024-6387) y ese ruido se convierte en un problema real.

Endurecer la configuración de SSH reduce el riesgo, Pero sacarlo de la internet pública lo elimina. Este artículo muestra cómo hacer esto en tres pasos.

Para saber de qué hablamos, ejecuta esto en tu servidor. En sistemas basados en Debian/Ubuntu:

journalctl -u ssh --since today | grep -c "Failed password"

En RHEL, AlmaLinux o RockyLinux los logs van a /var/log/secure:

grep -c "Failed\|Invalid user" /var/log/secure

Ese número son intentos de intrusión recibidos hoy. Y si quieres ver quién llama a la puerta en tiempo real:

tail -f /var/log/secure | grep --line-buffered "sshd"

Nivel 1: Desactiva el acceso por contraseña

El primer paso es el más sencillo y el más urgente. Si en algún servidor todavía está habilitado el login con contraseña, cualquier atacante puede intentarlo indefinidamente. Desactívalo:

# /etc/ssh/sshd_config
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Recarga el servicio con systemctl reload sshd, pero no cierres tu sesión actual. Abre una segunda terminal y comprueba que sigues pudiendo entrar. Así no te quedas fuera si algo sale mal. También es buen momento para revisar los authorized_keys de cada usuario — suele haber claves que ya no se usan.

Nivel 2: Restringe el acceso por origen

El daemon de SSH no puede ser atacado si nadie puede alcanzarlo. Si te conectas siempre desde una VPN o desde una máquina fija, configura el firewall para que solo esa IP pueda llegar al puerto 22:

permitir  tcp/22  desde  <tu IP de VPN o bastión>
denegar   tcp/22  desde  todo lo demás

Algunas advertencias prácticas antes de aplicarlo:

• Comprueba tu IP real de origen con echo $SSH_CLIENT dentro del servidor, no asumas cuál es.
• Aplica el cambio en el firewall que realmente gobierna el host (ufw, firewalld, nftables…). Una regla en el sitio equivocado se ignora o desaparece en el siguiente reload.
• Si tu proveedor cloud ofrece security groups, úsalos: puedes editarlos desde el panel aunque hayas perdido acceso al servidor.
• Deja programada una reversión automática con at y cancélala solo cuando confirmes que el acceso sigue funcionando.

El lado negativo: esta lista de IPs hay que mantenerla: rotan, cambian. Te pilla de guardia desde un hotel y quedas fuera. De ahí el nivel 3.

Nivel 3: Cierra el puerto definitivamente

La raíz del problema es que SSH funciona en dirección entrante: el servidor espera conexiones, y para eso necesita un puerto abierto. La solución es invertirlo.

Un agente ligero instalado en el servidor se conecta hacia fuera, a un plano de control, y mantiene abierto un canal cifrado y autenticado — igual que cualquier cliente HTTPS sale de tu red sin necesidad de abrir ningún puerto. Cuando necesitas una shell, te conectas al plano de control y tu sesión viaja por ese canal ya establecido: autenticada, auditada y por una conexión TLS cifrada.

antes:    tú ──▶ tcp/22 ──▶ sshd      puerto abierto a todo internet

después:  tú ──▶ plano de control ◀── agente   
          el servidor se conecta hacia afuera. Tu sesión viaja por ese canal

Con esto desaparece la clase entera de ataques: no hay puerto que los escáneres encuentren, no hay prompt de login que forzar, no hay daemon expuesto para el próximo 0-day de sshd.

El cierre del puerto en el firewall es solo la limpieza final:

denegar  tcp/22  desde  cualquier origen

Sobre este modelo está construido CentralHost: el agente mantiene un WebSocket saliente al panel de control, y cada sesión queda autenticada, ligada a un operador con nombre y registrada.

Importante: Es fundamental mantener igualmente una vía de emergencia — la consola de tu proveedor o un sshd limitado a tu VPN — por si el panel de control no estuviera disponible.

Por dónde empezar

1. Hoy — desactiva el login por contraseña y audita los authorized_keys.
2. Esta semana — restringe el puerto 22 a tu VPN o bastión.
3. Este trimestre — implanta el canal saliente, cierra el 22 entrante y documenta la vía de emergencia.

Después del último paso, el contador de ataques marcará 0 y tu puerto SSH dejará de ser un blanco de ataque.