CrowdSec Linux 2026: Fail2ban-Nachfolger…

Q: Wie whiteliste ich eine IP in CrowdSec?

Für einzelne IPs oder CIDR-Blöcke nutzen Sie cscli allowlists create und cscli allowlists add . Wer log-inhaltsbasierte Ausnahmen (z. B. bestimmte User-Agents) braucht, editiert /etc/crowdsec/parsers/s02-enrich/whitelists.yaml und reloaded den Agent.

Aktualisiert: 30. Juli 2026

CrowdSec unter Linux ist eine Open-Source-Intrusion-Prevention-Engine, die Logdateien in Echtzeit gegen verhaltensbasierte YAML-Szenarien prüft, bösartige IPs an entkoppelte Bouncer weiterreicht und eine gemeinschaftlich gepflegte Blocklist über eine zentrale API verteilt. Für mich ist es der praktische Fail2ban-Nachfolger für 2026, und in diesem Leitfaden zerlege ich die Angriffe, die ich in Pentests täglich fahre, und ordne jedem Schritt die passende CrowdSec-Kontrolle zu: SSH-Bruteforce, HTTP-Probing, Log4Shell-Scans und die AppSec-WAF-Komponente auf Basis der Coraza-Engine.

CrowdSec Engine 1.7.8 (Mai 2025) behebt einen High-Severity WAF-Bypass (CVE-2025-44982) und eine LAPI-DoS-Lücke (CVE-2025-44981) – Upgrade ist Pflicht, ältere Versionen filtern chunked HTTP-Body nicht.
Die Trennung von Detection (Agent), Speicherung (LAPI) und Enforcement (Bouncer) macht CrowdSec horizontal skalierbar; ein einziger LAPI kann Dutzende Server und Reverse-Proxies bedienen.
Der nftables-Firewall-Bouncer 0.0.28 nutzt ipsets mit einer Standardgröße von 131.072 Einträgen und blockt Community-Blocklist-IPs, bevor sie überhaupt einen Handshake versuchen.
Szenarien wie crowdsecurity/http-cve erkennen JNDI-, SQLi- und LFI-Probing; die AppSec-Komponente spricht ModSecurity SecLang und lädt OWASP CRS-Regeln direkt.
Der cscli dashboard-Befehl (Metabase) ist seit 1.7.0 deprecated – Ersatz sind die kostenlose Console oder Prometheus + Grafana.

Was ist CrowdSec und wie funktioniert es?

CrowdSec ist eine in Go geschriebene, verhaltensbasierte Intrusion-Prevention-Engine. Sie parst Logeinträge, wertet sie in einer Zeitfensterlogik gegen Szenarien aus und reicht getroffene Entscheidungen an separate Enforcement-Komponenten (die Bouncer) weiter. Die Architektur besteht aus drei Schichten. Der Agent liest Logs aus journald, Dateien, Docker, Kubernetes-Ereignissen oder syslog. Parser (YAML + Grok, seit 1.7 mit RE2-Regex-Engine für messbaren Performance-Gewinn) normalisieren die Zeilen zu Ereignissen. Szenarien zählen mittels Leaky-Bucket-Algorithmus, ob bestimmte Muster – etwa 10 fehlgeschlagene SSH-Logins in 60 Sekunden – überschritten werden. Ist der Bucket voll, entsteht ein Alert plus Decision.

Die LAPI (Local API) ist eine REST-Schnittstelle auf 127.0.0.1:8080, die Entscheidungen in SQLite, Postgres oder MySQL persistiert und alle Bouncer via API-Key bedient. Die CAPI (Central API) ist der Cloud-Endpunkt, an den – nur mit ausdrücklichem Opt-in – anonymisierte Signale gehen: Angreifer-IP, Attack-Typ, Zeitstempel. Aus diesen Signalen berechnet CrowdSec die Community Blocklist, die jede angeschlossene Instanz präventiv verteilt bekommt. Aus Pentester-Sicht: Ein Scanner, der heute morgen einen Server in Frankfurt bespritzt hat, ist mittags auf allen anderen Instanzen weltweit gesperrt, bevor er dort das erste TCP-SYN sendet.

CrowdSec vs. Fail2ban: die technischen Unterschiede

Die zentrale Frage bei jedem neuen Kundenprojekt lautet, ehrlich gesagt: Warum nicht einfach Fail2ban? Meine Kurzantwort: Fail2ban ist ein Python-Daemon, der Regex-Zeilen matcht und über den gleichen Prozess iptables oder nftables aufruft. Das reicht für einen einzelnen Server mit SSH und vielleicht Nginx. Sobald aber mehrere Hosts, ein Reverse-Proxy und HTTP-Bruteforce ins Spiel kommen, wird die statische Regex-Logik zum Bremsklotz. Ich habe letztes Jahr bei einem Kunden mit acht Web-Nodes noch versucht, Fail2ban mit rsyslog zentral zu betreiben, und irgendwann war der Wartungsaufwand höher als der Migrationsaufwand auf CrowdSec.

Kriterium	Fail2ban	CrowdSec 1.7.x
Runtime	Python-Daemon	Go-Binary, statisch gelinkt
Erkennung	Regex pro Zeile	YAML-Szenarien mit Zeitfenster (Leaky-Bucket)
Enforcement	gekoppelt (fail2ban ruft iptables)	entkoppelte Bouncer über REST/LAPI
Multi-Server	manuelle Skripterei	nativ (1 LAPI, n Bouncer, Console-Föderation)
Geteilte Intelligenz	keine	Community Blocklist über CAPI
Log-Quellen	Dateien	Datei, journald, Docker, Kubernetes, Windows Event Log, HTTP (AppSec)
WAF	keine	eingebaut (Coraza, ModSecurity-kompatibel)
GUI	keine	kostenlose SaaS-Console
Telemetrie	keine	Opt-in; nur IP + Typ + Timestamp

Für die Praxis heißt das: CrowdSec ersetzt Fail2ban strukturell dort, wo Sie mehr als einen Server oder mehr als eine Applikationsschicht schützen. Die entkoppelte Architektur bedeutet auch, dass Sie beide Systeme parallel fahren können – Fail2ban weiter für einen Legacy-Dienst, CrowdSec für alles Neue. Für konsistente Firewall-Regeln empfehle ich, das Enforcement in dem Fall komplett dem CrowdSec-nftables-Bouncer zu übertragen und Fail2ban ohne Ban-Action laufen zu lassen, damit sich keine Regeln überschreiben.

CrowdSec unter Debian, Ubuntu und RHEL installieren

Das crowdsec-Paket im Ubuntu-24.04-Universe-Repo ist mit 1.4.6 hoffnungslos veraltet. Installieren Sie immer über die offizielle Packagecloud-Repository, damit Sie 1.7.8 oder neuer erhalten. Für den Angreifer ist eine 1.4-Version genauso wertvoll wie ein offener Port: sie enthält den WAF-Bypass, den ich weiter unten beschreibe.

# Debian 12/13 und Ubuntu 24.04 – offizielles Repository und Engine + nftables-Bouncer
curl -s https://install.crowdsec.net | sudo sh
sudo apt update
sudo apt install crowdsec crowdsec-firewall-bouncer-nftables

# systemd-Services aktivieren
sudo systemctl enable --now crowdsec crowdsec-firewall-bouncer

# Versionen verifizieren
crowdsec -version
cs-firewall-bouncer -version   # sollte 0.0.28 oder neuer melden

Auf RHEL 9 und 10 (samt AlmaLinux und Rocky) läuft der gleiche Prozess über dnf. Sie wählen zwischen dem iptables- und dem nftables-Bouncer – auf allen modernen Distributionen ist nftables die richtige Wahl, da RHEL 9 bereits standardmäßig auf nftables über die iptables-Kompatibilitätsschicht setzt.

# RHEL 9/10, AlmaLinux, Rocky
curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.rpm.sh | sudo bash
sudo dnf install -y crowdsec crowdsec-firewall-bouncer-nftables
sudo systemctl enable --now crowdsec crowdsec-firewall-bouncer

# Hub-Index aktualisieren und Basis-Kollektionen installieren
sudo cscli hub update
sudo cscli collections install crowdsecurity/linux crowdsecurity/sshd
sudo systemctl reload crowdsec

Angriffsszenarien und Kollektionen: SSH, HTTP und CVE-Probing

CrowdSec ist so nützlich wie die Szenarien, die Sie installieren. Aus dem Hub ziehen Sie Kollektionen – Bundles aus Parsern, Szenarien und Postoverflows für einen Dienst. Für einen Standard-Webserver sind das erfahrungsgemäß vier Kollektionen, die ich in Pentests am schnellsten getroffen habe:

# Kern-Kollektionen für einen Linux-Webserver
sudo cscli collections install \
    crowdsecurity/linux \
    crowdsecurity/sshd \
    crowdsecurity/base-http-scenarios \
    crowdsecurity/http-cve

# Nginx- oder Apache-spezifische Parser, wenn Reverse-Proxy vorhanden
sudo cscli collections install crowdsecurity/nginx

# Neu geladene Konfiguration übernehmen
sudo systemctl reload crowdsec

# Übersicht des aktuellen Zustands
sudo cscli hub list
sudo cscli parsers list
sudo cscli scenarios list

Sobald ich hydra -l root -P rockyou.txt ssh://target laufen lasse, feuert die crowdsecurity/ssh-bf-Szenario nach etwa zehn Fehlversuchen in 60 Sekunden. Der Alert wird an die LAPI übergeben, die Decision wandert innerhalb einer Sekunde zum Firewall-Bouncer, der die Angreifer-IP in ein nftables-ipset packt. Der nächste Bruteforce-Versuch schlägt schon am Kernel-Paketfilter fehl (der SSH-Dienst sieht ihn nicht einmal mehr).

Interessanter wird es bei HTTP. Die base-http-scenarios-Kollektion enthält Regeln für 404-Stürme (Scanner wie Nikto oder ffuf), verdächtige User-Agents (Wpscan, sqlmap), sowie generische Bruteforce über HTTP-Statuscodes. Die http-cve-Kollektion ergänzt das um CVE-spezifische Fingerprints – laut CrowdSec-Team wurden allein im Juni 2025 46 neue CVEs hinzugefügt, darunter mehrere Ivanti- und GitLab-Lücken. Der Klassiker Log4Shell-Payload in einem HTTP-Header wird sofort geblockt.

# Aktive Alerts der letzten 24 Stunden
sudo cscli alerts list --since 24h

# Alle aktuellen Entscheidungen anzeigen
sudo cscli decisions list

# Nur Entscheidungen aus der Community Blocklist
sudo cscli decisions list --origin CAPI

# Detailansicht eines konkreten Alerts (Id aus alerts list)
sudo cscli alerts inspect 42 --details

nftables-Bouncer konfigurieren und Regeln verifizieren

Der crowdsec-firewall-bouncer-nftables ist in 99 % der Fälle die richtige Wahl. Beim Start meldet er sich bei der LAPI an, holt sich einen API-Key (der bei der Paketinstallation automatisch generiert wird), erzeugt eine eigene nftables-Tabelle und synchronisiert die aktuellen Entscheidungen mit einem ipset. Die relevante Konfigurationsdatei liegt unter /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml. Praxis-Tipp aus mehreren Migrationen: prüfen Sie zuerst, ob die Datei bereits einen API-Key trägt, bevor Sie einen neuen registrieren.

# Beispiel /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml
mode: nftables
update_frequency: 10s
log_level: info
api_url: http://127.0.0.1:8080/
api_key: <automatisch erzeugt>

# nftables-spezifisch
nftables:
  ipv4:
    enabled: true
    set-only: false
    table: crowdsec
    chain: crowdsec-chain
    priority: -10
  ipv6:
    enabled: true
    set-only: false
    table: crowdsec6
    chain: crowdsec6-chain
    priority: -10

blacklists_ipv4: crowdsec-blacklists
blacklists_ipv6: crowdsec6-blacklists
deny_action: DROP
deny_log: true

Nach einem systemctl restart crowdsec-firewall-bouncer prüfen Sie das Ergebnis direkt am Kernel. Alles andere ist nur Papier:

# Alle Tabellen anzeigen
sudo nft list ruleset | grep -i crowdsec

# Speziell die Blocklist-Sets ausgeben
sudo nft list set inet crowdsec crowdsec-blacklists
sudo nft list set inet crowdsec6 crowdsec6-blacklists

# Bouncer-Logs bei Problemen (fehlender API-Key, falsche Set-Größe)
sudo journalctl -u crowdsec-firewall-bouncer -e --no-pager

Für eine manuelle Sperre – etwa nach einem gezielten Vorfall – nutzen Sie cscli decisions add. Die Entscheidung wird über die LAPI an alle Bouncer verteilt, egal ob ein oder zwanzig Server dranhängen:

# IP für 24 Stunden bannen
sudo cscli decisions add --ip 203.0.113.42 --duration 24h --type ban

# Ein ganzes Netz für sieben Tage sperren
sudo cscli decisions add --range 203.0.113.0/24 -d 7d --reason "targeted attack"

# Wieder entfernen
sudo cscli decisions delete --ip 203.0.113.42

# Vertrauenswürdige IPs als Allowlist eintragen (nicht als Whitelist-Parser)
sudo cscli allowlists create office_ips -d "HQ egress"
sudo cscli allowlists add office_ips 198.51.100.0/24 -d "Frankfurt HQ"

Community Blocklist und Console-Anbindung

Die Community Blocklist ist übrigens der Grund, warum ich in Pentests bei CrowdSec-Zielen sehr schnell auf ein Reverse-Shell-Payload aus einem exotischen ASN umschalten muss: die üblichen Bulletproof-Hoster sind längst auf der Liste. Der Consensus-Algorithmus bezieht anonymisierte Signale aus allen freiwillig teilnehmenden Instanzen weltweit, verifiziert die Herkunft über Vertrauensscores und filtert manipulierte oder „tainted“ Szenarien heraus. Nur die offiziellen, mit einem Content-Hash validierten Szenarien fließen in die Berechnung ein.

Die Anbindung an die kostenlose CrowdSec Console ist der zweite Baustein, den ich jedem Kunden empfehle. Sie bekommen eine Übersicht über alle Instanzen, sehen Alerts konsolidiert und können Business- oder Threat-spezifische Blocklists (etwa Firehol, Emerging Threats, ProofPoint) mit einem Klick abonnieren.

# Instanz in die Console einschreiben (Key aus app.crowdsec.net)
sudo cscli console enroll -n prod-web1 -t webserver YOUR-ENROLL-KEY
# danach in der Web-UI bestätigen

# Blocklist per URL abonnieren (URL aus der Console kopieren)
sudo cscli blocklists add <blocklist-url>

# Status aller angebundenen Blocklists
sudo cscli blocklists list

# Metriken für Monitoring (Prometheus scraped /metrics auf 6060)
sudo cscli metrics

Wichtig: Der cscli dashboard-Befehl, der früher ein lokales Metabase-Container startete, ist seit Version 1.7.0 offiziell deprecated. Wer weiterhin einen selbst gehosteten Dashboard-Stack möchte, kombiniert die eingebaute Prometheus-Metrics-Schnittstelle mit Grafana. Für die meisten Setups reicht die kostenlose Console jedoch aus.

CrowdSec AppSec: die WAF-Komponente mit Coraza

Die AppSec-Komponente hebt CrowdSec endgültig von Fail2ban ab. Sie ist ein separater Prozess, der einen HTTP-Request vom Reverse-Proxy (Nginx, Traefik, HAProxy) via lokalem HTTP entgegennimmt, ihn durch die Coraza-Engine laufen lässt und mit einem Verdikt (block, allow, log) antwortet. Coraza spricht ModSecurity SecLang, weshalb Sie das OWASP Core Rule Set nahezu unverändert einbinden können – zusätzlich bietet CrowdSec ein natives YAML-Format für eigene Regeln.

In der Praxis heißt das: Sie bekommen SQL-Injection-, XSS-, LFI- und RCE-Schutz auf Layer 7, ohne einen kommerziellen WAF-Cluster kaufen zu müssen. Neu in 2025/2026 ist die Virtual-Patching-Logik. CrowdSec veröffentlicht bei bekannten CVEs (etwa Ivanti Connect Secure, Fortinet FortiOS) innerhalb weniger Stunden Coraza-Regeln, die Sie über den Hub ziehen können. Für kritische Systeme kombinieren Sie das mit den in unserem Leitfaden zu eBPF-Runtime-Security beschriebenen Tetragon- und Falco-Regeln, um Ausbruchsversuche auf Prozessebene zu erkennen.

# AppSec-Kollektion installieren (enthält Basis-Rules und Nginx-Hook-Bouncer)
sudo cscli collections install crowdsecurity/appsec-virtual-patching
sudo cscli collections install crowdsecurity/appsec-generic-rules

# AppSec-Konfiguration liegt unter
ls /etc/crowdsec/appsec-configs/
ls /etc/crowdsec/appsec-rules/

# Reverse-Proxy-Bouncer: Nginx-Beispiel
sudo apt install crowdsec-nginx-bouncer
# Die Nginx-Konfiguration erhält ein neues location-Snippet, das jeden Request
# an http://127.0.0.1:7422 (AppSec) vorprüft.

# Bouncer-Status
sudo cscli bouncers list

Für eine Zero-Trust-Architektur denken Sie AppSec konsequent als „defense in depth“ ergänzend zu einer Mandatory-Access-Control-Schicht. Wer noch keinen Vergleich zwischen den beiden Frameworks gezogen hat, findet die Kriterien in unserem SELinux-vs-AppArmor-Vergleich.

Sicherheitsupdate 1.7.8: WAF-Bypass und LAPI-DoS beheben

Im Mai 2025 veröffentlichte CrowdSec ein außerplanmäßiges Security-Release 1.7.8. Zwei Lücken sind für jeden CrowdSec-Betreiber relevant:

CVE-2025-44982 (High) – ein WAF-Bypass: Requests mit Transfer-Encoding: chunked (HTTP/1.1) oder HTTP/2 ohne Content-Length-Header wurden mit leerem Body ausgewertet. Jede Regel, die auf Body-Inhalt matcht (SQLi, XSS, RCE), wurde stumm umgangen. Das Update erzwingt eine OpenAPI-Schema-Validierung und setzt eine harte Body-Size-Grenze.
CVE-2025-44981 – LAPI-DoS: ein präpariertes Request-Muster konnte den LAPI-Prozess mit vertretbarem Aufwand blockieren. Auf Servern mit einem einzigen LAPI ist damit die gesamte Enforcement-Kette lahmgelegt.

# Upgrade auf die aktuelle Version
sudo apt update
sudo apt install --only-upgrade crowdsec crowdsec-firewall-bouncer-nftables \
    crowdsec-nginx-bouncer

# Version prüfen – 1.7.8 oder neuer erforderlich
crowdsec -version

# Nach dem Upgrade Hub-Index und Regeln refreshen
sudo cscli hub update
sudo cscli hub upgrade
sudo systemctl reload crowdsec

Für die Beobachtbarkeit exportieren Sie die /metrics-Schnittstelle auf Port 6060 an Prometheus und alerten in Grafana auf ungewöhnliche Sprünge bei cs_bucket_pour_total. Aus meiner Erfahrung ist das der zuverlässigste Indikator dafür, dass CrowdSec unter Angriff läuft. Wer ein SSH-lastiges Setup absichert, sollte den Leitfaden zur SSH-Härtung mit Post-Quantum-Kryptografie und FIDO2 parallel umsetzen, denn CrowdSec blockt Angreifer, verhindert aber nicht das Kompromittieren schwacher Schlüssel.

Häufig gestellte Fragen

Ist CrowdSec kostenlos und Open Source?

Ja. Die Engine, alle Bouncer, der Hub und die Community Blocklist stehen unter MIT-Lizenz. Die CrowdSec Console ist in der Free-Tier für bis zu drei Instanzen kostenfrei. Kostenpflichtig sind lediglich Premium-Blocklists, das Enterprise-Console-Tier und der CTI-Zugang.

Teilt CrowdSec meine Logs oder personenbezogene Daten?

Nein. An die CAPI werden nur drei Felder pro Alert übermittelt: die Angreifer-IP, der Szenario-Typ und ein Zeitstempel. Ihre eigenen Log-Inhalte, User-Namen oder Payloads verlassen den Server nicht. Das Signal-Sharing lässt sich zudem vollständig abschalten.

Wie whiteliste ich eine IP in CrowdSec?

Für einzelne IPs oder CIDR-Blöcke nutzen Sie cscli allowlists create und cscli allowlists add. Wer log-inhaltsbasierte Ausnahmen (z. B. bestimmte User-Agents) braucht, editiert /etc/crowdsec/parsers/s02-enrich/whitelists.yaml und reloaded den Agent.

Ersetzt CrowdSec eine WAF?

Mit der AppSec-Komponente ja, für den Großteil der OWASP-Top-10-Kategorien. Die Coraza-Engine ist ModSecurity-kompatibel, das OWASP CRS lässt sich direkt einbinden. Für hochregulierte Umgebungen mit spezifischen Zertifizierungsanforderungen bleibt eine kommerzielle WAF trotzdem oft ergänzend nötig.

Können CrowdSec und Fail2ban parallel laufen?

Technisch ja, praktisch heikel. Beide würden Firewall-Regeln setzen und sich potenziell überschreiben. Wenn Sie migrieren, deaktivieren Sie die Ban-Actions in Fail2ban oder stellen sie auf reines Logging, während CrowdSec das Enforcement übernimmt.

Was ist der Unterschied zwischen einem CrowdSec-Agent und einem Bouncer?

Der Agent erkennt Angriffe, indem er Logs parst und Szenarien auswertet. Der Bouncer setzt Entscheidungen durch – als nftables-Regel, Nginx-Redirect, Cloudflare-Firewall-Regel usw. Ein LAPI-Server kann viele Bouncer parallel bedienen; das ist der Kern der entkoppelten Architektur.