¿Vale la pena el esfuerzo para bloquear intentos fallidos de inicio de sesión?

¿Vale la pena ejecutar fail2ban , sshdfilter o herramientas similares, que enumeran las direcciones IP que intentan y no pueden iniciar sesión?

Lo he visto argumentar que esto es un teatro de seguridad en un servidor "debidamente protegido". Sin embargo, creo que probablemente haga que los kiddies de script pasen al siguiente servidor de su lista.

Digamos que mi servidor está "debidamente protegido" y no me preocupa que un ataque de fuerza bruta realmente tenga éxito: ¿estas herramientas simplemente mantienen limpios mis archivos de registro o estoy obteniendo algún beneficio valioso al bloquear los intentos de ataque de fuerza bruta?

Actualización : muchos comentarios sobre la fuerza bruta de adivinar las contraseñas. Mencioné que no estaba preocupado por esto. Quizás debería haber sido más específico y preguntar si fail2ban tenía algún beneficio para un servidor que solo permite inicios de sesión ssh basados ​​en claves.

Los intentos de inicio de sesión con limitación de velocidad son una manera fácil de evitar algunos de los ataques de alta velocidad para adivinar contraseñas. Sin embargo, es difícil limitar los ataques distribuidos y muchos corren a un ritmo bajo durante semanas o meses. Personalmente prefiero evitar el uso de herramientas de respuesta automatizadas como fail2ban. Y esto es por dos razones:

1. Los usuarios legítimos a veces olvidan sus contraseñas. No quiero prohibir a los usuarios legítimos de mi servidor, obligándome a habilitar manualmente sus cuentas de nuevo (o peor, intentar averiguar cuál de las 100/1000 direcciones IP prohibidas es la suya).
2. Una dirección IP no es un buen identificador para un usuario. Si tiene varios usuarios detrás de una sola IP (por ejemplo, una escuela que ejecuta NAT en 500 máquinas de estudiantes), un solo usuario que haga algunas conjeturas puede llevarlo a un mundo de dolor. Al mismo tiempo, la mayoría de los intentos de adivinar contraseñas que veo se distribuyen.

Por lo tanto, no considero fail2ban (y herramientas de respuesta automatizadas similares) como un enfoque muy bueno para asegurar un servidor contra ataques de fuerza bruta. Un simple conjunto de reglas de IPTables para reducir el spam de registro (que tengo en la mayoría de mis servidores Linux) es algo como esto:

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

Evita más de 4 intentos de conexión desde una sola IP a ssh en cualquier período de 60 segundos. El resto puede manejarse asegurando que las contraseñas sean razonablemente seguras. En los servidores de alta seguridad, obligar a los usuarios a usar la autenticación de clave pública es otra forma de dejar de adivinar.

Herramientas como fail2ban ayudan a reducir el tráfico innecesario de la red y a mantener los archivos de registro un poco más pequeños y limpios. No es una gran cura de seguridad, pero hace que la vida del administrador de sistemas sea un poco más fácil; Es por eso que recomiendo usar fail2ban en sistemas donde puede permitírselo.

No se trata solo de reducir el ruido: la mayoría de los ataques ssh intentan adivinar por fuerza bruta las contraseñas. Entonces, si bien verá muchos intentos fallidos de ssh, tal vez para el momento en que llegue el intento 2034 puedan obtener un nombre de usuario / contraseña válidos.

Lo bueno de fail2ban en comparación con otros enfoques es que tiene un efecto mínimo en los intentos de conexión válidos.

Bueno, salva su red de los ataques de negación, y ahorra la sobrecarga de procesar las fallas.

No ser el servidor más débil en una lista de script kiddies siempre es algo bueno.

Lo siento, pero diría que su servidor está debidamente protegido si su sshd rechaza los intentos de autenticación con contraseñas.

PasswordAuthentication no