Si hemos configurado nuestro sevidor SSH y echamos un ojo a los mensajes de seguridad: tail -n100 /var/log/messages o bien grep sshd /var/log/messages Veremos que hay muchos ataque por fuerza bruta a nuestro servidor. Podemos tomar varias medidas para solucionar el problema: 1) Cambiar nuestra configuración del servidor SSHD a través del fichero /etc/ssh/sshd_config . Algunos parámetros podrían ser: a) PermitRootLogin no <-- evitamos el acceso usando el usuario root, esto es casi obligatorio en cualquier sistema
Comentarios
Suponiendo que eth0 tiene el acceso a internet:
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP
#3 , #4 Eso tiene un problema: Cuando se trata de un ataque desde una granja de zombies, con IPs distintas.
Hace unos meses, en una máquina que solo tiene backups, recibí un ataque de estos.
Esa máquina no estaba protegida apenas (estaba recién instalada, sin tiempo para afinar.
Un día me dio por mirar los logs y vi que estaba recibiendo infinidad de intentos de acceso por fuerza bruta desde una IP. La bloqueé a mano. a los pocos segundos comenzó el ataque (continuando desde donde había quedado la máquina atacante anterior). La bloqueé también. Así hasta 8.
Entonces instalé el script sshblack.
Al día siguiente vi los logs y habían aumentado los ataques, esta vez simultaneo, desde más de 600 IPs distintas.
Resumiendo:
- 1º atacaba una sola e intentaba entrar constantemente por fuerza bruta.
- 2ª atacaba una tras otras e intentaban entrar constantemente por fuerza bruta continuando el ataque de la anterior
- 3º atacaban varias simultaneamente intentando entrar constantemente por fuerza bruta, continuando el ataque de las anteriores. Como estas IPs iban quedando bloqueadas en iptables (y eran cientos)
- 4º atacaban varias simultaneamente alternando ips y dejando pasar un intervalo entre cada intento desde cada ip atacante. Obviamente, si tienen tiempo y muchas máquinas (mas de 600, como decía), es mucho más difícil de controlar, porque la mayoría de scripts lo que hacen es banear si el número de intentos igual a X en un intervalo de tiempo Y desde una misma IP Z. A ver como se controla esto con tanta máquina, tanto tiempo y bien organizadas.
Al final opté por bloquear todo el tráfico excepto desde aquellas máquinas que tenían que hacer los backups, desde la red local y desde un par de ips concretas.
Otra forma que hubiese sido bastante útil es el configurar SSH para que no valide mediante usuario y clave, sino solo mediante llave RSA.
También se puede usar un script muy majo, llamado sshblack
Te permite configurar cuantas veces puede fallar el login desde una IP antes de bloquearla por iptables. Después de un tiempo que prefijemos, (3 días, por ejemplo) la elimina de iptables
http://www.pettingers.org/code/sshblack.html
Bah, con meter un retardo para presentar el login de 5 a 10 segundos se puede morir para meter solo 2000 combinaciones, conque la contraseña tenga tan solo 8 dígitos tiene para siglos y siglos de ataque hasta que lo abra como no sea pepe el suerte tecleando cosas al azar...
fail2ban - bans IPs that cause multiple authentication errors