Cloudflare - Tag - arleo.euhttps://www.arleo.eu/en/tags/cloudflare/Cloudflare - Tag - arleo.euHugo -- gohugo.ioenFri, 29 May 2026 20:30:00 +0200Hugo SEO: Googlebot 404s, noindex aliases and sitemap normalizationhttps://www.arleo.eu/en/posts/debug-seo-404-broken-links/Fri, 29 May 2026 20:30:00 +0200Jmrhttps://www.arleo.eu/en/posts/debug-seo-404-broken-links/

Context

Google Search Console was reporting four categories of issues on arleo.eu:

  • Googlebot 404s: /fr/tag/cloudflare, /en/tag/nginx, /fr/tag/javascript… URLs with /fr/ prefix or singular /tag/ never served by nginx
  • 16 “Excluded by noindex tag” pages: all redirect pages generated by aliases: in Hugo frontmatter
  • Robots tag: noodp hardcoded in the LoveIt theme
  • FR/EN sitemap: 104 vs 105 URLs — a duplicate FR tag and two missing tags

Act 1: Hugo aliases → nginx 301 redirects

Why Hugo generates noindex pages

Hugo generates aliases: frontmatter entries as static HTML files:

]]>CSP A+ on Hugo + Cloudflare: from hash-based to origin allowlist, auto-monitoring and hardeninghttps://www.arleo.eu/en/posts/csp-a-plus-hugo-cloudflare-origin-allowlist/Thu, 28 May 2026 23:45:41 +0200Jmrhttps://www.arleo.eu/en/posts/csp-a-plus-hugo-cloudflare-origin-allowlist/

Context

arleo.eu runs on Hugo (KVM VM) → OpenResty (NUC) → Cloudflare (CDN/WAF). Goal: A+ score on Mozilla Observatory with a strict CSP that resists edge-side injections.

The journey went through three strategies over a few weeks — nonces, hashes, then origin allowlist — before landing on a stable, automated solution.

Act 1: why hash-based failed

The initial idea seemed solid: Hugo Pipes externalizes all JS with SRI, we list the hashes in the CSP, clean result. In practice, two problems made the approach impossible.

]]>SRI on Hugo: automated hashes, auto-update and BetterStack alertinghttps://www.arleo.eu/en/posts/sri-cdn-hugo-automate/Sun, 17 May 2026 00:00:00 +0000Jmrhttps://www.arleo.eu/en/posts/sri-cdn-hugo-automate/

Why SRI?

When your site loads resources from a third-party CDN — FontAwesome, Mermaid, Animate.css — you’re trusting an external party you have no control over. If jsdelivr.net gets compromised, or if a supposedly immutable version is silently mutated, your site can become an attack vector.

Subresource Integrity (SRI) solves this cleanly: every <link> or <script> tag carries an integrity="sha256-…" attribute that the browser verifies before executing the resource. If the hash doesn’t match, the browser blocks the load.

]]>CSP Hash on Hugo: migrating from nonce to hash to preserve CDN cachehttps://www.arleo.eu/en/posts/csp-hash-hugo/Sat, 16 May 2026 00:00:00 +0000Jmrhttps://www.arleo.eu/en/posts/csp-hash-hugo/<div class="featured-image"> <img src="/images/csp-hash-hugo-featured.png" referrerpolicy="no-referrer"> </div>CSP nonces and CDN caching are incompatible by design. On a Hugo static site, SHA-256 hashes are the native approach: computed at build time, stable across requests, and fully compatible with Cloudflare caching.hugo-mcp Cloudflare plugin: smart cache purgehttps://www.arleo.eu/en/posts/hugo-mcp-plugin-cloudflare/Thu, 14 May 2026 09:43:19 +0200Jmrhttps://www.arleo.eu/en/posts/hugo-mcp-plugin-cloudflare/

TL;DR

The Cloudflare plugin in hugo-mcp v2.0 implements 3 cache purge modes (full, partial, smart). The partial mode computes the linked URLs to invalidate (canonical + sitemap + RSS + listing + home) to preserve 95% of the CDN cache on every modification. Concretely: 6 URLs purged instead of wiping everything. This post details the computation, the pitfalls, and why smart became the default.

]]>Post-mortem: Cloudflare Bot Management blocked MCP webhookshttps://www.arleo.eu/en/posts/postmortem-cf-bot-blocking-mcp/Sat, 09 May 2026 13:06:02 +0200Jmrhttps://www.arleo.eu/en/posts/postmortem-cf-bot-blocking-mcp/

The symptom

I just finished a webhook endpoint in hugo-mcp-proxy that will receive notifications from GitHub on every push to the arleo.eu repo. Clean implementation: HMAC-SHA256, rate limiting, IPAddressAllow GitHub ranges in systemd.

Functional test from an external client:

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

Response: 403 Forbidden.

Strange. The service is running, my source IP is whitelisted, the HMAC is correct. Why 403?

Server-side investigation

NUC nginx logs:

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

Empty. No request reaches nginx.

mcp-oauth-proxy logs:

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

Empty too. The request doesn’t even reach the service.

Either it’s blocked by the firewall before nginx (CrowdSec or ufw), or upstream by Cloudflare.

The truth at Cloudflare

]]>Post-mortem: 3 MCP timeouts — IPAddressDeny + Cloudflare + NFShttps://www.arleo.eu/en/posts/postmortem-mcp-timeouts-cloudflare/Sat, 09 May 2026 13:04:20 +0200Jmrhttps://www.arleo.eu/en/posts/postmortem-mcp-timeouts-cloudflare/

Context

I deployed a Hugo MCP Server (FastAPI, 7 tools) that lets me edit arleo.eu from Claude.ai. Architecture: claude.ai → mcp-oauth-proxy NUC → hugo-mcp-proxy NUC → MCP server VM.

]]>From 46 Hashes to Zero: Migrating CSP to Dynamic Nonceshttps://www.arleo.eu/en/posts/csp-nonce/Wed, 15 Apr 2026 13:22:00 +0200Jmrhttps://www.arleo.eu/en/posts/csp-nonce/

⚡ In short

The original CSP listed 46 SHA-256 hashes to cover inline scripts and styles — unmanageable, fragile, and approaching Cloudflare’s 4,096 character limit. This migration to dynamic nonces reduces the CSP to ~600 characters, eliminates all manual hash maintenance, and adds structured violation reporting in BetterStack.

The Grav plugin powering this is available on GitHub: 🔌 Plugin : jmrGrav/grav-plugin-csp-nonce

🧠 Why

When implementing a strict Content Security Policy on a Grav CMS site served through Cloudflare, the naive approach is to list SHA-256 hashes for every inline script. It works, but quickly becomes unmanageable. Several compounding problems:

]]>Infrastructure Scriptshttps://www.arleo.eu/en/scripts/Sun, 12 Apr 2026 21:25:00 +0200Jmrhttps://www.arleo.eu/en/scripts/1. crowdsec-cf-sync.py

Location: /usr/local/bin/crowdsec-cf-sync.py Systemd service: 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

Features

  • Syncs active CrowdSec bans → Cloudflare IP Access Rules (tag crowdsec-local-ban)
  • Reports banned IPs → AbuseIPDB (48h window, deduplicated)
  • Repeat-offender escalation: 1st CrowdSec ban handles | 2nd → 24h | 3rd+ → 7d (7d window)
  • ModSecurity score ≥ 5 → immediate 2h CF ban (tag modsec-ban) + AbuseIPDB report
  • Automatic /24 ban: 2+ IPs from same block in 7d → CF + CrowdSec ban 24h (tag crowdsec-cidr-ban)

Bug fixes (April 2026)

  • cs_origin vs origin in get_recent_local_bans() — the JSON field is cs_origin
  • REST API pagination /v1/decisions?limit=1000 misses cscli bans → replaced with cscli decisions list --origin
  • Items → items (lowercase) in CrowdSec allowlist JSON parsing

⚠️ Important: real tokens (CF_API_TOKEN, CF_ZONE_ID, CS_API_KEY, ABUSEIPDB_KEY) must be stored in /etc/secrets/ with chmod 600 and loaded via environment variables, not hardcoded in the script. The VOTRE_* values below are placeholders.

]]>Automating IP Bans with Cloudflare WAF, CrowdSec and AbuseIPDBhttps://www.arleo.eu/en/posts/crowdsec-cloudflare-waf-autoban/Fri, 10 Apr 2026 00:23:00 +0200Jmrhttps://www.arleo.eu/en/posts/crowdsec-cloudflare-waf-autoban/

⚡ In short

Passive monitoring is not enough. This pipeline automates closing the loop in under 5 minutes between an attack detected by Cloudflare WAF and the effective ban of the IP in CrowdSec, its synchronization to Cloudflare, and its report to AbuseIPDB. A Python script polls the Cloudflare GraphQL API every 5 minutes, applies a 3-hit threshold, and triggers the ban with recidivist escalation.

🧠 Why

Seeing an attack in BetterStack logs after the fact does not stop the malicious IP from continuing to hammer the server. Without automation, the detection → ban loop takes hours or never closes. Cloudflare WAF actions (block, challenge, managed_challenge, jschallenge) are clear attack signals, but they remain confined to the Cloudflare dashboard — without a bridge to CrowdSec, no IP is banned locally, none is reported to the AbuseIPDB community.

]]>