CrowdSec: Open-Source-WAF mit kollaborativer Blocklist für KMU-Server

Was ist CrowdSec?

CrowdSec ist eine Open-Source-Sicherheits-Engine, die im Mai 2026 als Marktführer für Application-Layer-Intrusion-Detection im KMU-Bereich gilt. Entwickelt seit 2020 von einer französischen SAS mit Sitz in Paris, ist die Software unter MIT-Lizenz freigegeben und damit auch für kommerzielle Eigennutzung ohne Restriktionen verwendbar.

Der entscheidende Unterschied zu klassischen Tools wie Fail2ban liegt in der kollaborativen Blocklist: Jede CrowdSec-Installation weltweit meldet anonymisiert beobachtete Angriffe (nur ein Hash der IP plus das gematchte Angriffsmuster) an die zentrale Plattform. Mai 2026 sind über 100.000 Server weltweit verbunden, die zusammen eine aktive Blocklist von 4 bis 6 Millionen bösartigen IPs pflegen. Eine IP, die in Berlin einen WordPress-Login angreift, ist innert 90 Sekunden auf einem Server in Zürich gesperrt.

Die Architektur besteht aus drei klar getrennten Komponenten. Der Agent liest Log-Quellen (nginx, sshd, postfix, eigene Anwendungen), parst sie in strukturierte Events und entscheidet auf Basis von YAML-Scenarios, ob ein Angriff vorliegt. Bouncer sind Plugins, die die Entscheidung erzwingen: cs-firewall-bouncer setzt eine iptables-DROP-Regel, cs-nginx-bouncer liefert HTTP 403, cs-cloudflare-bouncer trägt die IP in die Cloudflare-Block-Liste ein. Die Console ist das zentrale Dashboard, das die Knoten aggregiert und die geteilte Blocklist verteilt.

Im Mai 2026 ist die wichtigste Neuerung der AI-Bouncer, der im Q1 2026 produktiv ausgerollt wurde. Ein leichtes ML-Modell läuft lokal auf dem Agent und erkennt verhaltensbasierte Anomalien jenseits klassischer Regel-Schwellenwerte: Anfragerate, Pfad-Sequenzen, User-Agent-Drift, Header-Anomalien. Es fängt Angreifer, die unter den klassischen Triggern bleiben (zum Beispiel 1 Login-Versuch pro Minute statt 5 pro Minute) und damit von Fail2ban oder reinen Pattern-Matching-WAFs übersehen werden. Der AI-Bouncer ist in der Community Edition kostenlos enthalten.

Warum es für CH-KMU und Treuhand zählt

Drei Argumente machen CrowdSec im Mai 2026 zur Pflicht-Schicht für jeden CH-KMU-Server mit öffentlicher Erreichbarkeit.

Bedrohungslage: Ein typischer Hetzner- oder Infomaniak-Server sieht 200 bis 5000 fehlgeschlagene Login-Versuche pro Tag, automatisierte WordPress-Scans, SSH-Bruteforce aus Botnets, API-Token-Burn-Angriffe. Eine reine Netzwerk-Firewall (UFW/nftables) hilft nicht, weil die Pakete formal valide sind und die Anwendung antworten muss. CrowdSec dropt die Pakete nach 3 bis 5 Fehlversuchen in iptables, bevor sie die Anwendung erreichen. Die CPU-Last des Servers sinkt messbar, echte Vorfälle werden in den Logs wieder sichtbar.

Regulatorischer Bezug: Art. 8 revFADP verlangt Schutzmassnahmen nach dem Stand der Technik. Der EDÖB-Leitfaden führt Firewall und Brute-Force-Schutz explizit unter den technischen und organisatorischen Mindestmassnahmen. Wer einen Mandantenportal-Server ohne dokumentierten Intrusion-Detection-Layer betreibt, erfüllt die Sorgfaltspflicht nach Art. 717 OR für Verwaltungsräte nicht. Cyber-Versicherungen (Helvetia, Mobiliar, AXA, Zurich) verlangen seit 2025 dokumentierte Massnahmen gegen Brute-Force-Angriffe -- CrowdSec liefert per cscli decisions list eine auditierbare Liste.

Treuhand-Fit: Anwaltskanzleien und Treuhand-Büros mit Berufsgeheimnis-Pflicht nach StGB Art. 321 müssen verhindern, dass Dritte unautorisiert auf Mandantenakten zugreifen. Ein offener nginx-Endpunkt ohne Brute-Force-Schutz erfüllt diesen Standard nicht. Die kollaborative Blocklist liefert dabei einen Vorteil, den lokales Tooling nie erreicht: Botnets, die heute auf einem Server in Frankreich gesehen werden, sind bei dem Schweizer Mandantenportal bereits gesperrt, bevor sie überhaupt einen ersten Versuch starten. Im Mai 2026 mit über 2 Millionen aktiven IPs auf der Crowd-Liste deckt das den Grossteil der automatisierten Angriffsfläche ab.

Architektur und Docker-Compose-Setup

CrowdSec läuft als systemd-Service oder als Docker-Container. Wir zeigen das produktive Docker-Compose-Setup, das wir bei Fairlane für Mandanten-Deployments einsetzen.

```yaml version: "3.8" services: crowdsec: image: crowdsecurity/crowdsec:latest container_name: crowdsec restart: unless-stopped environment: - COLLECTIONS=crowdsecurity/nginx crowdsecurity/sshd crowdsecurity/linux - GID=1000 volumes: - ./crowdsec-config:/etc/crowdsec - ./crowdsec-data:/var/lib/crowdsec/data - /var/log/nginx:/var/log/nginx:ro - /var/log/auth.log:/var/log/auth.log:ro ports: - "127.0.0.1:8080:8080" bouncer-firewall: image: crowdsecurity/firewall-bouncer:latest container_name: cs-firewall-bouncer restart: unless-stopped network_mode: host cap_add: - NET_ADMIN - NET_RAW volumes: - ./bouncer-config:/etc/crowdsec/bouncers ```

Der Agent-Container liest die Logs read-only über Bind-Mounts. Acquis-Konfiguration in /etc/crowdsec/acquis.yaml definiert die Log-Quellen pro Service. Parser zerlegen die Log-Zeilen via grok-Patterns in strukturierte Events (source_ip, request_path, status_code). Scenarios sind YAML-Regeln, die Bedingungen matchen -- das Standard-Scenario http-bruteforce feuert bei 10 fehlgeschlagenen Logins in 60 Sekunden und sperrt die IP für 4 Stunden.

Die Console-Anbindung erfolgt per cscli console enroll <key>. Damit wird der Knoten Teil des Netzwerks: er empfängt die Crowd-Blocklist (Update alle 15 Minuten) und meldet eigene Decisions anonymisiert zurück. In der Community Edition ist das gratis bis 3 Maschinen pro Account; ab Mai 2026 mit Premium-Tier bis 25 Maschinen ohne Aufpreis für kleine KMU-Setups.

Wichtige cscli-Befehle: cscli decisions list zeigt aktive Sperren mit Quelle, Dauer und Scenario. cscli alerts list listet historische Vorfälle. cscli metrics zeigt verarbeitete Events pro Parser und Scenario. cscli bouncers add <name> registriert einen neuen Bouncer mit eindeutigem Token. cscli decisions delete --ip <ip> entsperrt manuell.

Die AI-Bouncer-Erweiterung wird via cscli hub install crowdsecurity/ai-anomaly-detection nachinstalliert und benötigt etwa 50 MB zusätzlich an Speicher. Das Modell wird monatlich nachtrainiert auf Basis der globalen Telemetrie und dann an alle Knoten verteilt -- keine Inference-API-Calls nach aussen, keine Mandantendaten verlassen den Server.

CrowdSec-Setup in 5 Schritten

1. 01Netzwerk-Firewall härten: ufw default deny incoming, ufw allow 22/2847/80/443, SSH-Public-Key-Auth aktivieren, Whitelist für Office-IP setzen.
2. 02CrowdSec installieren via Docker-Compose oder curl -s https://install.crowdsec.net | sudo sh; Collections für nginx, sshd, linux installieren.
3. 03Bouncer aufsetzen: cs-firewall-bouncer für iptables-DROP plus cs-nginx-bouncer für Layer-7-Block; Bouncer-Tokens via cscli bouncers add erzeugen.
4. 04Console verbinden via cscli console enroll <key>, Crowd-Blocklist aktivieren, AI-Bouncer via cscli hub install crowdsecurity/ai-anomaly-detection nachinstallieren.
5. 05Whitelist und Observe-Mode: Office-IP, Monitoring-IPs, Health-Check-Endpunkte unter scenarios/whitelists.yaml eintragen; AI-Bouncer 1-2 Wochen im Observe-Mode laufen lassen, dann scharf schalten.

Wann CrowdSec einsetzen

CrowdSec gehört auf jeden Linux-Server mit öffentlicher Erreichbarkeit und mehreren Anwendungen. Konkrete Trigger für eine Installation: (a) der Server hat einen Login-Endpunkt (Nextcloud, Bitwarden, Mandantenportal, Admin-Backend), (b) der Server fährt eine API mit kostenpflichtigen Calls (OpenAI, Anthropic, Stripe), bei der Token-Burn-Angriffe direkt Kosten verursachen, (c) der Server hat einen Mail-Service (postfix), der gegen Auth-Brute-Force geschützt werden muss, (d) mehrere Server sollen sich gegenseitig Threat-Intel teilen.

Gute Eignung für typische KMU-Stacks: Hetzner-Cloud mit Docker-Compose und n8n/Grafana/Qdrant; Infomaniak Public Cloud mit eigenen Anwendungen; ein selbst gehosteter Nextcloud-Server für Mandantenakten; ein Treuhand-Portal auf Cloudron oder Coolify. Im Vergleich zu Fail2ban bringt CrowdSec drei Vorteile: kollaborative Blocklist (90 Prozent der Brute-Force-Versuche sind bereits gesperrt, bevor sie überhaupt am Server ankommen), klare Trennung von Agent und Bouncer (mehrere Bouncer parallel möglich), YAML-Scenarios statt Fail2ban-Regex in INI-Files.

Für Mai 2026 explizit empfohlen: KMU mit 2-10 Servern, die heterogene Workloads betreiben (Webserver plus API plus Mail). Der Console-Sync sorgt dafür, dass ein Angriff auf den Webserver automatisch zu einer Sperre auf dem Mail-Server führt. AI-Bouncer aktivieren -- der Mehrwert gegenüber reiner Regel-Erkennung ist im Pilot bei Fairlane signifikant (etwa 15 Prozent zusätzliche Detection-Rate ohne false-positive-Anstieg).

Wann CrowdSec nicht passt

Drei Fälle, in denen CrowdSec nicht die richtige Wahl ist.

Erstens: reine statische Marketing-Site ohne Login und ohne API hinter Cloudflare. Cloudflare WAF deckt die Angriffsmuster bereits ab, eine zusätzliche CrowdSec-Schicht bringt wenig Mehrwert. UFW plus Cloudflare WAF reicht; CrowdSec wäre überzogen.

Zweitens: Mini-VPS unter 512 MB RAM oder Single-Core mit weniger als 0.5 vCPU. CrowdSec braucht etwa 200 MB RAM und einen halben CPU-Kern für eine produktive Konfiguration mit AI-Bouncer. Auf einem 512-MB-VPS ist das spürbar; für solche Mikro-Setups bleibt Fail2ban die richtige Wahl.

Drittens: streng compliance-getrieben mit Verbot von Cloud-API-Aufrufen ausserhalb der Schweiz. CrowdSec Community Edition sendet anonymisierte Telemetrie (IP-Hash plus Scenario-Name) an die Console in Frankreich. Wer diese Verbindung verbieten muss (FINMA-Hochrisiko-Mandate, bestimmte Anwaltskanzlei-Konstellationen), kann CrowdSec im Offline-Modus betreiben -- verliert dann allerdings den entscheidenden Crowd-Vorteil und liegt funktional bei Fail2ban-Niveau.

Generelle Fallen, die wir bei Mandanten gesehen haben: (a) zu aggressive Scenarios bauen, die false positives produzieren -- der eigene Health-Check fällt unter eine Bruteforce-Regel und der Loadbalancer wird gebannt. (b) Bouncer auf einem System aktivieren, ohne den Admin-Zugang per Whitelist zu schützen -- man sperrt sich selbst aus, sobald das eigene Office-VPN als Tor-Exit-Node-Match gewertet wird. (c) AI-Bouncer ohne Beobachtungs-Modus direkt mit Block-Aktion aktivieren -- ein bis zwei Wochen Observe-Mode mit Tagging statt Block ist Pflicht, um false positives zu kalibrieren.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. CrowdSec Documentation -- Getting Started and Reference · 2026-05
2. CrowdSec Hub -- Scenarios, Parsers, Collections · 2026-05
3. CrowdSec Blog -- AI Bouncer release Q1 2026 · 2026-04
4. EDÖB -- Technische und organisatorische Massnahmen · 2026-04
5. BSI IT-Grundschutz NET.3.2 Firewall · 2026-03