Cloudflare - Balise - arleo.eu https://www.arleo.eu/tags/cloudflare/ Cloudflare - Balise - arleo.eu Hugo -- gohugo.iofrFri, 29 May 2026 20:30:00 +0200 SEO Hugo : 404 Googlebot, aliases noindex et normalisation des sitemaps https://www.arleo.eu/posts/debug-seo-404-broken-links/ Fri, 29 May 2026 20:30:00 +0200 Jmr https://www.arleo.eu/posts/debug-seo-404-broken-links/

Contexte

Google Search Console remontait quatre catégories de problèmes sur arleo.eu :

  • 404 Googlebot : /fr/tag/cloudflare, /en/tag/nginx, /fr/tag/javascript… URLs avec préfixe /fr/ ou singulier /tag/ jamais servi par nginx
  • 16 pages “Exclue par la balise noindex” : toutes des pages de redirection générées par aliases: dans le frontmatter Hugo
  • Balise robots : noodp hardcodée dans le thème LoveIt
  • Sitemap FR/EN : 104 vs 105 URLs — un tag doublon FR et deux tags manquants

Acte 1 : aliases Hugo → redirections nginx 301

Pourquoi Hugo génère des pages noindex

Hugo génère les entrées aliases: du frontmatter comme des fichiers HTML statiques :

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

]]> CSP Hash sur Hugo : migrer du nonce vers le hash pour préserver le cache CDN https://www.arleo.eu/posts/csp-hash-hugo/ Sat, 16 May 2026 00:00:00 +0000 Jmr https://www.arleo.eu/posts/csp-hash-hugo/ Le nonce CSP et le cache CDN sont incompatibles par design. Sur un site Hugo statique, le hash SHA-256 est l’approche native : il est calculé au build, reste stable entre les requêtes, et laisse Cloudflare cacher le HTML.]]> Plugin Cloudflare hugo-mcp : purge ciblée plutôt que totale https://www.arleo.eu/posts/hugo-mcp-plugin-cloudflare/ Thu, 14 May 2026 09:42:22 +0200 Jmr https://www.arleo.eu/posts/hugo-mcp-plugin-cloudflare/

TL;DR

Le plugin Cloudflare de hugo-mcp v2.0 implémente 3 modes de purge cache (full, partial, smart). Le mode partial calcule les URLs liées à invalider (canonique + sitemap + RSS + listing + home) pour préserver 95% du cache CDN à chaque modification. Concrètement : 6 URLs purgées au lieu de tout vider. Ce post détaille le calcul, les pièges, et pourquoi smart est devenu le défaut.

]]> Post-mortem : Cloudflare Bot Management bloquait les webhooks MCP https://www.arleo.eu/posts/postmortem-cf-bot-blocking-mcp/ Sat, 09 May 2026 12:46:28 +0200 Jmr https://www.arleo.eu/posts/postmortem-cf-bot-blocking-mcp/

Le symptôme

Je viens de finaliser un endpoint webhook dans le hugo-mcp-proxy qui recevra des notifications de GitHub à chaque push sur le repo arleo.eu. Implementation propre : HMAC-SHA256, rate limiting, IPAddressAllow GitHub ranges côté systemd.

Test fonctionnel depuis un client externe :

$ curl -X POST https://mcp-hugo.arleo.eu/webhook/test \
    -H "Content-Type: application/json" \
    -d '{"test": true}'

Réponse : 403 Forbidden.

Curieux. Le service tourne, l’IP source de mon test est dans le whitelist, le HMAC est correct. Pourquoi 403 ?

Investigation côté serveur

Logs nginx côté NUC :

$ sudo tail -100 /var/log/nginx/mcp-hugo.access.log | grep webhook

Vide. Aucune requête n’arrive sur nginx.

Logs mcp-oauth-proxy :

$ sudo journalctl -u mcp-oauth-proxy -n 100 | grep webhook

Vide aussi. La requête n’arrive pas jusqu’au service.

Soit elle est bloquée par firewall avant nginx (CrowdSec ou ufw), soit en amont par Cloudflare.

La vérité côté Cloudflare

]]> Post-mortem : 3 timeouts MCP — IPAddressDeny + Cloudflare + NFS https://www.arleo.eu/posts/postmortem-mcp-timeouts-cloudflare/ Sat, 09 May 2026 12:44:44 +0200 Jmr https://www.arleo.eu/posts/postmortem-mcp-timeouts-cloudflare/

Contexte

J’ai mis en production un Hugo MCP Server (FastAPI, 7 tools) qui me permet d’éditer arleo.eu depuis Claude.ai. Architecture : claude.ai → mcp-oauth-proxy NUC → hugo-mcp-proxy NUC → MCP server VM.

]]> De 46 hashes à zéro : migration CSP vers les nonces dynamiques https://www.arleo.eu/posts/csp-nonce/ Wed, 15 Apr 2026 13:22:00 +0200 Jmr https://www.arleo.eu/posts/csp-nonce/

⚡ En bref

La CSP initiale listait 46 hashes SHA-256 pour couvrir les scripts et styles inline — ingérable, fragile, et à la limite des 4 096 caractères de Cloudflare. Cette migration vers des nonces dynamiques réduit la CSP à ~600 caractères, supprime toute maintenance manuelle des hashes, et ajoute un reporting structuré des violations dans BetterStack.

Le plugin Grav utilisé est disponible sur GitHub : 🔌 Plugin : jmrGrav/grav-plugin-csp-nonce

]]> Scripts Infrastructure https://www.arleo.eu/scripts/ Sun, 12 Apr 2026 21:24:00 +0200 Jmr https://www.arleo.eu/scripts/ 1. crowdsec-cf-sync.py

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.

]]> Automatiser le ban d'IPs avec Cloudflare WAF, CrowdSec et AbuseIPDB 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.

]]>