During a suspected flood, why is 'thousands of source addresses across hundreds of networks' not evidence of an attack?

## Why address spread is a symmetric signal The instinct is understandable: distributed denial of service is distributed, so a long list of distinct sources feels like proof. It is not, because the *other* explanation is equally distributed. A promoted launch draws from every consumer network in the market — thousands of addresses, hundreds of autonomous systems, arriving in the same minutes. Both stories predict the same observation, so the observation does not discriminate. The reverse trap is worse. Low diversity is not evidence of legitimacy either: - Carrier-grade NAT puts tens of thousands of real mobile users behind a small pool of addresses. - A corporate estate egresses through a handful of proxies. - Traffic that reaches you via an intermediary — a caching layer, a partner, a link-preview fetcher — arrives as that intermediary, and unless the real client address is carried in a header you trust for a specific reason, you cannot see behind it. So the count of distinct addresses tells you about *reach*, and reach is not intent. ## The pairing that does discriminate The useful measurement is joint: source spread against **client fingerprint cardinality**. A client fingerprint is what the client reveals about itself before any application data is exchanged and in the request it then sends — the ordering of cipher suites and extensions in the TLS ClientHello, the supported groups, the ALPN it offers, the HTTP version it negotiates, the order and casing of its headers, and the user agent it declares. None of that is secret and none of it is authenticated; it is simply structure, and different client software produces different structure. A real crowd is a population sample. It carries dozens or hundreds of distinct fingerprints because it is dozens of browser builds on several operating systems, with a large mobile fraction, some of them proxied, some of them old. A flood is often one program compiled once and run from many places. The addresses fan out; the fingerprint does not. **Thousands of sources presenting one fingerprint is one client, distributed** — and that is a fact about the traffic that no amount of source spread can explain away. ## Where the pairing breaks, and you must say so An interviewer will push here, and the honest answer has three caveats: 1. **A single legitimate fingerprint across many addresses is normal in one important case:** your own mobile application. If the launch included a push notification to an installed base, the resulting arrivals genuinely are one client run from a hundred thousand places. That cohort should look identical to a botnet on this measure and must be excluded by knowing your own client, not by the metric. 2. **The adversary can blur it.** Randomising extension order, rotating user agents, or driving real browser engines raises fingerprint cardinality on purpose. Encrypted Client Hello and other handshake privacy work also reduce what a passive observer sees. So the inference is one-directional: narrow fingerprint diversity across broad source diversity is strong evidence; wide diversity is not evidence of legitimacy, only absence of the cheap tell. 3. **You must own the vantage.** Fingerprint cardinality is only computable where the handshake is visible — the terminating edge, or an inspection point that records ClientHello structure. Flow records carry the five-tuple, byte and packet counts and timestamps and no payload at all, so they can show that bytes moved and never which client moved them. If your logging pipeline drops those fields to save storage, this evidence does not exist when you need it, and that storage decision was made months ago by someone who was not on this bridge. ## The comparison problem Diversity is most useful compared against your own history: how many fingerprints per thousand sources do you normally see on this path? In a merged estate, that history may not exist in a comparable form — two front doors, two logging stacks, two field sets, no shared denominator. Structural facts survive that better than ratios do. 'One fingerprint across 640 networks' needs no baseline to be alarming; '40x normal' needs a baseline you may not have. ## The price Calling it wrong in the direction of blocking has a specific shape here: fingerprint-based mitigation collateral is not random. If you challenge or drop a fingerprint, you drop *everyone using that client build* — which can mean every user on one mobile OS version, or every user behind one enterprise proxy, or your own app. That is a defensible action only when you can name whose fingerprint it is and accept losing them, and it is why arming reversibly, with a bypass for sessions that have already proved themselves, matters more than picking a clever discriminator.