¿Cómo se puede proteger un servidor Linux contra un atacante que intenta abrir una gran cantidad de sesiones SSH (probablemente tratando de forzar una contraseña) para que no haya puertos para poder iniciar sesión legítimamente en la máquina?
El servidor ya utiliza solo el acceso basado en clave SSH y no permite inicios de sesión de raíz, por lo que el forzado de contraseña no es una preocupación.
Una solución generalmente evocada es Fail2Ban : este es un sistema que usa las reglas de firewall (iptables) para bloquear las conexiones entrantes de direcciones IP desde las cuales, aparentemente, se está realizando algún tipo de ataque de búsqueda exhaustiva.
Esto, por supuesto, no funcionará con una DoS distribuida , proveniente de miles de direcciones IP distintas. En general, muy pocas cosas se resisten a un DoS distribuido.
Fail2Ban también puede ser problemático en caso de NAT a gran escala: tiene potencial para bloquear toda una red de los usuarios normales que simplemente comparten la misma dirección IP, visto desde el exterior.
Es muy recomendable , cuando comienzas a configurar herramientas como Fail2Ban, para ejecutar también otro servidor SSH en otro puerto, no cubierto por las reglas Fail2Ban, solo para permitir el reingreso en caso de que una mala configuración te bloquea.
Otra estrategia completamente diferente es mantener una conexión abierta en todo momento. P.ej. tiene un SSH de larga data entre su servidor y su propio sistema de escritorio; incluso puede multiplexar otras conexiones en él (con capacidades SSH para túneles, y / o SOCKS proxying). Esto evita el problema de asignación: no necesita obtener un puerto libre para su conexión root ya que ya tiene uno.
Lea otras preguntas en las etiquetas brute-force denial-of-service ssh