Fail2ban einrichten: Brute-Force-Angriffe automatisch blocken
Fail2ban überwacht deine Logs und sperrt IPs nach zu vielen Fehlversuchen – mit sicherer Whitelist für die eigene Adresse, damit du dich nicht aussperrst.
Inhaltsverzeichnis
Sieh dir nach ein paar Tagen im Internet einmal journalctl -u ssh an: Hunderte
Login-Versuche von fremden IPs, im Sekundentakt. Solange dein SSH auf
Schlüssel-Login umgestellt ist, kommt davon keiner rein –
aber es rauscht im Log und frisst Ressourcen. Fail2ban liest diese Logs mit und
sperrt automatisch, wer es zu oft erfolglos probiert.
Was bauen wir?
Am Ende überwacht Fail2ban 1.1 auf deinem Debian 13 die SSH-Anmeldungen und sperrt nach zu vielen Fehlversuchen die angreifende IP für eine festgelegte Zeit – per Firewall-Regel. Deine eigene IP steht auf einer Whitelist, damit dich das nie selbst trifft. Du kannst Sperren einsehen, manuell setzen und wieder aufheben.
Voraussetzungen
- Ein abgesicherter Server (Schlüssel-Login) mit aktiver Firewall
- Deine eigene öffentliche IP – finde sie z. B. über
wieistmeineip.de oder
curl -s ifconfig.mevon deinem lokalen Rechner
Schritt für Schritt
Bevor wir konfigurieren, drei Begriffe, die das ganze Werkzeug erklären:
- Filter – ein Muster, das eine „fehlgeschlagene Anmeldung" im Log erkennt (für SSH bringt Fail2ban das fertig mit).
- Jail („Gefängnis") – verbindet einen Filter mit einer Log-Quelle und den
Regeln „wie oft in welchem Zeitraum". Das
sshd-Jail überwacht die SSH-Logins. - Action – was beim Überschreiten passiert: Standardmäßig eine Firewall-Regel,
die die IP für
bantimeblockt.
Kurz: Filter erkennt Fehlversuche → Jail zählt sie → Action sperrt. Alles, was du unten konfigurierst, ist eine dieser drei Stellschrauben.
Schritt 1: Fail2ban installieren
sudo apt update
sudo apt install -y fail2banPrüfe die Version:
fail2ban-client --versionFail2Ban v1.1.0Schritt 2: Eigene Konfiguration in jail.local
Nie jail.conf bearbeiten
/etc/fail2ban/jail.conf wird bei Updates überschrieben. Eigene
Einstellungen gehören immer in /etc/fail2ban/jail.local – diese Datei bleibt
erhalten und überschreibt die Standardwerte.Lege die Datei an:
sudo nano /etc/fail2ban/jail.local[DEFAULT]
# Wie lange gesperrt wird
bantime = 1h
# Zeitfenster, in dem die Fehlversuche zählen
findtime = 10m
# So viele Fehlversuche sind erlaubt, dann Ban
maxretry = 5
# Deine eigene(n) IP(s) – wird NIE gesperrt
ignoreip = 127.0.0.1/8 ::1 DEINE_EIGENE_IP
[sshd]
enabled = trueZeile für Zeile:
bantime = 1h– Sperrdauer. Für hartnäckige Fälle siehe die Eskalation in Schritt 5.findtime+maxretry– „5 Fehlversuche innerhalb von 10 Minuten → Ban".ignoreip– die wichtigste Zeile: Trage hier deine eigene IP ein, damit du dich nicht selbst aussperrst. Hast du eine wechselnde IP zu Hause, nutze besser den Zugang über einen festen Punkt (später VPN) statt einer weiten Freigabe.[sshd] enabled = true– aktiviert das SSH-Gefängnis („Jail").
Erst die eigene IP eintragen
ignoreip, bevor du Fail2ban startest – sonst kann dich
schon ein eigener Tippfehler beim Login aussperren. Die Adresse, von der du gerade
verbunden bist, zeigt dir das erste Feld von echo "$SSH_CLIENT".Debian 13 liest das systemd-Journal
logpath (etwa /var/log/auth.log) angeben. Die Datei existiert auf
modernen Systemen oft gar nicht mehr; das Journal ist die richtige Quelle und
funktioniert ohne Zusatzkonfiguration.Schritt 3: Dienst starten und aktivieren
sudo systemctl enable --now fail2banenable --now startet den Dienst sofort und sorgt dafür, dass er nach einem
Reboot automatisch wieder läuft. Prüfe, dass er sauber läuft:
sudo systemctl status fail2banDu solltest active (running) sehen. Nach jeder Änderung an jail.local lädst du
die Konfiguration mit sudo systemctl reload fail2ban neu.
Schritt 4: Status prüfen
So siehst du, welche Jails aktiv sind:
sudo fail2ban-client statusStatus
|- Number of jail: 1
`- Jail list: sshdUnd die Details des SSH-Jails:
sudo fail2ban-client status sshdStatus for the jail: sshd
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- Journal matches: _SYSTEMD_UNIT=ssh.service + _COMM=sshd
`- Actions
|- Currently banned: 0
|- Total banned: 0
`- Banned IP list:Die Zeile Journal matches bestätigt, dass Fail2ban das systemd-Journal liest.
Currently banned steigt, sobald jemand zu oft danebengreift.
Schritt 5: Sperren verwalten – und Bans eskalieren
Eine IP von Hand entsperren (z. B. wenn ein Kollege sich vertippt hat):
sudo fail2ban-client set sshd unbanip 203.0.113.45Eine IP sofort sperren:
sudo fail2ban-client set sshd banip 203.0.113.45Gegen besonders hartnäckige Angreifer lohnt sich eskalierende Sperrzeit: Wer
wiederkommt, wird länger gesperrt. Ergänze im [DEFAULT]-Block:
bantime.increment = true
bantime.maxtime = 1wDamit verdoppelt Fail2ban die Sperrzeit bei jedem erneuten Auffallen derselben IP –
bis maximal eine Woche. Nach der Änderung sudo systemctl reload fail2ban.
Wenn es nicht funktioniert
Symptom: Du hast dich selbst ausgesperrt.
Ursache & Lösung: ignoreip fehlte oder enthielt die falsche IP. Verbinde dich
über die Konsole im netcup SCP (unabhängig von SSH) und entsperre dich mit
sudo fail2ban-client set sshd unbanip DEINE_EIGENE_IP. Trage deine IP anschließend in
ignoreip ein und lade neu. Deshalb steht die Whitelist in Schritt 2 an erster Stelle.
Symptom: fail2ban.service startet nicht (systemctl status zeigt „failed").
Ursache & Lösung: Fast immer ein Tippfehler in jail.local. Prüfe die Syntax mit
sudo fail2ban-client -t (Testmodus) – der Befehl nennt die fehlerhafte Zeile.
Symptom: Es wird nie jemand gesperrt, obwohl das Log voller Fehlversuche ist.
Ursache & Lösung: Prüfe mit sudo fail2ban-client status sshd, ob Total failed
überhaupt steigt. Bleibt es bei 0, findet der Filter die Einträge nicht – meist, weil
eine veraltete Anleitung einen logpath auf eine nicht existierende Datei gesetzt
hat. Auf Debian 13 den logpath aus jail.local entfernen und das Journal nutzen
(Schritt 2).
Symptom: Sperren „wirken" nicht – die IP verbindet sich weiter.
Ursache & Lösung: Fail2ban trägt seine Blockregeln in dieselbe Firewall
(nftables/iptables) ein wie UFW. Prüfe mit sudo nft list ruleset | grep f2b (bzw.
sudo iptables -L -n | grep f2b), ob die f2b-Ketten existieren. Fehlen sie, hakt
das Zusammenspiel mit der Firewall – Dienst neu starten und Logs ansehen.
Wartung & Backups
- Sperren im Blick behalten:
sudo fail2ban-client status sshdzeigt jederzeit, wie viele IPs aktuell gesperrt sind. Ein Blick ins Journal (journalctl -u fail2ban) zeigt die Historie. - Weitere Jails: Sobald Dienste mit eigenem Login dazukommen (z. B. eine Web-App),
kannst du passende Jails aktivieren – nach demselben Muster wie
[sshd]. jail.localsichern: Deine Konfiguration ist schnell wiederhergestellt, gehört aber ins Backup deiner Server-Konfiguration.- Ausblick CrowdSec: Fail2ban schützt deinen Host anhand deiner Logs. Der moderne Nachfolger CrowdSec ergänzt das später um eine kollaborative Angriffsabwehr (geteilte Blocklisten) – wir bauen ihn in einem eigenen Rezept auf, sobald der Reverse Proxy steht. Für den Einstieg ist Fail2ban genau richtig.
Damit ist das Sicherheits-Fundament komplett: Schlüssel-Login, zwei Firewall-Ebenen (UFW + netcup-Firewall), automatische Updates und aktiver Brute-Force-Schutz. Dein Server ist jetzt nicht nur eingerichtet, sondern solide abgesichert.
Zuletzt aktualisiert: 19.07.2026
Feedback per E-Mail: feedback@serverkueche.de
Das könnte dir auch schmecken

Restic-Backups einrichten: verschlüsselt und off-site
Off-Site-Backups mit Restic: verschlüsselt einrichten, Snapshots wiederherstellen, mit Retention aufräumen und per …

Erste Schritte mit einem netcup VPS
Vom bestellten Server zum einsatzbereiten System: SSH-Login, Updates, ein sudo-Benutzer und die wichtigsten Handgriffe …

unattended-upgrades: automatische Sicherheitsupdates für Debian
Debian installiert Sicherheitsupdates automatisch: unattended-upgrades einrichten, den Neustart steuern und prüfen, dass …