Why I built warden: fail2ban can't see attackers behind a Cloudflare tunnel

Description and use

Warden addresses the issue of banning attackers behind a Cloudflare tunnel where the real IP is only in HTTP headers. It collects and scores logs, proposes Cloudflare WAF rules via Discord for manual approval, and provides agentless vulnerability scanning.

Problem

Fail2ban and other local firewalls cannot block attackers when services are behind a Cloudflare tunnel because the real client IP is only present in HTTP headers, not at the network layer.

Outcome

Warden enabled accurate detection of attackers behind Cloudflare tunnels, prevented accidental self‑bans, and consolidated security tooling into a single, lightweight, agentless system.

Workflow

• 1. Collect logs from CrowdSec, reverse proxy, SSO, and Cloudflare tunnel.
• 2. Parse and score events to identify potential attackers.
• 3. Record proposed bans without applying them automatically.
• 4. Post proposals to Discord for review.
• 5. Upon approval, add a Cloudflare WAF rule that expires after 30 days; record rejections for 90 days.
• 6. Continuously update device inventory and DNS baselines to refine scoring.

Evidence

Behind the tunnel, the source address at the network layer is cloudflared or the Cloudflare edge. The attacker's real address only exists in the HTTP layer, in a header the proxy passes along.

Source

Warden ships detect-only. It records what it would ban and changes nothing. When I want something blocked at the edge, it proposes it in Discord and I tap ✅ or ❌.

Source

Everything it does is agentless. Vulnerability scanning copies the package list off each box and checks it against OSV.dev...

Source