Fail2ban: klassisches Log-basiertes IP-Banning für Linux-Server

Was ist Fail2ban?

Fail2ban ist ein Python-basiertes Intrusion-Prevention-Framework, das seit 2004 unter GPL-2-Lizenz von Cyril Jaquier und einer Maintainer-Community entwickelt wird. Es ist das klassischste Werkzeug seiner Kategorie -- in fast jedem Linux-Server-Hardening-Tutorial der letzten zwei Jahrzehnte als Standard-Empfehlung geführt, in Debian/Ubuntu/CentOS-Repos enthalten, mit minimaler Lernkurve.

Das Konzept ist einfach: Fail2ban liest in Echtzeit Log-Dateien (typisch /var/log/auth.log, /var/log/nginx/error.log, /var/log/fail2ban.log), matched Zeilen gegen Regex-Patterns in INI-Konfigurationsdateien (sogenannte Filter), und triggert bei Schwellenwert-Überschreitung eine Action (typisch eine iptables-DROP-Regel). Die Standard-Aktion blockiert die angreifende IP für eine konfigurierte Dauer (default 10 Minuten, oft auf 1 bis 4 Stunden hochgezogen).

Im Mai 2026 ist Fail2ban in der stabilen Version 1.x verfügbar, mit aktiver Maintainer-Community und regelmässigen Patches. Es läuft als systemd-Service (fail2ban.service), konsumiert minimal Ressourcen (etwa 30-50 MB RAM, kaum CPU im Leerlauf), und braucht keine externe Datenverbindung -- alles läuft lokal. Genau das macht Fail2ban zum Default für compliance-strenge oder Mini-VPS-Setups, in denen CrowdSec überdimensioniert oder regulatorisch problematisch wäre.

Die Konfigurationsstruktur ist klar: jails.local definiert pro Service ein Jail (sshd, nginx-http-auth, postfix-sasl) mit Pfad zur Log-Datei, Filter-Name, maxretry-Schwelle, bantime und findtime. Filter-Dateien in /etc/fail2ban/filter.d/ enthalten die Regex-Patterns. Action-Dateien in /etc/fail2ban/action.d/ definieren die Block-Befehle (iptables-multiport, nftables-multiport, ufw, route-block). Mit fail2ban-client status und fail2ban-client status sshd lassen sich aktive Sperren und Statistiken prüfen.

CrowdSec ist der konzeptionelle Nachfolger seit 2020 -- mit kollaborativer Blocklist und klarer Agent-Bouncer-Trennung. Fail2ban bleibt aber 2026 produktiv wertvoll für Setups, in denen Einfachheit, lokale Verarbeitung und minimaler Footprint Priorität haben.

Warum Fail2ban für CH-KMU und Treuhand relevant bleibt

Trotz CrowdSec-Dominanz bei Neuinstallationen bleibt Fail2ban Mai 2026 in drei Szenarien die richtige Wahl.

Compliance-strenge Offline-Setups: FINMA-Hochrisiko-Mandate, bestimmte Anwaltskanzlei-Konstellationen mit absolutem Berufsgeheimnis nach StGB Art. 321, oder Banken-Treuhand mit strikter Datenraum-Pflicht können keine externe Telemetrie zulassen -- auch nicht anonymisierte. Fail2ban läuft komplett offline, ohne API-Calls, ohne Cloud-Console. Das macht es zur richtigen Wahl, wenn die Compliance-Schicht keinen Crowdsource-Vorteil opfern darf.

Mini-VPS und Edge-Setups: Ein 512-MB-RAM-VPS bei einem Schweizer Hoster (Cyon, Hostpoint Cloud, Infomaniak Minimal-Tier) verkraftet die 30-50 MB von Fail2ban problemlos, während CrowdSec mit AI-Bouncer schon 250 MB beansprucht. Für Solo-Selbständige Treuhänder, die einen kleinen Mandantenportal-Server auf einem solchen Setup betreiben, ist Fail2ban die pragmatische Wahl.

Legacy-Hardening bestehender Server: Wer einen alten Ubuntu 20.04 oder Debian 11 Server übernimmt, der bereits Fail2ban konfiguriert hat, muss nicht zwingend migrieren. Ein gut konfigurierter Fail2ban-Stack mit sshd, nginx-http-auth, postfix-sasl und recidive-Jail (lebenslange Sperre nach mehreren Sperr-Zyklen) blockiert 80-90 Prozent der automatisierten Angriffe -- das reicht in Kombination mit UFW, Public-Key-SSH und 2FA für den revFADP-Mindeststandard.

Die regulatorische Bewertung ist eindeutig: Art. 8 revFADP verlangt Schutzmassnahmen nach dem Stand der Technik -- und Fail2ban gilt 2026 weiterhin als Stand der Technik für Brute-Force-Schutz, auch wenn es nicht mehr der modernste Vertreter ist. Der EDÖB-Leitfaden führt Fail2ban und CrowdSec gleichrangig als Beispiele für Intrusion-Detection-Tooling. Cyber-Versicherungen akzeptieren Fail2ban als Pflicht-Massnahme.

Konfiguration und Beispiel-Setup

Fail2ban-Konfiguration läuft über drei Dateien-Ebenen. /etc/fail2ban/jail.conf liefert die Default-Werte (nicht ändern). /etc/fail2ban/jail.local überschreibt Defaults (eigene Anpassungen). /etc/fail2ban/jail.d/*.conf fügt servicespezifische Jails hinzu.

Ein produktives jail.local-Setup für ein CH-KMU-Server-Setup:

```ini [DEFAULT] bantime = 4h findtime = 10m maxretry = 5 banaction = nftables-multiport ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24 10.0.0.0/8 destemail = security@treuhand-müller.ch sender = fail2ban@treuhand-müller.ch action = %(action_mwl)s

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

[nginx-http-auth] enabled = true logpath = /var/log/nginx/error.log maxretry = 5

[postfix-sasl] enabled = true logpath = /var/log/mail.log maxretry = 3

[recidive] enabled = true logpath = /var/log/fail2ban.log bantime = 1w findtime = 1d maxretry = 5 ```

Der recidive-Jail ist der wichtigste Trick: er liest die Fail2ban-eigenen Logs und sperrt IPs, die innert eines Tages 5 Mal bereits gebannt wurden, für eine ganze Woche. Das bekämpft persistente Angreifer, die mit Re-IP-Tricks immer wieder die maxretry-Schwelle zurücksetzen.

Filter-Datei /etc/fail2ban/filter.d/nginx-http-auth.conf enthält typisch: ``` [Definition] failregex = ^ \[error\] \d+#\d+: \*\d+ user "(?:[^"]+|.*?)":? (?:password mismatch|was not found in ".*"), client: <HOST>, server: \S+, request: "\S+ \S+ HTTP/\d+\.\d+", host: "\S+"$ ```

Die Action nftables-multiport ist Mai 2026 die empfohlene Wahl für moderne Linux-Distributionen (nftables ist der Kernel-Nachfolger von iptables). Auf älteren Systemen iptables-multiport. UFW-Integration via ufw-Action möglich, aber langsamer im Block.

Wichtige fail2ban-client-Befehle: fail2ban-client status zeigt aktive Jails. fail2ban-client status sshd zeigt aktuelle Sperren im sshd-Jail. fail2ban-client set sshd unbanip <ip> entsperrt manuell. fail2ban-client reload nach jail.local-Änderung. fail2ban-client get sshd findtime zeigt aktuellen Wert.

Für Loki/Grafana-Integration: Fail2ban-Logs nach /var/log/fail2ban.log; promtail-Collector lesen, Dashboard mit Bans pro Stunde, Top-Angreifer-IPs, Jail-Verteilung. Telegram-Alert auf BAN-Lines via simpler bash-Pipe.

Fail2ban-Setup in 5 Schritten

1. 01Installation: apt install fail2ban; systemctl enable --now fail2ban; status prüfen mit systemctl status fail2ban.
2. 02Basis-Konfiguration: /etc/fail2ban/jail.local mit bantime 4h, findtime 10m, maxretry 5, banaction nftables-multiport, ignoreip-Whitelist für eigene IPs.
3. 03Service-Jails aktivieren: sshd, nginx-http-auth, postfix-sasl je nach Stack; pro Jail enabled=true und logpath setzen.
4. 04Recidive-Jail aktivieren: persistente Angreifer mit bantime=1w nach 5 Sperren in 1 Tag; verhindert Re-IP-Bypass.
5. 05Monitoring: fail2ban-client status tägliche Routine; Loki/Grafana-Dashboard für Trend; Telegram-Alert bei recidive-BAN; monatlich Filter-Updates per apt einspielen.

Wann Fail2ban die richtige Wahl ist

Mai 2026 ist Fail2ban die richtige Wahl in vier konkreten Konstellationen.

Single-Service-Setup auf Mini-VPS: Ein Solo-Treuhand mit einem einzigen Server (Nextcloud plus Bitwarden), 1-2 GB RAM, der nicht in ein Multi-Server-Threat-Sharing investieren will. Fail2ban deckt sshd, nginx-http-auth und das eigene Web-Auth ab; die fehlende Crowd-Blocklist ist verschmerzbar, weil Cloudflare WAF die Layer-7-Vorfilterung übernehmen kann.

Compliance-strenge Offline-Pflicht: Anwaltskanzlei mit Berufsgeheimnis nach StGB Art. 321, die jede ausgehende Verbindung von Produktivservern verbieten muss. Fail2ban läuft komplett offline, ohne Telemetrie. Kombination mit Loki/Grafana für Audit-Trail, mit Wazuh für SIEM-Schicht.

Legacy-Server mit existierender Konfiguration: Übernahme eines bestehenden Linux-Servers (Debian 11, Ubuntu 20.04) mit funktionierender Fail2ban-Konfiguration. Re-Konfiguration auf CrowdSec verursacht 4-8 Stunden Aufwand und ein Test-Window, das im laufenden Betrieb teuer ist. Fail2ban weiterlaufen lassen, monatlich Updates prüfen, recidive-Jail aktivieren falls noch nicht vorhanden.

Lehr-Setups und Sandbox-Umgebungen: Schulungs-VMs für interne Mitarbeiter-Hardening-Schulungen. Fail2ban hat eine niedrigere Lernkurve und transparente Regex-Filter, die in einer Schulung erklärbar sind. CrowdSec-Acquis und YAML-Scenarios sind mächtiger, aber konzeptuell anspruchsvoller.

Für alle anderen Mai-2026-Szenarien (Multi-Server-KMU, Online-Setup, neue Hetzner-Bereitstellung, Treuhand mit mehreren Mandanten-Apps): CrowdSec ist die bessere Wahl. Migration von Fail2ban zu CrowdSec ist gut dokumentiert -- parallel betreiben für 7 Tage, Logs vergleichen, dann Fail2ban entfernen.

Wann Fail2ban nicht reicht

Drei Fälle, in denen Fail2ban Mai 2026 unzureichend ist.

Multi-Server-Setups mit heterogenen Workloads: ein CH-KMU mit Webserver, Mail-Server, API-Server und Worker-Knoten -- 4-8 Maschinen -- braucht zwingend Threat-Sharing zwischen den Knoten. Wer den n8n-Server angreift, sollte sofort auf dem Webserver gesperrt sein. Fail2ban hat keinen Sync-Mechanismus. Custom-Lösungen mit zentralem Log-Aggregator und Push-Skripten sind möglich, aber fragil. CrowdSec liefert das ab-Werk via Console.

Moderne Angriffsmuster jenseits Brute-Force: Layer-7-Angriffe, die unter den maxretry-Schwellen bleiben (1 Request pro Minute, langsame Login-Versuche, verteilte Botnet-Angriffe über 10000 IPs), werden von Fail2ban nicht erkannt. Hier liefert nur ein WAF (ModSecurity, Cloudflare WAF) oder eine ML-basierte Erkennung (CrowdSec AI-Bouncer) Schutz.

ISO-27001- oder PCI-DSS-Compliance mit dokumentierter Threat-Intel-Pflicht: PCI-DSS v4.0 verlangt seit 2024 dokumentierte Threat-Intel-Quellen im SIEM. Fail2ban liefert nur lokale Erkennung; eine Threat-Intel-Schicht (CrowdSec Console, AlienVault OTX, MISP) muss ergänzt werden. Wer sowieso eine SIEM-Lösung wie Wazuh braucht, kann dort Threat-Intel-Feeds einbinden.

Generelle Fallen bei Fail2ban-Setups: (a) Default-bantime von 10 Minuten beibehalten -- viel zu kurz, sollte auf 4 Stunden bis 24 Stunden je nach Service hochgezogen werden. (b) recidive-Jail vergessen -- persistente Angreifer mit Re-IP umgehen einfache Sperren. (c) ignoreip-Whitelist für Office-VPN vergessen -- Selbst-Aussperrung droht. (d) Logrotate nicht beachten -- nach Log-Rotation bleibt Fail2ban manchmal auf der alten Datei hängen und sieht neue Einträge nicht.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Fail2ban -- official project page · 2026-05
2. Fail2ban GitHub -- v1.x release notes · 2026-04
3. EDÖB -- Technische und organisatorische Massnahmen · 2026-04
4. BSI IT-Grundschutz SYS.1.3 Server unter Linux · 2026-03
5. PCI-DSS v4.0 -- Threat Intelligence Requirements · 2026-02