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:
No tengo inconvenientes irreparables, siempre que lo uses correctamente:
/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 yaOtro es fail2ban , que se basa en iptables (por lo que funciona con cualquier servicio, no solo ssh). Con fail2ban, puede:
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.