Monitoring - Tag - arleo.euhttps://www.arleo.eu/en/tags/monitoring/Monitoring - Tag - arleo.euHugo -- gohugo.ioenThu, 28 May 2026 23:45:41 +0200CSP 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.

]]>CrowdSec Log Pipeline with Vector: Filtering Noise and Capturing Real Banshttps://www.arleo.eu/en/posts/crowdsec-vector-pipeline/Wed, 15 Apr 2026 19:02:00 +0200Jmrhttps://www.arleo.eu/en/posts/crowdsec-vector-pipeline/

⚡ In short

The initial Vector pipeline was flooding BetterStack with ~500 events/24h, of which 434 were CAPI pulls with no local monitoring value. This work reconfigures the Vector filter to keep only high-value bans (cscli) and fixes a major blind spot: actual nginx-lua bouncer bans were not appearing anywhere in BetterStack.

🧠 Why

This homelab’s security stack relies on three components working together:

  • nginx with the CrowdSec lua bouncer (lua-resty-crowdsec) for real-time request blocking
  • CrowdSec for threat detection and ban decision management
  • Vector centralizing logs to BetterStack for monitoring

After setting up the initial pipeline, two problems quickly became apparent. First, the signal was drowned in noise: out of 500 events/24h, 434 came from the hourly community CAPI pull and 66 from third-party lists — neither represents a threat detected on this infrastructure. Second, actual lua bouncer bans (real-time blocks in nginx) were not appearing anywhere in BetterStack, creating a blind spot on real security activity.

]]>Normalizing nginx and CrowdSec Logs in BetterStack with Vectorhttps://www.arleo.eu/en/posts/vector-logs-harmonisation-betterstack/Fri, 10 Apr 2026 21:04:00 +0200Jmrhttps://www.arleo.eu/en/posts/vector-logs-harmonisation-betterstack/

⚡ In short

Two problems coexisted in BetterStack: mcp-oauth.access.log logs arrived as unreadable raw JSON, and CrowdSec logs produced visual duplicates. This work normalizes all logs so they display as structured clickable tags, with correct timestamps and without parasitic fields.

🧠 Why

BetterStack displays logs as highlighted clickable tags in the Live Tail when JSON fields are properly structured. Before this work, observation was degraded on two fronts:

  • mcp-oauth.access.log logs arrived as unreadable raw JSON (custom format incompatible with Vector’s nginx parser) — fields nginx.client, nginx.path, nginx.status were not extracted
  • CrowdSec and CF WAF logs arrived as plain text with duplicates (Ban ban | ... | Ban ban)

The goal was to normalize all logs in BetterStack to display like standard nginx logs:

]]>