Fail2ban einrichten: Angreifer automatisch aussperren

Fail2ban einrichten dauert auf einem Linux-Server etwa eine Viertelstunde und nimmt Ihnen danach viel Arbeit ab. Das Programm liest die Protokolle Ihrer Dienste, erkennt wiederholte Fehlversuche beim Login und sperrt die Absender für eine gewisse Zeit in der Firewall. Wer einen Server mit offenem SSH-Port betreibt, sieht im Protokoll Tausende Anmeldeversuche pro Tag. Fail2ban macht daraus ein paar Dutzend, bevor die Absender gesperrt sind. Ersetzen kann es eine gute Absicherung aber nicht, es ist eine zusätzliche Schicht.

Wie Fail2ban arbeitet

Sie müssen keine Programmierkenntnisse haben, um das Programm zu nutzen. Fail2ban besteht aus drei Bausteinen. Ein Filter beschreibt mit regulären Ausdrücken, wie ein Fehlversuch im Protokoll aussieht. Eine Aktion legt fest, was bei zu vielen Treffern passiert, meist eine Sperrregel in der Firewall. Ein Jail verbindet beides für einen Dienst: welches Protokoll, welcher Filter, wie viele Versuche in welcher Zeit und wie lange die Sperre dauert.

Für die meisten Server reichen die fertigen Filter, die Fail2ban mitbringt. Eigene reguläre Ausdrücke, also Suchmuster für Textzeilen, brauchen Sie nur für Sonderfälle wie den WordPress-Login weiter unten.

Wichtig ist, was Fail2ban nicht kann. Es sperrt einzelne Absender nach mehreren Versuchen. Ein Angriff von Tausenden verschiedenen Adressen, die jeweils nur einmal probieren, rutscht durch. Gegen Überlastungsangriffe hilft es ebenfalls kaum, dafür gibt es andere Mittel, die der Ratgeber zum DDoS-Schutz beschreibt. Die eigentliche Sicherheit für SSH kommt von Schlüsseln statt Passwörtern.

Voraussetzungen, um Fail2ban einrichten zu können

• ein vServer oder Root-Server mit Debian oder Ubuntu und Root-Rechten
• ein funktionierender SSH-Zugang, idealerweise mit Schlüssel
• eine aktive Firewall wie nftables oder ufw
• eine feste IP-Adresse, von der Sie selbst arbeiten, falls vorhanden

Auf Shared Hosting gibt es Fail2ban nicht zum Selbsteinrichten. Dort kümmert sich der Anbieter um den Schutz der Server.

Fail2ban installieren

Die Pakete in Debian und Ubuntu sind aktuell genug. Installieren und starten Sie das Programm mit:

sudo apt update
sudo apt install fail2ban
sudo systemctl enable --now fail2ban

Nach der Installation ist bei Debian und Ubuntu bereits ein Jail für SSH aktiv. Prüfen Sie das mit sudo fail2ban-client status. Die Ausgabe listet alle aktiven Jails, darunter sollte sshd stehen.

Fail2ban einrichten mit der jail.local

Wer Fail2ban einrichten will, braucht vor allem eine Datei. Die Grundeinstellungen stehen in /etc/fail2ban/jail.conf. Diese Datei ändern Sie nie, denn ein Update überschreibt sie. Eigene Einstellungen gehören in die Datei /etc/fail2ban/jail.local, die Fail2ban zusätzlich liest und deren Werte Vorrang haben. Legen Sie sie mit diesem Inhalt an:

[DEFAULT]
# eigene Adressen nie sperren
ignoreip = 127.0.0.1/8 ::1 203.0.113.10
bantime  = 1h
findtime = 10m
maxretry = 5
# Wiederholungstäter länger sperren
bantime.increment = true
bantime.maxtime   = 1w

[sshd]
enabled = true
backend = systemd

Die Werte bedeuten: Wer innerhalb von 10 Minuten 5 Fehlversuche hat, wird für eine Stunde gesperrt. Mit bantime.increment verlängert sich die Sperre bei jedem weiteren Mal, bis höchstens eine Woche. Tragen Sie bei ignoreip statt des Beispiels Ihre eigene feste IP-Adresse ein, falls Sie eine haben. Ohne feste Adresse lassen Sie den Eintrag beim lokalen Bereich und arbeiten mit SSH-Schlüsseln, dann kommen Sie gar nicht erst in die Lage, sich selbst auszusperren.

Die Zeile backend = systemd ist wichtig. Neuere Debian-Versionen schreiben die Anmeldeversuche nicht mehr in die Datei /var/log/auth.log, sondern nur noch ins Journal von systemd. Ohne diese Zeile findet Fail2ban dort nichts oder startet den Jail gar nicht. Laden Sie die Einstellungen danach neu:

sudo fail2ban-client reload
sudo fail2ban-client status sshd

Die richtige Firewall-Aktion

Fail2ban muss wissen, über welche Firewall es sperrt. Auf aktuellen Debian-Systemen ist nftables vorgegeben, ältere Anleitungen nennen noch iptables. Nutzen Sie ufw, setzen Sie im Bereich [DEFAULT] der jail.local die Zeile banaction = ufw, damit die Sperren auch mit sudo ufw status sichtbar sind. Arbeiten Sie direkt mit nftables, passt banaction = nftables-multiport. Welche Aktionen verfügbar sind, zeigt der Ordner /etc/fail2ban/action.d/. Mehr zu Regeln und Ports erklärt der Ratgeber zur Firewall-Konfiguration.

Nach dem Neuladen prüfen Sie, ob die Sperren wirklich ankommen. Bei nftables zeigt sudo nft list ruleset eine Tabelle mit dem Namen von Fail2ban, sobald die erste Adresse gesperrt ist.

Weitere Dienste schützen

Wenn Sie Fail2ban einrichten, lohnt sich der Blick über SSH hinaus. Das Programm bringt fertige Filter für viele Programme mit. Sie müssen sie nur in der jail.local einschalten. Sinnvoll sind vor allem diese:

[nginx-http-auth]
enabled = true

[postfix]
enabled = true
mode    = aggressive

[dovecot]
enabled = true

[recidive]
enabled  = true
bantime  = 1w
findtime = 1d

Der Jail nginx-http-auth greift bei falschen Passwörtern für geschützte Bereiche des Webservers. Die Jails für Postfix und Dovecot schützen einen eigenen Mailserver vor Passwort-Raten, wie es der Ratgeber zum E-Mail-Server beschreibt. Der Jail recidive beobachtet das Protokoll von Fail2ban selbst und sperrt Adressen, die immer wieder auffallen, für eine Woche. Läuft ein Dienst bei Ihnen nicht, lassen Sie den Jail aus, sonst meldet Fail2ban beim Start einen Fehler, weil das Protokoll fehlt.

Eigenen Filter für WordPress schreiben

Für den Login von WordPress gibt es keinen fertigen Filter, weil ein fehlgeschlagener Login dort im Zugriffsprotokoll gleich aussieht wie ein erfolgreicher. Ein einfacher Ansatz zählt viele POST-Anfragen auf die Login-Seite. Legen Sie die Datei /etc/fail2ban/filter.d/wordpress-login.conf an:

[Definition]
failregex = ^<HOST> .* "POST /wp-login\.php
            ^<HOST> .* "POST /xmlrpc\.php
ignoreregex =

Und dazu in der jail.local:

[wordpress-login]
enabled  = true
port     = http,https
filter   = wordpress-login
logpath  = /var/log/nginx/access.log
maxretry = 10
findtime = 5m

Testen Sie beim Fail2ban einrichten jeden eigenen Filter, bevor Sie ihn scharf schalten. Der Befehl sudo fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/wordpress-login.conf zeigt, wie viele Zeilen getroffen würden. Sind es auffällig viele von Ihrer eigenen Adresse, ist der Filter zu streng oder maxretry zu niedrig. Weitere Schutzmaßnahmen für den Login beschreibt der Ratgeber zur WordPress-Sicherheit.

Testen, ob die Sperre wirklich greift

Zum Fail2ban einrichten gehört ein Test. Ein Jail, der im Status als aktiv erscheint, sperrt noch lange nicht zuverlässig. Testen Sie deshalb einmal von einem zweiten Anschluss aus, etwa vom Handy im Mobilnetz mit einer SSH-App oder von einem anderen Server. Melden Sie sich dort mehrmals mit einem falschen Benutzer an, bis maxretry erreicht ist. Danach sollte sudo fail2ban-client status sshd die Adresse unter „Banned IP list“ zeigen, und neue Verbindungsversuche von dort laufen ins Leere.

Testen Sie nie von dem Anschluss, über den Sie gerade selbst arbeiten, es sei denn, er steht in ignoreip. Heben Sie die Testsperre danach mit dem Befehl aus dem nächsten Abschnitt wieder auf.

Sonderfall Docker

Laufen Ihre Dienste in Docker-Containern, kommt beim Fail2ban einrichten eine Falle hinzu. Docker leitet Verbindungen zu veröffentlichten Ports an den normalen Regeln der Firewall vorbei. Eine Sperre, die Fail2ban in die üblichen Ketten einträgt, greift dann für SSH auf dem Server, aber nicht für eine Anwendung im Container. Für solche Dienste muss die Sperre in die Kette DOCKER-USER, etwa mit der Zeile chain = DOCKER-USER im Jail und einer Aktion auf Basis von iptables. Die Protokolle der Container liest Fail2ban nur, wenn Sie sie in eine Datei schreiben lassen oder über das Journal weitergeben. Mehr zur Port-Falle steht im Ratgeber zu Docker auf dem vServer.

Fail2ban einrichten mit Benachrichtigung

Für einen Überblick reicht meist ein Blick ins Protokoll. Wer bei jeder Sperre eine Mail bekommen möchte, setzt in der jail.local action = %(action_mw)s sowie destemail und sender. Bei einem offenen SSH-Port sind das schnell Dutzende Mails am Tag. Sinnvoller ist eine Mail nur für den Jail recidive, also nur für hartnäckige Wiederholungstäter. Der Server braucht dafür ein Programm zum Mailversand, etwa msmtp.

Sperren prüfen und wieder aufheben

Im Alltag brauchen Sie nur wenige Befehle:

# Überblick über einen Jail mit gesperrten Adressen
sudo fail2ban-client status sshd
# eine Adresse wieder freigeben
sudo fail2ban-client set sshd unbanip 198.51.100.23
# alle Sperren aufheben
sudo fail2ban-client unban --all
# was Fail2ban gerade tut
sudo tail -f /var/log/fail2ban.log

Haben Sie sich selbst ausgesperrt, hilft die Konsole im Kundenmenü Ihres Anbieters. Sie verbindet Sie direkt mit dem Server, an der Firewall vorbei. Melden Sie sich dort an und heben Sie die Sperre mit dem Befehl oben auf.

Typische Fehler beim Fail2ban einrichten

• Änderungen in der jail.conf: Das nächste Update überschreibt sie.
• Jail aktiv, aber leeres Protokoll: Das Backend passt nicht. Unter Debian fehlt oft backend = systemd.
• Falsche Firewall-Aktion: Fail2ban meldet Sperren, aber die Firewall kennt sie nicht.
• Zu harte Werte: Mit maxretry = 1 sperren Sie Kollegen nach einem Tippfehler aus.
• Hinter einem Proxy oder CDN: Im Protokoll steht die Adresse des Proxys, und Fail2ban sperrt ihn statt des Angreifers. Dann muss der Webserver die echte Adresse der Besucher protokollieren.
• Fail2ban als einziger Schutz: Passwort-Login für Root bleibt ein Risiko, auch mit Sperren.

Die vollständige Beschreibung aller Optionen finden Sie im Projekt von Fail2ban. Was außer Fail2ban zu einem gut abgesicherten Server gehört, fasst der Ratgeber zur Root-Server-Sicherheit zusammen.