Einen kostenlosen WAF an meine Homebox anbinden: CrowdSec AppSec Tutorial mit Traefik und Dokploy

Ich betreibe eine "Homebox", in meinem Fall ein Cloud-Server, auf dem ich verschiedene persönliche Anwendungen hoste. Da einige dieser Anwendungen öffentlich im Internet erreichbar sind und ich diesen Server oft als schnelles Deployment-Gefäß für neue Projekte nutze, hat Sicherheit oberste Priorität.

Um dieses Setup zu schützen, habe ich kürzlich eine Web Application Firewall (WAF) mit CrowdSec eingerichtet. CrowdSec ist eine quelloffene, kollaborative Security-Engine. Eine WAF ist essenziell, weil sie "Virtual Patching" bietet: Sie stoppt bösartige Payloads, stoppt automatische Scanner und schützt die Anwendungen vor bekannten CVEs, selbst wenn der zugrunde liegende Code noch nicht aktualisiert wurde.

Meine Homebox wird mit Dokploy verwaltet, einem PaaS-Tool, das Traefik als Reverse Proxy nutzt. In diesem Tutorial zeige ich genau, wie ich CrowdSecs AppSec-Fähigkeiten über ein Plugin direkt in Traefik eingebunden habe, um eine robuste, kostenlose WAF zu schaffen, die all meine Deployments schützt.

(Hinweis: Dieses Tutorial verwendet Dokploy zur Verwaltung der Konfigurationen. Dieselben Konzepte und Docker-Compose-Dateien lassen sich aber auch nutzen, um jede andere Standard-Traefik-Umgebung zu schützen.)

Wie CrowdSec Intelligence funktioniert

Ein häufiger Irrtum ist, dass CrowdSec die Traffic-Logs in die Cloud sendet, um sie dort zu analysieren. Das stimmt überhaupt nicht.

1. Local First: CrowdSec baut seine Intelligence lokal auf. Die Engine läuft auf dem Server, erkennt Angriffe lokal und sperrt lokal. Sie funktioniert sogar ohne Internetverbindung.
2. Privacy-Preserving Community (Opt-in): Das Teilen von Intelligence mit der CrowdSec-Community ist streng optional. Wer sich über die CrowdSec Console anmeldet, teilt nur anonymisierte Signale (wie "IP X hat einen bekannten Exploit versucht"), niemals rohe Logs, Request-Payloads oder sensible Daten. Man profitiert von Community-Blocklisten, ohne die Privatsphäre der eigenen Daten zu gefährden.

Standard CrowdSec (Layer 4) vs. AppSec (Layer 7)

Bevor wir in die Konfiguration einsteigen, ist es wichtig, den Unterschied zwischen dem Standard-Verhalten von CrowdSec und der neueren AppSec-Funktion zu verstehen. Sie arbeiten auf völlig unterschiedlichen Schichten des OSI-Modells:

• Standard CrowdSec (Layer 4): Agiert auf Netzwerkebene. Es analysiert Logs (wie SSH-Fehlschläge oder HTTP-404-Fluten) und blockiert schlechte IP-Adressen vollständig, indem es mit einer Firewall (wie iptables) spricht. Wenn eine IP gesperrt ist, kann sie nicht einmal eine TCP-Verbindung zum Server aufbauen.
• CrowdSec AppSec (Layer 7): Agiert als echte WAF auf Anwendungsebene. Anstatt nur auf IPs zu schauen, inspiziert es aktiv die tatsächlichen HTTP-Payloads, Header und Query-Parameter (etwa gezielt nach bösartigem multipart/form-data), um Zero-Days und spezifische CVE-Exploits auf Anwendungsebene in Echtzeit zu erwischen.

Hier ist eine einfache Visualisierung, wie sich die Architektur unterscheidet:

┌────────────────────────────────────────────────────────┐
│ STANDARD CROWDSEC (Layer 4 - Network IP Blocking)      │
└────────────────────────────────────────────────────────┘
  Attacker IP ──> [ Firewall / iptables ] ──X (Blocked instantly)
                          ▲
                          │ (Updates ban list)
                    [ CrowdSec Engine ] <── (Reads background logs)
-
-
┌────────────────────────────────────────────────────────┐
│ CROWDSEC APPSEC (Layer 7 - Payload Inspection WAF)     │
└────────────────────────────────────────────────────────┘
  Attacker HTTP Request ──> [ Traefik + Bouncer Plugin ]
                                  │   ▲
                  (Sends payload) │   │ (Returns Allow/Block)
                                  ▼   │
                        [ CrowdSec AppSec Engine ] 
                           (Inspects HTTP body)

Traefik-Plugins und der CrowdSec Bouncer

Traefik ist ein moderner Reverse Proxy, der Traffic an meine Docker-Container weiterleitet. Eine seiner besten Funktionen sind Plugins, mit denen sich die Kernfunktionalität von Traefik erweitern lässt, ohne die Binary neu zu kompilieren.

Für dieses Setup nutzen wir das CrowdSec Traefik Bouncer plugin. Es agiert als Brücke zwischen Traefik und der CrowdSec AppSec-Engine. Es fängt Traffic an der Edge ab und fragt CrowdSec, ob eine Request-Payload sicher oder bösartig ist, bevor sie die Anwendung erreicht.

Schritt-für-Schritt-Anleitung

Hier ist genau, wie ich das in meiner Dokploy/Traefik-Umgebung konfiguriert habe.

1. Den CrowdSec-Container ausrollen

Zuerst habe ich die CrowdSec-Engine ausgerollt. Ich habe das offizielle Docker-Image verwendet und über die Umgebungsvariable COLLECTIONS automatisch die AppSec-Regeln beim Start installieren lassen.

services:
  crowdsec:
    image: crowdsecurity/crowdsec:latest
    environment:
      GID: "${GID-1000}"
      BOUNCER_KEY_TRAEFIK: "${BOUNCER_KEY_TRAEFIK}"
      COLLECTIONS: "crowdsecurity/linux crowdsecurity/traefik crowdsecurity/http-cve crowdsecurity/appsec-virtual-patching crowdsecurity/appsec-generic-rules"
    volumes:
      - ../files/acquis.yaml:/etc/crowdsec/acquis.yaml
      - crowdsec-db:/var/lib/crowdsec/data/
      - crowdsec-config:/etc/crowdsec/
    security_opt:
      - no-new-privileges:true
    labels:
      - traefik.enable=false
    restart: always
    networks: 
      - dokploy-network

2. Der kritische LAPI-Key

Man beachte die Variable BOUNCER_KEY_TRAEFIK oben. Das ist der LAPI-Key (Local API Key), der das Traefik-Plugin sicher bei der CrowdSec-Engine authentifiziert. Ohne ihn kann Traefik nicht mit CrowdSec kommunizieren.

Wenn man diese Umgebungsvariable setzt, erzwingt der CrowdSec-Container kein strenges Schlüsselformat. Jede Zeichenkette, die man setzt, wird zum gültigen Schlüssel. Man kann einfach einen starken, zufälligen 32-Zeichen-String generieren, ihn in der Docker-Compose-.env-Datei BOUNCER_KEY_TRAEFIK zuweisen und denselben String später in die Traefik-Middleware-Konfiguration eintragen.

3. Akquisition konfigurieren (acquis.yaml)

Die AppSec-Collection zu installieren reicht nicht; man muss CrowdSec explizit anweisen, auf AppSec-Traffic zu lauschen. Ich habe diese acquis.yaml-Datei in den Container gemountet:

---
source: appsec
listen_addr: 0.0.0.0:7422
path: /
appsec_configs:
  - crowdsecurity/appsec-default
labels:
  type: appsec

4. Die Traefik-Middleware (middlewares.yaml)

Als Nächstes habe ich die Traefik-Middleware über den integrierten Dateisystem-Editor von Dokploy konfiguriert. Das sagt Traefik, das Bouncer-Plugin zu nutzen und Requests an die CrowdSec-AppSec-Engine weiterzuleiten.

http:
  middlewares:
    redirect-to-https:
      redirectScheme:
        scheme: https
        permanent: true
    crowdsec:
      plugin:
        bouncer:
          enabled: true
          logLevel: DEBUG
          crowdsecMode: appsec
          crowdsecLapiKey: keystring # Replace with your LAPI key
          crowdsecLapiScheme: http
          crowdsecLapiHost: crowdsec:8080
          crowdsecAppsecEnabled: true
          crowdsecAppsecHost: crowdsec:7422
          crowdsecAppsecFailureBlock: true
          crowdsecAppsecUnreachableBlock: true

Fail-Closed-Schutz

Besonderes Augenmerk auf crowdsecAppsecFailureBlock: true und crowdsecAppsecUnreachableBlock: true. Diese sind sicherheitskritisch. Sie stellen eine "Fail-Closed"-Architektur sicher. Wenn der CrowdSec-Container abstürzt oder die AppSec-Engine einen 500-Fehler zurückgibt, blockiert Traefik den eingehenden Request komplett, anstatt ihn an der WAF vorbeizulassen und die Anwendung zu treffen.

5. Globale Durchsetzung

Um schließlich sicherzustellen, dass jeder einzelne Request, der meinen Server trifft, inspiziert wird, habe ich die crowdsec-Middleware direkt an die Haupteinstiegspunkte von Traefik (web und websecure) gehängt:

entryPoints:
  web:
    address: :80
    http:
      middlewares:
        - crowdsec@file
  websecure:
    address: :443
    http3:
      advertisedPort: 443
    http:
      tls:
        certResolver: letsencrypt
      middlewares:
        - crowdsec@file

Die WAF aktuell halten (Automatisierung)

Eine WAF zu installieren ist nur die halbe Miete. Schwachstellen werden täglich entdeckt, also müssen die Regeln ständig aktualisiert werden, um neue CVEs zu erwischen.

Um CrowdSec zu aktualisieren, braucht man zwei Befehle:

1. cscli hub update (Lädt den neuesten Index der verfügbaren Regeln herunter)
2. cscli hub upgrade (Wendet Updates auf die installierten Collections an)

Ich habe diesen Prozess mit Dokploy Schedules automatisiert und so konfiguriert, dass er einmal am Tag läuft. Tägliche Updates sind der Sweet Spot: Sie schützen vor neu veröffentlichten CVEs, ohne übermäßigen, zu feingranularen Ressourcenverbrauch zu verursachen.

Wie ich den erforderlichen Neustart handhabe

Ein wichtiger Vorbehalt: Nach dem Update der Regeln benötigt die CrowdSec-Engine einen Neustart, damit neue AppSec-Regeln wirksam werden.

In meinem Setup laufen meine routinemäßigen Dokploy-Container-Backups kurz nach dem Update-Zeitplan. Weil der Backup-Prozess den Container stoppt, um die Konfiguration zu sichern, und ihn danach wieder startet, wird das ganz natürlich zum Neustart-Schritt, der die aktualisierten Regeln anwendet.

Test in der Praxis: CVE-2025-55182 blockieren

Um das Setup zu verifizieren, habe ich es gegen einen sehr realen, sehr gefährlichen Exploit getestet: CVE-2025-55182 (eine Next.js Prototype Pollution-Schwachstelle, die zu Remote Code Execution führt).

Ich habe ein Open-Source-Exploit-Tool (rix4uni/CVE-2025-55182) verwendet und es direkt auf eine Domain gefeuert, die auf meiner geschützten Homebox gehostet ist.

1. Der Exploit-Versuch schlug fehl

Beim Ausführen des Kommandozeilen-Tools schlug jeder einzelne Payload-Versuch fehl, gegen den Server auszuführen. Das Tool konnte die Edge nicht umgehen.

2. Die CrowdSec-Logs

Beim Blick in die CrowdSec-Container-Logs konnte ich genau sehen, was passiert ist. CrowdSec hat den Exploit-Versuch aktiv abgewiesen und den bösartigen Payload in Echtzeit erkannt.

3. Log-Analyse

Zur Bestätigung habe ich die rohen Logs durch eine KI-Zusammenfassung laufen lassen, die verifizierte, dass die AppSec-Regeln von CrowdSec die Next.js-RCE-Payload erfolgreich abgefangen und verworfen haben, bevor sie jemals meinen Anwendungs-Container berührt hat.

Fazit

Durch die Kombination von Traefik, Dokploy und CrowdSec AppSec konnte ich eine fähige, kostenlose Web Application Firewall auf meiner Cloud-Homebox ausrollen. Meine persönlichen Apps und schnellen Deployments sind jetzt ab dem Moment, in dem sie die Edge treffen, vor aktiven, automatisierten Exploits geschützt.

Wer selbst hostet oder einen persönlichen Server betreibt, dem empfehle ich, eine ähnliche Edge-Level-WAF-Architektur zu übernehmen.