aegis-cloudflared-tunnel-hardening

Imported from AS-FOSS/aegis-skills (skills/server/cloudflared-tunnel/SKILL.md). Install upstream with npx skills add AS-FOSS/aegis-skills --skill cloudflared-tunnel. Copyright stays with the author.

Scope & Objectives

Audit one Linux host running the Cloudflare Tunnel daemon (cloudflared) — or the config-as-code repository that declares it. Eight domains, in priority order:

1. Daemon discovery & run mode — locate every cloudflared systemd unit; classify token-based mode (cloudflared tunnel run --token ...) vs config-file mode (config.yml + tunnel credentials JSON); detect undocumented or duplicate tunnels on one host.
2. Identity-material exposure — tunnel tokens embedded in unit files or environment variables, credentials JSONs (/etc/cloudflared/<UUID>.json), and the account-level cert.pem; permissions and placement. Whoever holds this material controls your tunnel.
3. Ingress precision — the ingress: table in config.yml is the tunnel's ACL: hostname→service mappings, terminal catch-all correctness, path-routing subtleties, origin targets pointing at LAN IPs, noTLSVerify: true hops, unix-socket targets.
4. Origin binding discipline — apps fronted by the tunnel MUST NOT also be reachable directly (wildcard binds, published container ports, missing firewall). Direct-to-origin access skips every Cloudflare protection.
5. Edge-layer controls inventory — WAF, rate limiting, bot fight, Zero Trust Access policies, Service Tokens, mTLS origin pull. These are configured in the Cloudflare dashboard and are INVISIBLE from the host/repo; record them strictly as interview questions.
6. Real visitor IP handling — the application must derive client IP from CF-Connecting-IP while trusting ONLY the Cloudflare/cloudflared proxy addresses; otherwise the value is client-spoofable.
7. Egress interplay — cloudflared needs outbound connectivity (443, plus UDP/7844 QUIC to regional edges); verify the egress-filtering design permits it AND treats Cloudflare ranges as an approved-destination example.
8. Operational hygiene — auto-update posture tradeoffs, metrics endpoint binding, log verbosity leaking sensitive data, multi-tunnel-per-host review, single-replica availability risk, containerized variants.

Out of scope (cross-references): firewall design and default-deny construction → FW/firewall-edge; token lifecycle, storage classes, rotation mechanics → TOK/api-token-security and HSECRET/host-secrets; TLS termination and cache/header behavior at proxies → TLS/tls-proxy; application-level authorization and request-forgery classes → AUTHZ/authz-access-control, PROTO/http-protocol; supply-chain pinning policy → SUPPLY/supply-chain; baseline sandboxing primitives → BASE/linux-baseline.

Operating rules:

• All inspection commands are read-only; mutating commands appear only under Remediation after approval.
• Prefer effective-state evidence (ss -tlnp, systemctl cat, stat) over documentation or claims.
• Commands needing root are tagged [ROOT]. Without root, audit world-readable state plus the config repo and judge rendered configs using Patterns & Signatures.
• REACTION DISCIPLINE: tunnel tokens are live secrets. When displaying unit contents or logs, pipe through the redaction filters shown in the sweep below and NEVER reproduce a raw token, TunnelSecret, or credentials-JSON body in the report.
• Restarting the cloudflared unit is service-affecting; propose restarts only under explicit approval (see Verification & Validation).
• Dashboard-side settings cannot be verified from here. Report them as "confirmed/unconfirmed — interview" rather than guessing.

Prerequisites & Vocabulary

Zero-background primer: the terms this module uses, one line each. Deeper plain-language explanations for every class live in the repository GUIDE.md glossary.

• cloudflared / tunnel: an outbound-only daemon relaying visitor traffic from Cloudflare's edge to local services
• ingress rules: the config table mapping which hostnames reach which local services
• origin: the real application behind the tunnel
• direct-to-origin bypass: reaching the app's own public port, skipping every Cloudflare protection
• edge controls: WAF, rate-limiting, and Access policies configured in the dashboard — invisible from this host
• CF-Connecting-IP: the header carrying the real visitor IP; trust it only from Cloudflare's addresses
• taint flow / source→sink: path untrusted data travels from entry point to dangerous function
• finding status: Confirmed > Probable > Needs-Review; evidence rules in templates/finding-report.md

Mental Model

cloudflared is an outbound-only daemon. It dials out to Cloudflare's edge network (QUIC over UDP/7844 to regional edge addresses, with an HTTP/2-over-TCP fallback) and keeps those connections alive. Public visitors hit a Cloudflare-hosted hostname; the edge relays each request back down the already-established connection to your daemon, which forwards it to a local origin service per the ingress rules. The host needs no inbound ports opened for the tunnel — the classic "open 80/443 and harden the web server" problem is replaced by a different one: whoever controls the daemon (or its credentials) has an always-on relay INTO your internal network that you deliberately punched through every perimeter.

The tunnel replaces port exposure, not application authorization. Two silent bypasses collapse the model. First, if the application behind the tunnel ALSO binds a public interface (0.0.0.0:8000) or the firewall was relaxed because "we use Cloudflare", anyone who learns the origin IP — via historical DNS records, certificate-transparency logs, misconfigured subdomains, or plain scanning — connects DIRECTLY and skips every Cloudflare protection: WAF rules, rate limits, bot management, Zero Trust Access policies all exist only at the edge. Second, even with perfect binding, whatever reaches the app arrives pre-authenticated-by-nothing unless the edge layers (Access/WAF) or the app itself enforce something; a tunnel to an unprotected admin panel is just a private door into an unlocked room.

Security posture therefore decomposes into four pillars, audited in order: (1) daemon identity protection — the token/credentials ARE the tunnel; exposure hands the attacker their own ingress with ingress rules of THEIR choosing; (2) ingress precision — config.yml decides which hostnames reach which local services, and a lazy catch-all turns the tunnel into a universal forwarder; (3) what sits in front at the edge — dashboard-configured WAF/rate-limit/Access layers that must be interviewed, never assumed; (4) origin binding discipline — loopback-only binds plus a STILL-default-deny firewall, so the tunnel remains the only road in. Treat every finding here as compounding with code-audit findings: an edge without app-layer authz is a single layer, and single layers fail completely.

What To Check

Run the paste-ready sweep at the end of this section first [ROOT], then work the tables below.

1. Daemon discovery & identity material

2. Ingress precision (config.yml mode)

Locate the config first (find /etc /root/.cloudflared "$HOME/.cloudflared" -name 'config.yml' -path '*cloudflared*'), then dump and read it as an ACL.

3. Origin binding discipline — THE key chain

For EVERY service named in the ingress table, find its listener line in ss -tlnp and classify its bind address:

4. Edge-layer controls inventory — dashboard-only, interview checklist

Nothing below is verifiable from the host or repo. Ask each question; record Confirmed / Unconfirmed / N-A with the interviewee's name and date. Do NOT report these as verified findings.

5. Real visitor IP handling at the application

The app sees connections FROM cloudflared (loopback) while real client IPs ride in CF-Connecting-IP. Trust configuration must match topology EXACTLY, else attackers spoof logs, rate-limit keys, and geo/IP ACLs by setting header values directly.

6. Egress requirements interplay

7. Operational hygiene

Paste-ready sweep (read-only)

# ===== cloudflared sweep [ROOT] =====
echo "== unit inventory =="; systemctl status cloudflared --no-pager 2>/dev/null | sed -n '1,5p'
ls -la /etc/systemd/system/cloudflared* /usr/lib/systemd/system/cloudflared* 2>/dev/null
echo "== effective unit text, REDACTED view (never paste raw tokens) =="
systemctl cat cloudflared 2>/dev/null | sed -E 's/(eyJ[A-Za-z0-9_-]{20,})/[REDACTED_TOKEN]/g'
echo "== token/env lines present? (values redacted) =="
systemctl cat cloudflared 2>/dev/null | grep -inE '(--token|Environment)' | sed -E 's/(eyJ[A-Za-z0-9_-]{20,}|=[A-Za-z0-9+/=_-]{40,})/[REDACTED]/g' || echo "none found"
echo "== identity-material permissions =="; stat -c '%a %U:%G %n' /etc/cloudflared /etc/cloudflared/*.json /etc/cloudflared/cert.pem "$HOME"/.cloudflared/cert.pem 2>/dev/null
echo "== locate config.yml =="; find /etc /opt /root/.cloudflared "$HOME/.cloudflared" -maxdepth 3 -name '*.yml' -o -maxdepth 3 -name '*.yaml' 2>/dev/null | grep -i cloudflared
CFG="$(find /etc/cloudflared /root/.cloudflared "$HOME/.cloudflared" -maxdepth 2 \( -name 'config.yml' -o -name 'config.yaml' \) 2>/dev/null | head -1)"
[ -n "$CFG" ] && { echo "-- $CFG --"; sed -n '1,120p' "$CFG"; }
echo "== metrics binding (expect 127.0.0.1) =="; ss -tlnp | grep -E 'cloudflared|:20241' || echo "no cloudflared TCP listener found"
echo "== FULL listener table -> feed every origin target to FW sweep =="; ss -tlnp
echo "== version + update-flag posture =="; cloudflared --version 2>/dev/null; systemctl cat cloudflared 2>/dev/null | grep -in update || echo "no update-related flags in unit"
echo "== log sensitivity sample (REDACTED) =="; journalctl -u cloudflared -n 100 --no-pager 2>/dev/null | sed -E 's/(eyJ[A-Za-z0-9_-]{20,})/[REDACTED]/g' | grep -icE 'authorization|cookie|cf-connecting-ip|debug' || echo "no sensitive-pattern hits in last 100 lines"

Where To Look

Evidence collection: tools/sweeps/sweep-cloudflared.sh captures [TNL-nn] sections verbatim; judge them against this module's rubrics, never against raw output alone.

Patterns & Signatures

Ingress table shapes:

# VULNERABLE — wildcard catch-all forwards EVERYTHING to the app; LAN origin target;
# unverified TLS on an internal-network hop
ingress:
  - hostname: app.example.com
    service: http://192.168.1.50:8000
  - hostname: '*'
    service: http://localhost:8080        # any hostname routed here reaches this app
  # no terminal http_status:404 rule at all in effect for unknown hosts

# FIXED — explicit mappings first, loopback origins, verified TLS with pinned SNI,
# terminal catch-all returns 404 from the edge path itself
ingress:
  - hostname: app.example.com
    service: http://localhost:8000
  - hostname: api.example.com
    path: ^/v2/.*
    originRequest:
      connectTimeout: 10s
    service: https://localhost:8443       # TLS to local TLS-terminating proxy
  - hostname: legacy.internal.example.com
    originRequest:
      caPool: /etc/cloudflared/internal-ca.pem
      originServerName: legacy.internal.example.com   # SNI matches origin cert
    service: https://10.20.0.11:8443
  - service: http_status:404              # ALWAYS last: terminal catch-all

Systemd shapes:

# VULNERABLE — root daemon, live token inline in ExecStart (any host reader owns the tunnel),
# no sandboxing, metrics implicitly default
[Unit]
Description=cloudflared

[Service]
ExecStart=/usr/bin/cloudflared tunnel run --token eyJ...REDACTED...
Restart=on-failure

# VULNERABLE — token via Environment= is equally exposed to anyone reading the unit/process env
[Service]
Environment=TUNNEL_TOKEN=eyJ...REDACTED...
ExecStart=/usr/bin/cloudflared tunnel run --token ${TUNNEL_TOKEN}

Grep signatures (host + repo):

grep -rn 'noTLSVerify:\s*true' --include='*.yml' --include='*.yaml' .          # MITM hop finding
grep -rEn 'service:\s*(http|tcp|ssh|rdp)://(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)' .  # LAN-origin targets
grep -rn 'hostname:' config.yml | sort                                          # exposure inventory
grep -rnE '\-\-token' /etc/systemd/system/                                      # token-in-unit
grep -rn "trust proxy" app/ src/ server/                                        # visitor-IP trust
grep -rEn 'set_real_ip_from' /etc/nginx/                                        # real_ip scoping
ss -tlnp | awk '$4 ~ /^0\.0\.0\.0:/ || $4 ~ /^\[::\]:/'                        # dual-binding candidates (cross-ref FW)

Healthy shape summary: one documented unit per tunnel → dedicated user or container → credentials at 600 root:root shape → ingress ends - service: http_status:404 → every origin bound to loopback → firewall still default-deny → edge layers confirmed by interview.

Taint Tracing Guidance

In config-as-code repos, trace these taints end-to-end:

1. Secret taint — source (CI variable, secret manager reference, .env, heredoc in Ansible) → sink (unit ExecStart=/Environment=, compose environment, terraform resource argument). If the rendered value lands in a world-readable file or repo history, treat as Critical (rotation → TOK module). Grep rendered artifacts, not just templates.
2. Authz taint — public hostname/path in ingress tables → sensitive route in the app's router (admin, debug, actuator, metrics). If the pair exists AND interview cannot confirm an Access policy, flag "edge-fronted admin path with zero Access/WAF front" (High anchor) even though the dashboard itself was not inspected.
3. TLS-trust taint — boolean/env driving noTLSVerify (e.g., a "skip_tls" convenience variable) → rendered originRequest. Defaults-on-insecure booleans propagate silently through templating; trace every consumer.
4. Trust-topology taint — deployment facts (app behind cloudflared/nginx) vs code facts (trusted-proxy allowlists, forwarded-header parsing). Mismatch in either direction = spoofable client IP (over-trust) or broken functionality (under-trust). Cross-check PROTO/AUTHZ modules for request-forgery-style header handling.
5. Bind-address taint — framework defaults (app.run(host="0.0.0.0"), HOST=0.0.0.0 in Dockerfile ENV, compose ports: publish) → runtime reality in ss -tlnp. Repo intent does not bind sockets; effective state wins.

Exploitation & Reproduction

All demonstrations are READ-ONLY on the audited host. External probing requires prior written authorization.

Demo 1 — prove token-in-plainfile (interpretation discipline)

Run the sweep's redacted greps. Interpreting output WITHOUT ever reproducing the secret:

/etc/systemd/system/cloudflared.service:5:ExecStart=/usr/bin/cloudflared tunnel run --token [REDACTED_TOKEN]

One line is enough for the finding. Narrative: the unit file is typically mode 644 (world-readable) because systemd requires units to be readable; therefore ANY local account (or anyone who later obtains arbitrary file-read via an app bug) reads the line, extracts the token, and runs cloudflared tunnel run --token <value> FROM THEIR OWN MACHINE — the tunnel now connects to their infrastructure too, with ingress rules they author, relaying into your origin network. The same applies to Environment= lines and process environments visible via /proc/<pid>/environ to same-UID readers. Severity anchor: Critical (see Severity Assessment). Remediation pointer: move to credentials-file mode with restrictive perms or secret-managed injection, rotate the exposed token (procedure → TOK module).

Demo 2 — prove origin double-binding bypass

From the sweep's listener table, interpret a finding shape:

State  Recv-Q Send-Q Local Address:Port  Process
LISTEN 0      128    127.0.0.1:49159     users:(("cloudflared",pid=1234,...))   # metrics on loopback: healthy
LISTEN 0      511    0.0.0.0:8000        users:(("gunicorn",pid=910,...))       # FINDING: app ALSO publicly bound

The app behind the tunnel binds 0.0.0.0:8000 while cloudflared forwards to it on loopback — the tunnel adds zero access restriction; it is now merely a second door. With authorization, confirm reachability from an EXTERNAL vantage: curl -sS -o /dev/null -w '%{http_code}\n' --connect-timeout 5 http://<origin-ip>:8000/ returning 200 proves direct access that skips WAF/rate-limits/Access entirely. In-host proof without external access: firewall policy ACCEPT/default-deny analysis plus the wildcard bind suffices for the High finding.

Demo 3 — prove the noTLSVerify hop

Finding shape in config:

ingress:
  - hostname: legacy.internal.example.com
    originRequest:
      noTLSVerify: true          # FINDING
    service: https://10.20.0.11:8443

Narrative: cloudflared opens TLS to 10.20.0.11:8443 but skips certificate validation, so any actor positioned on that hop (compromised router/VM on the segment, ARP spoofing neighbor, rogue DHCP) terminates TLS with a self-signed cert, receives decrypted application traffic (cookies, bearer headers), and relays tampered responses. On-loopback plaintext HTTP would honestly declare its threat model better than encrypted-but-unverified TLS to a LAN IP. Check whether caPool/originServerName exist as ready-made fixes.

Attacker narrative — why firewall discipline survives tunnels

1. Origin discovery: attacker wants the origin IP of app.example.com behind Cloudflare. Historical DNS records (passive-DNS services archive pre-Cloudflare A records), certificate-transparency logs naming direct.app.example.com, subdomain misconfigurations that CNAME to raw IPs, shodan/censys fingerprints of the origin's banner, or phishing/mail-server headers leaking internal IPs.
2. Direct connect: origin IP in hand, they browse http://<origin-ip>/ (Host header set to the vhost). Every Cloudflare-side control — WAF managed rulesets, rate limiting, bot fight, Zero Trust Access, IP reputation — NEVER SEES THIS TRAFFIC. Only the host firewall stands between them and the app.
3. Failure modes that enable step 2: admin opened 80/443 "so Cloudflare can reach us"; app dual-bound 0.0.0.0; IPv6 interface forgotten (parity gap); container DNAT publishing ports.
4. Why the mitigations hold: inbound firewall allowing ONLY Cloudflare IP ranges means discovered-origin-IP connections die at SYN; truly loopback-only bindings mean nothing answers regardless; Authenticated Origin Pulls (interview item) makes the origin reject non-Cloudflare-mTLS clients as defense-in-depth. The tunnel replaces port exposure ONLY if these hold.

Dashboard-config interview checklist (record verbatim answers)

Ask, per production hostname: (1) Which managed WAF ruleset is attached? (2) Rate-limiting rules on which exact routes, with what thresholds? (3) Bot Fight Mode state? (4) Access applications covering which paths, which policies, what identity providers? (5) Service Token usage on which machine-to-machine routes vs email OTP one-time-pin on human routes? (6) Authenticated Origin Pulls enabled? (7) Any cache/Page-Rule behavior affecting security headers on cached responses (deep dive → TLS module)? Mark each Confirmed/Unconfirmed/N-A; Unconfirmed edge controls are REPORT GAPS, not assumed-present.

Remediation

Apply in order: identity material → sandboxing → ingress precision → binding/firewall → edge layers → visitor IP. All commands below are MUTATING; require change approval and an agreed rollback.

1. Identity material

# [ROOT] dedicated user + restrictive material permissions (config-file mode shape)
useradd --system --home /nonexistent --shell /usr/sbin/nologin cloudflared 2>/dev/null || true
chown -R root:root /etc/cloudflared
chmod 755 /etc/cloudflared                      # traverse-only
chmod 600 /etc/cloudflared/*.json /etc/cloudflared/cert.pem
chgrp cloudflared /etc/cloudflared/<TUNNEL-UUID>.json   # only the file(s) this daemon needs
chmod 640 /etc/cloudflared/<TUNNEL-UUID>.json

If a token was ever exposed in a unit/repo/log: ROTATE it before cleanup (issuing new credentials, redeploying, revoking old — procedure → TOK/api-token-security). Deleting the line is not rotation. Prefer token mode with the token injected from a secret manager at runtime over literals in units; prefer NOT shipping account-level cert.pem to app hosts at all (keep it on the admin workstation that runs cloudflared tunnel login).

2. Hardened systemd drop-in

# /etc/systemd/system/cloudflared.service.d/hardening.conf
# [ROOT] systemctl daemon-reload after writing. Test in a maintenance window.
[Service]
User=cloudflared
Group=cloudflared
NoNewPrivileges=true
ProtectSystem=strict            # entire FS read-only; reading /etc/cloudflared still works
ProtectHome=true                # hides /root and /home incl. stray ~/.cloudflared material
PrivateTmp=true
PrivateDevices=true
ProtectKernelTunables=true
ProtectControlGroups=true
RestrictSUIDSGID=true
LockPersonality=true
MemoryDenyWriteExecute=true
CapabilityBoundingSet=          # no capabilities needed for outbound-only relay
AmbientCapabilities=
# CAVEAT: ProtectSystem=strict assumes config-file mode with READ-only needs.
# Run `cloudflared tunnel login`, credential creation, and manual updates interactively
# as an admin OUTSIDE this service context — the sandboxed daemon must never need write access.

Egress shaping CONCEPT (IPAddressAllow= on the unit can confine the daemon to Cloudflare ranges plus localhost for its metrics listener plus your resolvers): treat it as a follow-up hardening step requiring staged testing — an incomplete allowlist silently breaks tunnel registration or metrics, so validate against your cloudflared version's documented destination set during a maintenance window before enforcing (cross-ref FW egress module for the firewall-side equivalent).

3. Hardened ingress

Adopt the FIXED ingress shape from Patterns & Signatures: explicit hostname mappings first, loopback origins only, verified TLS with caPool/originServerName on any non-loopback hop, path rules reviewed against the app router, terminal - service: http_status:404 ALWAYS last. Validate with cloudflared tunnel ingress validate (config-mode; dry-run check) and cloudflared tunnel ingress rule --hostname <host> --path <path> style lookup subcommands where available in your installed version — consult cloudflared tunnel ingress --help on the host rather than assuming flags.

4. Binding + firewall discipline

# App side: bind loopback (examples — adapt per framework)
# gunicorn:  --bind 127.0.0.1:8000      uvicorn: --host 127.0.0.1 --port 8000
# nginx origin vhost: listen 127.0.0.1:8080;
# docker: publish nothing, or -p 127.0.0.1:PORT:PORT at most
ss -tlnp | grep <origin-port>     # verify 127.0.0.1 binding took effect

Firewall: KEEP default-deny inbound. Decide and implement ONE anti-bypass design: (a) inbound allowlist restricted to published Cloudflare IP ranges (fetch current ranges from Cloudflare's published lists at remediation time; schedule re-review — ranges change), or (b) origin unlisted + default-deny with documented acceptance of residual discovery risk. Record the choice in the asset register (construction details → FW/firewall-edge module).

5. Dashboard hardening checklist (interview-format — execute IN the console with the owner)

1. Attach the zone-appropriate WAF managed ruleset; document exceptions.
2. Create rate-limiting rules on auth/login/sensitive routes (thresholds documented).
3. Enable Bot Fight Mode (or document the business reason not to).
4. Create Access applications covering /admin* (minimum) or the whole hostname; define policies with a real IdP — avoid email OTP one-time-pin for anything sensitive; use Service Tokens for machine-to-machine routes.
5. Enable Authenticated Origin Pulls for sensitive hostnames; deploy the client-cert check at the origin proxy accordingly.
6. Review cache rules/Page Rules for security-header behavior on cached responses (deep dive → TLS module).
7. Re-run this checklist quarterly; answers are point-in-time evidence.

6. Real visitor IP trust

# nginx behind Cloudflare/cloudflared — trust ONLY CF ranges + local hops
set_real_ip_from 173.245.48.0/20;    # NOTE: fetch CURRENT published Cloudflare ranges at deploy time
set_real_ip_from 103.21.244.0/22;    # these four lines are ILLUSTRATIVE subset, not authoritative
set_real_ip_from 127.0.0.1;
real_ip_header CF-Connecting-IP;
real_ip_recursive on;

# uvicorn behind cloudflared/nginx on same host
ExecStart=/opt/app/venv/bin/uvicorn app:app --host 127.0.0.1 --proxy-headers
Environment=FORWARDED_ALLOW_IPS=127.0.0.1     # ONLY the literal proxy hop(s)

Express (qualitative semantics): app.set('trust proxy', N) trusts the outermost N hops of the chain; set it to exactly the number of trusted internal proxies (e.g., 1 for a single local nginx), NEVER true (trusts all) and never a broad CIDR including clients. Framework equivalents: Django SECURE_PROXY_SSL_HEADER only with matching proxy contract; Rails/Rack ActionDispatch::RemoteIp custom allowlists limited to proxy ranges. Cross-check detailed header-parsing risks → PROTO/http-protocol and AUTHZ/authz-access-control modules.

Verification & Validation

Post-fix verification sequence:

1. Re-run the full sweep — every identity-material stat returns the intended mode/owner; redacted unit greps find no secret lines; ingress table ends with http_status:404; no noTLSVerify: true remains; metrics bound loopback.
2. Restart gate — restarting the cloudflared unit drops the tunnel (brief outage; with a single replica it is total). Obtain EXPLICIT approval naming the window before any restart. With ≥2 connectors, rolling restart one at a time.
3. Through-path functional test — after approved restart: public URL loads through the tunnel from an external vantage; HTTP status, TLS cert, and expected headers correct; journalctl -u cloudflared -n 50 shows clean registration.
4. Anti-bypass negative test (authorized external vantage) — curl --connect-timeout 5 http://<ORIGIN-IP>/ (and HTTPS, and IPv6 address if present) MUST time out or refuse. A 200 here means the High finding persists. Also confirm from the origin host that the firewall counters for dropped direct traffic increment when tested.
5. Negative tests for regressions — legitimate traffic unaffected: normal browsing, API clients, AND websocket/streaming endpoints exercised through the tunnel (proxy upgrades are part of the through-path); authenticated admin flows still work post-Access-policy changes; machine-to-machine clients holding Service Tokens authenticate successfully.
6. Egress regression watch — if egress restrictions were added (firewall or unit-level): monitor journal across several hours/days for connection errors indicating blocked transports. cloudflared negotiates its transport (QUIC preferred) and falls back (e.g., an explicit --protocol http2 setting forces the TCP transport); an over-restrictive OUTPUT path can break the primary transport while leaving fallback flapping — qualitative symptom: intermittent "connection lost/registering" cycles. Confirm both transport paths reach their destinations before closing the ticket.
7. Config-as-code regression greps — in the repo: grep -rn 'cloudflare_.*tunnel' *.tf then review rendered resources against your PINNED provider version's docs (resource names changed across provider majors — validate, don't assume); ensure no secret argument holds a literal; ensure ingress-as-code ends with the 404 rule; CI should fail on noTLSVerify:\s*true and wildcard catch-alls.

Severity Assessment

Anchors (vectors are starting points — adjust scope/impact to the audited environment):

Compounding rule: this module's findings MULTIPLY code-audit findings rather than adding. A tunnel fronting an app with an authz bug and no Access policy is ONE layer between the internet and the bug; a Critical token leak plus a dual-bound app means two independent full compromises of different character. When scoring, evaluate the shortest complete attack path, not individual findings in isolation.

Common False Positives

• WARP client vs Cloudflare Tunnel confusion: a host running the WARP device client (warp-svc) is NOT running cloudflared tunneling — different product, different threat model (device egress vs inbound relay). Verify by unit/process name before applying this module; do not flag WARP hosts for missing ingress files.
• Internal-only hostnames intentionally without Access: a hostname routed over the tunnel but consumed only from networks that are themselves restricted (VPN-gated, zero-trust-device-only) may legitimately skip per-hostname Access policies IF the network restriction is confirmed and documented. Record as accepted-risk with evidence, not as a High finding.
• Test/staging tunnels with relaxed posture: lower environments often intentionally run simplified configs (no Access, broad catch-alls) against non-production data. If documented, scope findings down and reference the acceptance record; undocumented relaxed staging sharing credentials or networks with production is NOT exempt.
• Metrics port absent entirely: some deployments disable or never enable metrics listening; "port 20241 not found" is only a finding if the daemon IS running and bound elsewhere — check the actual listener list, not the expected port number alone.
• Token-mode units showing base64-looking strings that are NOT tokens (e.g., checksums, IDs): apply the redaction filter first, confirm the line shape matches --token <value> before raising the Critical anchor.

References

• Cloudflare docs — Cloudflare Tunnel / cloudflared (connections, config-file ingress rules, run modes, firewall/egress guidance): developers.cloudflare.com
• Cloudflare docs — Zero Trust / Cloudflare Access (policies, Service Tokens, self-hosted apps): developers.cloudflare.com
• Cloudflare docs — WAF managed rulesets, rate limiting rules, bot management, Authenticated Origin Pulls, IP ranges: developers.cloudflare.com
• CWE-16 Configuration: https://cwe.mitre.org/data/definitions/16.html
• CWE-284 Improper Access Control: https://cwe.mitre.org/data/definitions/284.html