Ajouter un WAF gratuit à ma Homebox : Tutoriel CrowdSec AppSec avec Traefik et Dokploy

Je maintiens une « Homebox », en l'occurrence un serveur cloud où j'héberge plusieurs applications personnelles. Comme certaines de ces applications sont exposées à internet public, et comme j'utilise souvent ce serveur comme vaisseau de déploiement rapide pour de nouveaux projets, la sécurité est primordiale.

Pour protéger ce setup, j'ai récemment ajouté un Web Application Firewall (WAF) avec CrowdSec. CrowdSec est un moteur de sécurité open-source et collaboratif. Un WAF est essentiel parce qu'il fournit du « virtual patching » : il stoppe les payloads malveillants, stoppe les scanners automatisés et protège les applications des CVE connues même si le code sous-jacent n'a pas encore été mis à jour.

Ma Homebox est gérée avec Dokploy, un outil PaaS qui utilise Traefik comme reverse proxy sous-jacent. Dans ce tutoriel, je vous montre exactement comment j'ai intégré les capacités AppSec de CrowdSec directement dans Traefik via un plugin, créant un WAF gratuit et robuste qui protège tous mes déploiements.

(Note : Bien que ce tutoriel utilise Dokploy pour gérer les configurations, ces concepts exacts et ces fichiers Docker Compose peuvent être utilisés pour protéger n'importe quel environnement Traefik standard.)

Comment fonctionne l'intelligence CrowdSec

Une idée reçue courante est que CrowdSec envoie vos logs de trafic dans le cloud pour les faire analyser. C'est entièrement faux.

1. Local First : CrowdSec construit son intelligence localement. Le moteur tourne sur votre serveur, détecte les attaques localement et bannit localement. Il fonctionne même sans aucune connexion internet.
2. Communauté préservant la vie privée (Opt-in) : Partager de l'intelligence avec la Communauté CrowdSec est strictement facultatif. Si vous vous inscrivez via la Console CrowdSec, cela ne partage que des signaux anonymisés (comme « l'IP X a tenté une exploit connu »), jamais de logs bruts, de payloads de requêtes ou de données sensibles. Vous bénéficiez des blocklists communautaires sans compromettre la vie privée de vos données.

CrowdSec standard (Couche 4) vs. AppSec (Couche 7)

Avant de plonger dans la configuration, il est important de comprendre la différence entre le comportement standard de CrowdSec et la nouvelle fonctionnalité AppSec. Ils opèrent à des couches complètement différentes du modèle OSI :

• CrowdSec standard (Couche 4) : Agit au niveau réseau. Il analyse les logs (comme les échecs SSH ou les inondations de HTTP 404) et bloque les mauvaises adresses IP en parlant à un firewall (comme iptables). Si une IP est bannie, elle ne peut même pas ouvrir une connexion TCP à votre serveur.
• CrowdSec AppSec (Couche 7) : Agit comme un vrai WAF au niveau applicatif. Au lieu de seulement regarder les IPs, il inspecte activement les payloads HTTP réels, les headers et les paramètres de query (comme chercher un multipart/form-data malveillant spécifique) pour capturer les zero-days et les exploits de CVE au niveau applicatif en temps réel.

Voici une visualisation simple de la différence d'architecture :

┌────────────────────────────────────────────────────────┐
│ 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)

Les plugins Traefik et le CrowdSec Bouncer

Traefik est un reverse proxy moderne qui route le trafic vers mes conteneurs Docker. Une de ses meilleures fonctionnalités est les Plugins, qui permettent d'étendre la fonctionnalité centrale de Traefik sans avoir à recompiler le binaire.

Pour ce setup, nous utilisons le plugin CrowdSec Traefik Bouncer. Il agit comme pont entre Traefik et le moteur AppSec de CrowdSec. Il intercepte le trafic au edge et demande à CrowdSec si un payload de requête est sûr ou malveillant avant de le laisser atteindre l'application.

Guide d'implémentation étape par étape

Voici exactement comment j'ai configuré cela dans mon environnement Dokploy/Traefik.

1. Déployer le conteneur CrowdSec

D'abord, j'ai déployé le moteur CrowdSec. J'ai utilisé l'image Docker officielle et la variable d'environnement COLLECTIONS pour installer automatiquement les règles AppSec au démarrage.

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. La clé LAPI critique

Remarquez la variable BOUNCER_KEY_TRAEFIK ci-dessus. C'est la clé LAPI (Local API Key), qui authentifie de façon sécurisée le plugin Traefik auprès de votre moteur CrowdSec. Sans elle, Traefik ne peut pas communiquer avec CrowdSec.

Quand elle est configurée via cette variable d'environnement, le conteneur CrowdSec n'impose pas un format de clé strict. N'importe quelle chaîne que vous définissez devient la clé valide. Vous pouvez simplement générer une chaîne aléatoire forte de 32 caractères, l'assigner à BOUNCER_KEY_TRAEFIK dans votre fichier .env Docker Compose, puis fournir cette même chaîne dans votre configuration de middleware Traefik plus tard.

3. Configurer l'acquisition (acquis.yaml)

Installer les collections AppSec ne suffit pas ; vous devez dire explicitement à CrowdSec de commencer à écouter le trafic AppSec. J'ai monté ce fichier acquis.yaml dans le conteneur :

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

4. Le middleware Traefik (middlewares.yaml)

Ensuite, j'ai configuré le middleware Traefik en utilisant l'éditeur de système de fichiers intégré à Dokploy. Cela dit à Traefik d'utiliser le plugin Bouncer et de transférer les requêtes au moteur AppSec de CrowdSec.

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

Protection fail-closed

Prêtez une attention particulière à crowdsecAppsecFailureBlock: true et crowdsecAppsecUnreachableBlock: true. Ils sont critiques pour la sécurité. Ils assurent une architecture « fail-closed ». Si le conteneur CrowdSec crash, ou si le moteur AppSec renvoie une erreur 500, Traefik bloquera entièrement la requête entrante plutôt que de la laisser contourner le WAF et atteindre votre application.

5. Application globale

Enfin, pour s'assurer que chaque requête atteignant mon serveur est inspectée, j'ai accroché le middleware crowdsec directement aux entrypoints principaux de Traefik (web et websecure) :

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

Maintenir le WAF à jour (Automatisation)

Installer un WAF n'est que la moitié de la bataille. Les vulnérabilités sont découvertes quotidiennement, donc vos règles doivent être constamment mises à jour pour capturer les nouveaux CVE.

Pour mettre à jour CrowdSec, il faut deux commandes :

1. cscli hub update (Télécharge le dernier index des règles disponibles)
2. cscli hub upgrade (Applique les mises à jour à vos collections installées)

J'ai automatisé ce processus avec Dokploy Schedules, en le configurant pour s'exécuter une fois par jour. Les mises à jour quotidiennes sont le sweet spot : elles vous protègent des CVE récemment publiés sans causer une consommation de ressources excessive et trop granulaire.

Comment je gère le redémarrage requis

Une réserve importante : après la mise à jour des règles, le moteur CrowdSec nécessite un redémarrage pour que les nouvelles règles AppSec prennent effet.

Dans mon setup, mes sauvegardes de conteneur Dokploy de routine s'exécutent peu après le calendrier de mise à jour. Comme le processus de backup arrête le conteneur pour sauvegarder la configuration puis le redémarre, cela devient naturellement l'étape de redémarrage qui applique les règles mises à jour.

Tests en conditions réelles : Bloquer CVE-2025-55182

Pour vérifier le setup, j'ai décidé de le tester contre un exploit bien réel et très dangereux : CVE-2025-55182 (une vulnérabilité de Prototype Pollution de Next.js qui conduit à une Remote Code Execution).

J'ai utilisé un outil d'exploit open-source (rix4uni/CVE-2025-55182) et l'ai tiré directement sur un domaine hébergé sur ma Homebox protégée.

1. La tentative d'exploit a échoué

En exécutant l'outil en ligne de commande, chaque tentative de payload a échoué à s'exécuter contre le serveur. L'outil n'a pas pu contourner le edge.

2. Les logs CrowdSec

En regardant les logs du conteneur CrowdSec, j'ai pu voir exactement ce qui s'est passé. CrowdSec a activement rejeté la tentative d'exploit, reconnaissant le payload malveillant en temps réel.

3. Analyse des logs

Pour confirmer, j'ai passé les logs bruts dans un résumé par IA, qui a vérifié que les règles AppSec de CrowdSec ont capturé et rejeté avec succès le payload RCE Next.js avant qu'il n'atteigne mon conteneur d'application.

Conclusion

En combinant Traefik, Dokploy et CrowdSec AppSec, j'ai pu déployer un Web Application Firewall capable et gratuit sur ma Homebox cloud. Mes applications personnelles et mes déploiements rapides sont maintenant protégés des exploits actifs et automatisés dès qu'ils touchent le edge.

Si vous faites du self-hosting ou maintenez un serveur personnel, je recommande d'adopter une architecture WAF similaire au niveau du edge.