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.

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.

🧠 Pourquoi

Voir une attaque dans les logs BetterStack après coup n’empêche pas l’IP malveillante de continuer à frapper. Sans automatisation, la boucle détection → ban prend des heures ou ne se ferme jamais. Les actions WAF Cloudflare (block, challenge, managed_challenge, jschallenge) sont des signaux clairs d’attaque, mais ils restent confinés dans le dashboard Cloudflare — sans pont vers CrowdSec, aucune IP n’est bannie localement, aucune n’est signalée à la communauté AbuseIPDB.

En bref

arleo.eu a été injoignable pendant 3 heures. La cause n’était ni le serveur, ni nginx, ni CrowdSec — c’était une règle de port forwarding HTTPS attachée à WAN générique au lieu de WAN1 explicite sur le Netgear PR60X. Le renouvellement quotidien du bail DHCP du modem 4G (WAN2) a déclenché un rebalance NAT qui a cassé le routage vers le port 443.