fail2ban einrichten und Brute-Force-Angriffe automatisch sperren

Jeder Server mit öffentlicher IPv4-Adresse bekommt innerhalb weniger Minuten nach der ersten Bereitstellung Login-Versuche auf Port 22. Das ist kein gezielter Angriff, sondern Grundrauschen. fail2ban liest die Logzeilen dieser Fehlversuche mit und lässt die Firewall die Quell-IP für eine definierte Zeit blockieren. Das Werkzeug ist in allen hier behandelten Distributionen paketiert und in wenigen Minuten eingerichtet. Die Tücken liegen woanders: fail2ban startet auf Debian 12 gerne mit einem Konfigurationsfehler, es sperrt auf manchen Systemen scheinbar, ohne dass ein Paket wirklich verworfen wird, und eine unbedachte Zeile in jail.local sperrt dich selbst aus.

Dieser Artikel deckt genau diese Stellen ab, für Debian 13, Debian 12, Ubuntu 24.04 LTS und Ubuntu 22.04 LTS.

Warum jail.local und niemals jail.conf

Die Datei /etc/fail2ban/jail.conf gehört dem Paket. Bei jedem Update kann sie überschrieben werden, und dann fragt dpkg im besten Fall nach, im schlechtesten Fall auf einem unbeaufsichtigten Update-Lauf gar nicht. Deine Anpassungen leben deshalb in /etc/fail2ban/jail.local. Diese Datei existiert nach der Installation nicht, du legst sie selbst an, und sie darf nur die Werte enthalten, die du wirklich änderst.

Wichtig ist die Reihenfolge, in der fail2ban liest. Die Handbuchseite jail.conf(5) nennt sie explizit:

1. jail.conf
2. jail.d/*.conf in alphabetischer Reihenfolge
3. jail.local
4. jail.d/*.local in alphabetischer Reihenfolge

Später gelesene Dateien gewinnen. Das heißt konkret: deine jail.local überschreibt auch die Vorgaben aus /etc/fail2ban/jail.d/defaults-debian.conf, die das Distributionspaket mitbringt. Viele Anleitungen behaupten das Gegenteil und empfehlen deshalb eine eigene Datei in jail.d/. Nötig ist das nicht. Sinnvoll ist jail.d/ nur, wenn du Jails per Konfigurationsmanagement einzeln ausrollen willst.

Was deine Distribution schon vorgibt

Der größte Unterschied zwischen den vier Systemen steckt nicht in fail2ban selbst, sondern in dieser einen Datei, die das Paket nach /etc/fail2ban/jail.d/defaults-debian.conf legt. Sieh sie dir zuerst an:

cat /etc/fail2ban/jail.d/defaults-debian.conf

Daraus folgt fast alles Weitere. Debian 13 und Ubuntu 24.04 lesen ab Werk das systemd-Journal und sperren über nftables. Debian 12 und Ubuntu 22.04 fallen auf die Vorgaben aus jail.conf zurück, also banaction = iptables-multiport und backend = auto. Und auto bedeutet ausdrücklich nicht "such dir das Richtige aus". Der Kommentar in jail.conf sagt, dass auto der Reihe nach pyinotify und polling probiert. Beides sind dateibasierte Verfahren. Der Wert auto wählt niemals das Journal. Ohne die Datei /var/log/auth.log läuft der sshd-Jail dort ins Leere.

Installation und die erste Kontrolle

apt update
apt install -y fail2ban

Auf Debian 12 und Ubuntu 22.04 kommt ein Paket dazu, wenn du das Journal statt einer Logdatei auswerten willst:

apt install -y python3-systemd

Auf Debian 13 ist python3-systemd eine harte Abhängigkeit des Pakets und bereits vorhanden. Auf Debian 12 ist es lediglich empfohlen, was die häufigste Fehlerquelle auf diesem System ist. Prüfe anschließend Version und Zustand:

apt-cache policy fail2ban
fail2ban-client --version
systemctl status fail2ban --no-pager

Wenn hier bereits active (running) steht, ist die halbe Miete drin. Steht dort failed, spring direkt zum Abschnitt über die Fehlermeldungen.

Die eigene jail.local aufbauen

Lege /etc/fail2ban/jail.local an. Diese Fassung funktioniert auf allen vier Systemen, sofern python3-systemd installiert ist:

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 203.0.113.7
bantime  = 1h
findtime = 10m
maxretry = 5

bantime.increment = true
bantime.factor    = 2
bantime.maxtime   = 7d

banaction = nftables
banaction_allports = nftables[type=allports]

[sshd]
enabled  = true
backend  = systemd
port     = ssh
maxretry = 4
bantime  = 2h

Die Bedeutung der Werte im Klartext: findtime ist das gleitende Zeitfenster, maxretry die Zahl der Fehlversuche darin, bantime die Sperrdauer. Vier Fehlversuche in zehn Minuten führen hier zu zwei Stunden Sperre. Zeitangaben verstehen Suffixe wie m, h, d und w, eine reine Zahl bedeutet Sekunden. Ein bantime von -1 sperrt dauerhaft.

Der interessante Teil ist bantime.increment. Damit verdoppelt fail2ban die Sperrzeit bei jedem Rückfall derselben IP, gedeckelt durch bantime.maxtime. Ein einmaliger Vertipper eines echten Nutzers kostet zwei Stunden, ein hartnäckiger Bot landet nach wenigen Runden bei einer Woche. Diese Funktion gibt es seit fail2ban 0.11, sie steht also auch auf Ubuntu 22.04 zur Verfügung. Damit sie über Neustarts hinweg greift, muss die Datenbank die Historie behalten, gesteuert über dbpurgeage in /etc/fail2ban/fail2ban.conf, standardmäßig ein Tag. Wenn du bantime.maxtime = 7d setzt, hebe dbpurgeage in einer fail2ban.local ebenfalls an.

Zwei Fallstricke in diesem Block. Erstens port = ssh: das löst sich über /etc/services zu Port 22 auf. Läuft dein SSH-Dienst auf 2222, muss dort port = 2222 stehen, sonst entsteht eine Firewall-Regel für einen Port, auf dem niemand klopft. Zweitens ignoreip: trage dort deine feste Büro-IP ein, aber niemals ein ganzes Provider-Netz. Und verlass dich nicht allein darauf. Der Wert ignoreself steht ohnehin per Vorgabe auf true und schützt die eigenen Server-IPs.

Abweichungen je nach System

Auf Debian 12 hast du zwei gleichwertige Wege. Entweder du bleibst bei backend = systemd und installierst python3-systemd, oder du installierst rsyslog, lässt backend weg und arbeitest mit /var/log/auth.log. Zusätzlich solltest du auf Debian 12 die banaction bewusst setzen. Das Paket empfiehlt nftables oder iptables, und apt installiert davon in der Regel nur nftables. Die Vorgabe aus jail.conf lautet aber iptables-multiport. Auf einer schlanken Installation greift fail2ban dann zu einem Binary, das gar nicht da ist.

Auf Ubuntu 22.04 ist rsyslog im Serverstandard enthalten, /var/log/auth.log existiert, und der Jail läuft ohne Zutun. Wenn du dort nichts umstellen willst, lass backend und banaction in deiner jail.local einfach weg. fail2ban 0.11.2 kennt die nftables-Aktion zwar, aber der Weg über iptables-multiport ist auf diesem System der ausgetretenere.

Auf Debian 13 und Ubuntu 24.04 deckt sich deine jail.local mit den Paketvorgaben. Das schadet nicht, es macht die Konfiguration nur explizit und damit lesbar.

Übernehmen und prüfen, ob es wirklich greift

Konfiguration einlesen, ohne bestehende Sperren zu verlieren:

fail2ban-client reload

Auf Debian 12 und Ubuntu 24.04 meldet fail2ban 1.0.2 beim Start und beim Neuladen die Warnung 'allowipv6' not defined in 'Definition'. Sie ist harmlos, der Dienst arbeitet trotzdem normal weiter.

Ein systemctl restart fail2ban ist selten nötig und setzt die laufenden Sperren zurück. Danach die Statusabfragen:

fail2ban-client ping
fail2ban-client status
fail2ban-client status sshd

Die letzte Ausgabe ist die aussagekräftige. Sie zeigt Currently failed, Total failed, die Zahl der Sperren und die Liste der gesperrten Adressen. Genau hier hören die meisten Anleitungen auf, und genau hier fängt das Problem an: ein Jail, der sauber startet und "0 banned" meldet, kann komplett blind sein. Ein Jail ohne Treffer sieht identisch aus wie ein Jail, der die falsche Logquelle liest.

Drei Kontrollen, die diesen Unterschied sichtbar machen. Erstens: sieht der Filter die Zeilen überhaupt?

fail2ban-regex systemd-journal /etc/fail2ban/filter.d/sshd.conf

Bei dateibasiertem Backend stattdessen:

fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

Am Ende steht eine Zeile wie Lines: 4211 lines, 0 ignored, 137 matched, 4074 missed. Steht dort 0 matched, obwohl im Log erkennbar Fehlversuche stehen, passt der Filter oder die Journal-Auswahl nicht.

Zweitens: welchen Journal-Filter benutzt der Jail tatsächlich?

fail2ban-client get sshd journalmatch

Die Antwort fällt je nach System unterschiedlich aus, und dieser Unterschied ist wichtig. Debian 13 meldet _SYSTEMD_UNIT=ssh.service + _COMM=sshd, Ubuntu 24.04 dagegen _SYSTEMD_UNIT=sshd.service + _COMM=sshd. Die Unit heißt dort also sshd.service und auf Debian ssh.service. Auf Debian 12 und Ubuntu 22.04 kommt im Auslieferungszustand No journal match filter set zurück, weil dort das systemd-Backend nicht voreingestellt ist und der Jail eine Logdatei liest. Das ist kein Fehler, sondern die Bestätigung, dass es überhaupt keinen Journal-Filter gibt. Erst mit backend = systemd in deiner jail.local wird auf diesen Systemen einer wirksam.

Die einzelnen Bedingungen sind durch + getrennt und werden als Oder verknüpft. _SYSTEMD_UNIT=ssh.service + _COMM=sshd passt also auf alles aus der Unit ssh.service oder auf jeden Prozess namens sshd. Für die Gegenprobe im Journal nimm genau den Unit-Namen aus der Ausgabe oben:

journalctl -u ssh --no-pager -n 50
journalctl _COMM=sshd --no-pager -n 50

Auf Ubuntu 24.04 lautet die erste Zeile entsprechend journalctl -u sshd --no-pager -n 50. Wer hier den falschen Namen nimmt, sieht eine leere Ausgabe und sucht anschließend am falschen Ende.

Wenn hier Zeilen mit Failed password for invalid user auftauchen, fail2ban aber nichts zählt, liegt es an der Journal-Auswahl. Relevant wird das, wenn du OpenSSH aus Backports betreibst oder auf Socket-Aktivierung umstellst. Seit OpenSSH 9.8 heißt der Kindprozess sshd-session, nicht mehr sshd, und bei Socket-Aktivierung heißt die Unit nicht mehr ssh.service. Dann ergänzt du in deiner jail.local (auf Ubuntu 24.04 mit _SYSTEMD_UNIT=sshd.service):

[sshd]
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session

Drittens die harte Probe. Sperre eine Adresse aus dem Dokumentationsnetz von Hand und sieh nach, ob sie in der Firewall ankommt:

fail2ban-client set sshd banip 203.0.113.10

Der Befehl quittiert mit 1, also einer gesperrten Adresse. Mit welchem Werkzeug du diese Sperre nachweist, hängt von der wirksamen banaction ab, und die ist je nach Distribution unterschiedlich voreingestellt:

Das ältere Debian 11 verhält sich dabei wie Debian 12. Woher der Unterschied kommt, siehst du in /etc/fail2ban/jail.d/defaults-debian.conf: nur Debian 13 und Ubuntu 24.04 bringen dort ein banaction = nftables mit, die übrigen bleiben bei der Vorgabe iptables-multiport aus jail.conf. Wer das nicht pro Server auseinanderhalten will, setzt banaction = nftables in die eigene jail.local, so wie im Beispiel weiter oben, und prüft danach überall mit nft.

Bei der nftables-Aktion gibt es eine Tabelle f2b-table in der Familie inet, darin eine Chain f2b-chain mit Priorität filter - 1 und ein Set namens addr-set-sshd. Dort muss 203.0.113.10 als Element stehen. Eine Kette f2b-sshd gibt es auf diesen Systemen nicht, iptables -n -L f2b-sshd antwortet dort mit No chain/target/match by that name. Umgekehrt meldet nft list table inet f2b-table auf Debian 12 und Ubuntu 22.04 Error: No such file or directory, solange dort iptables-multiport arbeitet. Beide Meldungen sind kein Beleg für eine kaputte Konfiguration, sondern nur für den falschen Befehl zur eingestellten Aktion.

Bei der iptables-Aktion muss 203.0.113.10 entsprechend in der Kette f2b-sshd stehen. Erst wenn die IP in der Firewall auftaucht, ist die Kette vom Log bis zum verworfenen Paket geschlossen. Aufräumen nicht vergessen.

Sperren wieder aufheben

Eine einzelne Adresse aus einem bestimmten Jail lösen:

fail2ban-client set sshd unbanip 203.0.113.10

Eine Adresse aus allen Jails auf einmal:

fail2ban-client unban 203.0.113.10

Und im Notfall alles auf null:

fail2ban-client unban --all

Der letzte Befehl ist der, den du brauchst, wenn du dich selbst ausgesperrt hast und über eine Notfallkonsole am Server sitzt. Er hebt alle Sperren auf, ohne den Dienst neu zu starten. Wenn du gar nicht mehr an den Server kommst, hilft nur der Weg über die Konsole im Kundenbereich. Auf KVM-Rootservern und Dedicated Servern von KernelHost erreichst du dort eine VNC-Sitzung, die unabhängig von SSH funktioniert. Das ist auch der Grund, warum du bantime = -1 auf einem Server ohne zweiten Zugangsweg nicht setzen solltest.

Eine Sperre, die du aufhebst, kommt sofort zurück, wenn die Fehlversuche im Zeitfenster noch gezählt werden. Deshalb hebt unban auch die zugehörigen Fehlversuche mit auf. Wer dauerhaft frei bleiben soll, gehört in ignoreip, gefolgt von fail2ban-client reload.

Zusammenspiel mit UFW und nftables

Hier entsteht der Schaden, den man am schwersten bemerkt, denn fail2ban meldet weiterhin fröhlich Sperren, während die Pakete durchgehen.

UFW ist ein Frontend für iptables. Beim Starten oder Neuladen schreibt es die Filtertabelle über iptables-restore neu. Dabei verschwinden die von fail2ban angelegten Chains ersatzlos, und fail2ban legt sie nicht von selbst wieder an. Nach jedem ufw enable, ufw disable oder ufw reload gilt deshalb: systemctl restart fail2ban. Bis dahin steht in fail2ban-client status sshd eine lange Liste gesperrter IPs, von denen keine einzige tatsächlich blockiert wird.

Sauberer ist es, fail2ban direkt über UFW sperren zu lassen. Die Aktion liegt in /etc/fail2ban/action.d/ufw.conf und ist in allen vier Distributionen enthalten. In jail.local:

[DEFAULT]
banaction = ufw
banaction_allports = ufw

Dann landen die Sperren als Regeln in UFW selbst und überstehen dessen Neuladen. Kontrolle:

ufw status numbered

Gesperrte Adressen erscheinen dort als DENY IN weit oben in der Liste. Wichtig ist, dass die Sperrregeln vor deiner Freigabe für Port 22 stehen, sonst greift die Freigabe zuerst. Die mitgelieferte Aktion setzt sie deshalb per insert an den Anfang.

Wer kein UFW einsetzt und stattdessen ein eigenes Regelwerk in /etc/nftables.conf pflegt, hat ein verwandtes Problem. Ein flush ruleset am Anfang dieser Datei, das die Standardvorlage so vorschlägt, löscht beim Neuladen auch f2b-table. Entweder du verzichtest auf das globale Flush und leerst nur deine eigene Tabelle, oder du hängst den Neustart von fail2ban an den nftables-Dienst. Der Vorteil der fail2ban-eigenen Tabelle ist, dass sie mit Priorität filter - 1 vor der normalen Filtertabelle greift und damit auch vor Regeln aus iptables-nft.

Nicht mischen solltest du banaction = nftables und ein eigenes iptables-Regelwerk in der Erwartung, dass iptables -L die Sperren zeigt. Beide Wege funktionieren parallel, aber jedes Werkzeug zeigt nur das eigene Regelwerk. Prüfe immer mit dem Werkzeug, das zur eingestellten banaction passt.

Fehlermeldungen im Wortlaut und was dahintersteckt

Die Logs findest du je nach System an zwei Orten:

journalctl -u fail2ban --no-pager -n 100
tail -n 100 /var/log/fail2ban.log

Failed during configuration: Have not found any log file for sshd jail

Die Signaturmeldung von Debian 12. Der Jail läuft mit backend = auto, sucht /var/log/auth.log, und die Datei existiert nicht, weil kein rsyslog installiert ist und alles im Journal landet. Der Dienst startet gar nicht erst, systemctl status fail2ban zeigt Failed with result 'exit-code'. Zwei Lösungen: entweder apt install -y rsyslog und einmal neu starten, oder in jail.local unter [sshd] die Zeile backend = systemd setzen. Der zweite Weg ist der modernere, verlangt aber das nächste Paket.

Backend 'systemd' failed to initialize due to No module named 'systemd'

Du hast backend = systemd gesetzt, aber die Python-Anbindung an das Journal fehlt. Auf Debian 12 ist python3-systemd nur empfohlen und wird bei Installationen ohne empfohlene Pakete nicht mitgezogen. Abhilfe:

apt install -y python3-systemd
systemctl restart fail2ban

Failed to access socket path: /var/run/fail2ban/fail2ban.sock. Is fail2ban running?

Der Client erreicht den Server nicht. In den allermeisten Fällen läuft der Dienst schlicht nicht, weil er an einem Konfigurationsfehler gescheitert ist. Erst systemctl status fail2ban lesen, dann das Journal. Selten bleibt nach einem harten Abbruch eine verwaiste Socket-Datei liegen, dann meldet der Serverstart Server already running. In dem Fall die Socket-Datei entfernen und neu starten.

NOK: ('sshd',)

Die Antwort auf fail2ban-client status sshd, wenn es diesen Jail zur Laufzeit nicht gibt. Entweder fehlt enabled = true, oder du hast dich beim Namen vertippt, oder ein Syntaxfehler weiter oben in jail.local hat den Abschnitt verschluckt. Welche Jails wirklich laufen, zeigt fail2ban-client status. Was fail2ban aus allen Dateien zusammengesetzt hat, zeigt der Konfigurationsabzug:

fail2ban-client -d

Error banning und iptables not found

Der Jail zählt korrekt, aber die Sperre scheitert an der Aktion. Typisch auf schlanken Debian-12-Installationen, auf denen nur nftables vorhanden ist, während die Vorgabe iptables-multiport lautet. Entweder apt install -y iptables nachziehen oder in jail.local auf banaction = nftables wechseln. Der zweite Weg ist der, den Debian 13 und Ubuntu 24.04 ohnehin von sich aus gehen.

Wenn nichts mehr hilft: der geordnete Rückbau

Weil alle Anpassungen in jail.local stehen, ist der Weg zurück kurz. Datei zur Seite legen, Dienst neu starten, und du bist wieder bei den Paketvorgaben:

mv /etc/fail2ban/jail.local /root/jail.local.bak
systemctl restart fail2ban
fail2ban-client status

Läuft es damit, liegt der Fehler in deiner Konfiguration, und du fügst die Blöcke einzeln wieder ein. Läuft es auch damit nicht, liegt es an der Umgebung, also an der fehlenden Logquelle oder am fehlenden Firewall-Werkzeug. Genau deshalb gehört jail.conf unberührt: dieser Rückbau in zehn Sekunden ist nur möglich, solange die Paketdatei im Auslieferungszustand ist.

Zum Schluss die Einordnung. fail2ban reduziert Lograuschen und stoppt langsame, wiederholte Anmeldeversuche. Ein ernsthafter Angriff aus einem großen Botnetz nutzt jede Adresse nur einmal und läuft an jeder Ratenbegrenzung vorbei. Der wirksamere Schritt gegen Brute Force auf SSH bleibt die Abschaltung der Passwortanmeldung zugunsten von Schlüsseln. Und gegen volumetrische Angriffe hilft ohnehin nur Filterung im Netz, bei uns über 3,2 Tbps Arbor-Echtzeitfilterung direkt im Rechenzentrum in Frankfurt am Main und bis zu 17 Tbps globale Filterkapazität in den Professional-Tarifen. fail2ban ist die Schicht darunter, auf dem Host, und dort erfüllt es seine Aufgabe zuverlässig, sobald die drei Dinge stimmen: die richtige Logquelle, die richtige Firewall-Aktion und eine jail.local, die du im Zweifel in einem Zug wieder entfernen kannst.