Fail2ban in der Praxis: Einbrüche erkennen und sperren

Fail2ban ist ein Werkzeug, das Protokolldateien beobachtet und bei wiederholten Fehlversuchen die Quelladresse für eine Zeit sperrt. Es ist die pragmatischste Massnahme gegen automatisiertes Durchprobieren von Zugangsdaten – und auf praktisch jedem öffentlich erreichbaren Server sinnvoll.

Wie es arbeitet

Fail2ban verfolgt keine Netzwerkverbindungen dauerhaft, sondern liest Protokolle. Der Ablauf ist immer derselbe:

1. Ein Filter (Muster) erkennt Fehlversuche in einer Protokolldatei.
2. Ein Zähler sammelt Treffer je Adresse innerhalb eines Zeitfensters.
3. Ist die Grenze erreicht, löst die Aktion aus – meist eine Sperre über die lokale Paketfilterung für eine festgelegte Dauer (bantime).
4. Nach Ablauf wird die Sperre aufgehoben. Wiederholte Verstöße führen zu längeren Sperren (Recidive).

Einrichtung für SSH

# Installation
apt install fail2ban          # Debian/Ubuntu
dnf install fail2ban          # RHEL/Fedora

# Konfiguration NICHT in jail.conf aendern - sie wird beim Update
# ueberschrieben. Stattdessen eine eigene Datei:
# /etc/fail2ban/jail.local

[DEFAULT]
# Eigene Sperren werden nicht mit anderen geteilt - saubere Trennung je Jail
bantime.increment      = true
bantime.factor         = 2
bantime.maxtime        = 4w
bantime                = 1h
findtime               = 10m
maxretry               = 5

# Wer nie gesperrt werden darf
ignoreip = 127.0.0.1/8 ::1 10.0.0.0/8

# Standardaktion: Sperre mit Erweiterung
banaction = nftables-multiport
banaction_allports = nftables-allports

[sshd]
enabled  = true
port     = ssh
logpath  = %(sshd_log)s
backend  = systemd
maxretry = 3
bantime  = 4h

[sshd-ddos]
enabled  = true
port     = ssh
filter   = sshd
logpath  = %(sshd_log)s
maxretry = 10
findtime = 1m
bantime  = 1h

# Ein eigenes Jail fuer einen Web-Login
[meine-app-login]
enabled  = true
port     = http,https
filter   = meine-app
logpath  = /var/log/meine-app/auth.log
maxretry = 5
findtime = 5m
bantime  = 2h

# Konfiguration pruefen und starten
fail2ban-client -t
systemctl restart fail2ban
systemctl enable fail2ban

# Zustand ansehen
fail2ban-client status
fail2ban-client status sshd
# Ausgabe zeigt: Currently banned, Total banned, Banned IP list

# Manuell sperren / entsperren
fail2ban-client set sshd banip 203.0.113.99
fail2ban-client set sshd unbanip 203.0.113.99

# Wirksame Regeln in der Paketfilterung ansehen
nft list ruleset | grep -i f2b

Eigenen Filter schreiben

Ein Filter ist eine Datei mit regulären Ausdrücken. Wichtig ist die <HOST>-Markierung – die Stelle, an der die zu sperrende Adresse steht:

# /etc/fail2ban/filter.d/meine-app.conf
[Definition]
failregex = ^.*Login failed for .* from <HOST>.*$
            ^.*Invalid credentials.*client=<HOST>.*$
ignoreregex = ^.*health-check.*$
datepattern = ^\[%%Y-%%m-%%d %%H:%%M:%%S\]

# Muster gegen ein echte Logdatei testen - unverzichtbar!
fail2ban-regex /var/log/meine-app/auth.log /etc/fail2ban/filter.d/meine-app.conf

# Ausgabe zeigt: Lines, Matches und die erkannten Adressen.
# Erscheinen keine Treffer, ist der Ausdruck falsch - nicht fail2ban.

fail2ban-regex ist der wichtigste Befehl überhaupt: Ohne Test gegen echte Protokolle weiß man nicht, ob der Filter greift. Ein ungetesteter Filter ist wirkungslos und erzeugt nur das Gefühl von Sicherheit.

Grenzen – wichtig für die Erwartung

• Es verhindert keine Angriffe mit verteilten Adressen. Ein Angriff aus tausend Adressen mit je zwei Versuchen erreicht nie die Grenze. Gegen solche Botnetze helfen nur andere Maßnahmen: Abschalten der Kennwortanmeldung, Netzwerkzugangsbeschränkung, Zwei-Faktor oder vorgeschalteter Schutz.
• Sperren wirken nur lokal. Andere Server sehen die Sperre nicht.
• Es reagiert nach einem Muster, nicht nach Verständnis. Eine legitime Anwendung mit falsch konfigurierten Zugangsdaten kann sich selbst sperren.
• Schützt nicht vor Fehlern im Code. Eine Sicherheitslücke in der Anwendung nutzt niemand über fehlgeschlagene Anmeldungen aus.

Die richtige Einordnung: Fail2ban ist ein Baustein, kein Ersatz. Auf einem SSH-Server ist die wirksamste Massnahme ohnehin, die Anmeldung mit Kennwort abzuschalten und nur Schlüssel zu erlauben – danach fällt der Nutzen von Sperren für SSH deutlich, weil Durchprobieren dann prinzipiell nicht mehr funktioniert.

Typische Fehler

Verwandte Grundlagen: Server härten, SSH-Härtung in der Praxis, Firewall, Brute-Force-Angriff.