TI-2026-066C — Behind the Orange Cloud

Series: The Allowlist · Part C · Classification: HIGH · Confidence: HIGH (updated — see Resolution)

Update — Resolved (2026-07-09). This dossier originally rated its central question MEDIUM and left it deliberately open: were the 76 "Cloudflare attackers" real actors laundering their origin through Cloudflare, or an artifact of our own vantage failing to restore the real client IP? We then went and checked the architecture. The answer is settled, and it is reading (1). The estate is not behind Cloudflare — so there was never a real IP to "restore," the edge addresses are genuine attacker egress, and the confidence is now HIGH. The original uncertainty is preserved below because how a question got resolved is part of the finding; the resolution is folded into Sections II, VIII and IX.

Part A trusted the wrong network; Part B trusted the wrong name tag. This part is about the last thing in the log a defender still believes: the source IP address itself. It is the one field that feels like ground truth — the machine did not type it, the packet carried it. And it is the easiest of the three to render meaningless. You just put a proxy in front of it. The orange one will do.

Executive Summary

Seventy-six attacker IPs in our data belong to Cloudflare — and that sentence is a trap, which is the whole point of this dossier.

• The IPs sit in Cloudflare's reverse-proxy edge ranges (172.71, 104.28, 104.23, 172.70, 162.158…), not its hosting. Each address is a proxy standing in front of an origin, not the origin.
• They run real attacks — credential_harvest (74), cms_detect, auth_probe — against named services (lsn-jupyter, lsn-mail, lsn-auth, and more).
• But a Cloudflare edge IP tells you nothing about who sent the attack. It is the most-allowlisted network on earth (everyone permits it, because their own site is behind it) and therefore the emptiest attribution signal in the log.

When first written, this dossier stopped there and marked the mechanism unresolved. The follow-up investigation resolved it: we confirmed the estate is not fronted by Cloudflare, which means these are attackers reaching us through Cloudflare's own egress (WARP / Workers) — origin genuinely erased, no header to recover. The source IP is not merely unreliable here; it is the closest look we will ever get at the sender, and it points only at the orange cloud.

I. Seventy-Six Cloudflare "Attackers"

The raw finding is easy to state and easy to misread. In the intent-labelled data, 76 attacker IPs resolve to Cloudflare (AS13335), distributed across its edge:

Their conduct is unambiguous: 74 run credential_harvest (32 behind a browser UA, 25 behind a scanner UA, 17 behind none), hitting lsn-jupyter, lsn-mail, lsn-images, lsn-auth, lsn-docs, lsn-library-search, lsn-ai-comfyui. If this were Part A, the headline would write itself: Cloudflare is an attack origin. But it is not Part A, because those are edge addresses — the reverse proxy, not the machine behind it. The attack is real. The attacker is not at that address.

II. The Trap, and How We Escaped It

When first written, a Cloudflare edge source IP admitted two explanations, and the dossier honestly declined to choose between them:

1. Someone is hiding behind Cloudflare. WARP, Workers, or a Cloudflare-fronted tunnel lets an attacker route through the edge, arriving wearing Cloudflare's address and its universal allowlist status.
2. We are blaming the messenger. If a host were proxied behind Cloudflare and the real client IP were not restored (via CF-Connecting-IP / trusted-proxy config), then every attacker behind that host would be recorded as a Cloudflare edge IP — Cloudflare faithfully forwarding someone else's attack, and our log crediting Cloudflare with it.

We resolved it by checking the architecture, and reading (2) is ruled out. Three facts settle it:

• DNS points straight at us. shuffle-on.com and the affected hosts (lsn-auth, lsn-jupyter) resolve directly to the homelab's address — a GoDaddy-DDNS residential IP — not to Cloudflare's anycast ranges (104.16–31, 172.64–71). We are not orange-clouded.
• There is no tunnel. No cloudflared / Cloudflare Tunnel exists anywhere in the cluster. Nothing sits between the internet and our reverse proxy except a NAT rule.
• The proxy already records the truth. Traefik's forwardedHeaders.trustedIPs is internal-only (127.0.0.0/8 plus the K8s and LAN ranges). It records the real network peer and ignores any externally-supplied X-Forwarded-For. There is no real client IP being discarded — because for this traffic, the Cloudflare edge address is the real network peer.

So the 76 are reading (1): attackers reaching us through Cloudflare's egress — a WARP exit (104.28.x) or a Worker's fetch() (the 172.71/70/69 edge). Cloudflare is not fronting the victim here; it is fronting the attacker. And that is worse for attribution than a measurement bug would have been, because there is no CF-Connecting-IP to recover — that header only exists when a site sits behind Cloudflare's proxy, which we do not. The origin is not misplaced in our logs. It is gone.

III. The Mirror: When They Want You to Be the Proxy

The same identity-erasure runs in reverse, and we caught one actor attempting it. A single IP on AS201884 (am-ispsupport) issued 2,084 HTTP CONNECT requests — the method a client uses to ask a server to open an outbound tunnel to somewhere else. It was trying to conscript our server as an open proxy: relay my traffic, wear my sins, let the next victim see your address instead of mine.

It failed — every one of the 2,084 returned 404, the relay refused. But the intent is the tell. Where the Cloudflare traffic hides an origin behind a proxy, the CONNECT flood tries to manufacture a new proxy out of us. Both moves want the same thing: to put a trusted, unattributable hop between the attacker and the target. One relentless IP, hammering the same closed door 2,084 times, is a small clean illustration of a large idea — anonymity is worth brute-forcing for.

IV. The Seven Questions

Who is this? Unresolvable from the source IP — which is the answer, now confirmed to be by the attacker's design rather than our measurement. Why the proxy? To borrow reputation and shed attribution. Who do they claim to be? Cloudflare — the most trusted address there is. Who are they really? An origin behind Cloudflare's egress that no header we receive can name. Whom are they related to? Only resolvable by behavior, never by the edge IP. Where is the money? In the allowlist bypass (Part A) and in anonymity itself (Section III). What is the official anchor? Cloudflare's published edge ranges — which tell you it is a proxy, and nothing more.

V. Steelman — "Then There's No Finding Here"

The original strongest objection was: if you admit the 76 might be a measurement artifact, you have no attacker to report — this is a config note dressed as intelligence. The resolution answers it directly: it is not a measurement artifact. We checked, and there is no un-restored client IP — the estate is not behind Cloudflare, so the edge addresses are the attackers' genuine egress. The finding is now a positive one, not a suspended one: a cohort of credential-harvesters routing through Cloudflare to erase their origin.

But the deeper point the original steelman raised still stands, and is the reason this dossier matters beyond one estate: had we been behind Cloudflare and not restored the client IP, every one of these attributions would have been wrong, and we would not have known. The single most common way threat data gets attribution wrong is by trusting a source IP that a proxy — the victim's own, or the attacker's — has already rewritten. Resolving our case did not make that risk go away for anyone else; it just told us which side of it we were on. The lesson is not "we were right." It is "you cannot know you are right about a source IP until you know exactly where your proxy sits."

VI. Read Between the Lines

• The more trusted the proxy, the more complete the anonymity it grants. Cloudflare protects millions of sites, which is precisely why an attack routed through it is the hardest to attribute and the most dangerous to block. Trust and opacity are the same property viewed from two sides.
• A CONNECT flood and a Cloudflare-egress credential sweep are the same sentence spoken backwards. Both insert an unaccountable hop. One borrows a proxy; one builds one.
• Reputation metadata failed here too: every one of these IPs is flagged is_proxy=false. The database did not know Cloudflare's edge was a proxy. Only structure (published prefixes) plus behavior did.

VII. The Human Layer

Consider the analyst staring at 76 hits from Cloudflare in the morning report. Every instinct trained into them pulls toward one of two buttons. Block it — and the helpdesk lights up because half the company's SaaS rides Cloudflare too. Allow it — and they have just written the rule from Part A. There is no right button, because the question ("is this IP bad?") is malformed the moment a proxy is in the path. The humane thing to tell that analyst is not which button but that the question changed: stop asking where it came from, start asking what it did — and go find out, precisely, where your own proxy sits, because that one architectural fact decides whether your source IPs mean anything at all.

VIII. Verdict

A source IP is an attribution solvent behind a reverse proxy. 76 credential-harvest attackers reach this estate through Cloudflare's egress — impossible to trust, impossible to block, and, we have now confirmed, impossible to attribute because the origin is genuinely erased rather than merely mis-recorded — while a separate actor's 2,084 CONNECT attempts try to manufacture the same anonymity in the other direction. Confidence: HIGH — the attacker-behind-Cloudflare reading is confirmed by direct architecture verification (DNS resolves to our residential IP, no tunnel, proxy trusts internal X-Forwarded-For only). The lesson is unchanged and sharpened: resolve identity by behavior, never by the source IP — and know exactly where your proxy sits before you trust either.

IX. Defensive Response

Behavior-based banning already fires regardless of source IP: a credential sweep from a Cloudflare edge address is scored and banned on conduct, not origin. The original edition proposed a "self-directed fix" — restoring the real client IP on proxied hosts. The follow-up investigation withdraws that recommendation, and the reason is instructive. Because we are not behind Cloudflare, adding Cloudflare's ranges to the proxy's trusted list would make it believe the X-Forwarded-For header on requests arriving from Cloudflare — and an attacker running a Cloudflare Worker can set that header to any address they like, forging their source IP to spoof past bans and frame innocent hosts. The "restoration" would be a source-IP-spoofing hole, not a fix. The correct posture is the current one: trust externally-supplied forwarded headers from no one, and ban on behavior at the egress IP. Restoring the real client IP is the right move only for an estate genuinely behind a proxy — and knowing which you are is the entire lesson of this part.

Crosslinks

• ← TI-2026-066A — Trusted by Default — the trusted ASN. Blocklisting Cloudflare fails for the same reason allowlisting it does.
• ← TI-2026-066B — The Browser Costume — the forged identity; here, the dissolved one.
• → TI-2026-066D — The Quiet German — from the most-trusted network to one nobody watches at all.
• → TI-2026-066F — Behavior Over Reputation — why the source IP joins the ASN and the user-agent on the list of signals that must never gate.

Sources: LSN web-threats ip_intel/requests — Cloudflare AS13335 edge-prefix breakdown, intent + host targeting, method=CONNECT corpus (2084 from AS201884), is_proxy flag audit; plus follow-up architecture verification (authoritative DNS for shuffle-on.com/lsn-auth/lsn-jupyter, cluster tunnel audit, Traefik forwardedHeaders.trustedIPs). Method: treat the source IP as unresolved behind a proxy — then resolve it by determining where the proxy actually sits. TLP:WHITE.