3 votes

Est-il sûr d'appliquer fail2ban aux journaux sshd "Received disconnect/Disconnected ... [preauth]" ?

Je vois beaucoup de journaux comme celui-ci dans /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]

Je sais que ce sont des tentatives d'intrusion, car personne ne devrait essayer de se connecter à cette machine (à part moi).

Il n'y a pas de règle correspondante dans /etc/fail2ban/filter.d/sshd.conf, donc ces tentatives n'entraînent pas un bannissement de l'adresse IP malveillante par fail2ban.

J'ai désactivé la connexion par mot de passe, donc je suppose que ce qui se passe ici, c'est que ces tentatives sont rejetées avant même de tenter de s'authentifier, et pour cette raison fail2ban ne les détecte pas.

Cependant, comme je sais qu'il s'agit de tentatives d'intrusion, je voudrais quand même interdire l'IP, pour les empêcher de tenter d'autres choses et de remplir mes journaux.

Est-il sûr pour moi d'ajouter une expression régulière correspondant à certaines de ces lignes, ou risquerais-je de correspondre à des tentatives de connexion légitimes (basées sur une clé) ? Quelles parties constitueraient une combinaison sûre ? Correspondre aux mots "Disconnected" et à la balise "[preauth]" indiquerait-elle nécessairement une tentative de force brute malveillante basée sur un mot de passe échouée ?

0 votes

Les filtres fournis avec fail2ban incluent déjà ceux-ci. Pourquoi ne les utilisez-vous pas?

2voto

AndroidX Points 166

Il n'y a pas de règle correspondante dans /etc/fail2ban/filter.d/sshd.conf, donc ces tentatives ne causent pas de bannissement de l'adresse IP en faute par fail2ban.

Quelle version utilisez-vous ? Fail2Ban est livré avec une règle prédéfinie à ce sujet, incluse dans le common failregex utilisé par tous les modes.

Fail2Ban v0.10.2 sur l'un de mes systèmes inclut cette règle:

^Received disconnect from : 11:

Et Fail2Ban v0.11.2 inclut celle-ci (qui est meilleure):

^Received disconnect from %(__on_port_opt)s:\s*11:

Apparemment, les développeurs ont pensé que l'une des lignes suivantes

Received disconnect from : 11:
Received disconnect from  port XXXXX:11:

sera suffisante. Les mots-clés pertinents sont Received disconnect from et la partie : 11: (au lieu du suffixe [preauth]).

Le signifie que cette ligne n'est pas un échec et s'attendra à un autre match sans pour bannir l'IP, donc vous devrez supprimer les balises environnantes.

1 votes

Merci c'était utile :) Je suis en train d'exécuter la version 0.10.2, qui inclut la première variante. Cette variante ne correspond pas réellement à mes journaux, qui incluent le numéro de port. La version 0.11.2 correspondrait, bien que je pense que j'ajouterai des règles personnalisées manuellement plutôt que d'utiliser une version qui n'est pas celle emballée. De plus, comme vous l'avez souligné, la balise signifie que celles-ci ne se déclencheront pas car je n'ai pas d'autres règles correspondantes.

0voto

JayTee Points 1

J'ai activé cette fonctionnalité en définissant le mode = agressif sous [sshd] dans mon fichier jail.local

0voto

sebix Points 4115

Est-ce sûr pour moi d'ajouter une Regexp correspondant à certaines de ces lignes, ou risquerais-je de correspondre à des tentatives de connexion légitimes (basées sur la clé) ? Quels éléments formeraient une combinaison sûre ? Correspondre aux mots "Disconnected" et à la balise "[preauth]" indiquerait-il nécessairement une tentative de force brute basée sur un mot de passe échouée ?

Une connexion et une authentification réussies légitimes ne déclenchent pas de telles lignes de journal. Ces entrées peuvent provenir de scanners, qui ne causent pas de dommages, mais peuvent également être bloquées. preauth signifie que ces clients n'ont pas encore commencé l'authentification.

Même si vous-même provoquez un échec de connexion, que ce soit en utilisant de mauvaises clés ou en tapant mal le mot de passe, l'utilisation de fail2ban est toujours OK. fail2ban ne bloque qu'après un nombre configurable de lignes de journal correspondantes et seulement pour une certaine période de temps.

Vous pouvez utiliser ce snippet (par exemple comme cmdfailre) dans Debian buster :

^Received disconnect from %(__on_port_opt)s:11: \s* %(__suff)s$
^Disconnected from authenticating user .*? %(__on_port_opt)s %(__suff)s$

0 votes

Merci c'est utile de savoir. J'ai marqué l'autre réponse comme acceptée, mais cette réponse est aussi utile, malheureusement je ne peux pas marquer les deux :(

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X