☰

¿Es seguro aplicar fail2ban en los registros sshd "Desconexión recibida/Desconectado... [preautorización]"?

tag-icon • tag-icon ssh fail2ban debian-buster
¿Es seguro aplicar fail2ban en los registros sshd "Desconexión recibida/Desconectado... [preautorización]"?

Veo muchos registros como estos en /var/log/auth.log(Debian Buster):

Jan  2 17:10:17 mybox sshd[16304]: Received disconnect from 1.2.3.4 port 37792:11: Bye Bye [preauth]
Jan  2 17:10:17 mybox sshd[16304]: Disconnected from authenticating user root 1.2.3.4 port 37792 [preauth]
Jan  2 17:10:20 mybox sshd[16306]: Received disconnect from 5.6.7.8 port 63061:11: Bye Bye [preauth]
Jan  2 17:10:20 mybox sshd[16306]: Disconnected from authenticating user root 5.6.7.8 port 63061 [preauth]
Jan  2 17:12:38 mybox sshd[16380]: Received disconnect from 9.10.11.12 port 55224:11: Normal Shutdown, Thank you for playing [preauth]
Jan  2 17:12:38 mybox sshd[16380]: Disconnected from authenticating user root 9.10.11.12 port 55224 [preauth]

Sé que estos son intentos de ingresar, porque nadie debería intentar iniciar sesión en esa máquina (aparte de mí).

No existe una regla correspondiente en /etc/fail2ban/filter.d/sshd.conf, por lo que estos intentos no provocan que fail2ban prohíba la dirección IP infractora.

He desactivado el inicio de sesión con contraseña, así que supongo que lo que sucede aquí es que estos intentos se descartan incluso antes de intentar autenticarse y, por esa razón, fail2ban no los detecta.

Sin embargo, como sé que se trata de intentos de interrupción, todavía me gustaría prohibir la IP para evitar que intenten otras cosas y llenen mis registros.

¿Es seguro para mí agregar una expresión regular que coincida con algunas de esas líneas, o me arriesgaría a coincidir con intentos de inicio de sesión legítimos (basados ​​en claves)? ¿Qué partes harían una combinación segura? ¿La coincidencia de las palabras "Desconectado" y la etiqueta "[preauth]" indicaría necesariamente una fuerza bruta basada en contraseña fallida?

Respuesta1

No existe una regla correspondiente en /etc/fail2ban/filter.d/sshd.conf, por lo que estos intentos no provocan que fail2ban prohíba la dirección IP infractora.

Qué versión estás usando? Fail2Ban viene con una regla predefinida al respecto, incluida en el failregex común utilizado por todos los modos.

Fail2Ban v0.10.2 en uno de mis sistemas incluye esta regla:

^<F-NOFAIL>Received <F-MLFFORGET>disconnect</F-MLFFORGET></F-NOFAIL> from <HOST>: 11:

Y Fail2Ban v0.11.2 incluye este (que es mejor):

^<F-NOFAIL>Received <F-MLFFORGET>disconnect</F-MLFFORGET></F-NOFAIL> from <HOST>%(__on_port_opt)s:\s*11:

Aparentemente los desarrolladores pensaron que cualquiera de las siguientes líneas

Received disconnect from <HOST>: 11:
Received disconnect from <HOST> port XXXXX:11:

Será suficiente. Las palabras clave relevantes son Received disconnect fromy la : 11:parte (en lugar del [preauth]sufijo).

Esto <F-NOFAIL>significa que esta línea no es un error y esperará otra coincidencia sin <F-NOFAIL>prohibir la IP, por lo que tendrás que eliminar las etiquetas circundantes.

Respuesta2

¿Es seguro para mí agregar una expresión regular que coincida con algunas de esas líneas, o me arriesgaría a coincidir con intentos de inicio de sesión legítimos (basados ​​en claves)? ¿Qué partes harían una combinación segura? ¿La coincidencia de las palabras "Desconectado" y la etiqueta "[preauth]" indicaría necesariamente una fuerza bruta basada en contraseña fallida?

Una conexión y autenticación legítimas y exitosas no activan dichas líneas de registro. Estas entradas pueden provenir de escáneres, que no causan daño, pero también pueden bloquearse. preauth significa que esos clientes aún no iniciaron la autenticación.

Incluso si usted mismo provoca un inicio de sesión fallido, ya sea usando claves incorrectas o escribiendo mal la contraseña, usar fail2ban aún está bien. fail2ban solo se bloquea después de un número configurable de líneas de registro coincidentes y solo durante un período de tiempo determinado.

Puede utilizar este fragmento (por ejemplo, como cmdfailre) en Debian Buster:

^Received disconnect from <HOST>%(__on_port_opt)s:11: \s* %(__suff)s$
^Disconnected from authenticating user <F-USER>.*?</F-USER> <HOST>%(__on_port_opt)s %(__suff)s$

Respuesta3

Habilité esta funcionalidad configurando mode = agresivo en [sshd] en mi archivo jail.local

información relacionada