Ist es sicher, fail2ban auf SSHD-Protokolle vom Typ „Received disconnect/Disconnected ... [preauth]“ anzuwenden?

Question

Ich sehe viele Protokolle wie diese in /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]

Ich weiß, dass es sich hierbei um Einbruchsversuche handelt, da niemand (außer mir) versuchen sollte, sich auf diesem Computer anzumelden.

Es gibt keine entsprechende Regel in /etc/fail2ban/filter.d/sshd.conf, daher führen diese Versuche nicht dazu, dass fail2ban die betreffende IP-Adresse sperrt.

Ich habe die Anmeldung per Passwort deaktiviert. Ich nehme daher an, dass diese Versuche abgebrochen werden, bevor überhaupt eine Authentifizierung durchgeführt wird. Aus diesem Grund erkennt fail2ban sie nicht.

Da ich jedoch weiß, dass es sich um Einbruchsversuche handelt, möchte ich die IP trotzdem sperren, um zu verhindern, dass sie andere Dinge versuchen und meine Protokolle füllen.

Ist es für mich sicher, einen regulären Ausdruck hinzuzufügen, der einigen dieser Zeilen entspricht, oder würde ich riskieren, dass legitime (schlüsselbasierte) Anmeldeversuche übereinstimmen? Welche Teile würden eine sichere Kombination ergeben? Würde eine Übereinstimmung mit den Wörtern „Disconnected“ und dem Tag „[preauth]“ zwangsläufig auf einen fehlgeschlagenen passwortbasierten Brute-Force-Angriff hinweisen?

Answer 1

In /etc/fail2ban/filter.d/sshd.conf gibt es keine entsprechende Regel, daher führen diese Versuche nicht dazu, dass fail2ban die betreffende IP-Adresse sperrt.

Welche Version verwenden Sie? Fail2Ban verfügt über eine vordefinierte Regel dazu, die im gemeinsamen Failregex enthalten ist, der von allen Modi verwendet wird.

Fail2Ban v0.10.2 enthält in einem meiner Systeme diese Regel:

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

Und Fail2Ban v0.11.2 enthält Folgendes (was besser ist):

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

Offenbar dachten die Entwickler, dass eine der folgenden Zeilen

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

reicht aus. Die relevanten Schlüsselwörter sind Received disconnect fromund der : 11:Teil (anstelle des [preauth]Suffixes).

Das <F-NOFAIL>bedeutet, dass diese Zeile kein Fehler ist und eine weitere Übereinstimmung erwartet, ohne <F-NOFAIL>die IP zu sperren. Daher müssen Sie die umgebenden Tags entfernen.

Answer 2

Ist es für mich sicher, einen regulären Ausdruck hinzuzufügen, der einigen dieser Zeilen entspricht, oder würde ich riskieren, dass legitime (schlüsselbasierte) Anmeldeversuche übereinstimmen? Welche Teile würden eine sichere Kombination ergeben? Würde eine Übereinstimmung mit den Wörtern „Disconnected“ und dem Tag „[preauth]“ zwangsläufig auf einen fehlgeschlagenen passwortbasierten Brute-Force-Angriff hinweisen?

Eine legitime erfolgreiche Verbindung und Authentifizierung löst keine solchen Protokollzeilen aus. Diese Einträge können von Scannern stammen, die keinen Schaden anrichten, aber ebenfalls blockiert werden können. preauth bedeutet, dass diese Clients noch nicht mit der Authentifizierung begonnen haben.

Auch wenn Sie selbst für einen fehlgeschlagenen Login verantwortlich sind, sei es durch die Verwendung falscher Tasten oder die Eingabe eines Passworts, ist die Verwendung von fail2ban in Ordnung. fail2ban blockiert erst nach einer konfigurierbaren Anzahl übereinstimmender Protokollzeilen und nur für einen bestimmten Zeitraum.

Sie können dieses Snippet (z. B. als cmdfailre) in Debian Buster verwenden:

^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$

Answer 3

Ich habe diese Funktionalität aktiviert, indem ich in meiner jail.local-Datei unter [sshd] den Modus „aggressiv“ eingestellt habe.