Installation und Verwendung von Fail2ban unter Debian 12
Fail2ban überwacht die Logdateien auf fehlgeschlagene Anmeldungen und sperrt die fehleranfällige Quell-IP-Adresse vorübergehend für den Zugriff auf den Host. Dies ist ein Schutz gegen Brute-Force-Angriffe, bei denen Passwörter erraten werden. Es ist sehr nützlich, fail2ban auf Hosts einzusetzen, die dem Internet ausgesetzt sind.
Die Version von fail2ban auf Debian 12 ist 1.0.2.
root@posti:~# fail2ban-client version 1.0.2
Um zu sehen, ob fail2ban gerade läuft, schickst du den Befehl ping mit fail2ban-client an den Server. Der Fail2ban-Server antwortet mit „pong“, wenn er läuft.
root@posti:/etc/fail2ban# fail2ban-client ping Server replied: pong root@posti:/etc/fail2ban#
Wie es funktioniert
Fail2ban sammelt Filter-, Aktions- und Überwachungsdateien in einem Jail. Mit der Distribution werden mehrere Jails mitgeliefert. Sie müssen aktiviert werden, damit sie funktionieren. filter legt fest, wie Authentifizierungsfehler erkannt werden sollen. action definiert, wie die Sperrung und Aufhebung der Sperrung erfolgt.
Einbruchsversuche lösen einen Bann aus, wenn während der Findungszeit mindestens maxretry Login-Fehler von derselben IP-Nummer erkannt werden. Dann wird die IP für bantime Sekunden gebannt. Nachdem die Sperre für bantime Sekunden in Kraft war, wird die Sperre aufgehoben und die IP kann wieder auf den Host zugreifen. Fail2ban kann sowohl IPv4 als auch IPv6 verarbeiten.
Weitere Informationen kannst du in den Dateien im Verzeichnis /usr/share/doc/fail2ban/ nachlesen.
Fail2ban einrichten
Auf Debian GNU/Linux-Systemen wird fail2ban standardmäßig mit aktiviertem sshd-Gefängnis und vernünftigen Einstellungen installiert. Dies geschieht in der Datei /etc/fail2ban/jail.d/defaults-debian.conf. Das ist die einzige Jail, die standardmäßig funktioniert. Andere Jails müssen vom Systemadministrator aktiviert werden.
Wenn du also nur möchtest, dass ssh-Logins überwacht und missbräuchliche Eindringlinge gebannt werden, ist keine zusätzliche Konfiguration erforderlich.
Leider funktioniert fail2ban unter Debian 12 möglicherweise nicht mit den Standardeinstellungen. Debian 12 hat das rsyslog-Paket als optional gekennzeichnet, was bedeutet, dass es möglicherweise nicht installiert ist und die Logs nur in journald [wiki.debian.org/Rsyslog] gesammelt werden.
Auf ISPConfig-Systemen funktioniert fail2ban, da der ISPConfig-Autoinstaller rsyslog installiert und das ISPConfig Perfect Server-Tutorial anweist, rsyslog zu installieren.
Mit rsyslog werden die Logdateien im Verzeichnis /var/log/ abgelegt, so dass die fail2ban Standardkonfiguration die Logdateien findet. Wenn rsyslog nicht installiert ist, muss die fail2ban-Konfiguration so geändert werden, dass sie die Logs aus dem systemd-Journal liest. Füge dem Abschnitt jail.local default backend = systemd hinzu, etwa so
[DEFAULT] backend = systemd
Aktivieren einer Jail
Die Dokumentation empfiehlt, alle eigenen Änderungen in den .local-Dateien vorzunehmen. Dadurch werden Probleme vermieden, wenn die von der Distribution bereitgestellten Dateien vom Betreuer aktualisiert oder geändert werden [Lies die Datei /usr/share/doc/fail2ban/README.Debian.gz].
Um beispielsweise die Jail von pure-ftpd zu aktivieren, fügen Sie der Datei /etc/fail2ban/jail.local (erstellen Sie die Datei, wenn sie noch nicht existiert) die folgenden Zeilen hinzu
[pure-ftpd] enabled = true
Der Jail-Name in eckigen Klammern beginnt den Abschnitt für die Einstellungen dieser Jail.
Wenn du mit den Änderungen fertig bist, erzwinge das erneute Einlesen der Konfigurationsdateien mit dem Befehl
systemctl reload fail2ban
Die Jail sollte jetzt laufen, was du mit fail2ban-client überprüfen kannst:
root@posti:/etc/fail2ban# fail2ban-client status pure-ftpd Status for the jail: pure-ftpd |- Filter | |- Currently failed: 0 | |- Total failed: 106 | `- File list: /var/log/syslog `- Actions |- Currently banned: 0 |- Total banned: 4 `- Banned IP list: root@posti:/etc/fail2ban#
Da jail.local nur die Einstellung „enabled“ für diese Jail enthält, sind alle anderen Einstellungen Standardeinstellungen aus der Distribution. Normalerweise haben sie gute Werte, sodass eine weitere Konfiguration unnötig ist. Bei Bedarf kann der Abschnitt jail.local für diese Jail Einstellungen enthalten, die die Einstellungen in den .conf-Dateien außer Kraft setzen.
In diesem Beispiel werden findtime, maxretry und bantime für die pure-ftpd-Jail geändert:
[pure-ftpd] enabled = true findtime = 2h maxretry = 6 bantime = 1d
Fail2ban-client zeigt die Zeiten in Sekunden an, aber die Zeiten können in den Konfigurationsdateien in einem einfacheren Format eingegeben werden, z.B. 10h statt 36000 Sekunden. man jail.conf im Kapitel „TIME ABBREVIATION FORMAT“ erklärt die benutzerfreundlichen Formate für die Zeiteingabe.
fail2ban-client hat die Option, das benutzerfreundliche Zeitformat in Sekunden umzuwandeln.
# fail2ban-client --str2sec 1d3h7m 97620
Verfolge die Logs
Um festzustellen, welche Jails aktiviert werden sollten, verfolge die Logs, die von den Diensten auf dem Host erstellt werden. Ein Tool, das Zusammenfassungen der Logs erstellt, wie logwatch oder pflogsumm, ist hilfreich. Das Lesen von Roh-Logs ist zeitaufwändig und mühsam.
Überprüfe, ob für einen Dienst, der auf dem Host läuft, eine Jail verfügbar ist, indem du vielleicht die jail.conf liest.
Sobald die Logs etwas Interessantes oder Besorgniserregendes zeigen, ist es an der Zeit, sie zu untersuchen. Zum Beispiel schickte pflogsumm eine E-Mail-Zusammenfassung mit Zeilen wie dieser:
136 unknown[91.224.92.40]: SASL LOGIN authentication failed: UGFzc3... 136 hostname srv-91-224-92-40.serveroffer.net does not resolve to a... 123 unknown[193.32.162.23]: SASL LOGIN authentication failed: UGFzc... 123 hostname mail.whatami.co does not resolve to address 193.32.162.23
Das zeigt, dass die IP 91.224.92.40 136 Mal beim Loggen in die E-Mail fehlgeschlagen ist, und einen weiteren ähnlichen Fall. Fail2ban hätte so viele Versuche verhindern müssen. Um zu sehen, warum das nicht passiert ist, schau dir das Fail2ban-Protokoll an.
root@posti:/etc/apt/apt.conf.d# grep 91.224.92.40 /var/log/fail2ban.log | head 2024-02-18 00:01:38,718 fail2ban.filter [996]: INFO [postfix-sasl] Found 91.224.92.40 - 2024-02-18 00:01:38 2024-02-18 00:11:50,261 fail2ban.filter [996]: INFO [postfix-sasl] Found 91.224.92.40 - 2024-02-18 00:11:50 2024-02-18 00:21:54,337 fail2ban.filter [996]: INFO [postfix-sasl] Found 91.224.92.40 - 2024-02-18 00:21:54 2024-02-18 00:32:14,232 fail2ban.filter [996]: INFO [postfix-sasl] Found 91.224.92.40 - 2024-02-18 00:32:14 2024-02-18 00:42:37,921 fail2ban.filter [996]: INFO [postfix-sasl] Found 91.224.92.40 - 2024-02-18 00:42:37 2024-02-18 00:53:06,796 fail2ban.filter [996]: INFO [postfix-sasl] Found 91.224.92.40 - 2024-02-18 00:53:06 2024-02-18 01:03:35,293 fail2ban.filter [996]: INFO [postfix-sasl] Found 91.224.92.40 - 2024-02-18 01:03:35 2024-02-18 01:14:03,765 fail2ban.filter [996]: INFO [postfix-sasl] Found 91.224.92.40 - 2024-02-18 01:14:03 2024-02-18 01:24:24,628 fail2ban.filter [996]: INFO [postfix-sasl] Found 91.224.92.40 - 2024-02-18 01:24:24 2024-02-18 01:34:43,876 fail2ban.filter [996]: INFO [postfix-sasl] Found 91.224.92.40 - 2024-02-18 01:34:43 root@posti:/etc/apt/apt.conf.d#
Diese IP versucht in Abständen von etwa 10 Minuten, sich zu verbinden, und das fail2ban-Gefängnis postfix-sasl erkennt sie.
Es ist eine gute Idee, herauszufinden, ob diese IP vielleicht zu einem legitimen Benutzer des Hosts gehört, der nur ein altes Passwort auf seinem Smartphone oder einem anderen Gerät hat, das in regelmäßigen Abständen versucht, sich zu verbinden. Ich verwende geoiplookup, das zeigt, aus welchem Land die IP stammt. Meine Nutzer kommen aus meinem Land, also sind ausländische Nutzer eher schlechte Akteure. geoiplookup kommt aus den Debian-Paketen geoip-database und geoip-bin.
$ geoiplookup 91.224.92.40 GeoIP Country Edition: LT, Lithuania
Um herauszufinden, warum die IP nicht gebannt wurde, untersuchst du die Findtime des Gefängnisses:
root@posti:/etc/apt/apt.conf.d# fail2ban-client get postfix-sasl findtime 600 root@posti:/etc/apt/apt.conf.d#
Ich habe kürzlich diese langsamen Angriffe gesehen, bei denen der Täter weiß, dass die Findtime 10 Minuten beträgt, und versucht, einen Bann zu vermeiden, indem er sich in größeren Abständen anmeldet. Das hat in diesem Fall funktioniert. Um zu erreichen, dass fehlgeschlagene Logins zu Banns führen, erhöhe die Findtime für die Jail, zum Beispiel auf 10 Stunden. Füge dies in der Datei jail.local im Abschnitt [postfix-sasl] hinzu:
findtime = 10h
Dann hat die Jail nach systemctl reload fail2ban eine längere Findtime:
root@posti:/etc/fail2ban# fail2ban-client get postfix-sasl findtime 36000 root@posti:/etc/fail2ban#
Eine weitere Möglichkeit, wie Eindringlinge versuchen, einzubrechen, ist, hartnäckig zu sein. Selbst wenn der Eindringling gebannt ist, wartet er einfach, bis die Sperre endet und rät weiter das Passwort. Die Bannzeit könnte verlängert werden, aber das führt zu Problemen für legitime Nutzer, die sich bei der Passworteingabe vertippen und dann nicht mehr auf ihr Konto zugreifen können, bis die Bannzeit endet. Für Wiederholungstäter gibt es ein Gefängnis namens recidive. Es funktioniert, indem es im fail2ban-Log nach wiederholten Bans für eine IP sucht und diese dann für eine lange Zeit sperrt, zum Beispiel eine Woche.
Die folgende Liste stammt aus dem Logwatch-Bericht:
--------------------- pam_unix Begin ------------------------
sshd:
Authentication Failures:
unknown (212.70.149.150): 59 Time(s)
Die Suche nach dieser IP in der Logdatei zeigt:
2024-02-21 03:42:39,121 fail2ban.filter [895]: INFO [sshd] Found 212.70.149.150 - 2024-02-21 03:42:38 2024-02-21 03:42:39,508 fail2ban.actions [895]: NOTICE [sshd] Ban 212.70.149.150 2024-02-21 03:52:38,386 fail2ban.actions [895]: NOTICE [sshd] Unban 212.70.149.150 2024-02-21 03:54:33,560 fail2ban.filter [895]: INFO [sshd] Found 212.70.149.150 - 2024-02-21 03:54:33 2024-02-21 03:54:35,364 fail2ban.filter [895]: INFO [sshd] Found 212.70.149.150 - 2024-02-21 03:54:35 2024-02-21 04:00:37,017 fail2ban.filter [895]: INFO [sshd] Found 212.70.149.150 - 2024-02-21 04:00:36 2024-02-21 04:00:39,021 fail2ban.filter [895]: INFO [sshd] Found 212.70.149.150 - 2024-02-21 04:00:38 2024-02-21 04:06:43,036 fail2ban.filter [895]: INFO [sshd] Found 212.70.149.150 - 2024-02-21 04:06:42 2024-02-21 04:06:45,039 fail2ban.filter [895]: INFO [sshd] Found 212.70.149.150 - 2024-02-21 04:06:44 2024-02-21 04:06:45,426 fail2ban.actions [895]: NOTICE [sshd] Ban 212.70.149.150 2024-02-21 04:16:44,302 fail2ban.actions [895]: NOTICE [sshd] Unban 212.70.149.150 2024-02-21 04:19:04,868 fail2ban.filter [895]: INFO [sshd] Found 212.70.149.150 - 2024-02-21 04:19:04
Fail2ban funktioniert wie vorgesehen, findet die falschen Logins und spricht eine Sperre für 10 Minuten aus. Während dieser Sperre wird der Täter daran gehindert, auf diesen Host zuzugreifen, kann aber nach Aufhebung der Sperre weiterarbeiten. Dies scheint der Fall eines ernsthaften Einbruchsversuchs zu sein. Die Abhilfe besteht darin, eine wiederkehrende Sperre mit niedriger Maximalzahl und langer Bantime zu aktivieren.
Ich verwende gerne eine kurze Anfangssperre, zum Beispiel 10 Minuten. Wenn ein echter Nutzer gebannt wurde, wartet er einfach diese Zeit ab, nutzt die Zeit hoffentlich, um das richtige Passwort zu finden und versucht es dann erneut. Diejenigen, die am gleichen Tag erneut gesperrt werden, werden für eine Woche gesperrt. Die Standardwerte von recidive jail findest du in der Datei jail.conf, dort ist bantime auf 1 Woche und findtime auf 1 Tag eingestellt. Aber ich habe maxretry auf 2 gesetzt, dann werden Straftäter schneller gebannt. Ich habe der Datei jail.local hinzugefügt:
[recidive] enabled = true maxretry = 2
Länger als 1 Woche sind Bans meiner Meinung nach nicht sinnvoll. Schließlich wird die alte IP-Adresse überall gebannt oder auf die schwarze Liste gesetzt, so dass der Täter eine neue IP bekommt. Die alte IP wird an einen unschuldigen neuen Internetnutzer weitergegeben, der nicht für die schlimmen Dinge bestraft werden sollte, derer sich der vorherige Besitzer dieser IP schuldig gemacht hat.
Fehlersuche
Nach dem Booten des Betriebssystems oder dem Neustart von fail2ban wird der Status wiederhergestellt, so dass die Bans weiterlaufen, bis die Bantime abgelaufen ist. Daher können Tests und Fehlersuche Neustarts beinhalten.
Um die Konfiguration zu testen, gibt es eine Testoption:
fail2ban-server --test
Um herauszufinden, ob eine IP gesperrt ist, können neuere Versionen von fail2ban Folgendes tun
# fail2ban-client banned 43.131.9.186 [['recidive']]
Der Befehl zeigt eine Liste der Jails an, in denen eine bestimmte IP derzeit gesperrt ist.
Ältere Versionen von fail2ban verfügen nicht über diesen Befehl. So kannst du jedes Jail einzeln testen:
# fail2ban-client status recidive | tr " " "\n" | grep 43.163.219.232 43.163.219.232
Wenn die Ausgabe die IP anzeigt, dann war sie in der Liste der gesperrten IP-Nummern. Der tr-Befehl dient dazu, die Liste der gesperrten IP-Nummern (es ist eine lange Zeile) in eine IP pro Zeile zu zerlegen.
Um zu sehen, was mit einer bestimmten IP passiert ist, kannst du sie in fail2ban.log nachschlagen:
root@posti:/etc/mysql# grep 43.131.9.186 /var/log/fail2ban.log | cut --characters=-80 2024-03-06 09:00:40,295 fail2ban.filter [3574846]: INFO [sshd] Found 2024-03-06 09:02:53,954 fail2ban.filter [3574846]: INFO [sshd] Found 2024-03-06 09:02:55,958 fail2ban.filter [3574846]: INFO [sshd] Found 2024-03-06 09:04:34,193 fail2ban.filter [3574846]: INFO [sshd] Found 2024-03-06 09:04:36,195 fail2ban.filter [3574846]: INFO [sshd] Found 2024-03-06 09:04:36,388 fail2ban.actions [3574846]: NOTICE [sshd] Ban 43 2024-03-06 09:04:36,626 fail2ban.filter [3574846]: INFO [recidive] Fo 2024-03-06 09:14:35,180 fail2ban.actions [3574846]: NOTICE [sshd] Unban 2024-03-06 09:15:10,073 fail2ban.filter [3574846]: INFO [sshd] Found 2024-03-06 09:16:55,919 fail2ban.filter [3574846]: INFO [sshd] Found 2024-03-06 09:16:58,522 fail2ban.filter [3574846]: INFO [sshd] Found 2024-03-06 09:18:44,972 fail2ban.filter [3574846]: INFO [sshd] Found 2024-03-06 09:20:30,018 fail2ban.filter [3574846]: INFO [sshd] Found 2024-03-06 09:20:30,499 fail2ban.actions [3574846]: NOTICE [sshd] Ban 43 2024-03-06 09:20:30,620 fail2ban.filter [3574846]: INFO [recidive] Fo 2024-03-06 09:20:30,899 fail2ban.actions [3574846]: NOTICE [recidive] Ba 2024-03-06 09:20:32,021 fail2ban.filter [3574846]: INFO [sshd] Found 2024-03-06 09:30:29,289 fail2ban.actions [3574846]: NOTICE [sshd] Unban
Das ausführliche Dumping der fail2ban-Konfiguration zeigt die Einstellungen zur Überprüfung an:
# fail2ban-client -vvv -d
Whitelisting eigener IP-Adressen
Vielleicht werden deine eigenen Hosts gebannt oder du möchtest sicherstellen, dass einige fremde Hosts nie gebannt werden, auch wenn sie sich schlecht verhalten. Diese IP-Adressen können auf eine Whitelist gesetzt werden. Standardmäßig ist nichts auf der Whitelist, du kannst das mit überprüfen:
root@posti:~# fail2ban-client get sshd ignoreip No IP address/network is ignored root@posti:~
Die ignoreip-Einstellung könnte in jedem Jail-Abschnitt gesetzt werden, aber diese Einstellung sollte alle Jails betreffen, deshalb ist es besser, sie im DEFAULT-Abschnitt zu setzen. Am besten ist es, ignore auf das interne Subnetz zu setzen, damit alle eigenen Hosts nicht gesperrt werden. Dies steht am Anfang der jail.local:
[DEFAULT] ignoreip = 92.237.123.96/27
Der Abschnitt Default kann andere Einstellungen enthalten, die alle Jails betreffen. Zum Beispiel könnte dort findtime = 10h hinzugefügt werden.
Manuelles Banning
Um zu testen, was beim Bannen passiert, setze den Ban manuell. Teste zuerst mit einem Jail mit kurzer Banzeit, damit du irgendwann zurückkommst, wenn du dich versehentlich selbst gebannt hast. Zum Beispiel
# fail2ban-client set sshd banip 8.8.4.4</>
Wenn sich eine IP schlecht verhält, aber du kannst fail2ban nicht dazu bringen, sie zu erkennen und Banns auszusprechen, kannst du diese IP mit einem manuellen Bann in einem reaktiven Jail für eine Woche loswerden.
# fail2ban-client set recidive banip 8.8.4.4
Das Bannen eines Subnetzes funktioniert mit der CIDR-Notation:
fail2ban-client set recidive banip 5.188.87.0/24
Manuelles Bannen aufheben
Eine Sperre aufheben ist möglich, aber bedenke, dass die IP wieder gesperrt wird, wenn das schlechte Verhalten anhält. Du solltest also herausfinden, was passiert (z.B. durch Lesen der Logs) und das schlechte Verhalten beheben.
# fail2ban-client set recidive unbanip 8.8.4.4
Die IP kann in mehreren Jails gebannt sein. Um eine IP in allen Jails zu entsperren, benutze
# fail2ban-client unban 8.8.4.4
Ich muss das allerdings nur selten tun. Ich habe 10 Minuten Bannzeit, nur das recidive jail hat 1 Woche, also hebe ich die IP nur im recidive jail auf, die anderen Jails sind bereits abgelaufen. Wenn du kein recidive jail verwendest, kann es sein, dass IPs in mehreren Jails gleichzeitig gebannt sind.
Um alle IP-Adressen aus allen Jails freizugeben, mache
fail2ban-client unban --all
Fazit
Fail2ban macht das Erraten von Passwörtern schwieriger, verhindert aber nicht vollständig, dass Cracker versuchen, auf den Host zuzugreifen. Bei SSH bietet die Verwendung von SSH-Schlüsseln mehr Schutz, da die Anmeldung mit einem Passwort verhindert wird. Bei anderen Diensten verhindert die Multi-Faktor-Authentifizierung die Anmeldung, wenn nur das Passwort bekannt ist.
