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 :

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.

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

Connecter Claude.ai à un site Hugo hébergé dans une VM KVM en 30 minutes : un serveur FastAPI expose 6 outils MCP (lire, créer, modifier, supprimer des pages, rebuilder le site) via JSON-RPC 2.0, un proxy OAuth réutilise l’infrastructure existante, et chaque modification déclenche automatiquement un rebuild Hugo + une purge du cache Cloudflare.

Le code est disponible sur GitHub :

• 🔌 Serveur MCP Hugo : jmrGrav/hugo-mcp
• 🔐 Proxy OAuth : jmrGrav/mcp-oauth-proxy

🧠 Pourquoi

Le protocole MCP (Model Context Protocol) d’Anthropic permet à Claude.ai de se connecter à des sources de données externes via des outils standardisés. Contrairement à Grav CMS qui est dynamique (PHP), Hugo génère du HTML statique — ce qui rend la gestion de contenu via MCP encore plus puissante : chaque modification est compilée et déployée instantanément.

⚡ En bref

Migrer son media stack (Sonarr, Radarr, SABnzbd) dans une VM KVM dédiée sur Ubuntu 24.04 : isolation sécurité, snapshots facilités, NFS QNAP monté dans la VM, reverse proxy nginx sur l’hôte. La migration conserve intégralement les bases de données SQLite et la configuration existante.

Stack cible :

• 🖥️ Hôte : NUC8i3BEH, Ubuntu Server, nginx reverse proxy, Plex (transcodage GPU)
• 📦 VM media-vm : Ubuntu 24.04, 2 vCPU, 8 Go RAM, 120 Go (X5 NVMe), NFS QNAP
• 🎬 Services migrés : Sonarr (port 8989), Radarr (port 7878), SABnzbd (port 6789)

🧠 Pourquoi isoler le media stack dans une VM

Sonarr, Radarr et SABnzbd présentent une surface d’attaque non négligeable : accès réseau vers des indexeurs externes, exécution de scripts post-download, accès au système de fichiers de la bibliothèque. Les confiner dans une VM apporte :

⚡ En bref

Migration progressive de Grav CMS vers Hugo — un générateur de site statique. L’objectif est d’isoler Hugo dans une VM KVM dédiée sur le NUC8i3BEH, avec nginx sur le host en proxy inverse. Le site statique généré est servi par nginx dans la VM, sans PHP, sans base de données, sans surface d’attaque applicative.

• 🖥️ Host : NUC8i3BEH Ubuntu 24.04 — nginx proxy + KVM
• 🗄️ Disque VM : NVMe externe Samsung X5 (exFAT → image ext4 loop)
• 🌐 Accès : hugo-test.arleo.eu
• 🎨 Thème : LoveIt

🧠 Pourquoi

Grav CMS est excellent mais repose sur PHP — une surface d’attaque non négligeable. Hugo génère du HTML statique pur : zéro PHP, zéro base de données, zéro vulnérabilité applicative. Les performances sont aussi radicalement meilleures — le HTML est servi directement par nginx sans traitement dynamique.

⚡ 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