Fail2ban installieren und verwenden: SSH, Logs und sinnvolle Sperren
Fail2ban installieren und verwenden gehört für inzwischen zu den Dingen, die auf einem Linux-Server schnell erledigt sind und im Alltag trotzdem richtig helfen. Das Tool liest Logdateien, erkennt zu viele fehlgeschlagene Logins und sperrt die betroffene IP anschließend über die Firewall. Kein Hexenwerk, aber genau solche kleinen Schutzschichten machen einen Server angenehmer.
Gerade bei SSH sieht man sehr schnell, warum das sinnvoll ist. Ein öffentlich erreichbarer Server bekommt früher oder später Loginversuche ab. Meistens eher früher. Fail2ban stoppt diese Versuche nicht für immer, aber es reduziert das Rauschen deutlich und hält besonders stumpfe Brute-Force-Versuche vom Hals.
🧠 Was Fail2ban eigentlich macht
Fail2ban arbeitet nach einem einfachen Prinzip: Es überwacht Logs, zählt auffällige Einträge und führt bei einem Treffer eine Aktion aus. Meistens ist diese Aktion eine temporäre Sperre per iptables, nftables oder ufw.
Die einzelnen Regeln heißen bei Fail2ban Jails. Eine Jail besteht aus einem Filter, einer Logdatei und einer Aktion. Für SSH ist das schon vorbereitet. Für Dienste wie Nginx, Apache, Postfix oder eigene Anwendungen kannst du ebenfalls Jails nutzen oder selbst bauen.
Wichtig ist aber: Fail2ban ersetzt keine saubere Grundhärtung. SSH-Keys, deaktivierter Root-Login, Updates und sinnvolle Firewall-Regeln bleiben Pflicht. Fail2ban ist die Schicht darüber. Sozusagen der Türsteher, der irgendwann keine Lust mehr auf falsche Passwörter hat.
🛠 Fail2ban installieren
Unter Ubuntu und Debian ist die Installation angenehm unspektakulär. Genau so mag ich das bei Server-Basics.
sudo apt update sudo apt install fail2ban -y sudo systemctl enable --now fail2ban
Danach prüfst du kurz, ob der Dienst läuft:
sudo systemctl status fail2ban sudo fail2ban-client version sudo fail2ban-client status
Auf meinem Testsystem mit Ubuntu 24.04 lief Fail2ban danach direkt als aktiver Dienst. Der Befehl fail2ban-client status zeigt dir, welche Jails aktiv sind.
🔐 SSH mit Fail2ban absichern
Die wichtigste Datei ist nicht jail.conf, sondern deine eigene lokale Konfiguration. Die Datei jail.conf kann bei Updates überschrieben werden. Deine Anpassungen gehören deshalb in /etc/fail2ban/jail.local oder in eine Datei unter /etc/fail2ban/jail.d/.
[DEFAULT] ignoreip = 127.0.0.1/8 ::1 10.0.1.0/24 bantime = 1h findtime = 10m maxretry = 5 backend = auto [sshd] enabled = true port = ssh logpath = /var/log/auth.log
Die Werte sind schnell erklärt:
ignoreipschützt eigene IPs oder interne Netze davor, gebannt zu werden.bantimelegt fest, wie lange eine IP gesperrt wird.findtimeist das Zeitfenster, in dem Fehlversuche gezählt werden.maxretrygibt an, wie viele Treffer erlaubt sind, bevor Fail2ban eingreift.
Nach Änderungen lädst du die Konfiguration neu:
sudo fail2ban-client reload sudo fail2ban-client status sshd
📊 Die wichtigsten Befehle im Alltag
Im Alltag brauchst du gar nicht viele Befehle. Diese hier reichen meistens schon, um zu sehen was passiert und bei Bedarf einzugreifen.
sudo fail2ban-client status sudo fail2ban-client status sshd sudo fail2ban-client banned sudo fail2ban-client get sshd bantime sudo fail2ban-client get sshd findtime sudo fail2ban-client get sshd maxretry
Wenn du eine IP manuell sperren oder wieder freigeben möchtest, geht das ebenfalls direkt über den Client:
sudo fail2ban-client set sshd banip 203.0.113.10 sudo fail2ban-client set sshd unbanip 203.0.113.10 sudo fail2ban-client unban 203.0.113.10
Und wenn du wissen willst, was Fail2ban gerade so denkt, helfen die Logs. Die sind manchmal erstaunlich gesprächig.
sudo journalctl -u fail2ban --no-pager -n 50 sudo tail -f /var/log/fail2ban.log
🧪 Filter testen, bevor du dich aussperrst
Wenn du eigene Filter baust oder bestehende Regeln anpasst, teste sie vorher. Fail2ban bringt dafür fail2ban-regex mit. Das spart Nerven und manchmal auch den Griff zur VPS-Konsole.
sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf sudo fail2ban-client -t
Der erste Befehl prüft, ob der Filter zu den Logzeilen passt. Der zweite testet die Konfiguration. Wenn hier schon Fehler auftauchen, brauchst du den Dienst nicht erst neu starten und dich anschließend wundern.
🌐 Beispiele aus dem Alltag
SSH ist der Klassiker, aber Fail2ban kann mehr. Besonders spannend wird es bei Diensten, die saubere Logeinträge schreiben. Ohne passende Logs kann Fail2ban nichts erkennen. Es ist ein Log-Wächter, kein Gedankenleser.
Ein Beispiel für Nginx HTTP Basic Auth sieht so aus:
[nginx-http-auth] enabled = true port = http,https filter = nginx-http-auth logpath = /var/log/nginx/error.log maxretry = 3 findtime = 10m bantime = 2h
Bei WordPress, Nextcloud oder anderen Webanwendungen hängt es stark davon ab, ob fehlgeschlagene Logins überhaupt in einer für Fail2ban lesbaren Datei landen. Manche Anwendungen schreiben in eigene Logs, manche nur in die Datenbank und manche hinterlassen im Webserver-Log nicht genug Details. Dann musst du entweder Logging sauber aktivieren oder ein passendes Plugin beziehungsweise eine eigene Log-Ausgabe nutzen.
Sehr praktisch ist auch die Jail recidive. Sie sperrt Wiederholungstäter länger, wenn sie nach einer normalen Sperre direkt wieder auffällig werden. Das ist die höfliche Variante von: Du schon wieder?
[recidive] enabled = true logpath = /var/log/fail2ban.log findtime = 1d maxretry = 5 bantime = 1w
📦 Fail2ban und Docker
Fail2ban in Docker ist möglich, aber ich würde es nicht pauschal als Standard empfehlen. Wenn Fail2ban den Host schützen soll, muss es die relevanten Host-Logs lesen und am Ende auch an der richtigen Firewall-Schicht sperren können. Ein hübscher Container bringt dir wenig, wenn er nur im eigenen Netzwerk beleidigt mit den Schultern zuckt.
Für Docker-Dienste ist oft der bessere Weg: Logs sauber auf dem Host verfügbar machen, Reverse Proxy ordentlich konfigurieren und Fail2ban auf dem Host laufen lassen. Bei Traefik, Nginx Proxy Manager oder Nginx kannst du dann gezielt auf die jeweiligen Access- und Error-Logs gehen.
Wichtig bei Proxys und CDN-Diensten wie Cloudflare: Achte darauf, dass dein Webserver die echte Client-IP sieht. Wenn Fail2ban nur die IP deines Reverse Proxys oder CDN sieht, sperrst du im schlechtesten Fall den falschen Kandidaten. Das ist dann sehr effektiv, aber leider gegen dich selbst.
💡 Tipps aus der Praxis
- Trage deine eigene Admin-IP oder dein internes Netz in
ignoreipein. - Starte mit moderaten Sperrzeiten und erhöhe sie erst, wenn alles sauber läuft.
- Nutze SSH-Keys und deaktiviere Passwort-Logins, wenn es zu deinem Setup passt.
- Prüfe nach Änderungen immer
fail2ban-client -t. - Schau regelmäßig in
fail2ban-client status, aber übertreib es nicht. Man kann auch Logs kaputtstarren. - Dokumentiere eigene Filter. In sechs Monaten weiß sonst niemand mehr, warum diese eine Regex so aussieht, wie sie aussieht. Auch du nicht. Leider.
🆚 Alternativen zu Fail2ban
Fail2ban ist bewährt, aber nicht mehr das modernste Tool. Das ist nicht schlimm. Ein Hammer wird auch nicht schlecht, nur weil es inzwischen Akkuschrauber gibt. Trotzdem lohnt sich ein Blick auf Alternativen und Ergänzungen.
- CrowdSec arbeitet ebenfalls mit Logs, setzt aber stärker auf Szenarien, Community-Blocklisten, zentrale Verwaltung und sogenannte Bouncer für Firewall, Reverse Proxy oder Webserver.
- SSHGuard ist schlank und konzentriert sich stark auf Brute-Force-Schutz für SSH und andere Dienste.
- UFW, nftables oder iptables sind keine direkten Alternativen, sondern die Firewall-Basis. Damit kannst du feste Regeln, erlaubte Netze und Portfreigaben sauber definieren.
- Rate Limiting im Reverse Proxy hilft bei Webdiensten oft zusätzlich. Bei Nginx, Traefik oder Caddy kannst du Anfragen begrenzen, bevor eine Anwendung überhaupt arbeiten muss.
- Wazuh oder ein SIEM ist eher die größere Nummer. Spannend, wenn du mehrere Systeme überwachen, auswerten und korrelieren willst.
Meine Kurzfassung: Für einen einzelnen Linux-Server ist Fail2ban weiterhin völlig okay. Wenn du mehrere Hosts, Reverse Proxys, Cloudflare, zentrale Sichtbarkeit oder Community-Blocklisten willst, schau dir CrowdSec genauer an.
🔗 Weiterführende Links
✅ Fazit
Fail2ban ist kein neues, glänzendes Security-Wunder. Muss es auch nicht sein. Es ist ein solides Werkzeug, welches auf vielen Linux-Servern schnell eingerichtet ist und besonders bei SSH, Webserver-Logs und wiederkehrenden Fehlversuchen seinen Zweck erfüllt.
Ich würde es nicht als einzige Schutzmaßnahme betrachten, aber als zusätzliche Schicht ist es weiterhin nützlich. Erst sauber absichern, dann Fail2ban dazu. Genau in dieser Reihenfolge.
👥 Techniverse Community
Lust auf Austausch rund um Matrix, Selfhosting und andere smarte IT-Lösungen?
In der Techniverse Community triffst du Gleichgesinnte, kannst Fragen stellen oder einfach nerdigen Talk genießen. 🚀
👉 Jetzt der Gruppe auf Matrix beitreten
~ Direkte Raumadresse: #community:techniverse.net
👉 Für lockere Gespräche abseits der Kernthemen komm in den Talkraum
~ Direkte Raumadresse: #talk:techniverse.net
Wir freuen uns, wenn du dabei bist!
