> ## Content Index
> Fetch the complete content index at: https://www.diogomoleta.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Origin Hardening & Zero Trust Architecture with Cloudflare Tunnels
- URL: https://www.diogomoleta.com/origin-hardening-zero-trust-architecture-with-cloudflare-tunnels/
- Published: 2026-10-03T19:54:51.000Z
- Updated: 2026-10-03T20:09:15.000Z
- Author: Diogo Moleta
- Tags: Cloudflare, SecOps, Incident Response, WAF, Technology

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.