Résumé

Le 25 mai 2026 vers 22h02 (heure locale), Sonarr et Radarr sont devenus totalement inaccessibles depuis l’IP maison (82.XX.XX.XX), retournant 403 sur toutes les URLs y compris /login. Le service était pourtant opérationnel. Le diagnostic initial suspectait les récents déploiements du refactor crowdsec-cf-sync — la cause réelle est un faux positif heuristique CrowdSec AppSec.

Timeline

Cause racine

CrowdSec AppSec maintient un état heuristique en mémoire, distinct des décisions LAPI. Lorsque le navigateur tente de charger simultanément de nombreuses ressources et reçoit des 302/403 de l’application upstream (Sonarr), AppSec interprète cette rafale d’échecs comme du sondage agressif (http-probing) et bloque l’IP source.

Après des années avec ModSecurity + OWASP CRS sur nginx, j’ai migré arleo.eu vers une stack plus moderne : CrowdSec AppSec sur OpenResty. Le résultat est une architecture WAF inline mieux intégrée, plus facile à maintenir, et plus cohérente avec le reste de la stack de sécurité.

Pourquoi abandonner ModSecurity ?

ModSecurity v2 est en fin de vie active. Le maintien des règles OWASP CRS sur nginx classique génère de la friction : faux positifs fréquents, logs difficiles à corréler avec CrowdSec, et une configuration dispersée entre plusieurs outils sans vision unifiée.

⚡ En bref

Un audit de la stack sécurité du NUC révèle une double inspection WAF redondante : ModSecurity + OWASP CRS chargent 11 872 règles en mémoire malgré SecRuleEngine Off, en parallèle d’un CrowdSec AppSec déjà actif et couvrant le même périmètre. Après suppression du module nginx ModSecurity et 5 autres correctifs ciblés, nginx passe de ~520 MB à ~27 MB PSS. Sécurité identique, empreinte divisée par 20.

🏗️ Architecture avant audit

La stack sécurité reposait sur six couches empilées :

⚡ En bref

Le pipeline Vector initial inondait BetterStack de ~500 events/24h, dont 434 pulls CAPI sans valeur de supervision locale. Ce travail reconfigure le filtre Vector pour ne garder que les bans à haute valeur (cscli) et corrige un angle mort majeur : les bans effectifs du bouncer nginx-lua n’apparaissaient nulle part dans BetterStack.

🧠 Pourquoi

La stack de sécurité repose sur trois composants qui travaillent ensemble :

• nginx avec le bouncer lua CrowdSec (lua-resty-crowdsec) qui bloque les requêtes en temps réel
• CrowdSec pour la détection et la gestion des décisions de ban
• Vector qui centralise les logs vers BetterStack pour la supervision

Après avoir mis en place le pipeline initial, deux problèmes sont apparus rapidement. D’abord, le signal était noyé dans le bruit : sur 500 events/24h, 434 venaient du pull CAPI communautaire horaire et 66 des listes tierces — ni les uns ni les autres ne représentent une menace détectée sur cette infrastructure. Ensuite, les bans effectifs du bouncer lua (blocages en temps réel dans nginx) n’apparaissaient nulle part dans BetterStack, ce qui créait un angle mort sur l’activité de sécurité réelle.

2. CrowdSec → Cloudflare Sync (crowdsec-cf-sync.py)

Emplacement : /usr/local/bin/crowdsec-cf-sync.py Service : crowdsec-cf-sync.service Logs : /var/log/crowdsec/cf-sync.log

Emplacement : /usr/local/bin/crowdsec-cf-sync.py Service systemd : crowdsec-cf-sync.service Logs : /var/log/crowdsec/cf-sync.log

Installation

cp crowdsec-cf-sync.py /usr/local/bin/
chmod +x /usr/local/bin/crowdsec-cf-sync.py
systemctl enable crowdsec-cf-sync
systemctl start crowdsec-cf-sync

Fonctionnalités

• Synchronise les bans CrowdSec actifs → Cloudflare IP Access Rules (tag crowdsec-local-ban)
• Reporte les IPs bannies → AbuseIPDB (fenêtre 48h, dédupliqué)
• Escalade récidivistes : 1er ban CrowdSec gère | 2ème → 24h | 3ème+ → 7j (fenêtre 7j)
• ModSecurity score ≥ 5 → ban CF immédiat 2h (tag modsec-ban) + report AbuseIPDB
• Ban /24 automatique : 2+ IPs du même bloc en 7j → ban CF + CrowdSec 24h (tag crowdsec-cidr-ban)

Bugs corrigés (avril 2026)

• cs_origin vs origin dans get_recent_local_bans() — le champ JSON s’appelle cs_origin
• Pagination API REST /v1/decisions?limit=1000 rate les bans cscli → remplacé par cscli decisions list --origin
• Items → items (minuscule) dans le parsing JSON de la allowlist CrowdSec

⚠️ Important : les vrais tokens (CF_API_TOKEN, CF_ZONE_ID, CS_API_KEY, ABUSEIPDB_KEY) doivent être stockés dans /etc/secrets/ avec chmod 600 et chargés via variables d’environnement, pas hardcodés dans le script. Les valeurs VOTRE_* ci-dessous sont des placeholders.

]]> https://www.arleo.eu/posts/vector-logs-harmonisation-betterstack/ Fri, 10 Apr 2026 21:04:00 +0200 Jmr https://www.arleo.eu/posts/vector-logs-harmonisation-betterstack/

⚡ En bref

Deux problèmes coexistaient dans BetterStack : les logs mcp-oauth.access.log arrivaient en JSON brut illisible, et les logs CrowdSec produisaient des doublons visuels. Ce travail uniformise tous les logs pour qu’ils s’affichent comme des tags cliquables structurés, avec timestamps corrects et sans champs parasites.

🧠 Pourquoi

BetterStack affiche les logs sous forme de tags surlignés cliquables dans le Live Tail lorsque les champs JSON sont correctement structurés. Avant ce travail, l’observation était dégradée sur deux fronts :

]]> https://www.arleo.eu/posts/crowdsec-cloudflare-waf-autoban/ Fri, 10 Apr 2026 00:23:00 +0200 Jmr https://www.arleo.eu/posts/crowdsec-cloudflare-waf-autoban/

⚡ En bref

Le monitoring passif ne suffit pas. Ce pipeline automatise la fermeture de la boucle en moins de 5 minutes entre une attaque détectée par Cloudflare WAF et le ban effectif de l’IP dans CrowdSec, sa synchronisation vers Cloudflare et son signalement sur AbuseIPDB. Un script Python poll l’API GraphQL Cloudflare toutes les 5 minutes, applique un seuil de 3 hits, et déclenche le ban avec escalade récidiviste.

]]>