Zum Inhalt springen
Serverküche
Suche

Die Suche wird geladen … (nur in der veröffentlichten Seite verfügbar).

Sicherheit Schwierigkeit: Fortgeschritten

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.

· 6 Min. Lesezeit ·Dauer: ca. 40 Minuten
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

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 bantime blockt.

Kurz: Filter erkennt Fehlversuche → Jail zählt sie → Action sperrt. Alles, was du unten konfigurierst, ist eine dieser drei Stellschrauben.

Schritt 1: Fail2ban installieren

Terminal
sudo apt update
sudo apt install -y fail2ban

Prüfe die Version:

Terminal
fail2ban-client --version
Ausgabe
Fail2Ban v1.1.0

Schritt 2: Eigene Konfiguration in jail.local

Nie jail.conf bearbeiten

Die mitgelieferte /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:

Terminal
sudo nano /etc/fail2ban/jail.local
INI
[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 = true

Zeile 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

Setze deine eigene IP in 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

Auf Debian 13 nutzt Fail2ban standardmäßig das systemd-Journal als Quelle – du musst keinen 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

Terminal
sudo systemctl enable --now fail2ban

enable --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:

Terminal
sudo systemctl status fail2ban

Du 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:

Terminal
sudo fail2ban-client status
Ausgabe
Status
|- Number of jail:	1
`- Jail list:	sshd

Und die Details des SSH-Jails:

Terminal
sudo fail2ban-client status sshd
Ausgabe
Status 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):

Terminal
sudo fail2ban-client set sshd unbanip 203.0.113.45

Eine IP sofort sperren:

Terminal
sudo fail2ban-client set sshd banip 203.0.113.45

Gegen besonders hartnäckige Angreifer lohnt sich eskalierende Sperrzeit: Wer wiederkommt, wird länger gesperrt. Ergänze im [DEFAULT]-Block:

INI
bantime.increment = true
bantime.maxtime = 1w

Damit 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 sshd zeigt 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.local sichern: 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

Erste Schritte mit einem netcup VPS
Grundlagen Einsteiger

Erste Schritte mit einem netcup VPS

Vom bestellten Server zum einsatzbereiten System: SSH-Login, Updates, ein sudo-Benutzer und die wichtigsten Handgriffe …

· 4 Min. Lesezeit