Crowdsec auf Debian 13 einrichten: Crowd-basierte Intrusion Detection mit Live-Threat-Sharing. Die moderne fail2ban-Alternative für SSH, Nginx, Traefik und mehr — mit globaler Blocklist.
💡 Hinweis: Dieses Tutorial setzt voraus, dass du einen normalen Benutzer mit sudo-Rechten verwendest — wie im Tutorial Debian 13 Server absichern beschrieben.
Einleitung — Was ist Crowdsec?
Wer einen Server im Internet betreibt, kennt das Schauspiel: Innerhalb von Minuten nach dem Start landen die ersten Brute-Force-Versuche auf SSH. Bots scannen Nginx nach bekannten Exploit-Pfaden. Login-Formulare werden mit Credential-Stuffing-Listen geflutet. Klassische Lösung: fail2ban — gut, aber technisch etwas in die Jahre gekommen und arbeitet komplett alleine.
Crowdsec ist die moderne Alternative. Es analysiert eure Logs nach Angriffsmustern (genau wie fail2ban), aber zusätzlich teilt es bestätigte Angreifer-IPs anonym mit der Crowdsec-Community. Im Gegenzug bekommt ihr eine globale Blocklist mit IPs, die woanders bereits negativ aufgefallen sind. Ein Angreifer, der gestern jemand anderen attackiert hat, wird heute bei euch schon vor dem ersten Versuch geblockt.
Was Crowdsec kann
- Log-Analyse in Echtzeit — SSH, Nginx, Apache, Traefik, MySQL, PostgreSQL und 50+ weitere Services
- Crowd-Intelligence — Globale Blocklist mit bestätigten Angreifern
- Bouncer — Modulare Reaktion (firewall, nginx-block, captcha, ban)
- Hub-System — Vorgefertigte Szenarien für gängige Angriffe
- Web-Console — Übersicht aller Decisions, Alerts, Metrics
- REST-API — Eigene Bouncer und Integrations bauen
- Performance — Geschrieben in Go, sehr leichtgewichtig
- Distributed — Multi-Server-Setups mit zentralem LAPI möglich
Crowdsec vs. fail2ban
| Feature | Crowdsec | fail2ban |
|---|---|---|
| Log-Parsing | YAML-basiert, modular | Regex-basiert |
| Crowd-Intelligence | Ja | Nein |
| Performance | Sehr gut (Go) | Mittel (Python) |
| Updates für Filter | cscli hub upgrade | Manuell |
| Web-Dashboard | Ja (Cloud-Console) | Nein |
| Bouncer-Modell | Modular, getrennt | In fail2ban verbaut |
| Captcha-Challenges | Ja (für Web) | Nein |
| Multi-Server | Ja, nativ | Komplex |
fail2ban ist nicht schlecht — es ist nur älter und limitierter. Wer heute neu aufsetzt, sollte Crowdsec wählen.
In diesem Guide richten wir Crowdsec auf Debian 13 ein, schützen damit SSH und Nginx, integrieren einen Firewall-Bouncer und verbinden den Server mit der Crowdsec-Cloud-Console.
Architektur des Setups
[Eingehender Traffic]
↓
[Server: SSH, Nginx, Apache, ...]
↓ schreibt Logs
[Crowdsec Agent] ← analysiert Logs nach Mustern
↓ erkennt Angriff
[Local API (LAPI)] ← speichert Decisions
↓ informiert
[Bouncer] ← blockiert IP via iptables/nftables
↓
[Geblockte IP]
↑
[Crowdsec Cloud] ← Anonyme Telemetrie + Blocklist-Sync- Agent — Liest Logs, erkennt Angriffe
- LAPI — Entscheidet, was passieren soll
- Bouncer — Setzt Entscheidungen um (Firewall, Nginx-Modul, Custom)
- Cloud-Console (optional) — Web-UI, Threat-Sharing
Voraussetzungen
- Debian 13 (Trixie) — siehe Debian 13 Server-Guide
- Eine zu schützende Anwendung — SSH läuft sowieso, weitere wie Nginx oder Traefik je nach Setup
- Optional: Account auf
app.crowdsec.net— kostenlose Cloud-Console
💡 Hinweis: Crowdsec funktioniert vollständig ohne Cloud-Account. Die Console ist optional, aber für Übersicht und Threat-Intel sehr praktisch.
Schritt 1: Crowdsec installieren
Wir nutzen das offizielle Crowdsec-Repository:
curl -s https://install.crowdsec.net | sudo sh
sudo apt install -y crowdsecCrowdsec startet automatisch und installiert dabei Standard-Collections für Linux-Logs, SSH und systemd.
Status prüfen
sudo systemctl status crowdsec
sudo cscli metricsBei metrics solltet ihr eine Tabelle mit Datenströmen sehen. Crowdsec liest schon eure Logs.
Schritt 2: Hub-Übersicht und installierte Komponenten
Crowdsec ist modular. Es gibt Collections (Themenpakete), die aus Parsers (Log-Verständnis) und Scenarios (Angriffsmuster) bestehen.
sudo cscli collections list
sudo cscli parsers list
sudo cscli scenarios listWas schon installiert ist:
crowdsecurity/linux— Allgemeine Linux-Logscrowdsecurity/sshd— SSH-Brute-Forcecrowdsecurity/iptables— Firewall-Logs
Hub-Updates regelmäßig holen
Filter-Definitionen werden ständig verbessert. Updates holen:
sudo cscli hub update
sudo cscli hub upgradeSchritt 3: Den ersten Bouncer installieren — Firewall
Crowdsec erkennt Angriffe, aber es blockt sie nicht direkt. Dafür sind Bouncer da. Der wichtigste: der Firewall-Bouncer, der per iptables/nftables IPs blockt.
sudo apt install -y crowdsec-firewall-bouncer-iptables(Auf modernen Systemen mit nftables alternativ crowdsec-firewall-bouncer-nftables.)
Während der Installation registriert sich der Bouncer automatisch beim lokalen LAPI.
Status prüfen
sudo systemctl status crowdsec-firewall-bouncer
sudo cscli bouncers listIn bouncers list sollte ein Eintrag mit valid: ✔️ stehen.
✅ Geschafft! Crowdsec analysiert Logs und ein Bouncer setzt Entscheidungen in Firewall-Regeln um. Ihr seid bereits geschützt — die Standardszenarien decken SSH und einige Linux-spezifische Angriffe ab.
Schritt 4: Crowdsec mit der Cloud-Console verbinden — optional
Mit einem kostenlosen Account auf app.crowdsec.net bekommt ihr ein Web-Dashboard und Live-Threat-Intel.
Account erstellen, dann im Console-Dashboard auf Add Engine klicken. Dort gibt es einen enroll-Befehl wie:
sudo cscli console enroll EUER_ENROLLMENT_TOKENIm Browser den Server nochmal akzeptieren — und ab sofort taucht er im Dashboard auf, mit Live-Metriken, Decisions, Alerts und Hub-Status.
💡 Tipp: Die Cloud-Console ist für Privatpersonen kostenlos. Sie zeigt euch, welche Angriffe gerade laufen, welche IPs in eurer Blocklist stehen und wie eure Filter performen. Sehr empfehlenswert.
Schritt 5: Nginx mit Crowdsec schützen
Falls ihr Nginx als Reverse Proxy nutzt, gibt es eine eigene Collection dafür:
sudo cscli collections install crowdsecurity/nginx
sudo systemctl restart crowdsecNginx-Logs für Crowdsec sichtbar machen
Crowdsec liest die Logs aus /var/log/nginx/access.log und error.log. Das ist der Default — falls ihr custom Pfade habt, müsst ihr das in der Acquisition-Config eintragen:
sudo nano /etc/crowdsec/acquis.yamlBeispiel-Inhalt:
filenames:
- /var/log/nginx/<strong>*.log</strong>
labels:
type: nginx
---
filenames:
- /var/log/auth.log
labels:
type: syslogCrowdsec neu laden:
sudo systemctl restart crowdsec
sudo cscli metricsIn den Metrics solltet ihr jetzt Nginx-Acquisition mit hoffentlich vielen Reads sehen.
Test: Nginx-Angriff simulieren
Auf einem zweiten Rechner:
# Mehrfache 404-Anfragen (ein typisches Bot-Muster)
for i in {1..30}; do curl -s "https://eure-domain.com/wp-admin.php" > /dev/null; doneAuf dem Server prüfen:
sudo cscli alerts list
sudo cscli decisions listWenn alles funktioniert, sollte eure Test-IP gelistet sein.
Schritt 6: Web-Bouncer für Captcha-Challenges (optional)
Manche Angreifer sind nicht eindeutig böse — z.B. Bots, die einfach zu schnell scrapen. Statt direkt zu blocken könnt ihr einen Captcha vorschalten.
sudo apt install -y crowdsec-nginx-bouncerDie Installation richtet ein Lua-Modul für Nginx ein. Nach dem Setup wird jede Anfrage von verdächtigen IPs erst durch ein Captcha geprüft.
💡 Hinweis: Der nginx-bouncer braucht OpenResty oder Nginx mit
lua-nginx-module. Die Standard-nginx-Pakete von Debian haben das nicht — die Crowdsec-Repository-Variante kommt damit aber out-of-the-box.
Die Standard-Konfiguration steht unter /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf und kann fein-getuned werden (Captcha-Provider hCaptcha/reCAPTCHA, Schwellwerte, Whitelists).
Schritt 7: Custom Whitelists
Es kommt vor, dass ihr selbst getriggert werdet (z.B. bei aggressiven SSH-Tests von eurer Heim-IP). Damit das nicht passiert:
sudo nano /etc/crowdsec/parsers/s02-enrich/00-whitelist-custom.yamlInhalt:
name: crowdsecurity/whitelists-custom
description: "Whitelist für eigene IPs"
whitelist:
reason: "Eigene Heim-IP"
ip:
- "EURE_HEIM_IP"
- "EURE_VPN_IP"
cidr:
- "192.168.1.0/24"
- "10.0.0.0/8"Crowdsec neu laden:
sudo systemctl reload crowdsecAnfragen aus diesen IPs werden niemals als Angriff gewertet.
⚠️ Wichtig: Whitelists sind mächtig — eine falsch eingetragene IP kann Schutz aushebeln. Prüft IPs zweimal und benutzt CIDR-Blöcke nur, wenn ihr wirklich ein ganzes Netz freigeben wollt.
Schritt 8: Decisions verwalten
Aktuelle Bans anzeigen
sudo cscli decisions listIP manuell bannen
sudo cscli decisions add --ip 1.2.3.4 --duration 24h --reason "manuell geblockt"IP entbannen
sudo cscli decisions delete --ip 1.2.3.4Alle Bans löschen (Vorsicht!)
sudo cscli decisions delete --allSchritt 9: Globale Blocklists abonnieren
Crowdsec bietet kuratierte Blocklists, die ihr mit einem Befehl abonniert. Im Cloud-Console-Dashboard:
- Blocklists → Free → CrowdSec Community Blocklist
- Klick auf Subscribe
Auf dem Server:
sudo cscli capi register
sudo systemctl restart crowdsecJetzt importiert euer Server stündlich tausende bekannter Angreifer-IPs aus der Community.
sudo cscli decisions list -t communityzeigt euch, was aktuell aus der Community-Liste aktiv ist.
Performance & Monitoring
Crowdsec selbst ist sehr leichtgewichtig — typisch unter 100 MB RAM und sehr wenig CPU.
sudo cscli metrics
sudo systemctl status crowdsecFür tiefes Monitoring exportiert Crowdsec Prometheus-Metriken auf http://127.0.0.1:6060/metrics — perfekt für ein späteres Grafana-Setup.
💡 Tipp: Wenn ihr Prometheus + Grafana bereits laufen habt, gibt es offizielle Grafana-Dashboards für Crowdsec. Sehr nützlich, um Angriffsmuster über Zeit zu sehen.
Backups
Crowdsec speichert Konfiguration in /etc/crowdsec/ und Daten in /var/lib/crowdsec/.
Was muss gesichert werden?
/etc/crowdsec/— Konfiguration, Whitelists, Custom-Scenarios/var/lib/crowdsec/data/crowdsec.db— SQLite-Datenbank mit Decisions- Liste der installierten Hub-Komponenten
Automatisches Backup-Script
sudo nano /usr/local/bin/crowdsec-backup.shInhalt:
#!/bin/bash
set -e
BACKUP_DIR="/var/backups/crowdsec"
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
RETENTION_DAYS=14
mkdir -p "$BACKUP_DIR"
# Crowdsec-eigenes Backup-Tool
sudo cscli config backup "$BACKUP_DIR/cscli-$TIMESTAMP"
# Konfiguration & Datenbank zusätzlich tarren
tar -czf "$BACKUP_DIR/files-$TIMESTAMP.tar.gz" \
/etc/crowdsec /var/lib/crowdsec/data <strong>2</strong>>/dev/null
find "$BACKUP_DIR" -type f -mtime +$RETENTION_DAYS -delete
find "$BACKUP_DIR" -type d -mtime +$RETENTION_DAYS -exec rm -rf {} + 2>/dev/null || true
echo "Backup completed: $TIMESTAMP"Mit systemd Timer automatisieren — wie in unserem restic Backup-Tutorial beschrieben.
sudo chmod +x /usr/local/bin/crowdsec-backup.shWiederherstellung
sudo cscli config restore /var/backups/crowdsec/cscli-DATUM
sudo systemctl restart crowdsecUpdates
# Hub-Komponenten aktualisieren (Filter, Szenarien)
sudo cscli hub update
sudo cscli hub upgrade
# Crowdsec selbst aktualisieren
sudo apt update && sudo apt upgrade crowdsec crowdsec-firewall-bouncer-iptables
sudo systemctl restart crowdsec
sudo systemctl restart crowdsec-firewall-bouncer💡 Empfehlung: Hub-Updates (
hub upgrade) solltet ihr wöchentlich automatisieren. Neue Angriffsmuster tauchen ständig auf — eure Filter müssen aktuell bleiben. Per systemd-Timer in 5 Zeilen erledigt.
Zusammenfassung & Checkliste
| Schritt | Status |
|---|---|
| Debian 13 Server eingerichtet | ☐ |
| Crowdsec über offizielles Repository installiert | ☐ |
cscli metrics zeigt aktive Acquisition | ☐ |
| Firewall-Bouncer installiert und registriert | ☐ |
| Cloud-Console verbunden (optional) | ☐ |
| Nginx-Collection installiert (falls Nginx im Einsatz) | ☐ |
| Whitelist mit eigenen IPs angelegt | ☐ |
| Test-Angriff erkannt und gebannt | ☐ |
| Community-Blocklist aktiviert | ☐ |
| Hub-Update-Automatisierung eingerichtet | ☐ |
| Backup-Script eingerichtet | ☐ |
| Backup einmal manuell getestet | ☐ |
Troubleshooting
Crowdsec startet nicht
sudo systemctl status crowdsec
sudo journalctl -u crowdsec -fHäufigste Ursachen:
- Syntax-Fehler in
acquis.yaml(YAML ist whitespace-sensitiv!) - Log-Datei in
acquis.yamlexistiert nicht - SQLite-DB korrupt →
sudo rm /var/lib/crowdsec/data/crowdsec.db && sudo systemctl restart crowdsec
Bouncer kann sich nicht verbinden
sudo cscli bouncers list
sudo systemctl status crowdsec-firewall-bouncer
sudo journalctl -u crowdsec-firewall-bouncer -f- Token in
/etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yamlkorrekt? - LAPI lauscht?
sudo ss -tlnp | grep 8080
Eigene IP ist gebannt
sudo cscli decisions delete --ip EURE_IPWhitelist erweitern (siehe Schritt 7), dann Crowdsec neu laden.
Nginx-Logs werden nicht analysiert
- Pfad in
acquis.yamlkorrekt? - Hat Crowdsec Lese-Rechte?
sudo -u crowdsec cat /var/log/nginx/access.logtesten - Ist die
crowdsecurity/nginx-Collection installiert?
„could not communicate with the central API“
- Internet-Verbindung vorhanden?
ping app.crowdsec.net - Firewall blockiert ausgehende HTTPS-Verbindungen?
- Token noch gültig? Falls nicht:
sudo cscli capi register
Bot-Welle trotz Crowdsec — was tun?
- Aggressivere Szenarien aktivieren:
sudo cscli scenarios install crowdsecurity/http-crawl-non_statics - Community-Blocklist abonnieren (siehe Schritt 9)
- Captcha-Bouncer einsetzen (siehe Schritt 6)
Nächste Schritte
Crowdsec läuft — und jetzt? Hier sind sinnvolle nächste Schritte:
- Crowdsec mit Traefik integrieren — Eigener Bouncer für Traefik
- Multi-Server-Setup — Ein zentrales LAPI für mehrere Server
- Custom-Scenarios schreiben — Eigene Angriffsmuster erkennen
- Slack/Discord-Notifications — Alerts in eure Chats
- Geo-Blocking — Komplette Länder ausschließen
- Integration mit Wazuh oder Graylog — Zentrales Security-Dashboard
Crowdsec ist ein riesiger Schritt vorwärts gegenüber fail2ban — moderne Architektur, Crowd-Intelligence und ein aktives Ökosystem. Die offizielle Dokumentation ist sehr gut.
Habt ihr Fragen oder Probleme? Schreibt es in die Kommentare — ich helfe gerne!
