¿Cuáles son las ventajas y desventajas de los diversos métodos para bloquear los ataques de SSH por fuerza bruta?

Existen varios paquetes diferentes para bloquear las IP desde las cuales se lanzan ataques SSH de fuerza bruta en su sistema. Por ejemplo:

• DenyHosts
• Sshguard
• fail2ban

¿Cuáles son las ventajas y desventajas de estos u otros?

Mi solución actual es tomar el correo electrónico que logwatch genera todos los días y volcar las direcciones IP atroces en un archivo de texto que introduzco en un script que luego reconstruye iptables. Es hacky, lento y manual, y me gustaría una mejor manera.

(Tenga en cuenta que no pregunté cuál era la "mejor" forma de resolver el problema, porque no hay una "mejor" forma de hacer nada).

Uso DenyHosts, así que al menos puedo responder por eso:

Pros

• Es completamente automático
• Es configurable (cuántos intentos fallidos antes de la lista negra, para nombres de usuario que no existen, nombres de usuario que existen y una entrada especial para root)
• Puede enviarle un correo electrónico con una lista de hosts recientemente incluidos en la lista negra periódicamente, y / o ejecutar un programa determinado cada vez que un nuevo host está incluido en la lista negra
• Admite hosts que no están en la lista negra automáticamente después de un tiempo

Contras

No tengo inconvenientes irreparables, siempre y cuando lo uses correctamente:

• En su configuración predeterminada, no lo alertará sobre los hosts recién incluidos en la lista negra, por lo que si alguien está atacando su red desde cientos de direcciones diferentes, es posible que no lo note de inmediato como lo haría si está monitoreando sus registros manualmente, pero (como se menciona en la sección de profesionales) puede enviarle un correo electrónico o ejecutar un ejecutable para alertarlo cuando se agregan nuevos hosts
• De forma predeterminada, incluirá en la lista negra a sus hosts igual que cualquier otro, por lo que probablemente desee agregarlos /etc/hosts.allow. Me bloqueé una vez solo por no poder escribir mi contraseña, y una vez que alguien del trabajo intentó iniciar sesión en mi cuenta raíz como una broma y puso en la lista negra la IP de mi trabajo, y me llevó unos días descubrir por qué de repente no pude conectarme. a mi red del trabajo más

Otro es fail2ban , que se basa en iptables (por lo que funciona con cualquier servicio, no solo ssh). Con fail2ban, puedes:

• Especifique la ruta a cualquier archivo de registro (apache, ssh, nginx, servidor de correo, ...).
• Especifique expresiones regulares para patrones de ataque (por ejemplo, más de 10 "errores 404" por la misma ip en el registro de acceso nginx en 6 segundos)
• Especifique expresiones regulares para ignorar ciertos patrones (¡muy útil!)
• Especificar tiempo de prohibición
• Enviar un correo electrónico (o cualquier otra alerta ...)
• Totalmente personalizable (puede escribir sus propias alertas y filtros)

Una "desventaja" de DenyHosts es que requiere envoltorios tcp, por lo que solo funcionará con servicios que busquen en el archivo /etc/hosts.deny. Pero para ser justos con DenyHosts, sshd está compilado para usar TCP Wrappers en la mayoría de las distribuciones de Linux. También encuentro que DenyHosts es más fácil de configurar de fábrica que fail2ban (pero menos potente).

Referencia a una pregunta SF similar

Una protección simple y efectiva en la práctica contra ataques basados ​​en escaneo es no usar el puerto estándar. 443 (el puerto https) lo expone a diferentes ataques de fuerza bruta que no van a descifrar sus contraseñas débiles, y posiblemente funcione a través de más firewalls que el puerto predeterminado (22).

La mayoría de los métodos para prevenir ataques de fuerza bruta ssh son excelentes formas de auto-DoS (¡Uy, arruiné la configuración! ¡Vaya, hice un montón de rsync rápidos y ahora estoy prohibido por el día!) , el atacante proviene de / ha subvertido una máquina en la misma subred que yo (rango dinámico de IP, red universitaria ...) ¡y también me han prohibido!).

Si solo inicia sesión desde unos pocos lugares, puede simplemente incluir en la lista blanca las direcciones IP de origen. Obviamente, eso no es bueno si desea hacer ssh desde su computadora portátil o teléfono celular mientras viaja.

Tener un demonio ssh que solo escuche conexiones IPv6 debería protegerlo de los escaneos durante algunos años. Pero muchos firewalls no le permitirán transportar IPv6 de ninguna manera razonable.

Otro método que no menciona es el golpe de puerto . No sufre problemas de auto-DoS (aparte de la configuración incorrecta), pero no cruza bien los firewalls y puede agregar una latencia de varios segundos al establecimiento de la conexión.

Si tiene buenas contraseñas, o puede vivir sin autenticación de contraseña, desactive la autenticación de contraseña. (Las claves y las contraseñas de un solo uso son suficientes para la mayoría de los casos de uso: si no confía en la máquina del cliente lo suficiente como para almacenar una clave ssh, tampoco confía en que no tenga un keylogger). Luego, los ataques de fuerza bruta le costarán un poco de CPU y ancho de banda, pero no lo expondrán a una intrusión (siempre y cuando haya verificado que ninguna de sus claves proviene de un OpenSSL de baja entropía de Debian ).

En general, tenga en cuenta que cambiar el puerto no reduce significativamente su exposición. Obtendrá menos escaneo , pero todo lo que puede cortar es la fruta que busca explotar vulnerabilidades antiguas y contraseñas débiles. Siempre y cuando mantenga su demonio actualizado y aplique contraseñas razonables o límites de velocidad de intento razonables, cambiar el puerto es más una responsabilidad que una medida de seguridad.