Fail2ban einrichten: SSH vor Brute-Force-Angriffen schützen

Fail2ban ist ein Dienst, der die Logs von Diensten überwacht, wiederholte fehlgeschlagene Anmeldeversuche bemerkt und die IP-Adresse, von der sie kommen, für eine bestimmte Zeit sperrt. Für SSH ist das der einfachste Schutz gegen das Raten von Passwörtern: Bots geben auf, nachdem sie einige Fehler gemacht haben. Im Folgenden finden Sie fail2ban einrichten von der Installation bis zur Kontrolle der Sperren und zu typischen Fehlern.

Warum fail2ban, wenn man SSH-Schlüssel hat?

Jeder Server mit offenem Port 22 bekommt schon wenige Minuten nach dem Start Anmeldeversuche von Bots. Überzeugen Sie sich selbst:

$ sudo journalctl -u ssh --since "1 hour ago" | grep -c "Failed password"
412

Ist die Anmeldung per Passwort deaktiviert und es werden nur Schlüssel verwendet, ist ein Zugriff praktisch nicht zu erraten. Trotzdem ist fail2ban nützlich: Es räumt die Logs auf, entlastet den Server von Tausenden Verbindungen und schützt vor Konfigurationsfehlern, wenn die Passwortanmeldung versehentlich aktiv geblieben ist. Das ist eine zweite Schutzschicht, kein Ersatz für Schlüssel.

Wie fail2ban arbeitet

Die Logik besteht aus drei Teilen:

• Filter — eine Sammlung regulärer Ausdrücke, die in einem Log Zeilen über einen fehlgeschlagenen Versuch finden und daraus die IP extrahieren. Die Filter liegen in /etc/fail2ban/filter.d/.
• Aktion (action) — was mit dem Störenfried geschieht: eine Regel in iptables, nftables, ufw oder firewalld anlegen. Die Aktionen liegen in /etc/fail2ban/action.d/.
• Gefängnis (jail) — die Verbindung aus Filter, Aktion, Logquelle und Schwellenwerten. Das Jail sshd überwacht zum Beispiel das SSH-Log.

Erreicht eine IP innerhalb von findtime die Zahl maxretry an Treffern, wird sie für bantime gesperrt. Nach Ablauf der Frist hebt fail2ban die Sperre automatisch auf.

Installation von fail2ban

Auf Debian und Ubuntu:

sudo apt update
sudo apt install fail2ban

Auf RHEL, Rocky, AlmaLinux ist das Paket im Repository EPEL enthalten:

sudo dnf install epel-release
sudo dnf install fail2ban

Aktivieren Sie den Autostart und prüfen Sie den Zustand des Dienstes:

sudo systemctl enable --now fail2ban
sudo systemctl status fail2ban

Unter Debian und Ubuntu ist das Jail für SSH bereits standardmäßig aktiv, über /etc/fail2ban/jail.d/defaults-debian.conf. In der RHEL-Familie ist nach der Installation nichts aktiviert — Jails müssen Sie von Hand einschalten.

Wo die Einstellungen liegen: jail.conf und jail.local

Die Hauptdatei ist /etc/fail2ban/jail.conf, bearbeiten sollten Sie sie aber nicht: Bei einem Paket-Update wird sie überschrieben. Eigene Einstellungen legen Sie in /etc/fail2ban/jail.local oder in einzelnen Dateien /etc/fail2ban/jail.d/*.local ab. fail2ban liest die Dateien in dieser Reihenfolge, und jede spätere überschreibt die vorherige:

1. jail.conf
2. jail.d/*.conf
3. jail.local
4. jail.d/*.local

Kopieren Sie nicht die gesamte jail.conf nach jail.local — damit frieren Sie alte Standardwerte ein. In jail.local schreiben Sie nur das, was Sie ändern.

fail2ban einrichten für SSH: minimale jail.local

Legen Sie die Datei an:

sudo nano /etc/fail2ban/jail.local

Und fügen Sie folgenden Inhalt ein:

[DEFAULT]
# Eigene Adressen, die niemals gesperrt werden
ignoreip = 127.0.0.1/8 ::1 203.0.113.10
bantime  = 1h
findtime = 10m
maxretry = 5
# Woher die Logs kommen: systemd-Journal oder Dateien
backend  = systemd

[sshd]
enabled  = true
port     = ssh
maxretry = 3

Starten Sie den Dienst neu und prüfen Sie, ob das Jail läuft:

$ sudo systemctl restart fail2ban
$ sudo fail2ban-client status
Status
|- Number of jail:      1
`- Jail list:   sshd

Bedeutung der Parameter

Zeitangaben dürfen Suffixe haben: s, m, h, d, w. Zahlen ohne Suffix gelten als Sekunden.

backend: systemd oder Datei

Auf modernen Systemen wie Debian 12 und Ubuntu 24.04 gibt es die Datei /var/log/auth.log möglicherweise nicht, wenn rsyslog nicht installiert ist: Die SSH-Logs liegen dann nur im systemd-Journal. In dem Fall brauchen Sie backend = systemd, sonst startet fail2ban mit einem Fehler, dass keine Logdatei gefunden wurde. Ist rsyslog vorhanden, können Sie die Variante mit Datei verwenden:

[sshd]
enabled  = true
backend  = auto
logpath  = /var/log/auth.log

Auf RHEL-Systemen lautet die entsprechende Datei /var/log/secure.

SSH auf einem nicht standardmäßigen Port

Lauscht sshd etwa auf Port 2222, tragen Sie ihn im Jail ein — sonst sperrt fail2ban Port 22, und der Angriff geht auf 2222 weiter:

[sshd]
enabled = true
port    = 2222

Um einen Störenfried auf allen Ports zugleich zu sperren, verwenden Sie über den Parameter banaction die Aktion iptables-allports oder nftables-allports.

Wahl der Firewall: iptables, nftables, ufw, firewalld

Standardmäßig nutzt Debian banaction = nftables (in älteren Versionen iptables), RHEL nutzt firewalld. Ist auf dem Server ufw eingerichtet, ist es praktischer, dass die Sperren dort sichtbar sind:

[DEFAULT]
banaction = ufw

Für firewalld:

[DEFAULT]
banaction = firewallcmd-rich-rules

Ob die Regeln tatsächlich angelegt wurden, prüfen Sie mit sudo nft list ruleset | grep f2b oder sudo iptables -L -n | grep f2b: fail2ban legt Ketten mit dem Präfix f2b- an.

Wie Sie die Funktion prüfen: fail2ban-client status

Das wichtigste Werkzeug zur Verwaltung ist fail2ban-client. Den Status eines bestimmten Jails zeigen Sie so:

$ sudo fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed: 2
|  |- Total failed:     147
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 4
   |- Total banned:     38
   `- Banned IP list:   45.148.10.12 92.118.39.7 185.224.128.40 218.92.0.112

Hier sehen Sie, wie viele Fehler gerade im Zeitfenster liegen, wie viele IPs gesperrt sind und welche das genau sind. Um den Schutz praktisch zu testen, versuchen Sie es mehrmals von einem anderen Rechner aus (nicht von einem, der in ignoreip steht) mit einem falschen Passwort — nach dem dritten Versuch kommt keine Verbindung mehr zustande.

Das Log von fail2ban selbst liegt in /var/log/fail2ban.log:

$ sudo tail -n 3 /var/log/fail2ban.log
2026-10-14 09:12:41,118 fail2ban.filter  [812]: INFO    [sshd] Found 218.92.0.112
2026-10-14 09:12:44,302 fail2ban.filter  [812]: INFO    [sshd] Found 218.92.0.112
2026-10-14 09:12:47,551 fail2ban.actions [812]: NOTICE  [sshd] Ban 218.92.0.112

Wie Sie eine IP in fail2ban entsperren

Haben Sie sich selbst oder einen Kollegen ausgesperrt, heben Sie die Sperre über die Konsole des Servers auf (über das Panel des Hosters oder von einer anderen IP aus):

sudo fail2ban-client set sshd unbanip 203.0.113.25

Alle Sperren in allen Jails aufheben:

sudo fail2ban-client unban --all

Eine Adresse von Hand sperren, ohne auf den Filter zu warten:

sudo fail2ban-client set sshd banip 198.51.100.7

Damit sich der Vorfall nicht wiederholt, tragen Sie feste Adressen oder das Büronetz in ignoreip ein.

Wachsende Sperre für Wiederholungstäter

Viele Bots kommen direkt nach einer Entsperrung zurück. Seit Version 0.11 kann fail2ban die Sperrdauer für Wiederholungstäter verlängern:

[DEFAULT]
bantime = 1h
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 4w

Jede weitere Sperre derselben IP dauert länger als die vorherige, aber höchstens vier Wochen. Eine Alternative für ältere Versionen ist das Jail recidive. Es liest das Log von fail2ban selbst und sperrt Adressen, die mehrfach aufgefallen sind, für längere Zeit:

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 5

Filter prüfen: fail2ban-regex

Läuft das Jail, sperrt aber niemanden, prüfen Sie, ob der Filter im Log überhaupt Zeilen findet. Für ein Dateilog:

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

Für das systemd-Journal:

sudo fail2ban-regex systemd-journal sshd

In der Ausgabe achten Sie auf die Zeile Lines: ... matched. Null Treffer bedeutet, dass der Filter nicht zum Format der Logs passt oder die falsche Quelle angegeben ist. Vor einem Neustart lohnt sich außerdem eine Syntaxprüfung der gesamten Konfiguration:

sudo fail2ban-client -t

Typische Fehler

• Dienst startet nicht: „Have not found any log file for sshd jail“. Es gibt kein /var/log/auth.log. Setzen Sie backend = systemd oder installieren Sie rsyslog.
• Sperren stehen im Status, der Angriff geht aber weiter. Der Port ist falsch (SSH wurde verlegt), oder eine frühere erlaubende Firewall-Regel überlagert die Sperre. Prüfen Sie port und die Ausgabe von nft list ruleset.
• Änderungen wirken nicht. Sie haben jail.conf bearbeitet, in jail.local oder jail.d/*.local steht aber ein anderer Wert. Prüfen Sie den tatsächlichen Wert: sudo fail2ban-client get sshd maxretry.
• Sie haben sich selbst gesperrt. Heben Sie die Sperre über die Konsole auf und tragen Sie Ihre IP in ignoreip ein.
• fail2ban sieht in Docker keine Angriffe. Veröffentlichte Container-Ports laufen über die Kette DOCKER, die INPUT umgeht. Für solche Dienste verwenden Sie in der Aktion chain = DOCKER-USER.

Was Sie sonst noch für den SSH-Schutz tun sollten

fail2ban funktioniert am besten zusammen mit grundlegenden Maßnahmen in /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin no
MaxAuthTries 3

Nach der Änderung prüfen Sie die Konfiguration mit sudo sshd -t und starten den Dienst neu. Schließen Sie Ihre aktuelle Sitzung erst, wenn die Anmeldung mit Schlüssel in einer neuen Sitzung funktioniert. Zusätzlich können Sie den Zugang zu SSH auf Firewall-Ebene auf die nötigen Adressen beschränken.

Fazit

fail2ban einrichten besteht aus wenigen Schritten: Paket installieren, jail.local mit dem Abschnitt [sshd] anlegen, das richtige Backend und den richtigen Port wählen, maxretry, findtime und bantime festlegen, eigene Adressen in ignoreip eintragen und mit fail2ban-client status sshd die Funktion prüfen. Zusammen mit der Anmeldung nur per Schlüssel schützt das SSH zuverlässig vor dem Raten von Passwörtern. Der Schutz eines Servers und der Einsatz von fail2ban werden im Kurs zu Linux praxisnah behandelt.