Security Stack : Caddy + CrowdSec

1. Quoi ? — Définition et contexte

La Security Stack est la couche de protection qui se place entre Internet et tous les services de l’infrastructure. Elle combine deux composants :

Composant	Rôle	Port
Caddy	Reverse proxy avec TLS automatique et HTTP/3	80, 443, 443/udp
CrowdSec	WAF comportemental et threat intelligence collaborative	8080 (LAPI), 7422 (AppSec)
Trivy	Scanner CVE pour images Docker, appelé via docker exec	aucun port exposé

Reverse proxy

Un reverse proxy est un serveur qui reçoit tout le trafic externe et le redistribue aux services internes. Cela permet d’avoir un seul point d’entrée sécurisé avec TLS, et d’exposer plusieurs services sur le même serveur.

Architecture visuelle

---

2. Pourquoi ? — Enjeux et motivations

Pourquoi Caddy plutôt que Nginx ou Traefik ?

Critère	Caddy	Nginx	Traefik
TLS automatique	Natif (Let’s Encrypt)	Certbot externe	Natif
HTTP/3 QUIC	Natif	Module expérimental	Non
Configuration	Caddyfile simple	nginx.conf verbeux	YAML/Labels
Rechargement	Sans interruption	Reload graceful	Sans interruption
CrowdSec	Module bouncer officiel	Module lua	Plugin tiers

Critères de décision :

1. Simplicité — La syntaxe Caddyfile est lisible et concise
2. TLS zéro-config — Certificats Let’s Encrypt automatiques, pas de cron Certbot
3. Intégration CrowdSec native — Module bouncer officiel, pas de workaround

Qu’est-ce que CrowdSec apporte ?

WAF comportemental

Un WAF (Web Application Firewall) analyse les requêtes HTTP pour détecter et bloquer les attaques : injections SQL, XSS, scans de vulnérabilités, brute force… CrowdSec est “comportemental” : il apprend des patterns d’attaque.

Fonction	Bénéfice
Threat intelligence collaborative	Les IPs malveillantes détectées par d’autres instances CrowdSec sont partagées
Scénarios de détection	Règles prêtes pour HTTP, SSH, CVE connus
Bouncer temps réel	Les IPs bannies sont bloquées avant d’atteindre le backend
Whitelists automatiques	Bots légitimes (Googlebot, etc.) ne sont pas bloqués

---

3. Comment ? — Mise en œuvre technique

Configuration Caddyfile

{
    # Options globales
    email admin@guigpap.com

    # Module CrowdSec
    crowdsec {
        api_url http://crowdsec:8080
        api_key {env.CROWDSEC_API_KEY}
        ticker_interval 15s
    }
}

# Redirection www → apex
www.guigpap.com {
    redir https://guigpap.com{uri} permanent
}

# Site principal
guigpap.com {
    crowdsec

    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Referrer-Policy "strict-origin-when-cross-origin"
    }

    reverse_proxy blog:4321
}

# N8N avec webhooks protégés
n8n.guigpap.com {
    crowdsec

    # Bloquer les webhooks internes depuis l'extérieur
    @blocked_webhooks {
        path /webhook/notify/*
        path /webhook/prometheus/*
        path /webhook/claude/*
        path /webhook/claude-simple-chat
        path /webhook/docker-controller
        path /webhook/odoo/*
    }
    respond @blocked_webhooks 403

    reverse_proxy n8n:5678
}

# Autres services
grafana.guigpap.com {
    crowdsec
    reverse_proxy grafana:3000
}

odoo.guigpap.com {
    crowdsec
    reverse_proxy odoo:8069
}

Collections CrowdSec installées

# Lister les collections actives
docker exec crowdsec cscli collections list

Collection	Rôle
crowdsecurity/caddy	Parser des logs Caddy
crowdsecurity/base-http-scenarios	Détection attaques HTTP courantes
crowdsecurity/http-cve	Exploits CVE connus
crowdsecurity/appsec-virtual-patching	Patching virtuel
crowdsecurity/linux	Scénarios système Linux
crowdsecurity/sshd	Détection brute force SSH
crowdsecurity/whitelist-good-actors	Liste blanche bots légitimes

Comment fonctionne le bouncer

1. Caddy reçoit une requête
2. Le module bouncer interroge l’API CrowdSec (cache local)
3. Si l’IP est dans la liste de décisions → 403 Forbidden
4. Sinon → requête transmise au backend

Latence

Le bouncer met en cache les décisions localement. L’interrogation de l’API CrowdSec n’ajoute que quelques millisecondes, uniquement pour les nouvelles IPs.

Protection des webhooks internes

Webhook	Appelé par	Bloqué depuis Internet
/webhook/notify/*	DIUN	Oui
/webhook/prometheus/*	Alertmanager	Oui
/webhook/claude/*	CLI Ollama	Oui
/webhook/claude-simple-chat, /webhook/claude-approve, /webhook/claude-reject	N8N	Oui
/webhook/odoo/*	Odoo internal	Oui
/webhook/docker-controller	Telegram Orchestrator	Oui
/webhook/notification-hub	N8N (Execute Workflow)	Oui

Les services internes appellent ces webhooks via http://n8n:5678 (réseau Docker), pas via le domaine public.

Rate limiting et AppSec WAF

Les routes webhooks de n8n.guigpap.com sont rate-limitées à 30 requêtes/minute par IP via le module caddy-ratelimit. Cela complète l’auth (Bearer / Header / HMAC) en empêchant le brute-force sur les endpoints exposés. CrowdSec AppSec écoute en parallèle sur le port 7422 et rejoue les règles crowdsecurity/appsec-virtual-patching + appsec-generic-rules avant que les requêtes atteignent les backends.

Crawlers IA et llms.txt

Le blog (blog.guigpap.com) sert volontairement deux artefacts pour les crawlers IA (ChatGPT, Gemini, Perplexity, etc.) :

1. /llms.txt et /llms-full.txt — index machine-readable des articles du blog, déclarés via header Link :

   header Link "</llms.txt>; rel=\"llms-txt\", </llms-full.txt>; rel=\"llms-full-txt\""
   header X-Llms-Txt "/llms.txt"

2. Mirrors Markdown — chaque article a un jumeau .md qui rend la version source. Caddy force Content-Type: text/plain au lieu de text/markdown parce que les parseurs des crawlers grand public laissent passer plain text mais ignorent souvent text/markdown :

   @markdown_mirror path_regexp md_ext \.md$
   header @markdown_mirror {
       Content-Type "text/plain; charset=utf-8"
       defer
   }

La CSP du blog autorise 'wasm-unsafe-eval' (pour Pagefind, le moteur de recherche statique) et les data: URIs côté font-src (pour les sous-ensembles fontsource embarqués) :

header Content-Security-Policy "default-src 'self'; \
  script-src 'self' 'unsafe-inline' 'wasm-unsafe-eval'; \
  style-src 'self' 'unsafe-inline'; \
  img-src 'self' data:; \
  font-src 'self' data:"

CrowdSec : image Debian + détection SSH

L’engine CrowdSec utilise l’image latest-debian (et non Alpine) car le VPS Debian 13 expose ses logs SSH uniquement via journald — il n’y a pas de /var/log/auth.log. L’image Debian inclut journalctl ; l’image Alpine ne l’a pas. Le container monte /var/log/journal, /run/log/journal et /etc/machine-id du host.

Layer	Rôle	Application
CrowdSec + Caddy bouncer	HTTP/HTTPS	Block via Caddy (403)
CrowdSec SSH detection	Brute-force SSH	Détection seule (pas de bouncer host)
fail2ban	Enforcement SSH	Ban via nftables (inet f2b-table)
UFW	Firewall baseline	Ports 22, 80, 443 uniquement

SSH non bloqué par CrowdSec

CrowdSec détecte les scenarios SSH brute-force (incl. CVE-2024-6387) mais ne peut pas bloquer au niveau réseau — il n’y a pas de bouncer firewall sur le host. fail2ban est le seul service qui bloque réellement les attaquants SSH sur ce VPS.

Commandes d’exploitation

# Gestion CrowdSec
docker exec crowdsec cscli decisions list      # IPs bannies
docker exec crowdsec cscli decisions delete --ip 1.2.3.4  # Débannir
docker exec crowdsec cscli alerts list         # Alertes récentes
docker exec crowdsec cscli metrics             # Statistiques

# Gestion Caddy
docker exec caddy caddy validate --config /etc/caddy/Caddyfile
docker exec caddy caddy reload --config /etc/caddy/Caddyfile
docker logs caddy --tail 100

# Trivy : scan d'une image
docker exec trivy trivy image --format json \
  --severity CRITICAL,HIGH --ignore-unfixed postgres:17

---

4. Et si ? — Perspectives et limites

Retour d’expérience actuel

Déploiement récent

CrowdSec est installé récemment sur cette infrastructure. Le recul n’est pas encore suffisant pour quantifier les attaques bloquées ou identifier des patterns de faux positifs.

Limites actuelles

Limite	Impact	Mitigation
Pas de HA Caddy	Single point of failure	Monitoring + restart auto
CrowdSec non testé en charge	Comportement inconnu sous attaque DDoS	Rate limiting amont possible
Faux positifs possibles	IPs légitimes potentiellement bloquées	Whitelist manuelle à prévoir

Scénarios d’évolution

Si des faux positifs apparaissent :

• Créer des whitelists par IP ou par User-Agent
• Ajuster les seuils des scénarios (cscli scenarios inspect)
• Désactiver des scénarios trop agressifs

Si la charge augmente :

• Activer le mode streaming Caddy pour les gros fichiers
• Ajouter un cache (Varnish) devant certains services
• Considérer un CDN (Cloudflare) pour le contenu statique

Si une attaque DDoS survient :

• CrowdSec détecte mais ne suffit pas seul
• Activer le mode Under Attack de Cloudflare
• Contacter l’hébergeur pour mitigation amont

Métriques à surveiller

Métrique	Source	Seuil d’attention
IPs bannies/jour	cscli decisions list	> 100 = vérifier les scénarios
Alertes HTTP	cscli alerts list	Spike soudain = attaque potentielle
403 responses	Logs Caddy	Taux anormal = faux positifs possibles

---

Pages liées

Infrastructure

• Architecture VPS — Vue d’ensemble
• Monitoring Stack — Métriques Caddy

Référence

• Glossaire — WAF, Bouncer, TLS, Reverse Proxy