Fail2ban einrichten: Brute-Force-Angriffe automatisch blocken

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.me von 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 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

sudo apt update
sudo apt install -y fail2ban

Prüfe die Version:

fail2ban-client --version

Fail2Ban v1.1.0

Schritt 2: Eigene Konfiguration in jail.local

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 = 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"). Auf Debian ist es über defaults-debian.conf ohnehin schon an; explizit in der eigenen Datei zu stehen schadet nicht und macht sichtbar, was läuft.

Schritt 3: Konfiguration übernehmen

Prüfe zuerst, ob die Datei syntaktisch stimmt – das erspart dir einen Dienst, der nach dem Reload nicht mehr hochkommt:

sudo fail2ban-client -t

OK: configuration test is successful

Jetzt die neue Konfiguration übernehmen:

sudo systemctl reload fail2ban

Der Reload ist der entscheidende Schritt. Der Dienst läuft ja schon seit der Installation – ein systemctl start (oder enable --now) macht bei einem laufenden Dienst gar nichts, deine jail.local bliebe unbeachtet und es gälten weiter Debians Standardwerte. Nach jeder Änderung an jail.local also erneut reload.

Dass Fail2ban nach einem Reboot von selbst wieder startet, hat das Paket schon eingerichtet – nachsehen kostet nichts:

systemctl is-enabled fail2ban

enabled

Kommt hier disabled, hol es mit sudo systemctl enable --now fail2ban nach. Und der Blick auf den Dienst selbst:

sudo systemctl status fail2ban

Du solltest active (running) sehen.

Schritt 4: Status prüfen

So siehst du, welche Jails aktiv sind:

sudo fail2ban-client status

Status
|- Number of jail:	1
`- Jail list:	sshd

Und die Details des SSH-Jails:

sudo fail2ban-client status sshd

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 – und das summiert sich: Auf unserem Testserver zählte Fail2ban in elf Tagen Laufzeit 9.494 Fehlversuche und 481 Sperren – rund 860 Anmeldeversuche und 44 Bans pro Tag, ohne dass wir irgendetwas dafür tun mussten.

Ob wirklich deine Werte gelten und nicht mehr Debians Standard, fragst du direkt ab:

sudo fail2ban-client get sshd bantime

3600

3600 Sekunden sind die Stunde aus deiner jail.local. Steht hier noch 600, hat der Reload aus Schritt 3 gefehlt – dann läuft Fail2ban weiter mit den Standardwerten.

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.45

Eine IP sofort sperren:

sudo fail2ban-client set sshd banip 203.0.113.45

Beide Befehle antworten mit der Zahl der IPs, die sie tatsächlich angefasst haben:

1

Kommt eine 0 zurück, ist nichts passiert – beim Entsperren heißt das meist, dass die IP gar nicht gesperrt war (Tippfehler in der Adresse).

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

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. Dass die Eskalation wirklich aktiv ist, bestätigt dir – wie in Schritt 4 – eine direkte Abfrage:

sudo fail2ban-client get sshd bantime.increment

True

Wenn es nicht funktioniert

Wartung & Backups

• Sperren im Blick behalten: sudo fail2ban-client status sshd zeigt jederzeit, wie viele IPs aktuell gesperrt sind. Die Historie steht nicht im Journal, sondern in einer eigenen Datei – Fail2ban loggt laut logtarget in /etc/fail2ban/fail2ban.conf nach /var/log/fail2ban.log:

  Terminal

  sudo grep -E "Ban|Unban" /var/log/fail2ban.log | tail -5

  Ausgabe

  2026-08-16 01:36:52,583 fail2ban.actions        [326875]: NOTICE  [sshd] Ban 203.0.113.45

  journalctl -u fail2ban zeigt dagegen nur Start, Reload und Fehler des Dienstes.

• 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.

• Nächster Schritt CrowdSec: Fail2ban schützt deinen Host anhand deiner Logs. Der moderne Nachfolger CrowdSec ergänzt das um eine kollaborative Angriffsabwehr (geteilte Blocklisten) und wertet die Zugriffs-Logs deines Reverse Proxy aus – sinnvoll, sobald Web-Apps dazukommen. 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.