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 (interne)

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

Internet
    │
    ▼ (ports 80, 443, 443/udp)
┌─────────────────────────────────────────────────────────┐
│              Caddy (security-stack)                      │
│  ├─ TLS termination (Let's Encrypt, auto-renew)         │
│  ├─ HTTP/3 QUIC support                                 │
│  ├─ Security headers (HSTS, CSP, X-Frame-Options)       │
│  └─ CrowdSec bouncer module                             │
└───────────────────────┬─────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────┐
│              CrowdSec Engine                             │
│  ├─ Parse Caddy access logs                             │
│  ├─ Detect attacks (scenarios)                          │
│  ├─ Apply decisions (ban, captcha)                      │
│  └─ Share threat intel (CAPI)                           │
└───────────────────────┬─────────────────────────────────┘
                        │
                        ▼ (réseau webproxy)
┌─────────────────────────────────────────────────────────┐
│            Services internes                             │
│  ┌─────┐  ┌─────────┐  ┌──────┐  ┌────────┐  ┌──────┐ │
│  │ N8N │  │ Grafana │  │ Odoo │  │  ntfy  │  │ Blog │ │
│  └─────┘  └─────────┘  └──────┘  └────────┘  └──────┘ │
└─────────────────────────────────────────────────────────┘

---

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/*	Claude Ollama	Oui
/webhook/odoo/*	Odoo internal	Oui
/webhook/docker-controller	Telegram Orchestrator	Oui

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

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

---

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