fail2ban: Angreifer nach wenigen Fehlversuchen aussperren
Ein öffentlicher Server wird ständig angeklopft. fail2ban liest die Logs mit, erkennt Muster wie „Failed password“ oder „Invalid user“ und sperrt die Absender-IP für eine Weile in der Firewall. Der Angreifer kommt dann nicht mehr an den Dienst heran, nicht einmal für weitere Versuche.
Bausteine
| Begriff | Bedeutung |
|---|
| Filter | Regulärer Ausdruck, der eine Logzeile als Fehlversuch erkennt (/etc/fail2ban/filter.d/) |
| Jail | Ein Filter plus Regeln für einen Dienst, z. B. sshd |
| maxretry / findtime | Wie viele Fehlversuche in welcher Zeit zur Sperre führen |
| bantime | Wie lange die Sperre dauert |
| ignoreip | Adressen, die nie gesperrt werden (eigenes Netz) |
Installation und Konfiguration
apt install fail2ban
Eigene Einstellungen gehören nicht in jail.conf, denn die wird bei Updates überschrieben. Stattdessen eine Datei in /etc/fail2ban/jail.d/:
# /etc/fail2ban/jail.d/sshd.local
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24
[sshd]
enabled = true
backend = systemd
mode = aggressive
maxretry = 4
findtime = 10m
bantime = 1h
bantime.increment = true
bantime.factor = 4
bantime.maxtime = 4w
- 4 Fehlversuche in 10 Minuten → 1 Stunde Sperre.
backend = systemd: Moderne Debian-Systeme haben oft keine /var/log/auth.log mehr (kein rsyslog). fail2ban liest dann direkt das Journal.mode = aggressive zählt zusätzlich Verbindungen, die vor der Anmeldung abgebrochen werden (typisch bei Scannern).bantime.increment: Wiederholungstäter werden länger gesperrt, bis höchstens vier Wochen.
systemctl enable --now fail2ban
systemctl restart fail2ban # nach Änderungen an der Konfiguration
Bedienung im Alltag
fail2ban-client status # welche Jails laufen?
fail2ban-client status sshd # gesperrte IPs und Zähler
fail2ban-client set sshd unbanip 203.0.113.55 # eine IP wieder freigeben
journalctl -u fail2ban --since today # was hat fail2ban getan?
Direkt nach dem Start prüft fail2ban auch das bereits vorhandene Journal. Auf einem Server, der schon länger im Netz steht, sind deshalb sofort mehrere Adressen gesperrt, ohne dass neue Angriffe nötig waren.
Selbst ausgesperrt? Wer sich mehrfach mit falschem Schlüssel oder Passwort verbindet, sperrt die eigene IP. Deshalb ignoreip pflegen, und wer eine wechselnde Heim-IP hat, sollte einen Zugang über die Konsole des Hosters kennen (fail2ban-client set sshd unbanip …).
Grenzen von fail2ban
- Reaktiv: Die ersten Versuche kommen durch. Deshalb ersetzt fail2ban keine sichere Konfiguration. Mit reiner Schlüssel-Anmeldung sind die Versuche ohnehin wirkungslos, fail2ban reduziert dann vor allem Lärm und Last.
- Verteilte, langsame Angriffe (viele IPs, je ein Versuch) erkennt es nicht.
- Nur was im Log steht: Ein Dienst, der Fehlversuche nicht protokolliert, kann nicht geschützt werden.
- Docker: Veröffentlichte Container-Ports laufen an der normalen
INPUT-Kette vorbei durch die FORWARD-Kette. Die Standard-Sperren von fail2ban greifen dort nicht. Für Container-Dienste muss die Aktion auf die Kette DOCKER-USER zeigen (chain = DOCKER-USER).
- Falsche Sicherheit: Gesperrt wird eine IP, kein Mensch. Bei geteilten Adressen (Firmen-NAT, Mobilfunk) trifft es auch Unbeteiligte.
Erfolg messen
fail2ban-client status sshd | grep -E "Currently|Total" # aktuell gesperrt / insgesamt gesperrt
journalctl -u ssh --since "24 hours ago" | grep -c "Failed password\|Invalid user"
Ein Vorher/Nachher-Vergleich der Fehlversuche pro Tag zeigt schnell, ob die Sperren wirken.
fail2ban ist der Türsteher, die Schlüssel-Anmeldung das Schloss. Beides zusammen ist mehr als jedes für sich, aber das Schloss zuerst.