Intrusion Prevention: CrowdSec statt fail2ban
fail2ban sperrt IPs nach wiederholten Fehlversuchen aus — lokal, allein, reaktiv. CrowdSec macht das auch, aber es teilt die Information mit allen anderen CrowdSec-Instanzen. Ein Angreifer, der in Helsinki gegen einen anderen Server scheitert, kommt bei uns in Kufstein gar nicht erst rein.
Das Prinzip: Crowdsourced Threat Intelligence
CrowdSec analysiert Logs — SSH, HTTP, SMTP, Sie nennen es. Erkennt es einen Angriff (Brute-Force, Scanner, Exploit-Versuch), sperrt es die IP lokal — und schickt einen anonymisierten Report an die zentrale API. Alle anderen Instanzen beziehen diese Blockliste und wehren die IP ebenfalls ab.
Das ist kein Geheimdienst, sondern gelebte Gemeinschaft: Wer teilt, profitiert.
Installation: Docker, ein Befehl
docker run -d --name crowdsec \
-v /var/log:/var/log:ro \
-v crowdsec-config:/etc/crowdsec \
crowdsecurity/crowdsec
Dazu ein Bouncer — etwa der Firewall-Bouncer für iptables/nftables oder der Caddy-Bouncer — und die Logs werden live ausgewertet. Die Einrichtung dauert eine halbe Stunde, danach läuft es.
Was CrowdSec besser macht als fail2ban
- Zentrales Blocklist-Management statt individueller jail.conf-Frickelei — eine Konfigurationsdatei, alle Dienste
- Reputation: Nicht nur Fehlversuche zählen, sondern die globale Historie der IP
- Moderne Parsing-Engine: Versteht JSON-Logs, Syslog, sogar eigene Formate
- Kein Regex-Leiden: fail2ban-Filter sind Regex-Puzzles. CrowdSec-Parser sind YAML und logisch
Mehr als IP-Blocking: AppSec/WAF
CrowdSec ist über reine IP-Sperren hinausgewachsen. Die AppSec-Komponente wirkt als anwendungsnahe Web Application Firewall (u. a. mit CRS-/ModSecurity-kompatiblen Regeln) und fängt Angriffsmuster direkt am HTTP-Request ab — nützlich vor exponierten Webanwendungen hinter dem Reverse Proxy.
NIS2-konform: Datenhaltung on-prem
Die Bedrohungsdaten stammen von einer externen API, aber die Log-Auswertung und Blockierung laufen lokal. Keine eigenen Logdaten verlassen das Haus — nur anonymisierte Signale ("IP X hat Brute-Force gegen SSH gemacht"). NIS2-konformer geht Bedrohungsaustausch kaum.
Was fail2ban immer noch besser kann
Für einen einzelnen Dienst auf einem einzelnen Server, der nie angreifbar aus dem Internet erreichbar ist, reicht fail2ban. Die Komplexität von CrowdSec lohnt sich erst ab dem Punkt, an dem Sie wirklich exponiert sind — Reverse Proxy, Mailserver, SSH mit Internet-Zugang.
Fazit
CrowdSec ersetzt fail2ban nicht als Nischenwerkzeug, sondern als Standard-IDS. Wer mehr als zwei Dienste öffentlich betreibt, sollte es einsetzen. Der Schwarm ist stärker als der Einzelne — das gilt in der Security genauso wie in der Biologie.
Was macht CrowdSec besser als fail2ban?+
CrowdSec teilt Bedrohungsdaten über alle Teilnehmer. Ein Angreifer, der anderswo scheitert, wird bei Ihnen gar nicht erst zugelassen. Dazu kommen zentrales Blocklist-Management statt individueller jail.conf-Frickelei, Reputation über die globale Historie einer IP, eine moderne Parsing-Engine für JSON und Syslog und YAML-Parser statt Regex-Puzzles. Über reine IP-Sperren hinaus wirkt die AppSec-Komponente als WAF.
Verlassen bei CrowdSec meine Logdaten das Haus?+
Nein. Die Bedrohungsdaten stammen zwar von einer externen API, aber Log-Auswertung und Blockierung laufen lokal. Keine eigenen Logdaten verlassen das Haus — nur anonymisierte Signale wie eine Meldung, dass eine IP Brute-Force gegen SSH versucht hat. Datenhaltung on-prem und NIS2-konformer Bedrohungsaustausch schließen sich damit nicht aus; wer teilt, profitiert vom Schwarm.
Lohnt sich CrowdSec auch für einen einzelnen Server?+
Nicht unbedingt. Für einen einzelnen Dienst auf einem einzelnen Server, der nie aus dem Internet erreichbar ist, reicht fail2ban. Die Komplexität von CrowdSec lohnt sich erst, wenn Sie wirklich exponiert sind — Reverse Proxy, Mailserver, SSH mit Internet-Zugang. Wer mehr als zwei Dienste öffentlich betreibt, sollte CrowdSec einsetzen.