Monitoring - Balise - arleo.eu https://www.arleo.eu/tags/monitoring/ Monitoring - Balise - arleo.eu Hugo -- gohugo.iofrThu, 28 May 2026 23:40:12 +0200 CSP A+ sur Hugo + Cloudflare : de hash-based à origin allowlist, monitoring auto et durcissement https://www.arleo.eu/posts/csp-a-plus-hugo-cloudflare-origin-allowlist/ Thu, 28 May 2026 23:40:12 +0200 Jmr https://www.arleo.eu/posts/csp-a-plus-hugo-cloudflare-origin-allowlist/

Contexte

arleo.eu tourne sur Hugo (VM KVM) → OpenResty (NUC) → Cloudflare (CDN/WAF). Objectif : score A+ sur Mozilla Observatory avec une CSP stricte qui résiste aux injections côté edge.

Le parcours a traversé trois stratégies en quelques semaines — nonces, hashes, puis origin allowlist — avant d’aboutir à une solution stable et automatisée.

Acte 1 : pourquoi hash-based a échoué

L’idée de départ semblait solide : Hugo Pipes externalise tout le JS avec SRI, on liste les hashes dans la CSP, résultat propre. En pratique, deux problèmes ont rendu l’approche impossible.

]]> SRI sur Hugo : hashes automatiques, auto-update et alerting BetterStack https://www.arleo.eu/posts/sri-cdn-hugo-automate/ Sun, 17 May 2026 00:00:00 +0000 Jmr https://www.arleo.eu/posts/sri-cdn-hugo-automate/

Pourquoi le SRI ?

Quand votre site charge des ressources depuis un CDN tiers — FontAwesome, Mermaid, Animate.css — vous faites confiance à un tiers sur lequel vous n’avez aucun contrôle. Si jsdelivr.net est compromis ou si une version « immuable » est mutée silencieusement, votre site peut devenir vecteur d’attaque.

Le Subresource Integrity (SRI) résout ça simplement : chaque balise <link> ou <script> porte un attribut integrity="sha256-…" que le navigateur vérifie avant d’exécuter la ressource. Si le hash ne correspond pas, le navigateur bloque le chargement.

]]> Pipeline de logs CrowdSec avec Vector : filtrer le bruit et capturer les vrais bans https://www.arleo.eu/posts/crowdsec-vector-pipeline/ Wed, 15 Apr 2026 19:01:00 +0200 Jmr https://www.arleo.eu/posts/crowdsec-vector-pipeline/

⚡ 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.

]]> Harmonisation des logs nginx et CrowdSec dans BetterStack via Vector 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 :

]]>