CrowdSec mit Docker installieren: Community-IDS/IPS für Ihren Linux-Server

Jeder öffentlich erreichbare Linux-Server sieht laufend SSH-Bruteforce-Versuche und automatisierte Web-Scans. CrowdSec ist ein quelloffenes IDS/IPS (Intrusion Detection und Prevention System): Es erkennt Angriffe in Logdateien und lässt sie über einen Bouncer blockieren. Erkannte Angreifer-IPs fließen in eine gemeinsame Community-Blockliste. Diese Anleitung richtet die Security Engine in Version 1.8.1 (September 2026) als Docker-Container ein und installiert den Firewall-Bouncer als Paket direkt auf dem Host, weil er iptables bzw. nftables des Host-Kernels ändern muss.

Voraussetzungen

1. Linux-Host mit Root-/sudo-Zugriff: Ubuntu 22.04/24.04 oder Debian 12/13, x86_64 oder ARM64. Windows und macOS scheiden für den Firewall-Bouncer aus (kein Linux-Kernel für iptables/nftables).
2. Docker Engine mit Docker Compose Plugin v2. Falls noch nicht vorhanden, hilft die Grundlage-Anleitung zu Docker und Docker Compose auf Linux.
3. 1 CPU-Kern und 512 MB freier RAM reichen für die Security Engine (im Test belegte der Container rund 35 MB RAM). Dazu etwa 500 MB Speicher für Image und Volumes.
4. Log-Dateien der zu schützenden Dienste auf dem Host: SSH-Logs unter /var/log/auth.log bzw. /var/log/secure, Nginx-Logs in /var/log/nginx/. Debian 12 und 13 schreiben ohne das Paket rsyslog kein auth.log, sondern nur ins Journal.
5. curl und apt (oder dnf) für den Firewall-Bouncer auf dem Host.
6. Optional: kostenloser Account auf app.crowdsec.net für die CrowdSec Console.

CrowdSec-Architektur verstehen

Ohne Bouncer werden Angriffe nur erkannt, aber nicht blockiert. Ein Bouncer als privilegierter Container wäre möglich, vergrößert aber die Angriffsfläche.

Schritt 1: Projektordner und acquis.yaml anlegen

Die acquis.yaml legt fest, welche Logs CrowdSec liest. Sie muss vor dem ersten Container-Start existieren, sonst verarbeitet CrowdSec keine Logs. Der Hersteller empfiehlt inzwischen alternativ einzelne Dateien in /etc/crowdsec/acquis.d/; die hier genutzte einzelne acquis.yaml funktioniert weiterhin (im Test mit 1.8.1 geprüft).

sudo mkdir -p /opt/crowdsec/crowdsec
cd /opt/crowdsec

Das folgende Beispiel überwacht SSH- und Nginx-Logs auf einem Ubuntu- oder Debian-Host:

# /opt/crowdsec/crowdsec/acquis.yaml
---
# SSH / Authentifizierungs-Logs (Ubuntu/Debian)
filenames:
  - /var/log/auth.log
labels:
  type: syslog
---
# Nginx Access- und Error-Logs
filenames:
  - /var/log/nginx/access.log
  - /var/log/nginx/error.log
labels:
  type: nginx

Passen Sie die Pfade an: Auf RHEL-Systemen heißt die Datei /var/log/secure. Logs von Proxy-Containern binden Sie über ein gemeinsames Volume ein.

Verifizieren: Die Datei existiert, und die eingetragenen Log-Pfade sind auf dem Host vorhanden:

ls -la /opt/crowdsec/crowdsec/acquis.yaml
# Erwartete Ausgabe: -rw-r--r-- 1 root root ... acquis.yaml

ls /var/log/auth.log /var/log/nginx/access.log
# Beide Dateien müssen vorhanden sein – sonst Pfad in acquis.yaml anpassen

Schritt 2: .env-Datei mit Konfiguration erstellen

Secrets gehören in die .env, nicht in die compose.yaml. Erzeugen Sie den Bouncer-Key als Hex-Zeichenkette; Sonderzeichen wie ! oder # führen beim Einlesen leicht zu Fehlern.

# 32-Zeichen-Key erzeugen:
openssl rand -hex 16
# /opt/crowdsec/.env

# Zeitzone des Hosts (für korrekte Log-Zeitstempel)
TZ=Europe/Berlin

# Gruppe der Log-Dateien (stat /var/log/auth.log)
GID=1000

# Collections: Space-separiert, mindestens linux + sshd
CROWDSEC_COLLECTIONS=crowdsecurity/linux crowdsecurity/sshd crowdsecurity/nginx

# Bouncer-Key: Ausgabe von openssl rand -hex 16
BOUNCER_KEY_FIREWALL=hier_ihren_generierten_key_eintragen

# Optional: CrowdSec-Console-Enrollment-Key (aus app.crowdsec.net)
# ENROLL_KEY=ihr-console-key

GID muss zur Gruppe der Log-Dateien passen: Die Zahl hinter „Gid:“ in stat /var/log/auth.log ist der Wert.

Verifizieren: Die Datei ist vorhanden, um das = stehen keine Leerzeichen, der Bouncer-Key enthält nur Hex-Zeichen:

cat /opt/crowdsec/.env
# Prüfen: BOUNCER_KEY_FIREWALL=... ist gesetzt und alphanumerisch

Schritt 3: compose.yaml erstellen

Die compose.yaml bindet die Log-Quellen-Konfiguration als Read-Only-Mount ein und definiert zwei Pflicht-Volumes. Seit v1.7.0 ist ein Volume für /var/lib/crowdsec/data Pflicht, sonst gehen Decisions und Alerts beim Neuerstellen verloren.

# /opt/crowdsec/compose.yaml
services:
  crowdsec:
    image: crowdsecurity/crowdsec:v1.8.1
    container_name: crowdsec
    restart: unless-stopped
    ports:
      # LAPI: NUR an 127.0.0.1 binden – niemals 0.0.0.0 exponieren!
      - "127.0.0.1:8080:8080"
      # Prometheus-Metriken: nur bei Bedarf auskommentieren
      # - "127.0.0.1:6060:6060"
    environment:
      COLLECTIONS: "${CROWDSEC_COLLECTIONS:-crowdsecurity/linux crowdsecurity/sshd}"
      GID: "${GID:-1000}"
      TZ: "${TZ:-Europe/Berlin}"
      # Bouncer automatisch beim Container-Start registrieren:
      BOUNCER_KEY_firewall: "${BOUNCER_KEY_FIREWALL}"
      # CrowdSec Console (optional):
      # ENROLL_KEY: "${ENROLL_KEY}"
    volumes:
      # Konfigurationsdateien (Parsers, Scenarios, Profiles):
      - crowdsec-config:/etc/crowdsec
      # Decisions-Datenbank (ab v1.7.0 Pflicht!):
      - crowdsec-data:/var/lib/crowdsec/data
      # Host-Logs (SSH, System) – Read-Only:
      - /var/log:/var/log:ro
      # Log-Quellen-Konfiguration:
      - ./crowdsec/acquis.yaml:/etc/crowdsec/acquis.yaml:ro
    networks:
      - crowdsec-net

networks:
  crowdsec-net:
    name: crowdsec-net

volumes:
  crowdsec-config:
  crowdsec-data:

Das Tag ist bewusst festgeschrieben (Pinning), damit Sie Updates kontrolliert einspielen. Die Slim-Variante (v1.8.1-slim) enthält keine GeoIP-Datenbank; Szenarien mit Geo-Bezug greifen dann nicht. Für SSH- und Nginx-Schutz reicht sie.

Verifizieren: docker compose config gibt die Konfiguration ohne Fehlermeldung aus:

cd /opt/crowdsec
docker compose config
# Ausgabe: die zusammengeführte Konfiguration ohne Fehlermeldungen

Schritt 4: Container starten und Collections prüfen

Beim ersten Start lädt CrowdSec die in COLLECTIONS genannten Pakete aus dem Hub (30 bis 60 Sekunden).

cd /opt/crowdsec
docker compose up -d
docker compose logs -f crowdsec

Im Log erscheinen Zeilen wie diese (Ausgabe aus dem Test mit 1.8.1):

level=info msg="Loaded 9 scenarios"
level=info msg="Adding file /var/log/auth.log to datasources"
level=info msg="Starting processing data"

Verifizieren: Container läuft, Collections und Bouncer sind registriert:

docker compose ps
# Erwartete Ausgabe:
# NAME       IMAGE                          STATUS
# crowdsec   crowdsecurity/crowdsec:v1.8.1  Up X minutes

# Installierte Collections prüfen:
docker exec crowdsec cscli collections list
# Erwartete Ausgabe: crowdsecurity/linux, crowdsecurity/sshd, crowdsecurity/nginx – alle "enabled"

# Bouncer bereits registriert (durch BOUNCER_KEY_firewall Env-Var):
docker exec crowdsec cscli bouncers list
# Erwartete Ausgabe: Bouncer "firewall", Spalte Valid mit Haken

# Werden Logs gelesen? (Lines read > 0, sobald neue Zeilen anfallen)
docker exec crowdsec cscli metrics show acquisition

Schritt 5: Firewall-Bouncer auf dem Host installieren

Installieren Sie den Firewall-Bouncer als Systempaket direkt auf dem Docker-Host, weil er iptables/nftables des Host-Kernels ändert. CrowdSec stellt dafür ein offizielles Paket-Repository bereit:

# CrowdSec-Repository einrichten (Debian/Ubuntu):
curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash

# Firewall-Bouncer passend zum Firewall-Backend installieren:
# Für iptables (Standard auf den meisten Ubuntu/Debian-Systemen):
sudo apt install -y crowdsec-firewall-bouncer-iptables

# Alternativ für nftables:
# sudo apt install -y crowdsec-firewall-bouncer-nftables

Tragen Sie in der Bouncer-Konfiguration den API-Key aus der .env ein:

sudo nano /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml

api_url: http://127.0.0.1:8080/
api_key: wert_von_BOUNCER_KEY_FIREWALL

# Wichtig für Docker-Container-Schutz: DOCKER-USER Chain ergänzen!
iptables_chains:
  - INPUT
  - FORWARD
  - DOCKER-USER

Ohne die Chain DOCKER-USER blockiert der Bouncer keinen Verkehr zu veröffentlichten Container-Ports, weil Docker diesen Verkehr an INPUT vorbeileitet.

# Bouncer-Dienst starten und aktivieren:
sudo systemctl enable --now crowdsec-firewall-bouncer

# Status prüfen:
sudo systemctl status crowdsec-firewall-bouncer

Verifizieren: Der Dienst läuft, und die LAPI zeigt einen aktuellen Abruf:

sudo systemctl status crowdsec-firewall-bouncer
# Erwartete Ausgabe: active (running) – keine "connection refused"-Fehler

# Bouncer in CrowdSec als aktiv markiert?
docker exec crowdsec cscli bouncers list
# Spalte "Last API pull": sollte aktuellen Zeitstempel zeigen

# Aktive iptables-Rules von CrowdSec:
sudo iptables -L crowdsec-blacklists -n 2>/dev/null || echo "Noch keine Blockierungen aktiv"

Schritt 6: Erste Erkennungen und manuelle Tests

Den Bouncer prüfen Sie mit einer manuell gesetzten Test-Sperre (im Test überstand die Sperre auch einen Neustart des Containers):

# Test-IP aus dem Dokumentationsbereich blockieren (nie die eigene Admin-IP):
docker exec crowdsec cscli decisions add --ip 203.0.113.1 --duration 5m --reason "Test"

# Prüfen ob iptables-Rule gesetzt:
sudo iptables -L crowdsec-blacklists -n | grep 203.0.113.1

# Test-Blockierung wieder entfernen:
docker exec crowdsec cscli decisions delete --ip 203.0.113.1

Optional binden Sie die Instanz an die CrowdSec Console: ENROLL_KEY in .env und compose.yaml setzen, docker compose up -d ausführen, die Anmeldung in der Console bestätigen und unter app.crowdsec.net prüfen, ob die Instanz erscheint.

Verifizieren: Alerts und Decisions erscheinen, der Bouncer läuft. Im Test erzeugten zwölf fehlgeschlagene SSH-Anmeldungen einer IP sofort Alerts für crowdsecurity/ssh-bf und eine vierstündige Sperre:

docker exec crowdsec cscli alerts list
# Einträge mit Scenario z. B. "crowdsecurity/ssh-bf"

docker exec crowdsec cscli decisions list
# Aktiv geblockte IPs (falls Angriffe stattfanden)

Schritt 7: Updates und Hub-Wartung

CrowdSec hat zwei Update-Ebenen: das Image und die Hub-Inhalte.

cd /opt/crowdsec

# 1. Container-Image aktualisieren (vorher Tag in compose.yaml anheben):
docker compose pull
docker compose up -d

# 2. Hub-Inhalte aktualisieren (Collections, Parsers, Scenarios):
docker exec crowdsec cscli hub upgrade

# Status nach Update prüfen:
docker compose ps
docker exec crowdsec cscli version

Für den Firewall-Bouncer auf dem Host gilt das normale Paket-Update:

sudo apt update && sudo apt upgrade crowdsec-firewall-bouncer-iptables
sudo systemctl restart crowdsec-firewall-bouncer

Wie Sie über neue Versionen informiert werden, zeigt die Anleitung zu Docker-Container automatisch aktualisieren mit Diun und WUD.

Verifizieren: Aktuelle Version und laufender Container nach dem Update:

docker exec crowdsec cscli version
# Ausgabe: version: v1.8.1 (oder die neu eingetragene Version)

docker compose ps
# STATUS: Up X minutes – kein Neustart-Loop

Troubleshooting / Typische Fehler

1. Decisions verschwinden nach Neustart: Das Volume für /var/lib/crowdsec/data fehlt. Seit v1.7.0 Pflicht. Container mit docker compose down && docker compose up -d neu erstellen (nicht nur neu starten).
2. Bouncer meldet „connection refused“: LAPI noch nicht bereit oder falscher Port. Prüfen Sie mit curl -i http://127.0.0.1:8080/health; erwartet wird HTTP 200 (der Pfad /v1/health liefert 404).
3. cscli metrics zeigt keine gelesenen Zeilen: Die acquis.yaml fehlt oder zeigt auf Pfade, die im Container nicht existieren. Auf Debian ohne rsyslog gibt es kein /var/log/auth.log: Installieren Sie rsyslog oder nutzen Sie eine journald-Quelle.
4. Docker-Container werden nicht geblockt trotz aktiver Decisions: Die Chain DOCKER-USER fehlt in /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml. Nach der Änderung: sudo systemctl restart crowdsec-firewall-bouncer.
5. Permission denied beim Log-Lesen: GID passt nicht zur Gruppe der Log-Dateien. GID mit stat /var/log/auth.log ermitteln, in der .env anpassen, dann docker compose up -d --force-recreate.
6. BOUNCER_KEY_xxx wird ignoriert: Der Key enthält Sonderzeichen wie ! oder #. Erzeugen Sie ihn neu mit openssl rand -hex 16.
7. Bouncer-Dienst startet nicht: API-Key falsch oder LAPI nicht erreichbar. Details liefert sudo journalctl -u crowdsec-firewall-bouncer -n 50.
8. Console-Enrollment wird nicht aktiv: Anmeldung in der Console bestätigen, dann docker compose restart crowdsec.

Häufige Fragen

Brauche ich einen CrowdSec-Account?

Nein. Erkennung, Sperren und Community-Blockliste funktionieren ohne Account. Den kostenlosen Account brauchen Sie nur für die Console (zentrales Monitoring mehrerer Instanzen).

Was ist der Unterschied zwischen Security Engine und Bouncer?

Die Security Engine (Container) wertet Logs mit Parsern und Szenarien aus und verwaltet Decisions, also zu sperrende IPs. Der Bouncer (Remediation Component) liest diese Decisions über die LAPI und setzt die Sperre per iptables/nftables um. Ohne Bouncer bleibt CrowdSec ein reines IDS.

Kann CrowdSec mit Traefik oder Nginx als Reverse-Proxy arbeiten?

Ja. Für Traefik und Nginx gibt es Bouncer, die HTTP-Anfragen direkt am Proxy blockieren, auch ohne Root-Zugriff auf den Host. Firewall- und Web-Bouncer lassen sich parallel betreiben.

Welche Collections sollte ich mindestens installieren?

Mindestens crowdsecurity/linux (Basis-Parser) und crowdsecurity/sshd (SSH-Bruteforce). Je nach Dienst zusätzlich crowdsecurity/nginx, crowdsecurity/traefik oder crowdsecurity/http-cve (bekannte Web-Schwachstellen). Nachinstallieren mit docker exec crowdsec cscli collections install crowdsecurity/http-cve.

Wie prüfe ich, ob CrowdSec tatsächlich etwas erkennt?

cscli metrics zeigt gelesene Logzeilen, cscli alerts list erkannte Angriffe, cscli decisions list aktive Sperren (jeweils mit docker exec crowdsec davor). Den Bouncer prüfen Sie mit sudo systemctl status crowdsec-firewall-bouncer.

Wie unterscheidet sich CrowdSec von Fail2Ban?

Fail2Ban arbeitet rein lokal. CrowdSec trennt Erkennung und Sperre über eine API, teilt Bedrohungsdaten mit der Community und bietet Bouncer für Firewall, Proxy und Cloud-Dienste. Parallelbetrieb ist möglich, erzeugt aber doppelte Firewall-Regeln; entscheiden Sie sich je Dienst für ein Werkzeug.

Fazit

CrowdSec ergänzt einen Linux-Server mit Docker-Diensten um eine Erkennungs- und Sperrschicht: Der Container analysiert, der Host-Dienst blockiert. Bei Diensten hinter einem Reverse-Proxy lohnt zusätzlich ein Web-Bouncer für Traefik oder Nginx. Für eine vollständige Härtung kombinieren Sie CrowdSec mit UFW-Firewall und Fail2Ban auf der System-Ebene und abgesicherte Docker-Compose-Stacks für die Container-Ebene.

Weiterführende Anleitungen und Quellen

1. Linux-Server absichern: UFW-Firewall und Fail2Ban
2. Docker Compose absichern: Secrets, Healthchecks und Non-Root
3. Docker und Docker Compose auf Linux installieren
4. Docker-Container automatisch aktualisieren: Diun, WUD und Renovate

Offizielle Quellen: CrowdSec Docker-Installationsdokumentation, crowdsecurity/crowdsec auf Docker Hub, CrowdSec GitHub Repository, CrowdSec Firewall-Bouncer-Dokumentation.