¿Cómo proteger el servidor ubuntu de los ataques ssh de fuerza bruta?

Tengo mis contraseñas seguras, pero escuché a la gente quejarse de que un servidor se está cayendo drásticamente cuando se produce un ataque de fuerza bruta. ¿Cómo puedo proteger mi servidor ubuntu 10.10 de tales ataques? ¿Hay un perfil de aparición para esto? ¿O alguna otra forma de abordarlo?

Hay diferentes soluciones. La mejor es usar la autenticación RSA que usa claves públicas / privadas para autenticar a los usuarios.

Consulte este excelente manual para conocer diferentes enfoques (autenticación RSA incluida): http://www.la-samhna.de/library/brutessh.html

Estoy usando la tercera solución en mi servidor porque no quiero complicarla para mis usuarios no técnicos: usar iptablespara limitar la cantidad de conexiones por minuto que hace que los ataques de fuerza bruta sean ineficientes e ineficaces.

Aquí está la solución que estoy usando:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Como se menciona aquí : esto permitirá tres conexiones de 22 puertos desde cualquier dirección IP dentro de un período de 60 segundos, y requerirá 60 segundos de intentos de conexión posteriores antes de que se reanude permitiendo conexiones nuevamente. La opción --rttl también tiene en cuenta el TTL del datagrama al hacer coincidir paquetes, a fin de tratar de mitigar las direcciones de origen falsificadas.

Como se indica en la guía mencionada, es mejor usar una lista blanca para separar a los usuarios confiables de estas reglas:

iptables -N SSH_WHITELIST

luego agregue hosts de confianza:

iptables -A SSH_WHITELIST -s $TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT

y luego haz las reglas:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Recibo ataques ssh de fuerza bruta en mis servidores con una tasa de 1 a 2 por día. He instalado denyhosts (paquete ubuntu: denyhosts). Es una herramienta muy simple pero efectiva para ese propósito: esencialmente escanea periódicamente sus registros para detectar ataques de fuerza bruta y coloca las IP de donde se originan estos ataques en su archivo /etc/hosts.deny. No volverá a saber de ellos y su carga debería reducirse considerablemente. Es muy configurable a través de su archivo de configuración /etc/denyhosts.conf para modificar problemas como cuántos intentos incorrectos constituyen un ataque, etc.

Debido a su funcionamiento transparente, puede ver fácilmente lo que está sucediendo (notificación por correo electrónico: "¡ajá, otro ataque horrible frustrado!") Y deshacer errores debido a que sus usuarios escriben mal sus contraseñas repetidamente.

Por supuesto, todo lo que se dijo anteriormente sobre cambiar a otros métodos de autenticación es válido, pero a veces sus requisitos no están de acuerdo con los de sus usuarios.

Además, la limitación de la velocidad de conexión nueva en iptables podría ser una mejor opción que negar el acceso a través de hosts.deny. Por lo tanto, eche un vistazo a fail2ban también. Pero si sabe que la fuerza bruta ssh es su principal preocupación (mire manualmente /var/log/auth.log para determinar esto), vaya con esta herramienta muy fácil y de bajo impacto.

1. Cambie el puerto sshd a algo no estándar
2. Úselo knockdpara implementar un sistema de apertura de puertos
3. Use iptables recenty hashlimitcoincidencias para limitar intentos de SSH consecutivos
4. No use contraseñas, en su lugar use claves SSH

En primer lugar, debe considerar no usar contraseñas y usar claves en su lugar. No hay necesidad de usar una contraseña. Si esto funciona para usted, puede configurar el servidor OpenSSH para que no reaccione en los inicios de sesión de contraseña.

https://help.ubuntu.com/10.04/serverguide/C/openssh-server.html

Usar fail2ban también podría ser una opción.

https://help.ubuntu.com/community/Fail2ban

¿Cuán ampliamente está expuesto el servidor en la red? Quizás pueda hablar con el administrador de la red y verificar si es posible monitorear y restringir el acceso de la red al servidor. Incluso si los inicios de sesión de la cuenta son seguros, parece que el servidor podría sufrir un simple ataque DoS / DDoS.

Una alternativa a fail2ban es CSF: ConfigServer Security & Firewall .

Viene con LFD: un Daemon de falla de inicio de sesión que puede detectar múltiples intentos fallidos de inicio de sesión en varios servicios y bloqueará la dirección IP infractora (temporal o permanentemente).

Tiene algunas otras opciones que pueden ayudar contra ataques de inundación y posiblemente detectar intrusiones.

Desventajas

• Debe usar CSF como su firewall para que LFD haga su trabajo. Entonces, si tiene un firewall existente, deberá reemplazarlo con CSF y transferir su configuración.
• No está empaquetado para Ubuntu. Tendrá que confiar en las actualizaciones automáticas de configserver.com o deshabilitar las actualizaciones automáticas.
• He oído que es bastante popular, por lo que los intrusos inteligentes probablemente sabrán cómo deshabilitar la detección de intrusos antes de que sean detectados.

¿Pretende permitir el servicio SSH al mundo? ¿O solo para miembros del equipo en lugares particulares? Mi respuesta depende un poco de la gravedad de tu desafío.

En cualquier caso, una cosa que debe hacer es asegurarse de que el servidor SSH no permita inicios de sesión de contraseña para el usuario root.

1. En / etc / ssh / sshd_config, asegúrese de no permitir nunca un inicio de sesión raíz, excepto con una clave SSH.

En mis sistemas, tengo esta configuración

PermitRootLogin without-password

pero noto que en Ubuntu más nuevos tienen

PermitRootLogin prohibit-password

Si lees "man sshd_config", creo que significa que esta nueva "prohibición de contraseña" significa lo mismo y ciertamente tiene un significado más obvio. Eso NO es predeterminado en algunos sistemas Linux, pero probablemente debería serlo.

Ahora, sobre tu problema. ¿Su sistema solo sirve a algunos usuarios en lugares particulares? ¡Hacer esto!

2. edite /etc/hosts.deny e inserte

   TODO TODO

Luego edite /etc/hosts.allow y enumere los números de IP o un rango que desee permitir el uso de SSH. La notación allí es un poco confusa porque si desea permitir todos los sistemas con números IP como 111.222.65.101 a 111.222.65.255, ingrese una entrada como esta en hosts.allow

ALL: 127.0.0.1
sshd: 111.222.65.
sshdfwd-X11: 111.222.65.

Esa es una fuerza bruta, una solución poderosa. Si sus usuarios se pueden enumerar por rango de IP, ¡hágalo!

Esta solución existía antes de que se crearan las tablas IP, es (creo) mucho más fácil de administrar, pero no es tan buena como una solución de tablas IP porque las rutinas de las tablas IP detectarán enemigos antes que los programas conducidos por hosts.allow y hosts .negar. Pero este es un fuego seguro, una forma simple de cerrar muchos problemas, no solo de SSH.

Tenga en cuenta el problema que crea para usted mismo. Si desea abrir un servidor FTP, un servidor web o cualquier otra cosa, deberá permitir que las entradas en los hosts lo permitan.

Puede lograr el mismo propósito básico jugando con iptables y el firewall. En cierto sentido, esta es una solución preferida porque estás bloqueando enemigos en el límite exterior. Ubuntu tiene "ufw" (firewall sin complicaciones) y "man ufw" tiene muchos ejemplos. Prefiero tener una buena GUI para leer esto, no tengo que hacer esto todo el tiempo. Tal vez otros puedan decirnos si hay uno ahora.

3. Otras publicaciones aquí sugieren utilizar la clave pública SSH solo para sus usuarios. Eso ciertamente ayudará, a costa de la complejidad y la frustración de sus usuarios. En nuestro laboratorio, hay 15 computadoras. Los usuarios van entre las computadoras. Requerir la autenticación de la clave SSH causaría una gran molestia porque las personas van de una computadora a otra.

Otra fuente de frustración ocurrirá cuando algunos usuarios acumulen diferentes claves ssh para varios servidores. Debido a que tengo claves SSH para aproximadamente 12 proyectos diferentes, ahora ssh falla porque tengo demasiadas claves públicas (que requieren "ssh -o PubkeyAuthentication = false" o la creación de una entrada en el archivo .ssh / config. Es un PITA)

4. Si debe dejar el servidor abierto a SSH desde el gran mundo, definitivamente debe usar una rutina de rechazo para bloquear ubicaciones que con frecuencia intentan iniciar sesión. Hay 2 buenos programas para esto, los que hemos usado son denyhosts y fail2ban . Estos programas tienen configuraciones que le permiten prohibir a los delincuentes, durante el tiempo que desee.

En nuestros sistemas Centos Linux, noté que descartaron el paquete denyhosts y solo ofrecen fail2ban. Me gustó denyhosts porque creó una lista de usuarios problemáticos / rangos de ip y luego en hosts.deny, esa lista se observó. Instalamos fail2ban en su lugar y está bien. Tengo entendido que preferiría bloquear a estos usuarios malos en el borde exterior del servidor, por lo que los bloqueadores basados ​​en tablas de IP, como fail2ban, son realmente mejores. Denyhosts funciona en el nivel secundario, después de que los enemigos hayan superado las iptables, el demonio sshd los rechaza.

En ambos programas, es un poco tedioso sacar a los usuarios de la cárcel si olvidan su contraseña e intentan iniciar sesión varias veces. Es un poco difícil que las personas vuelvan a entrar cuando cometen errores de inicio de sesión. Habría adivinado que habría una GUI de apuntar y hacer clic donde podría señalar y dejar que la gente vuelva a entrar, pero no es así. Solo tengo que hacer esto cada pocos meses y olvidar cómo cada vez, así que escribí instrucciones para mí en mi página web http://pj.freefaculty.org/blog/?p=301