Parst Logs, erkennt Szenarien und erzeugt Alerts.
CrowdSec
CrowdSec zentral für mehrere Server betreiben
Eine zentrale CrowdSec-LAPI bündelt Security-Signale aus mehreren Servern. Agents analysieren Logs, Bouncer setzen Decisions durch, und Dashboards machen Angriffe sichtbar. Dieser Guide erklärt den operativen Aufbau, typische Fehler und sinnvolle Debugging-Schritte.
Architektur
Erkennung, Entscheidung und Durchsetzung sauber trennen.
CrowdSec besteht operativ aus mehreren Rollen: Agents lesen und analysieren Logs, die LAPI verwaltet Maschinen, Alerts und Decisions, und Bouncer setzen diese Decisions technisch durch. Erst wenn diese Rollen sauber zusammenspielen, entsteht ein belastbares Multi-Server-Security-Setup.
Verwaltet Machines, Bouncer, Alerts und Decisions.
Blockt oder limitiert Traffic über Firewall, Traefik oder andere Integrationen.
Macht Angriffe, Quellen, Szenarien und Trends sichtbar.
Zentrale LAPI
Warum eine zentrale LAPI sinnvoll ist.
Bei mehreren Servern wird lokale Einzelerkennung schnell unübersichtlich. Eine zentrale LAPI schafft eine gemeinsame operative Sicht: Welche Server melden, welche Bouncer sind aktiv, welche Quellen werden geblockt, und welche Szenarien feuern?
Server eindeutig registrieren
Jeder Agent braucht eine eigene Machine-Registrierung. Namen sollten sprechend sein, damit später klar ist, welcher Server welche Events liefert.
Durchsetzung kontrollieren
Jeder Bouncer hat eigene Credentials. Dadurch kann man gezielt rotieren, sperren und nachvollziehen, welche Komponente Entscheidungen abfragt.
Blockierungen nachvollziehen
Decisions zeigen, welche IP oder Range blockiert wird, warum, wie lange und durch welches Szenario die Entscheidung entstanden ist.
Angriffsmuster sehen
Alerts helfen bei der Analyse: Brute Force, Scanner, Web-Angriffe, aggressive Bots oder wiederkehrende Quellen.
Zugriffe sauber verwalten
Credentials gehören nicht wild kopiert. Sie müssen pro Agent/Bouncer dokumentiert und sicher verteilt werden.
Betrieb sichtbar machen
Metriken und Dashboards zeigen, ob die Security Engine arbeitet oder ob Komponenten still kaputt sind.
Inventar
Machines und Bouncer prüfen.
Der erste Check bei CrowdSec-Problemen ist immer das Inventar. Sind die Machines registriert? Sind die Bouncer vorhanden? Gibt es alte, doppelte oder falsch benannte Einträge?
Registrierungen anzeigen
cscli machines list
cscli bouncers list
cscli decisions list
cscli alerts list
Wenn viele alte Bouncer oder Machine-Namen herumliegen, wird Troubleshooting unnötig schwer. Saubere Namen sind kein Luxus, sondern Betriebsdisziplin.
Credentials
401 ist fast immer ein Credentials-Problem.
Wenn ein Agent oder Bouncer mit 401 Unauthorized scheitert, spricht er
meistens mit falschen Credentials, gegen die falsche LAPI oder nutzt eine kaputte
YAML-Datei.
Credential-Dateien kontrollieren
cat /etc/crowdsec/local_api_credentials.yaml
cat /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml
grep -R "url:" /etc/crowdsec/
file /etc/crowdsec/*.yaml
Besonders tückisch sind Windows-Zeilenenden. Wenn eine YAML-Datei per Copy/Paste
oder Windows-Editor verändert wurde, kann dos2unix notwendig sein.
Fehlerbild 403
Wenn die Middleware plötzlich legitime Requests blockt.
Ein 403 Forbidden kann korrekt sein — oder ein Hinweis auf eine zu aggressive
Bouncer-Entscheidung. Wenn eine Website vorher funktioniert hat und plötzlich 403 liefert,
sollte die CrowdSec-Middleware temporär isoliert getestet werden.
Router matcht, aber Middleware oder Bouncer blockt den Request.
Temporär nur Security-Headers aktiv lassen und CrowdSec aus der Route nehmen.
cscli decisions list und Bouncer-Logs auswerten.
False Positive löschen, Szenario prüfen oder Whitelist sauber setzen.
Firewall-Bouncer
Docker-Hosts brauchen besondere Aufmerksamkeit.
Auf klassischen Hosts kann ein Firewall-Bouncer zuverlässig Traffic blockieren. Auf Docker-Hosts ist die Lage komplexer, weil Docker eigene NAT- und Filterregeln erstellt. Veröffentlichte Container-Ports können anders wirken als erwartet.
DOCKER-USER prüfen
iptables -S DOCKER-USER
iptables -L DOCKER-USER -n -v
nft list ruleset
Wenn eine Decision existiert, der Containerdienst aber weiterhin erreichbar ist, greift die Blockierung wahrscheinlich nicht an der richtigen Stelle.
Traefik-Bouncer
Webtraffic direkt am Reverse Proxy stoppen.
Ein Traefik-Bouncer kann Webrequests blockieren, bevor sie den Backend-Service erreichen. Das ist besonders sinnvoll bei öffentlich erreichbaren Webdiensten, APIs und Dashboards.
Middleware prüfen
docker service inspect SERVICE --pretty
curl -s http://127.0.0.1:8082/api/http/routers | jq
docker logs traefik --tail=100 | grep -i crowdsec
Wichtig ist die Reihenfolge und Zielsetzung der Middleware: Security-Headers, Auth, Rate-Limits und CrowdSec müssen bewusst kombiniert werden.
Betriebs-Checkliste
Was im Multi-Server-Betrieb sitzen muss.
CrowdSec funktioniert nur zuverlässig, wenn Konfiguration, Erreichbarkeit, Credentials und Durchsetzung regelmäßig geprüft werden.
LAPI kontrollieren
- Listen-Adresse dokumentieren
- Port und Firewall prüfen
- Machines sauber benennen
- Logs regelmäßig auswerten
Credentials pflegen
- Je Bouncer eigenen Key nutzen
- Keine CRLF-Dateien
- Alte Keys entfernen
- Rotation dokumentieren
Durchsetzung testen
- Decisions erzeugen und prüfen
- Firewall-Ketten kontrollieren
- Traefik-Middleware isoliert testen
- False Positives korrigieren
Troubleshooting
Die häufigsten CrowdSec-Fehlerbilder.
Die meisten Probleme lassen sich schnell eingrenzen, wenn man den Fehlercode korrekt liest.
Unauthorized
Falscher API-Key, falsche Credentials-Datei, falsche LAPI-URL oder kaputte YAML-Datei.
Forbidden
Middleware oder Bouncer blockt. Decisions prüfen und CrowdSec testweise isolieren.
LAPI nicht erreichbar
Port blockiert, falsche Listen-Adresse, Firewall-Regel fehlt oder Service läuft nicht.
Decision greift nicht
Docker-NAT oder falsche Firewall-Kette verhindert, dass die Blockierung den Container erreicht.
Config kaputt
Einrückung, Tabs, CRLF oder falsche Werte brechen Agent- oder Bouncer-Konfigurationen.
Falsche LAPI-Adresse
Agent oder Bouncer spricht mit localhost, obwohl die zentrale LAPI auf einem anderen Host läuft.
Live Threat Observatory
Aus Security-Events wird ein sichtbares Lagebild.
Ein öffentliches Dashboard kann technische Angriffsmuster sichtbar machen, ohne interne Details offenzulegen. Sinnvoll sind aggregierte Zahlen, Szenarien, Länder/ASN-Auswertung, Trends und geblockte Quellen — aber keine sensiblen Hostdetails.
Welche Szenarien feuern auf welchen Diensten?
Welche IPs werden blockiert und wie lange?
Aus welchen Netzen und Regionen kommt Aktivität?
Aggregierte Daten werden als Threat Observatory sichtbar.
Fazit
CrowdSec wird stark, wenn Betrieb und Architektur sauber sind.
Eine zentrale LAPI, sprechende Komponenten-Namen, kontrollierte Credentials, geprüfte Bouncer und sichtbare Metriken machen aus CrowdSec ein belastbares Security-Werkzeug für Multi-Server-Umgebungen.