¿Cuáles son los pros / contras de los distintos métodos para bloquear ataques SSH de fuerza bruta?
Hay una serie de paquetes diferentes para bloquear las IP desde las que se lanzan ataques SSH de fuerza bruta en su sistema. Por ejemplo:
¿Cuáles son los pros/contras 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 ingreso en un script que luego reconstruye iptables. Es hacky, requiere mucho tiempo y es manual, y me gustaría una mejor manera.
(Tenga en cuenta que no pregunté cuál era la "mejor" manera de resolver el problema, porque no existe la "mejor" manera de hacer nada).
Yo 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 sí existen y una entrada especial para root)
- Puede enviarle un correo electrónico con una lista de hosts nuevos en la lista negra periódicamente y/o ejecutar un programa determinado cada vez que un nuevo host se incluye en la lista negra.
- Admite la eliminación automática de hosts en la lista negra después de un tiempo
Contras
No tengo inconvenientes irreparables, siempre que lo uses correctamente:
- En su configuración predeterminada, no lo alertará sobre 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 estuviera 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 avisarle cuando se agreguen nuevos hosts
- De forma predeterminada, incluirá a sus hosts en la lista negra al igual que cualquier otro, por lo que probablemente desee agregarlos a
/etc/hosts.allow. Una vez me bloqueé por no escribir mi contraseña, y una vez alguien del trabajo intentó iniciar sesión en mi cuenta de root como una broma y puso en la lista negra mi IP de trabajo, y me tomó unos días descubrir por qué de repente no podía conectarme a mi red desde el trabajo ya
Otro es fail2ban , que se basa en iptables (por lo que funciona con cualquier servicio, no solo ssh). Con fail2ban, puede:
- 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 de nginx en 6 segundos)
- Especifique regex para ignorar ciertos patrones (¡muy útil!)
- Especificar el tiempo de prohibición
- Envíe 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 que fail2ban (pero menos poderoso).
Una protección simple y efectiva en la práctica contra los 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! ¡Uy, hice un montón de rsync rápidos y ahora estoy prohibido por el día!) O auto-DoS asistido , el atacante viene de/ha subvertido una máquina en la misma subred que yo (rango de IP dinámico, red universitaria ...) ¡y también me están prohibiendo!).
Si solo inicia sesión desde algunos lugares, puede incluir las direcciones IP de origen en la lista blanca. Obviamente, eso no es bueno si desea realizar un 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 cortafuegos no le permitirán transportar IPv6 de forma razonable.
Otro método que no mencionas es golpe de puerto . No sufre problemas de auto-DoS (aparte de una mala configuración), 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 lo suficiente en la máquina cliente 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 que haya verificado que ninguna de sus claves proviene de un Debian OpenSSL de baja entropía ) .
Con todo, 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 madura que busca explotar viejas vulnerabilidades y contraseñas débiles. Siempre que mantenga su daemon actualizado y aplique contraseñas razonables o límites razonables de tasa de intentos, cambiar el puerto es más una responsabilidad que una medida de seguridad.