Cómo es realmente un ataque de fuerza bruta SSH

El ataque, en términos claros

Un ataque de fuerza bruta SSH no va dirigido a ti. Es una operación de masas: alguien alquila una botnet, le pasa rangos de IP y le hace intentar iniciar sesión en todo lo que responda en el puerto 22. La lista de nombres es corta y aburrida — root, admin, ubuntu, test, git, oracle, postgres, y las cuentas de servicio que estén de moda este año.

La economía lo mantiene en marcha. Una shell en una máquina Linux vale dinero — para minar, como proxy, como punto de apoyo hacia todo lo que la máquina alcance — y un intento no cuesta prácticamente nada. Pon un servidor nuevo en una IP pública: el primer sondeo suele llegar en menos de una hora, y una semana después unos miles de fallos al día no tiene nada de particular.

El volumen es lo importante. Una persona adivinando tu contraseña es una anécdota. Cien mil intentos al mes desde direcciones rotatorias es una condición de fondo, y las defensas pensadas para lo primero no hacen nada contra lo segundo.

Qué están intentando realmente

En el mismo registro aparecen tres comportamientos distintos, y piden respuestas diferentes.

Los intentos de inicio de sesión como root son los más ruidosos y los menos peligrosos, porque cualquier servidor bien configurado tiene PermitRootLogin en no o prohibit-password. Miles al día significan que los bots aún no han deducido que root no está disponible — nunca lo deducen, porque seguir preguntando no les cuesta nada.

Luego viene la enumeración de nombres: un recorrido por cuentas comunes buscando una que exista. En OpenSSH moderno las diferencias de tiempo que hacían esto fiable han desaparecido en gran medida, pero los bots lo intentan igual, y un acierto les da un objetivo.

El credential stuffing es el que funciona. Pares de usuario y contraseña de la filtración de otro, reproducidos contra tu servidor. Parece un número pequeño de intentos, no una avalancha, y funciona cuando un desarrollador reutilizó una contraseña. Ningún límite de tasa lo atrapa, porque no hay tasa que limitar.

Lo que SSH ofrece y otros protocolos no

SSH tiene una salida de la que carecen la mayoría de servicios expuestos: la autenticación por clave pública. Desactiva la autenticación por contraseña por completo y toda la categoría de ataques de adivinación pasa a ser no más difícil, sino imposible. No hay contraseña que adivinar.

Ese es realmente el movimiento más fuerte disponible, y si puedes hacerlo, todo lo demás en este artículo es secundario. Tiene su propia guía.

Sin embargo, no detiene el tráfico. Los bots no conocen tu configuración; siguen conectándose, siguen ofreciendo contraseñas y siguen siendo rechazados. Cada intento sigue costando una conexión TCP, un fork de sshd, una línea de registro y una porción de CPU, y tu registro de autenticación sigue rotando lo bastante rápido como para perder los eventos que necesitabas. Solo-claves elimina el riesgo. No elimina la carga.

Por qué limitar la tasa no basta

La primera respuesta habitual es fail2ban, y es razonable — está en los repositorios de todas las distribuciones y funciona. Sus límites conviene entenderlos antes de confiarle toda la defensa.

Banea direcciones sueltas. Las botnets rotan por un rango: banea 203.0.113.47 y .48 arranca una hora después. Banear el /24 termina la tanda de un golpe, y fail2ban no lo hace de fábrica.

Sus baneos caducan. El valor por defecto se mide en minutos, y la misma botnet vuelve esta noche. Puedes alargarlos, pero el estado vive en memoria y en un archivo que no sobrevive a una reconstrucción.

No aprende de nadie más. Cada servidor descubre a cada atacante por su cuenta, desde cero, al precio de absorber los primeros N intentos cada vez.

Y falla en silencio. Una expresión regular que dejó de coincidir tras una actualización de distribución, una jail desactivada por una actualización de paquete, un servicio que no volvió tras un reinicio — nada de eso se anuncia, y el fallo parece exactamente calma.

Qué reduce realmente el tráfico

Solo una cosa cambia el volumen: negarse a hablar con el origen. Todo lo demás negocia con él.

Eso significa vigilar el flujo de fallos y, cuando un origen cruza un umbral, descartarlo en el firewall antes de que sshd gaste nada en él. Tres propiedades separan una defensa que aguanta de una que gotea:

• Banear la subred, no la dirección. El tráfico de ataque viene de rangos de hosting donde las direcciones vecinas pertenecen al mismo operador; los usuarios legítimos casi nunca comparten un /24 con un escáner.
• Banear de forma permanente y sobrevivir a los reinicios. La regla tiene que vivir en nftables y restaurarse al arrancar, no en la memoria de un demonio.
• Ponerte a ti mismo en la lista blanca antes de activar nada. La forma más común de estropearlo es un administrador que bloquea su propia dirección en un servidor al que solo llega por SSH.

Conseguirlo sin mantener la maquinaria

SSH Protector es esa lógica empaquetada como agente. Lee el mismo flujo de journald o auth.log que leerías tú, decide localmente — así que sigue funcionando si cae la red — y mantiene un único conjunto nftables consolidado con todos los rangos baneados.

Al instalarse detecta el puerto SSH real desde la configuración de sshd en lugar de asumir el 22, y pone en lista blanca la dirección desde la que estás conectado antes de bloquear nada.

Lo que no puedes construir solo es la reputación compartida: una dirección que atacó a otro cliente ya está bloqueada antes de llegar a ti, así que nunca absorbes sus primeros N intentos. Un servidor es gratis para siempre, lo bastante para observar un flujo de ataques real en tu propia máquina y decidir con pruebas en vez de con un artículo.