Inhalt (6 Abschnitte)
Öffnen Sie einen SSH-Port zum Internet und sehen Sie sich die Logs an: Die Versuche kommen ununterbrochen, zu Tausenden, von Botnetzen, die in Endlosschleife Kombinationen aus Benutzername und Passwort durchprobieren. Fail2ban ist die klassische Antwort: Logs lesen, wiederholte Fehlschläge erkennen, die Quelladresse sperren. Fünf Minuten für die Installation, und genau das ist das Problem: Die meisten Installationen bleiben beim Tutorial stehen, mit einer SSH-Jail in der Standardkonfiguration, die mehr beruhigt als schützt. Hier sehen Sie, was eine Produktionskonfiguration ändert, einschließlich der selbst erlebten Fallstricke.
Fail2ban richtig einordnen #
Zunächst klar gesagt: Fail2ban ist ein Rauschunterdrücker, keine primäre Verteidigung. Akzeptiert Ihr SSH Passwörter, bremst Fail2ban die Angreifer; akzeptiert Ihr SSH nur Schlüssel (PasswordAuthentication no), ist Brute Force bereits erledigt: Fail2ban hält dann nur noch die Logs sauber und spart Ressourcen. Die Reihenfolge der Prioritäten lautet also: ausschließlich Schlüsselauthentifizierung, minimale Angriffsfläche (eine Firewall, die nur das Nötige öffnet, IP-Allowlists für die Administration) und danach Fail2ban für das verbleibende Rauschen. So sind unsere Frontend-Server aufgebaut: Die Firewall des Hypervisors lässt aus dem öffentlichen Netz nur HTTP/HTTPS durch, SSH läuft mit Schlüsseln, und Fail2ban räumt den Rest auf.
Die Basis, Stand 2026: journald, nicht auth.log #
Erster Fallstrick älterer Tutorials: sie richten Fail2ban auf /var/log/auth.log aus… das es auf modernen Systemen ohne rsyslog nicht mehr gibt, denn dort liegt alles im systemd-Journal. Eine Jail, die eine fehlende oder eingefrorene Datei liest, sperrt niemanden, und zwar ohne jede Meldung. Die Abhilfe: backend = systemd. Hier unsere Grundkonfiguration in jail.local, mit der zweiten Einstellung, die alles verändert, der progressiven Sperre:
# /etc/fail2ban/jail.local
[DEFAULT]
backend = systemd
banaction = nftables-multiport
# Progressive Sperre: Jeder Rückfall vervielfacht die Strafe.
bantime = 1h
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 1w
findtime = 10m
maxretry = 5
# IPs, die NIE gesperrt werden dürfen: Überwachung, Admin. Kurze, begründete Liste.
ignoreip = 127.0.0.1/8 ::1 <ip-supervision>
[sshd]
enabled = true
mode = aggressiveDie progressive Sperre macht auf Dauer den Unterschied: Ein gelegentlicher Scanner bekommt eine Stunde, ein Wiederholungstäter ist am Ende eine Woche gesperrt. Und prüfen Sie immer, ob eine Jail tatsächlich arbeitet: fail2ban-client status sshd muss steigende Trefferzahlen zeigen. Eine Jail, die auf einem exponierten Server seit Wochen bei null steht, ist eine kaputte Jail, kein verschonter Server.
Die nächste Stufe: HTTP-Jails hinter einem Reverse Proxy #
Brute Force zielt nicht nur auf SSH: Die Anmeldeseiten von Webanwendungen, API-Endpunkte und Administrationspfade bekommen denselben Verkehr ab. Fail2ban kann sie schützen, sofern es die Logs des Reverse Proxy (Traefik, nginx…) liest und dort Salven von 401/403 erkennt. Zwei nicht verhandelbare Bedingungen, beide aus eigener schmerzlicher Erfahrung gelernt:
- Die echte Client-IP sperren, nie die des Proxys. Liegt Ihre Anwendung hinter einem Reverse Proxy (oder schlimmer, macht Docker davor NAT), zeigen die Logs womöglich nur die interne IP des Proxys. Sperren Sie diese, kappen Sie den gesamten Verkehr. Die Kette muss die Quelladresse durchgehend erhalten; auf einem unserer Server mussten wir dafür den Proxy ins Host-Netzwerk verlegen, sonst erschienen alle IPv6-Besucher mit derselben internen IP des Docker-Gateways.
- Strukturierte Logs. Ein Access-Log im JSON-Format lässt sich ohne fragile Regex parsen: Der Fail2ban-Filter wird zu einer zuverlässigen Zeile statt zu einem Ausdruck, der beim ersten Formatwechsel bricht.
Die zwei Fallstricke, die teuer werden #
Der Unternehmens-Proxy: eine IP = Dutzende Menschen #
Im Produktivbetrieb erlebt: Salven verdächtiger Anfragen von einer einzigen IP, der Reflex, sie zu sperren… und es war ein Unternehmens-Proxy (etwa Zscaler): Hinter dieser Adresse saßen Dutzende legitimer Beschäftigter, darunter womöglich Ihr Kunde. Dasselbe gilt für externe Überwachungssensoren, deren Verhalten (regelmäßige Anfragen, wechselnde Ports) einem Scan zum Verwechseln ähnlich sieht. Bevor Sie eine „seltsame“ IP sperren: Ein whois dauert zehn Sekunden; Unternehmens-Proxys und Ihre Sensoren gehören in ignoreip, dokumentiert, mit dem Grund als Kommentar.
nftables: der Restart, der alles löscht #
Fail2ban schreibt seine Sperren in die Firewall (heute nftables). systemctl restart nftables löscht jedoch das komplette Ruleset, bevor die Datei neu geladen wird, und reißt dabei die dynamischen Tabellen von Fail2ban mit und, falls Docker läuft, auch dessen NAT-Regeln: Wir haben erlebt, wie ein harmloser Restart das DNS eines Containers im Produktivbetrieb lahmlegte. Um eine nftables-Konfiguration neu zu laden, verwenden Sie nft -f (atomar, additiv), niemals einen Restart des Dienstes auf einer Maschine mit Fail2ban oder Docker.
Fail2ban zeigt gut, wovon wir überzeugt sind: Sicherheit ist kein Produkt, das man installiert, sondern eine Reihe von Details, die man prüft. Genau das decken unsere Managed Services ab: Härtung, Überwachung der Jails und unveränderliche Backups für den Tag, an dem alles andere versagt hat. Zweifel, wie exponiert Ihre Server wirklich sind? Sprechen wir darüber.
