Wer einen Linux-Server betreibt, kennt die Logs: Hunderte oder tausende fehlgeschlagener SSH-Anmeldeversuche pro Tag, Brute-Force-Attacken auf Webformulare, Wörterbuch-Angriffe auf Mailkonten. Automatisierte Bots durchsuchen das gesamte IPv4-Adressraum rund um die Uhr nach offenen Diensten und schwachen Passwörtern. Fail2ban ist die bewährte Antwort darauf — ein Daemon, der Logdateien überwacht und Angreifer-IPs automatisch sperrt, bevor sie Schaden anrichten können.

Wie Fail2ban funktioniert

Fail2ban arbeitet nach einem einfachen, aber effektiven Prinzip: Log-Parsing gefolgt von automatischen Firewall-Sperren. Der Ablauf in drei Schritten:

Log-Überwachung: Fail2ban liest Logdateien kontinuierlich mit — standardmäßig per inotify, also nahezu in Echtzeit. Jeder Dienst hat einen eigenen Filter, der mit regulären Ausdrücken fehlgeschlagene Authentifizierungsversuche erkennt.
Muster-Erkennung: Sobald eine IP-Adresse innerhalb des konfigurierten Zeitfensters (findtime) mehr als die erlaubten Versuche (maxretry) erreicht, gilt sie als Angreifer.
Automatische Sperre: Fail2ban legt eine Regel in iptables, nftables oder einer anderen konfigurierten Action an, die weiteren Datenverkehr von dieser IP blockiert — für die Dauer von bantime.

Das Regelwerk ist modular aufgebaut: Jede Kombination aus Filter und Action heißt Jail. Die Standard-Installation bringt bereits fertige Jails für dutzende Dienste mit.

Installation auf Debian, Ubuntu und RHEL

Fail2ban ist in den offiziellen Paketquellen aller gängigen Distributionen verfügbar:

# Debian / Ubuntu
apt update && apt install fail2ban

# RHEL / AlmaLinux / Rocky Linux (EPEL erforderlich)
dnf install epel-release
dnf install fail2ban

# Dienst starten und dauerhaft aktivieren
systemctl enable --now fail2ban

Die Standardkonfiguration liegt in /etc/fail2ban/jail.conf. Diese Datei niemals direkt bearbeiten — sie wird bei Updates überschrieben. Stattdessen eine lokale Überschreibungsdatei anlegen:

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Alle eigenen Einstellungen kommen ausschließlich in jail.local oder in separate Dateien unter /etc/fail2ban/jail.d/.

jail.local konfigurieren: die wichtigsten Parameter

Der [DEFAULT]-Abschnitt in jail.local setzt globale Werte, die für alle Jails gelten — sofern nicht pro Jail überschrieben:

# /etc/fail2ban/jail.local

[DEFAULT]
# Zeitfenster in Sekunden, in dem maxretry-Versuche gezählt werden
findtime = 600

# Maximale Fehlversuche bevor eine IP gesperrt wird
maxretry = 5

# Sperrzeit in Sekunden (3600 = 1 Stunde)
# Negativer Wert = permanente Sperre
bantime = 3600

# Exponentielles Wachstum der Sperrzeit bei Wiederholungstätern
bantime.increment = true
bantime.multiplier = 2
bantime.maxtime = 604800

# IPs, die niemals gesperrt werden (eigene IPs, VPN-Exits, Monitoring)
ignoreip = 127.0.0.1/8 ::1 192.168.0.0/24 203.0.113.10

# Standard-Aktion: ban ohne E-Mail
action = %(action_)s

SSH-Jail (sshd)

Die wichtigste Jail schützt den SSH-Dienst. Auf Systemen mit systemd-journald als Log-Backend:

[sshd]
enabled = true
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 3
bantime  = 86400

Weitere Dienste schützen

Nginx und Apache

Fail2ban kann auch Web-Server-Logs überwachen und Brute-Force-Angriffe auf Login-Seiten oder übermäßiges HTTP-Error-Rauschen unterbinden:

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

[nginx-limit-req]
enabled  = true
port     = http,https
logpath  = /var/log/nginx/error.log
maxretry = 10

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

Postfix und Dovecot

Mail-Server sind ein beliebtes Angriffsziel. Die fertigen Jails erkennen fehlgeschlagene SMTP-Auth- und IMAP-Logins:

[postfix]
enabled = true
port    = smtp,465,submission
logpath = /var/log/mail.log

[dovecot]
enabled = true
port    = pop3,pop3s,imap,imaps,submission,465,sieve
logpath = /var/log/mail.log
maxretry = 5

OPNsense Web-GUI

Wer OPNsense als Firewall betreibt, kann dessen API-Endpunkt ebenfalls absichern. OPNsense bringt Fail2ban als Plugin mit (os-fail2ban), das direkt im Paketmanager installierbar ist und Failed-Login-Versuche auf das Web-Interface erkennt.

Eigene Filter für Anwendungslogs

Für Anwendungen ohne fertige Fail2ban-Filter lassen sich eigene Definitionen erstellen. Beispiel für eine WordPress-Anwendung, die Login-Fehler in /var/log/nginx/wordpress-error.log schreibt:

# /etc/fail2ban/filter.d/wordpress.conf
[Definition]
failregex = ^<HOST> .* "POST /wp-login\.php HTTP.*" 200
ignoreregex =

# In jail.local
[wordpress]
enabled  = true
port     = http,https
filter   = wordpress
logpath  = /var/log/nginx/wordpress-access.log
maxretry = 5
findtime = 300
bantime  = 7200

Der reguläre Ausdruck nutzt <HOST> als Platzhalter — Fail2ban ersetzt diesen automatisch durch den entsprechenden IPv4/IPv6-Erkennungsausdruck.

Whitelist und ignoreip

Eigene IP-Adressen, Monitoring-Server und VPN-Ausgangspunkte müssen zwingend in ignoreip eingetragen werden, um eine versehentliche Selbst-Sperrung zu verhindern:

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1
           192.168.1.0/24
           10.0.0.0/8
           203.0.113.42

Fail2ban unterstützt sowohl einzelne IPs als auch CIDR-Blöcke und IPv6-Adressen. Wichtig: ignoreip gilt nur für neue Bans — bereits gesperrte IPs müssen manuell entsperrt werden.

E-Mail-Alerts bei Sperren

Für produktive Umgebungen empfiehlt sich eine Benachrichtigung bei jedem neuen Ban. Fail2ban bringt E-Mail-Actions mit:

# In /etc/fail2ban/jail.local

[DEFAULT]
destemail = admin@example.com
sender    = fail2ban@server.example.com
mta       = sendmail

# Aktion: Ban + E-Mail mit Whois-Info
action = %(action_mwl)s

Die Action action_mwl sendet bei jedem Ban eine E-Mail mit IP-Informationen, Whois-Daten und den relevanten Log-Zeilen. Für ruhigere Benachrichtigungen reicht action_mw ohne Log-Auszug.

fail2ban-client: wichtige Befehle

Der Kommandozeilen-Client erlaubt das Live-Management laufender Jails:

# Globalen Status aller Jails anzeigen
fail2ban-client status

# Details zu einer bestimmten Jail (gesperrte IPs, Statistiken)
fail2ban-client status sshd

# Eine IP manuell sperren
fail2ban-client set sshd banip 198.51.100.55

# Eine gesperrte IP entsperren
fail2ban-client set sshd unbanip 198.51.100.55

# Fail2ban nach Konfigurationsänderungen neu laden
fail2ban-client reload

# Alle aktuellen Bans prüfen (via iptables)
iptables -n -L f2b-sshd

Vergleich: Fail2ban vs. CrowdSec vs. sshguard vs. CSF

Merkmal	Fail2ban	CrowdSec	sshguard	CSF
Ansatz	Log-Parsing, lokale Rules	Log-Parsing + Community-Blocklists	Log-Parsing, minimal	Log-Parsing + Firewall-Wrapper
Installation	Alle Distributionen	Alle Distributionen	Alle Distributionen	CentOS/cPanel-fokussiert
Konfiguration	Mittel (jail.local)	Einfach (YAML)	Sehr einfach	Einfach (csf.conf)
Community-Threat-Intelligence	Nein	Ja (opt-in)	Nein	Nein
Multi-Dienst-Unterstützung	Sehr gut	Gut	Eingeschränkt (SSH-Fokus)	Gut
IPv6-Unterstützung	Ja	Ja	Ja	Ja
Ressourcenverbrauch	Gering	Mittel	Minimal	Gering
Aktive Weiterentwicklung	Moderat	Aktiv	Aktiv	Aktiv

Fail2ban ist die universellste Lösung mit der größten Auswahl an fertigen Filtern. CrowdSec ergänzt lokale Entscheidungen um community-basierte Bedrohungsdaten. Für reine SSH-Absicherung ohne Konfigurationsaufwand ist sshguard die leichtgewichtige Alternative.

Fail2ban und DATAZONE Control: fleetweites Ban-Monitoring

Auf einem einzelnen Server reicht es, fail2ban-client status im Blick zu haben. Bei einer größeren Linux-Flotte braucht man eine zentrale Sicht: Welche Server werden aktuell angegriffen? Welche IPs tauchen auf mehreren Systemen auf? Gibt es Dienste, bei denen die Ban-Rate plötzlich ansteigt?

DATAZONE Control ergänzt Fail2ban auf Flottenebene:

Zentrales Alert-Dashboard: Ban-Ereignisse aller verwalteten Server in einer Ansicht zusammengefasst
Anomalie-Erkennung: Ungewöhnliche Anstiege der Brute-Force-Aktivität werden erkannt und gemeldet — bevor ein Server überfordert ist
Konfigurationsdrift-Überwachung: Änderungen an jail.local oder Fail2ban-Filtern werden getrackt und können bei unerwarteten Abweichungen alarmieren
Cross-Server-Korrelation: Eine IP, die auf fünf verschiedenen Servern gesperrt wurde, ist ein klares Signal für eine koordinierte Attacke

Die Kombination aus lokaler Fail2ban-Härtung und zentralem Monitoring mit DATAZONE Control schließt die Lücke zwischen reaktivem Sperren und proaktiver Bedrohungserkennung.

Best Practices im Überblick

jail.local statt jail.conf bearbeiten — Updates überschreiben nie eigene Einstellungen
bantime.increment aktivieren — Wiederholungstäter werden progressiv länger gesperrt
ignoreip sorgfältig pflegen — Monitoring-IPs und eigene Netze immer eintragen
Log-Backend prüfen — systemd-journald erfordert backend = systemd, klassische Logs backend = auto
Filter testen vor dem Scharfstellen: fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf
E-Mail-Alerts für Produktivsysteme einrichten — stille Bans können maskieren, dass ein System gezielt angegriffen wird
Firewall-Persistenz prüfen — nach einem Neustart müssen Fail2ban-Regeln neu angelegt werden (wird automatisch gemacht, wenn der Dienst autostartet)
Regelmäßige Log-Review: Fail2ban ersetzt keine manuelle Analyse — auffällige Muster können auf weitergehende Kompromittierungen hinweisen

Sie möchten Ihre Linux-Server systematisch gegen Brute-Force-Angriffe absichern? Kontaktieren Sie uns — wir konfigurieren Fail2ban, richten fleetweites Monitoring mit DATAZONE Control ein und sorgen dafür, dass Ihre Infrastruktur dauerhaft geschützt bleibt.

Fail2ban: Brute-Force-Schutz für Linux-Server automatisieren