Security Architecture • 5 min read

Zero Trust Ingress: Origin Cloaking with Strict IP Ingress Filtering and Mutual TLS (mTLS)

Defence-in-depth architecture before managed tunnels: protecting origin servers against direct-to-IP bypass attacks using netfilter firewall whitelisting and mutual TLS authentication.

Published • Updated
5 min read
Architecture diagram of edge proxy to hardened origin server with mTLS and firewall filtering

When placing a public web application behind an edge Content Delivery Network (CDN) or Web Application Firewall (WAF) such as Cloudflare, engineering teams frequently fall into a false sense of security. They assume that because public DNS records point to the CDN’s Anycast proxy IPs, the origin server is fully shielded from malicious traffic, volumetric DDoS, and automated exploit scanners.

This assumption is flawed. Public IPv4 address space is continuously probed by internet-wide port scanners (such as Shodan, Censys, and automated botnets). If an attacker discovers your origin IP address—whether via historical DNS logs, MX records, outbound webhook leaks, or raw CIDR scanning—they can bypass the CDN entirely, connecting directly to your origin web server and evading all edge rate-limiting and WAF inspections.

To achieve true Zero Trust Ingress on self-hosted or cloud origins without paying enterprise transit fees, you must implement a defence-in-depth model combining Layer 3/4 netfilter ingress allowlisting with Layer 7 Mutual TLS (mTLS) Authenticated Origin Pulls.


Threat Model: The Edge Bypass Vulnerability

Zero Trust Origin Cloaking and Ingress Filtering Topology

  1. Direct-to-IP Scanning: Attackers probe IP blocks requesting HTTPS handshakes with random or missing SNI headers.
  2. Virtual Host Exploitation: If the web server responds to direct IP requests with a default SSL certificate containing your domain name in the Common Name (CN) or Subject Alternative Name (SAN), your origin IP is irrevocably exposed.
  3. Application-Layer Rule Leakage: Relying solely on application-level filtering (such as Apache .htaccess or Nginx allow/deny directives) still leaves the TCP handshake, TLS negotiation, and HTTP request parsing vulnerable to resource exhaustion.

Defence Tier 1: Netfilter/iptables Ingress Allowlisting

The first line of defence must operate at the Linux kernel packet filter layer (netfilter). Any packet arriving on the WAN interface targeting port 443 whose source IP does not match the CDN’s published IPv4 prefixes must be discarded before the socket is accepted.

1. Automated CIDR Prefix Synchronisation

Cloudflare publishes and periodically updates its authorised edge IP ranges. We implement an atomic fetch and update script to ensure the firewall remains synchronised without risking service disruption:

Create /etc/cloudflare/sync-ips.sh:

#!/bin/sh
set -e

DEST_DIR="/etc/cloudflare"
TMP_FILE="$DEST_DIR/ips-v4.tmp"
TARGET_FILE="$DEST_DIR/ips-v4"

mkdir -p "$DEST_DIR"

# Download current CIDRs atomically
if wget -q https://www.cloudflare.com/ips-v4 -O "$TMP_FILE"; then
    # Verify the payload is non-empty and well-formed
    if [ -s "$TMP_FILE" ] && grep -q "\." "$TMP_FILE"; then
        mv "$TMP_FILE" "$TARGET_FILE"
        /etc/init.d/firewall restart
        logger -t cloudflare-sync "Successfully updated Cloudflare IPv4 prefix list."
    else
        logger -t cloudflare-sync "Downloaded CIDR payload is invalid. Retaining existing configuration."
        rm -f "$TMP_FILE"
    fi
else
    logger -t cloudflare-sync "Failed to reach Cloudflare endpoint. Retaining existing configuration."
    rm -f "$TMP_FILE"
fi

Schedule this via CRON to execute weekly during low-traffic maintenance windows:

# Synchronise CDN edge prefixes every Monday at 03:00 UTC
0 3 * * 1 /bin/sh /etc/cloudflare/sync-ips.sh

2. Linux Kernel NAT & Forwarding Rules

In /etc/firewall.user (or within your router’s ingress firewall configuration):

# Flush prior custom forward chain hooks if present
iptables -N CF_INSPECT 2>/dev/null || iptables -F CF_INSPECT

# Forward only HTTPS traffic from authenticated CDN source CIDRs
for cfip in $(cat /etc/cloudflare/ips-v4); do
    iptables -A PREROUTING -t nat -i pppoe-wan -s "$cfip" -p tcp --dport 443 -j DNAT --to 192.168.1.100:443
done

# Restrict the forward chain to accept only established and DNAT-authorised connections
iptables -A FORWARD -p tcp -d 192.168.1.100 --dport 443 -j ACCEPT

Packets arriving from unauthorised IPs are silently dropped or rejected at the gateway. The web server never allocates socket descriptors for malicious ingress.


Defence Tier 2: Mutual TLS (mTLS) Authenticated Origin Pulls

While netfilter IP filtering blocks casual scanners, determined adversaries operating on shared hosting or compromised nodes within the CDN network could theoretically forge requests or leverage misconfigured CDN tenants.

To guarantee that traffic entering your web server was generated exclusively by your designated CDN zone, we enforce Mutual TLS (mTLS). Under mTLS, the web server acts not only as a TLS host but also demands that the client (the CDN edge) present a cryptographically signed client certificate issued by the CDN’s Origin Certificate Authority.

Client (CDN Edge)                          Origin Server (Apache/Nginx)
        │                                                │
        │ ─── 1. ClientHello ──────────────────────────> │
        │ <── 2. ServerHello + Origin Cert + CertRequest ─ │ (Demands Client Certificate)
        │ ─── 3. Client Certificate (Cloudflare CA) ────> │
        │ ─── 4. Finished ─────────────────────────────> │
        │                                                │ (Validates against CA Root)
        ▼                                                ▼
   [ Session Encrypted and Cryptographically Authenticated ]

1. Origin Server Configuration (Apache)

Download Cloudflare’s published Origin Pull Certificate Authority bundle:

sudo wget -O /etc/ssl/certs/cloudflare-origin-pull-ca.pem https://developers.cloudflare.com/ssl/static/authenticated_origin_pull_ca.pem

Configure your Apache VirtualHost configuration (/etc/apache2/sites-available/production.conf):

<VirtualHost *:443>
    ServerName www.leowkahman.com
    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/leowkahman.com.crt
    SSLCertificateKeyFile /etc/ssl/private/leowkahman.com.key

    # Enforce Mutual TLS (mTLS) Client Verification
    SSLVerifyClient require
    SSLVerifyDepth 1
    SSLCACertificateFile /etc/ssl/certs/cloudflare-origin-pull-ca.pem

    # Security Headers
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "DENY"

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Reload the web server:

sudo systemctl reload apache2

2. Verify Fail-Closed State (Test-Driven Hardening)

Before enabling the toggle in the CDN dashboard, verify that direct requests fail closed. Attempting to browse the website through the proxy will temporarily yield:

HTTP/2 525 SSL Handshake Failed

Or when probing the origin directly via curl:

curl -v -k https://203.0.113.50/
# Output:
# * TLSv1.3 (IN), TLS alert, certificate required (554):
# * OpenSSL SSL_connect: SSL_ERROR_ZERO_RETURN in connection

This confirms the server refuses connections unless presented with an authentic client certificate.

3. Activate Authenticated Origin Pulls

In the Cloudflare Dashboard:

  1. Navigate to SSL/TLS > Origin Server.
  2. Toggle Authenticated Origin Pulls to On.

Within seconds, the CDN begins presenting the client certificate on all outbound origin fetches. The 525 error clears, and traffic flows with end-to-end cryptographic mutual verification.


Architectural Takeaways

  • Perimeter Defence Requires Multi-Layered Enforcement: Relying solely on DNS or CDN proxying is security by obscurity. True origin protection requires isolating Layer 3/4 transport via netfilter allowlists and Layer 7 verification via client certificates.
  • Fail-Closed Verification: Implementing mTLS ensures that even if origin firewall rules accidentally drop or reset during a host migration, the web server itself will reject any connection lacking the trusted CA signature.
  • Modern Evolution: While modern cloud deployments often adopt zero-ingress tunnels (such as Cloudflare Tunnel or AWS Systems Manager Session Manager), understanding and implementing netfilter CIDR allowlisting combined with mTLS remains the gold standard for high-throughput, latency-optimised edge-to-origin architectures.

Topics & Technologies

#Security #Zero Trust #Firewall #Cloudflare #TLS #DevSecOps