CrowdSec mit Docker einsetzen – Container und Reverse Proxys wirksam absichern
Container vereinfachen die Bereitstellung von Webservern, Reverse Proxys und Anwendungen erheblich. Gleichzeitig entstehen durch Docker neue Anforderungen an die Sicherheitsüberwachung.
CrowdSec kann nur Angriffe erkennen, deren Logeinträge es tatsächlich lesen kann. Läuft CrowdSec selbst in einem Container, befinden sich die relevanten Protokolle jedoch häufig in einem anderen Container, einem Docker-Volume oder ausschließlich in der Standardausgabe des Docker-Dienstes.
Für eine funktionierende CrowdSec-Installation müssen deshalb drei Bereiche sauber zusammenspielen:
Webanwendung oder Reverse Proxy
│
▼
Protokolldaten
│
▼
CrowdSec Security Engine
│
▼
Decision
│
▼
Bouncer
│
▼
Zugriff wird blockiert
CrowdSec erkennt den Angriff und erstellt eine Entscheidung. Die tatsächliche Sperre wird anschließend von einem Bouncer beziehungsweise einer Remediation Component umgesetzt.
Voraussetzungen
Für die folgende Anleitung benötigen Sie:
- einen Linux-Server, beispielsweise Debian 13
- Docker Engine
- Docker Compose
- einen laufenden Reverse Proxy oder Webserver
- grundlegende Kenntnisse über Docker-Netzwerke und Volumes
- Root-Rechte oder einen Benutzer mit Docker-Berechtigungen
Prüfen Sie zunächst die installierten Versionen:
docker --version docker compose version
Verzeichnisstruktur anlegen
Für eine übersichtliche Installation erstellen wir ein eigenes Projektverzeichnis:
sudo mkdir -p /opt/crowdsec-docker/crowdsec/acquis.d sudo mkdir -p /opt/crowdsec-docker/logs/nginx sudo chown -R "$USER":"$USER" /opt/crowdsec-docker cd /opt/crowdsec-docker
Die spätere Struktur sieht beispielsweise so aus:
/opt/crowdsec-docker/
├── compose.yaml
├── .env
├── crowdsec/
│ └── acquis.d/
│ └── nginx.yaml
└── logs/
└── nginx/
Wie CrowdSec in Docker an Protokolle gelangt
CrowdSec benötigt Zugriff auf die Logquellen. Dafür gibt es zwei verbreitete Verfahren:
- Webserver und CrowdSec verwenden einen gemeinsamen Ordner oder ein gemeinsames Volume.
- CrowdSec liest die Standardausgabe der Container über die Docker-Datenquelle.
Ein gemeinsames, ausschließlich lesbar eingebundenes Log-Volume ist häufig die einfachste und restriktivste Variante. Die offizielle CrowdSec-Dokumentation weist ausdrücklich darauf hin, dass Logquellen in den CrowdSec-Container eingebunden werden müssen. Außerdem müssen das Daten- und das Konfigurationsverzeichnis persistent gespeichert werden. (CrowdSec Dokumentation)
Variante 1: Protokolle über ein gemeinsames Volume bereitstellen
Im folgenden Beispiel schreibt ein Nginx-Container seine Zugriffs- und Fehlerprotokolle in einen gemeinsamen Ordner. CrowdSec bindet denselben Ordner schreibgeschützt ein.
Erstellen Sie die Datei compose.yaml:
services:
reverse-proxy:
image: nginx:alpine
container_name: reverse-proxy
restart: unless-stopped
ports:
- "80:80"
- "443:443"
volumes:
- ./nginx/conf.d:/etc/nginx/conf.d:ro
- ./nginx/certs:/etc/nginx/certs:ro
- ./logs/nginx:/var/log/nginx
networks:
- proxy
crowdsec:
image: crowdsecurity/crowdsec:latest
container_name: crowdsec
restart: unless-stopped
environment:
TZ: Europe/Berlin
COLLECTIONS: crowdsecurity/nginx
depends_on:
- reverse-proxy
volumes:
- ./crowdsec/acquis.d:/etc/crowdsec/acquis.d:ro
- ./logs/nginx:/var/log/nginx:ro
- crowdsec-data:/var/lib/crowdsec/data
- crowdsec-config:/etc/crowdsec
networks:
- security
- proxy
volumes:
crowdsec-data:
crowdsec-config:
networks:
proxy:
security:
internal: true
Das Beispiel muss an Ihre vorhandene Nginx-Konfiguration angepasst werden. Insbesondere die Verzeichnisse nginx/conf.d und nginx/certs müssen vorhanden sein, wenn sie wie gezeigt eingebunden werden.
Warum zwei persistente CrowdSec-Volumes erforderlich sind
CrowdSec benötigt insbesondere diese Verzeichnisse dauerhaft:
/var/lib/crowdsec/data /etc/crowdsec
Das Datenverzeichnis enthält unter anderem lokale Datenbankinformationen. Im Konfigurationsverzeichnis befinden sich Collections, Parser, Szenarien, Zugangsdaten und weitere Einstellungen.
Ohne persistente Speicherung könnten Konfiguration und lokale Daten beim Neuerstellen des Containers verloren gehen. Die offizielle Docker-Anleitung nennt deshalb sowohl /var/lib/crowdsec/data als auch /etc/crowdsec als zu persistierende Verzeichnisse. (CrowdSec Dokumentation)
Docker empfiehlt benannte Volumes für Daten, die unabhängig vom Lebenszyklus eines Containers bestehen bleiben sollen. Bind Mounts eignen sich dagegen besonders für gezielt vom Host bereitgestellte Konfigurations- oder Logdateien. (Docker Documentation)
Acquisition-Datei für Nginx erstellen
CrowdSec muss wissen, welche Dateien eingelesen und mit welchem Parser verarbeitet werden sollen.
Erstellen Sie:
nano crowdsec/acquis.d/nginx.yaml
Inhalt:
filenames: - /var/log/nginx/access.log - /var/log/nginx/error.log labels: type: nginx
CrowdSec unterstützt weiterhin die zentrale Datei /etc/crowdsec/acquis.yaml. Für neue Konfigurationen werden jedoch Dateien unter /etc/crowdsec/acquis.d/*.yaml bevorzugt. (CrowdSec Dokumentation)
Container starten
Prüfen Sie zunächst die Compose-Datei:
docker compose config
Starten Sie anschließend die Container:
docker compose up -d
Kontrollieren Sie den Status:
docker compose ps
Die CrowdSec-Protokolle können Sie mit folgendem Befehl verfolgen:
docker compose logs -f crowdsec
Installation überprüfen
Zeigen Sie die CrowdSec-Version an:
docker compose exec crowdsec cscli version
Prüfen Sie die installierten Collections:
docker compose exec crowdsec cscli collections list
Zeigen Sie die aktuellen Metriken an:
docker compose exec crowdsec cscli metrics
In den Metriken sollte erkennbar sein, ob die Nginx-Protokolle gelesen und verarbeitet werden.
Zusätzlich können Sie die Dateien direkt im Container prüfen:
docker compose exec crowdsec ls -l /var/log/nginx
Werden dort keine Logdateien angezeigt, liegt meist ein Fehler beim Volume-Mount oder beim verwendeten Pfad vor.
Testzugriffe erzeugen
Rufen Sie die Webseite mehrfach auf:
curl -I http://SERVER-IP
Anschließend prüfen Sie erneut:
docker compose exec crowdsec cscli metrics
Die Anzahl der gelesenen Zeilen sollte steigen.
Aktuelle Alerts zeigen Sie so an:
docker compose exec crowdsec cscli alerts list
Aktive Entscheidungen erhalten Sie mit:
docker compose exec crowdsec cscli decisions list
Wichtig: Ein normaler Seitenaufruf erzeugt noch keinen Alert. Er dient lediglich dazu, zu kontrollieren, ob CrowdSec die Protokolldatei grundsätzlich einliest.
Variante 2: Container-Logs über den Docker-Socket lesen
Viele Container schreiben ihre Protokolle nicht in Dateien, sondern nach stdout und stderr. Diese Ausgaben sind beispielsweise über folgenden Befehl sichtbar:
docker logs CONTAINERNAME
CrowdSec besitzt eine Docker-Datenquelle, mit der es laufende Container und deren Standardausgaben überwachen kann. Dabei können Container anhand ihres Namens, ihrer ID, regulärer Ausdrücke oder spezieller Labels ausgewählt werden. (CrowdSec Dokumentation)
Eine entsprechende Acquisition-Datei kann beispielsweise so aussehen:
source: docker container_name: - reverse-proxy labels: type: nginx
Alternativ lassen sich Container über Docker-Labels automatisch auswählen:
source: docker use_container_labels: true
Der zu überwachende Container erhält dann beispielsweise folgende Labels:
labels: - crowdsec.enable=true - crowdsec.labels.type=nginx
Im CrowdSec-Service muss zusätzlich der Docker-Socket verfügbar sein:
volumes: - /var/run/docker.sock:/var/run/docker.sock:ro
Eine zusammenhängende Konfiguration könnte so aussehen:
services:
reverse-proxy:
image: nginx:alpine
container_name: reverse-proxy
restart: unless-stopped
labels:
- crowdsec.enable=true
- crowdsec.labels.type=nginx
crowdsec:
image: crowdsecurity/crowdsec:latest
container_name: crowdsec
restart: unless-stopped
environment:
TZ: Europe/Berlin
COLLECTIONS: crowdsecurity/nginx
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
- ./crowdsec/acquis.d:/etc/crowdsec/acquis.d:ro
- crowdsec-data:/var/lib/crowdsec/data
- crowdsec-config:/etc/crowdsec
Sicherheitsrisiko Docker-Socket
Der Docker-Socket bietet weitreichenden Zugriff auf den Docker-Daemon. Selbst eine schreibgeschützte Einbindung sollte nicht mit einem gewöhnlichen Dateizugriff verwechselt werden.
Ein kompromittierter Container mit Socket-Zugriff kann unter Umständen Informationen über andere Container und die gesamte Docker-Umgebung erhalten. Abhängig von der verfügbaren API und Konfiguration kann daraus ein erhebliches Sicherheitsrisiko entstehen.
Daher gilt:
- Docker-Socket nur einbinden, wenn er tatsächlich benötigt wird
- CrowdSec-Image regelmäßig aktualisieren
- keine unnötigen Werkzeuge im Container installieren
- Containerrechte möglichst begrenzen
- alternativ einen abgesicherten Socket-Proxy einsetzen
- für reine Dateiprotokolle besser schreibgeschützte Log-Volumes verwenden
Die Docker-Datenquelle ist komfortabel und flexibel. Das gemeinsame Log-Volume bietet jedoch häufig die kleinere Angriffsfläche.
Welche Variante ist besser?
Ein gemeinsames Log-Volume eignet sich besonders, wenn:
- Nginx, Apache oder ein anderer Dienst echte Logdateien schreibt
- möglichst wenige Docker-Rechte vergeben werden sollen
- die Logpfade stabil und bekannt sind
- CrowdSec nur ausgewählte Dienste überwachen soll
Die Docker-Datenquelle eignet sich besonders, wenn:
- Anwendungen ausschließlich nach
stdoutoderstderrschreiben - viele Container automatisch erkannt werden sollen
- Container häufig erstellt oder ersetzt werden
- die Auswahl über Labels erfolgen soll
Beide Varianten können auch kombiniert werden. Dabei muss jedoch darauf geachtet werden, dieselben Ereignisse nicht doppelt einzulesen.
Bouncer einrichten
CrowdSec erkennt Angriffe, blockiert aber nicht automatisch selbst. Dafür wird ein Bouncer beziehungsweise eine Remediation Component benötigt.
Für Docker-Umgebungen kommen verschiedene Möglichkeiten infrage:
- Bouncer im Reverse Proxy
- Firewall-Bouncer auf dem Docker-Host
- Cloudflare-Bouncer
- Traefik-Integration
- Nginx- oder OpenResty-Bouncer
- HAProxy-SPOA-Bouncer
- AppSec-fähige Reverse-Proxy-Integration
Welche Variante sinnvoll ist, hängt davon ab, welche Dienste geschützt werden sollen.
Reverse-Proxy-Bouncer
Bei Webanwendungen ist ein Bouncer direkt am Reverse Proxy häufig die beste Wahl.
Der Datenfluss sieht dann so aus:
Internet │ ▼ Reverse Proxy mit Bouncer │ ├── Anfrage erlaubt │ │ │ ▼ │ Webanwendung │ └── Anfrage blockiert
Der Bouncer fragt die CrowdSec Local API ab und blockiert IP-Adressen, für die eine aktive Entscheidung vorliegt.
Für webbasierte Anwendungen empfiehlt CrowdSec heute eine WAF- beziehungsweise AppSec-fähige Integration mit Nginx, OpenResty, Traefik oder HAProxy SPOA. Der reine Firewall-Bouncer eignet sich besonders für Netzwerkdienste wie SSH, Datenbanken und SMTP. Beide Ansätze können auf einem öffentlich erreichbaren Server auch parallel betrieben werden. (CrowdSec Dokumentation)
API-Schlüssel für einen Bouncer erzeugen
Ein Bouncer benötigt einen API-Schlüssel für die Local API.
Erzeugen Sie beispielsweise einen Schlüssel:
docker compose exec crowdsec \ cscli bouncers add reverse-proxy-bouncer
Die Ausgabe enthält den API-Schlüssel:
API key for 'reverse-proxy-bouncer': EINGEBLENDETER_API_SCHLUESSEL
Speichern Sie diesen Schlüssel sicher. Er wird gewöhnlich nur einmal vollständig angezeigt.
Aktivierte Bouncer lassen sich später anzeigen:
docker compose exec crowdsec cscli bouncers list
API-Schlüssel über eine Umgebungsdatei bereitstellen
Legen Sie eine Datei .env an:
nano .env
Beispiel:
CROWDSEC_BOUNCER_API_KEY=HIER_DEN_API_SCHLUESSEL_EINTRAGEN
Schützen Sie die Datei:
chmod 600 .env
In einer Compose-Datei lässt sich der Wert anschließend referenzieren:
environment:
CROWDSEC_BOUNCER_API_KEY: ${CROWDSEC_BOUNCER_API_KEY}
Noch besser ist die Verwendung von Docker Secrets, sofern die eingesetzte Bouncer-Integration sie unterstützt. Docker stellt Secrets innerhalb eines Containers gezielt unter /run/secrets/ bereit. (Docker Documentation)
CrowdSec Local API nicht öffentlich freigeben
Die Local API verwendet standardmäßig Port 8080. Dieser Port sollte normalerweise nicht öffentlich über alle Netzwerkschnittstellen veröffentlicht werden.
Vermeiden Sie nach Möglichkeit:
ports: - "8080:8080"
Benötigen ausschließlich andere Container Zugriff, genügt ein gemeinsames internes Docker-Netzwerk:
networks:
security:
internal: true
Bouncer und CrowdSec können sich dann über den Servicenamen erreichen:
http://crowdsec:8080
Muss ein auf dem Host laufender Bouncer auf die containerisierte LAPI zugreifen, kann der Port ausschließlich an die Loopback-Adresse gebunden werden:
ports: - "127.0.0.1:8080:8080"
Genau diese lokale Bindung verwendet auch das offizielle CrowdSec-Compose-Beispiel. (CrowdSec Dokumentation)
Echte Client-IP hinter einem Reverse Proxy
Eine der wichtigsten Besonderheiten besteht darin, dass CrowdSec die tatsächliche IP-Adresse des Besuchers erkennen muss.
Ohne korrekte Reverse-Proxy-Konfiguration kann im Log statt der echten Client-IP nur eine interne Docker-Adresse erscheinen:
172.20.0.5
In diesem Fall würde CrowdSec möglicherweise den Reverse Proxy oder einen anderen Container als vermeintlichen Angreifer erkennen.
Achten Sie daher auf:
- korrekt konfigurierte
X-Forwarded-For-Header - gegebenenfalls
X-Real-IP - vertrauenswürdige Proxy-Netzwerke
- korrekte Real-IP-Konfiguration des Webservers
- keine ungeprüfte Übernahme beliebiger Client-Header
Bei Nginx kann eine Konfiguration beispielsweise grundsätzlich so aussehen:
set_real_ip_from 172.20.0.0/16; real_ip_header X-Forwarded-For; real_ip_recursive on;
Das Netzwerk muss exakt an das tatsächlich verwendete Docker-Netz angepasst werden.
Vertrauen Sie niemals pauschal allen IP-Adressen, wenn der Webserver auch direkt erreichbar ist. Andernfalls könnte ein Angreifer den Header selbst manipulieren.
Container nicht direkt veröffentlichen
Backend-Anwendungen sollten nach Möglichkeit nicht zusätzlich zum Reverse Proxy über Host-Ports erreichbar sein.
Ungünstig:
ports: - "8081:80"
Besser ist eine ausschließlich interne Erreichbarkeit:
expose: - "80" networks: - proxy
Der Reverse Proxy erreicht die Anwendung dann über das interne Docker-Netzwerk. Externe Anfragen müssen zwangsläufig den geschützten Proxy und damit den Bouncer passieren.
Host-Netzwerk und Bridge-Netzwerk
Im normalen Bridge-Modus besitzen Container eigene interne IP-Adressen. Dadurch muss besonders auf die Weitergabe der Client-IP geachtet werden.
Der network_mode: host kann bestimmte Netzwerkprobleme umgehen, hebt jedoch einen wichtigen Teil der Container-Isolation auf und ist nicht für jede Umgebung sinnvoll.
In der Regel ist ein klar strukturiertes Bridge-Netzwerk mit korrekt konfiguriertem Reverse Proxy vorzuziehen.
Firewall-Bouncer auf dem Host oder im Container?
Ein Firewall-Bouncer muss die Firewall des Docker-Hosts verändern können. Wird er in einem Container betrieben, benötigt er dafür weitreichende Rechte, beispielsweise zusätzliche Capabilities oder Zugriff auf den Host-Netzwerk-Namespace.
Das kann eine Konfiguration erfordern wie:
network_mode: host cap_add: - NET_ADMIN - NET_RAW
Solche Rechte vergrößern die Angriffsfläche des Containers.
Für viele Installationen ist es deshalb einfacher und sicherer, den CrowdSec Security Engine in Docker zu betreiben, den Firewall-Bouncer jedoch direkt auf dem Host zu installieren.
Alternativ kann ein Reverse-Proxy-Bouncer verwendet werden, wenn ausschließlich Webanwendungen geschützt werden sollen.
Docker-Firewall und nftables
Docker verwaltet eigene Firewallregeln. Je nach System kommen iptables-Kompatibilitätsschichten oder nftables zum Einsatz.
Dabei muss berücksichtigt werden:
- Docker kann eigene Chains und Regeln erzeugen
- UFW-Regeln allein schützen veröffentlichte Container-Ports nicht immer wie erwartet
- ein Bouncer muss an der richtigen Stelle im Paketfluss greifen
- Änderungen sollten nach Docker- und Firewall-Updates erneut geprüft werden
- IPv4 und IPv6 müssen getrennt betrachtet werden
Testen Sie deshalb nicht nur, ob eine Decision in CrowdSec existiert, sondern auch, ob die Verbindung tatsächlich blockiert wird.
Manuelle Sperre testen
Ermitteln Sie zunächst Ihre öffentliche Test-IP oder verwenden Sie ein kontrolliertes externes Testsystem.
Legen Sie anschließend eine befristete Entscheidung an:
docker compose exec crowdsec \ cscli decisions add \ --ip 203.0.113.25 \ --duration 5m \ --reason "Docker-Bouncer-Test"
Prüfen Sie die Entscheidung:
docker compose exec crowdsec cscli decisions list
Versuchen Sie danach, die geschützte Anwendung von dieser Adresse aufzurufen.
Nach dem Test können Sie die Sperre entfernen:
docker compose exec crowdsec \ cscli decisions delete \ --ip 203.0.113.25
Achten Sie darauf, sich nicht selbst dauerhaft vom Server auszusperren.
Metriken und Diagnose
Die wichtigsten Prüfungen sind:
docker compose exec crowdsec cscli metrics docker compose exec crowdsec cscli alerts list docker compose exec crowdsec cscli decisions list docker compose exec crowdsec cscli bouncers list docker compose logs --tail=200 crowdsec
Zeigt CrowdSec keine eingelesenen Zeilen, liegt die Ursache meist in einem dieser Bereiche:
- falscher Pfad in der Acquisition-Datei
- Volume nicht oder falsch eingebunden
- Webserver schreibt keine Datei
- Logdatei besitzt unzureichende Berechtigungen
- falsches Label wie
type: nginx - Anwendung schreibt ausschließlich nach
stdout - Logformat passt nicht zum installierten Parser
Die CrowdSec-Dokumentation stuft eine vollständig fehlende Logaufnahme als kritisches Problem ein, weil ohne eingelesene Logs weder Ereignisse noch Alerts entstehen können. (CrowdSec Dokumentation)
Konfiguration im Container untersuchen
Acquisition-Dateien anzeigen:
docker compose exec crowdsec \ find /etc/crowdsec/acquis.d -maxdepth 1 -type f -print
Konfiguration prüfen:
docker compose exec crowdsec crowdsec -t
Installierte Parser anzeigen:
docker compose exec crowdsec cscli parsers list
Installierte Szenarien anzeigen:
docker compose exec crowdsec cscli scenarios list
Einzelne Logzeilen können mit cscli explain untersucht werden. Kopieren Sie dafür eine Testdatei in den Container oder binden Sie ein Testverzeichnis ein.
Beispiel:
docker compose exec crowdsec \ cscli explain \ --log "203.0.113.25 - - [20/Jul/2026:12:00:00 +0200] \"GET /wp-login.php HTTP/1.1\" 404 153" \ --type nginx
CrowdSec aktualisieren
Aktualisieren Sie das Image:
docker compose pull crowdsec
Erstellen Sie den Container neu:
docker compose up -d crowdsec
Prüfen Sie danach:
docker compose exec crowdsec cscli version docker compose exec crowdsec cscli metrics docker compose exec crowdsec cscli bouncers list
Da Daten und Konfiguration in persistenten Volumes liegen, bleiben sie beim Neuerstellen des Containers erhalten.
Hub-Komponenten aktualisieren
Die CrowdSec-Komponenten im lokalen Hub können Sie ebenfalls aktualisieren:
docker compose exec crowdsec cscli hub update docker compose exec crowdsec cscli hub upgrade
Danach sollte der Container neu gestartet werden:
docker compose restart crowdsec
Backup erstellen
Sichern Sie mindestens:
- die Compose-Datei
- die
.env-Datei beziehungsweise Secrets - eigene Acquisition-Dateien
- eigene Parser und Szenarien
- CrowdSec-Konfiguration
- lokale Datenbank, sofern deren Historie benötigt wird
Eine einfache Sicherung der benannten Volumes kann beispielsweise über einen temporären Container erfolgen. Alternativ können die relevanten Konfigurationen bewusst als Bind Mounts auf dem Host abgelegt und mit dem regulären Backup-System gesichert werden.
Typische Fehler
CrowdSec liest keine Logs
Prüfen Sie:
docker compose exec crowdsec ls -la /var/log/nginx docker compose exec crowdsec cscli metrics
Stimmen Hostpfad und Containerpfad überein?
Logdateien bleiben leer
Möglicherweise schreibt der Webserver ausschließlich nach stdout.
Prüfen Sie:
docker logs reverse-proxy
Verwenden Sie anschließend entweder die Docker-Datenquelle oder konfigurieren Sie den Webserver so, dass er zusätzlich Dateien schreibt.
Bouncer erreicht die API nicht
Prüfen Sie, ob beide Container dasselbe Docker-Netzwerk verwenden.
Innerhalb des Netzwerks sollte die API über folgenden Namen erreichbar sein:
http://crowdsec:8080
Nicht geeignet ist innerhalb eines Containers normalerweise:
http://127.0.0.1:8080
Denn 127.0.0.1 bezeichnet dort den jeweiligen Container selbst.
Decisions werden angezeigt, aber nicht blockiert
Dann funktioniert die Erkennung, jedoch nicht die Durchsetzung.
Prüfen Sie:
- ist ein Bouncer aktiv?
- ist dessen API-Schlüssel korrekt?
- erreicht der Bouncer die LAPI?
- durchläuft der Datenverkehr tatsächlich den Reverse Proxy?
- ist die Anwendung zusätzlich direkt erreichbar?
- greifen die Firewallregeln auch für Docker-Ports?
CrowdSec erkennt nur interne IP-Adressen
Prüfen Sie die Real-IP- und Forwarded-Header-Konfiguration des Reverse Proxys.
Konfiguration verschwindet nach einem Update
Kontrollieren Sie, ob /etc/crowdsec und /var/lib/crowdsec/data tatsächlich persistent eingebunden sind.
Best Practices
Für einen sicheren produktiven Betrieb haben sich folgende Maßnahmen bewährt:
- CrowdSec-Konfiguration und Daten persistent speichern
- Logverzeichnisse nur lesbar einbinden
- Docker-Socket möglichst vermeiden
- Local API nicht öffentlich freigeben
- API-Schlüssel nicht direkt in die Compose-Datei schreiben
- interne Docker-Netzwerke für CrowdSec und Bouncer verwenden
- Backend-Anwendungen nicht direkt veröffentlichen
- echte Client-IP sicher und nachvollziehbar weitergeben
- Reverse-Proxy- und Firewall-Bouncer passend zum Einsatzzweck wählen
- IPv4 und IPv6 testen
- CrowdSec- und Bouncer-Images regelmäßig aktualisieren
- Metriken und Logs nach jedem Update prüfen
- eigene Konfigurationen versionieren und sichern
- Sperrtests mit kontrollierten IP-Adressen durchführen
CrowdSec lässt sich sehr gut in Docker-Umgebungen integrieren. Die reine Bereitstellung des Containers reicht jedoch nicht aus. CrowdSec benötigt zuverlässigen Zugriff auf die relevanten Protokolle, persistente Speicherbereiche und einen Bouncer, der erkannte Angreifer tatsächlich blockiert.
Für klassische Reverse-Proxy-Umgebungen ist ein gemeinsames, schreibgeschütztes Log-Volume häufig die sicherste und übersichtlichste Lösung. Werden Protokolle ausschließlich über stdout ausgegeben, kann die Docker-Datenquelle verwendet werden. Der dafür notwendige Zugriff auf den Docker-Socket sollte jedoch bewusst und restriktiv erfolgen.
Besonders wichtig sind außerdem die korrekte Ermittlung der Client-IP, ein internes Netzwerk zwischen CrowdSec und Bouncer sowie die Vermeidung ungeschützter direkter Zugriffe auf Backend-Container. Mit einer sauberen Trennung zwischen Logauswertung und Durchsetzung entsteht eine flexible Sicherheitslösung für containerisierte Webdienste.
