# Fail2Ban Masterclass: Proaktive Abwehr von Angriffen

TL;DR / Management Summary Ein einfacher IP-Bann für 10 Minuten ist nur ein Tropfen auf den heißen Stein. In diesem Modul heben wir Fail2Ban auf das Enterprise-Niveau. Wir implementieren die Recidive-Jail für Langzeit-Sperren von Wiederholungstätern, lernen das Schreiben von Custom Regex Filtern für spezialisierte Applikationen und integrieren eine Cloud-Intelligence (AbuseIPDB), um bekannte Angreifer bereits vor dem ersten Paket zu blockieren.

# 1. Einführung & Architektur

Vom einfachen Bann zum IPS.

Fail2Ban arbeitet standardmäßig reaktiv. Durch die Integration von Reputations-Datenbanken wird es zu einem proaktiven Intrusion Prevention System (IPS).

# Die erweiterte Abwehr-Kette (Mermaid)

graph TD
    A[Attacker IP] --> B{Local Firewall Check}
    B -->|Banned?| C[Drop Packet]
    B -->|Unknown| D[App Log / Journald]
    D --> E[Fail2Ban Filter: Regex]
    E --> F{Match Found?}
    F -->|Count Threshold| G[Action: Ban IP]
    G --> H[Action: Report to AbuseIPDB]
    I[Global Intel: AbuseIPDB] -->|Blacklist| B

# 2. Abwehr von Wiederholungstätern (Recidive)

Den Lerneffekt nutzen.

Wenn ein Angreifer immer wieder kommt, setzen wir ihn auf die “schwarze Liste”.

# Konfiguration (/etc/fail2ban/jail.local)

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
filter   = recidive
# Wer 5 Mal in 24h gebannt wurde...
findtime = 1d
maxretry = 5
# ...wird für eine Woche gesperrt!
bantime  = 1w

# 3. Custom Filter schreiben

Eigene Applikationen schützen.

Angenommen, Ihre App loggt Fehler wie: FAILED_LOGIN user=admin from=1.2.3.4.

# Schritt 1: Filter definieren (/etc/fail2ban/filter.d/myapp.conf)

[Definition]
failregex = ^FAILED_LOGIN user=.* from=<HOST>$
ignoreregex =

# Schritt 2: Jail aktivieren

[myapp]
enabled = true
port    = http,https
logpath = /var/log/myapp/error.log

# 4. Day-2 Operations: Cloud Intelligence

Wissen, was das Internet weiß.

Integrieren Sie AbuseIPDB, um Ihre Banns mit der Welt zu teilen und von den Meldungen anderer zu profitieren.

# Automatisches Reporting

Nutzen Sie eine action, die bei jedem Bann eine API-Anfrage sendet:

# In jail.local unter 'action'
action_mwl = %(action_mw)s
             abuseipdb[apikey="YOUR_API_KEY", category="18"]

# 5. Troubleshooting & “War Stories”

Wenn die Regex fehlzündet.

# Story 1: “Der falsche Zeilenumbruch”

Symptom: Fail2Ban meldet Erfolg beim Testen des Filters, aber blockiert im Live-Betrieb niemanden. Ursache: Das Log-Format im Journald enthält Metadaten, die der Regex-Parser nicht sieht, wenn man nur Text-Files testet. Lösung: Testen Sie immer mit dem echten Stream: fail2ban-regex --systemd sshd.

# Story 2: “Performance-Einbruch bei Riesen-Logs”

Symptom: Die CPU-Last von Fail2Ban steigt massiv an, sobald der Webserver unter Last steht. Ursache: Fail2Ban muss jede einzelne Logzeile gegen hunderte Regex-Muster prüfen. Lösung: Nutzen Sie das systemd backend, da es effizienter auf neue Events reagiert als das Polling von Textdateien. Optimieren Sie die Regex (Vermeiden Sie .* am Anfang).

# 6. Fazit & Empfehlung

• Strategie: Nutzen Sie kurze Bannzeiten (1h) für den ersten Verstoß und lange Zeiten (1w) für Recidive.
• Wartung: Prüfen Sie regelmäßig fail2ban-client status, um zu sehen, ob Ihre Jails effektiv arbeiten.
• Wahl: Nutzen Sie CrowdSec als moderne Alternative, wenn Sie eine Cloud-native Lösung mit nativer Threat-Intelligence-Anbindung suchen.

# Anhang: Cheatsheet für Profis