Cloudflare

Origin Hardening & Zero Trust Architecture with Cloudflare Tunnels

Diogo Moleta

Diogo Moleta

— 3 min read
Share
Origin Hardening & Zero Trust Architecture with Cloudflare Tunnels

One of the most critical and frequently overlooked vulnerabilities in perimeter security architectures is the WAF Bypass via Direct Origin Access.

When deploying a Web Application Firewall (WAF) at the edge, organizations often assume all incoming web traffic is thoroughly inspected before reaching their applications. However, if the origin server maintains open inbound ports (e.g., 80 or 443) and possesses a discoverable public IP address whether leaked via historical DNS records like Shodan, Censys, or active network reconnaissance an attacker can bypass the edge entirely by directing malicious requests straight to the origin server's IP address.

In this second SecOps project, the goal was to eliminate this attack vector by implementing a Zero Trust Origin Hardening architecture using Cloudflare Tunnels (cloudflared), ensuring the origin server remains completely invisible to the public Internet.

The Technical Problem: The Illusion of Edge Security

In the previous project, a spoofing mitigation rule leveraging User-Agent Client Hints (UA-CH) was deployed at the WAF level. While the rule successfully blocked manipulated traffic at the edge, a core architectural flaw remained:

  • Legitimate Flow: Client ->Cloudflare Edge (WAF Inspection) -> Origin IP:443
  • Attack Vector (Direct IP Bypass): Attacker ->Origin IP:443 (Bypassing Edge WAF Completely)

If an attacker identifies the origin IP address, any security rule configured at the edge becomes ineffective. Achieving true Defense-in-Depth required neutralizing this vulnerability at the transport layer (TCP/IP).

Proposed Architecture: Zero Trust & Outbound-Only Tunnels

The solution isolates the origin server from all direct incoming network traffic, removing the need to expose listening ports to the Internet.

[ Client / Attacker ]
         │
         ▼
┌────────────────────────────────────────────────────────┐
│ Cloudflare Edge (Lisbon PoP)                           │
│ - WAF Inspection (UA-CH Rules / Rate Limiting)         │
│ - Malicious Traffic Filtering                          │
└────────────────────────┬───────────────────────────────┘
                         │ (Encrypted QUIC/TLS Tunnel - Outbound Only)
                         ▼
┌────────────────────────────────────────────────────────┐
│ Origin Server (Google Cloud Shell / Linux Environment) │
│ - cloudflared Daemon (Initiates Outbound Connection)   │
│ - Nginx Listening Strictly on 127.0.0.1:80             │
│ - Zero Inbound Ports Open to Public Internet           │
└────────────────────────────────────────────────────────┘

Core Architectural Benefits:

  1. Zero Inbound Ports: The host/cloud firewall blocks all incoming TCP connections on ports 80 and 443.
  2. Outbound-Only Connections: The cloudflared daemon initiates encrypted, multiplexed QUIC/TLS connections from inside the origin to Cloudflare's edge network.
  3. Immunity to IP Scanners: Automated reconnaissance tools (e.g., Shodan, Nmap) scanning the origin IP receive no response (Connection Refused or Timeout).

Practical Implementation

1. Web Server Setup & Agent Provisioning

The origin web server was configured to run Nginx bound strictly to the local loopback interface (127.0.0.1:80).

After installing the official cloudflared package, the daemon was authenticated against the Cloudflare account, and a named tunnel was provisioned:

# Authenticate and create the named tunnel
cloudflared tunnel login
cloudflared tunnel create secops-tunnel

This generated a unique Tunnel UUID: a1f15763-baad-4140-9913-993919b1602c.

2. Ingress Rules Configuration (config.yml)

To map incoming edge traffic to the local service, an ingress configuration file was structured in ~/.cloudflared/config.yml:

YAML

tunnel: a1f15763-baad-4140-9913-993919b1602c
credentials-file: /home/diogo_moleta/.cloudflared/a1f15763-baad-4140-9913-993919b1602c.json

ingress:
  - hostname: tunnel.experiement.xyz
    service: http://127.0.0.1:80
  - service: http_status:404

3. Edge DNS Routing

The target subdomain was pointed directly to the encrypted tunnel using Cloudflare's automated routing command:

cloudflared tunnel route dns secops-tunnel tunnel.experiement.xyz

This automatically provisioned a CNAME record in the Cloudflare DNS zone pointing tunnel.experiement.xyz to the tunnel target (*.cfargotunnel.com).

Security Validation & Real-World Telemetry

With the tunnel actively running (cloudflared tunnel run secops-tunnel), security validation was conducted across two distinct access patterns.

Scenario A: Legitimate Access (Web Browser)

Accessing [https://tunnel.experiement.xyz](https://tunnel.experiement.xyz) via a standard browser:

  • The HTTP request reached Cloudflare's Point of Presence (PoP).
  • The Edge WAF validated the browser request headers.
  • Traffic was forwarded through the outbound tunnel to Nginx on 127.0.0.1:80.
  • Result: HTTP 200 OK response serving the default Nginx welcome page over a valid edge TLS certificate.

Scenario B: Bypass Attempt & User-Agent Spoofing (curl)

To simulate an automated attack attempting to bypass edge inspection by sending a spoofed User-Agent without the required Client Hints, an external request was executed:

curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/122.0.0.0" -I https://tunnel.experiement.xyz

Real Server Response Log:

HTTP/2 403
date: Sat, 03 Oct 2026 19:33:13 GMT
content-type: text/html; charset=UTF-8
server: cloudflare
cf-ray: a44e6094dc77ff4e-LIS

Security Analysis:

  1. Immediate Edge Mitigation: The HTTP/2 403 Forbidden response was issued directly at Cloudflare's Lisbon PoP (cf-ray: ...-LIS).
  2. Zero Origin Overhead: The malicious payload never reached the tunnel or the origin server. Zero CPU cycles, memory, or bandwidth were spent on the origin machine to handle the threat.
  3. Resilience to Direct Access: Direct IP connection attempts fail, as no listening ports are exposed to the public Internet.

Key Takeaways & SecOps Best Practices

  • Origin Sovereignty: Modern security perimeters must not rely on keeping origin IP addresses secret. Network isolation must be absolute.
  • Operational Cost Reduction: Offloading threat mitigation to the edge saves compute and bandwidth resources on origin infrastructure.
  • Zero Trust as Default: Implementing outbound-only encrypted tunnels provides an accessible, zero-cost path to transitioning from legacy perimeter models to a robust Zero Trust architecture.

Read more