fail2ban erklärt — Brute-Force-Schutz für SSH und Webserver

Direkte Antwort: fail2ban beobachtet Logfiles auf fehlgeschlagene Login-Versuche und sperrt aufdringliche IPs automatisch via Firewall-Regel. Auf einem OpenClaw-Server schützt es vor allem SSH, kann aber auch nginx, Postfix oder andere Dienste absichern.

Was ist fail2ban?

fail2ban ist ein klassisches Linux-Sicherheits-Tool, das automatisch IPs blockt, von denen wiederholt fehlgeschlagene Login-Versuche kommen. Es überwacht Logfiles, erkennt Muster (z.B. "X fehlgeschlagene SSH-Logins in Y Sekunden") und schreibt eine Firewall-Regel, die diese IP für eine definierte Zeit aussperrt.

Auf einem öffentlich erreichbaren Server (z.B. einem Hetzner-VPS, auf dem dein OpenClaw-Agent läuft) ist fail2ban ein Muss. Innerhalb von Minuten nach Inbetriebnahme treffen die ersten Brute-Force-Versuche aus aller Welt ein.

Kontext

Brute-Force-Attacken auf SSH sind keine theoretische Bedrohung. Wer ein frisches VPS aufsetzt und nichts macht, sieht in den Logs schon nach 30 Minuten dutzende Login-Versuche aus China, Russland und Vietnam. Ohne Schutz ist es eine Frage der Zeit, bis ein schwaches Passwort geknackt wird.

fail2ban ist die einfachste, schnellste und stabilste Antwort darauf. Es ist seit 2004 verfügbar, sehr gut getestet und auf jeder Distribution ein Apt/Dnf-Paket entfernt.

Funktionsweise

fail2ban arbeitet in drei Komponenten:

1. Filter: Regex-Muster, die fehlgeschlagene Logins in Logfiles erkennen
2. Jail: Eine Konfiguration, die einen Filter mit Aktion und Limits verbindet
3. Action: Was passieren soll bei Treffer (typisch: IP via iptables/nftables blocken)

Standard-Verhalten:

• 3 fehlgeschlagene SSH-Logins in 10 Minuten -> IP für 10 Minuten gesperrt
• Bei wiederholtem Vorfall -> längere Sperre

Praxis-Beispiel

Installation auf Ubuntu/Debian:

sudo apt update
sudo apt install fail2ban
sudo systemctl enable --now fail2ban

Konfiguration: Erstelle eine lokale Override-Datei (Original nicht editieren):

sudo nano /etc/fail2ban/jail.local

Inhalt:

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 3
backend = systemd
ignoreip = 127.0.0.1/8 ::1

[sshd]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 24h

Aktivieren:

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Beispiel-Output von fail2ban-client status sshd:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     127
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 4
   |- Total banned:     38
   `- Banned IP list:   45.146.165.x 121.227.31.x 45.95.169.x ...

Erweiterte Jails

fail2ban kann mehr als SSH:

[nginx-http-auth]
enabled = true
filter = nginx-http-auth
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 3

[postfix]
enabled = true
filter = postfix
logpath = /var/log/mail.log
maxretry = 5

Praxis-Setup für OpenClaw-Server:

• SSH (auf Port 22 oder Custom-Port)
• nginx (falls du eine Web-UI hostest)
• Webhook-Endpoint (eigener Filter für deine API)

fail2ban + UFW

UFW und fail2ban beißen sich nicht — sie ergänzen sich. UFW ist die statische Firewall (welche Ports sind offen?), fail2ban die dynamische Reaktion (welche IPs sind aktuell zu aggressiv?). Beide sollten gleichzeitig laufen.

| Aspekt | UFW | fail2ban | | --- | --- | --- | | Zweck | Statische Port-Regeln | Dynamische IP-Bans | | Konfiguration | Selten geändert | Reagiert kontinuierlich | | Schutz vor | Unerwünschten Ports | Brute-Force-Attacken |

Häufige Fehler / Stolperfallen

1. Eigene IP nicht gewhitelistet: Wenn du dich aus Versehen 5x falsch einloggst, sperrst du dich selbst aus. Setze deine eigene IP in ignoreip. Lockout-Recovery: Über das Hetzner Web-Console-Feature einloggen.
2. Logpath falsch: Auf systemd-Systemen liegt SSH-Log meist im Journal, nicht in /var/log/auth.log. Dann backend = systemd setzen.
3. bantime zu kurz: 10 Minuten reichen oft nicht — Bots versuchen es einfach später nochmal. Stunden oder Tage sind sinnvoller.
4. maxretry zu hoch: "10 Versuche erlauben" lädt Bots ein. 3 reicht für Menschen aus, Bots werden schnell rausgekickt.
5. Nicht testen: Nach Setup einmal absichtlich falsch einloggen und prüfen, ob Ban greift. sudo fail2ban-client status sshd zeigt's.

fail2ban + SSH-Key statt Passwort

Die wirkungsvollste Maßnahme bleibt: Passwort-Auth komplett deaktivieren und nur SSH-Keys erlauben. Damit nutzen Brute-Force-Versuche nichts mehr, fail2ban hält trotzdem die Logs sauber:

# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no

Manuell IPs unbannen

Falls du eine IP manuell entsperren willst:

sudo fail2ban-client set sshd unbanip 1.2.3.4

Oder eine IP explizit bannen:

sudo fail2ban-client set sshd banip 1.2.3.4

fail2ban-Logs prüfen

Logs gehen ins systemd-Journal:

sudo journalctl -u fail2ban -f
sudo journalctl -u fail2ban --since "24 hours ago"

Beispiel-Eintrag bei einem Ban:

fail2ban.actions: WARNING [sshd] Ban 45.146.165.x

fail2ban + Tailscale

Wenn du Tailscale nutzt, ist fail2ban für SSH meist überflüssig — denn dein SSH ist gar nicht mehr öffentlich erreichbar. fail2ban macht aber weiterhin Sinn für andere öffentliche Services (nginx-Auth, Webhooks).

Performance-Aspekt

fail2ban liest Logfiles permanent. Auf großen Servern mit viel Traffic kann das CPU kosten. Lösung: backend = systemd statt polling, das ist effizienter weil event-getrieben statt File-Polling.

Verwandte Begriffe

• UFW (Uncomplicated Firewall)
• systemd
• Tailscale
• Webhook

Vollständiges Server-Hardening: Modul 2 der Masterclass und Modul 6.