Surviving the Flood: DDoS, Bots, and the Art of Telling Machines from Humans

26/10/2026

Here's a statistic that rearranges how you see the web: for years, automated traffic has hovered around half of everything. And the recent surge of AI crawlers and agents has pushed it past humans on many sites. When you operate anything public, most of your visitors are not people. The two hard problems this creates (surviving deliberate floods, and sorting the machine traffic you want from the machine traffic you don't) are worth understanding even if you never touch a firewall, because they explain half the friction of the modern internet, from CAPTCHAs to "verifying your browser" pages.

DDoS: a queue problem, not a hacking problem

A denial-of-service attack doesn't break in; it crowds out. Every system has finite capacity (bandwidth, connection slots, CPU, database queries), and an attacker who fills any one of those queues with junk denies it to everyone else. The distributed part (DDoS) is where the traffic comes from: thousands to millions of compromised machines (botnets of hijacked servers, home routers, and cheap IoT devices), so there's no single source to block.

The flavours matter because the defences differ. Volumetric attacks are brute tonnage: hundreds of gigabits per second of garbage, far beyond what any single origin's pipe can drink. Protocol attacks exhaust connection-handling machinery with half-open handshakes. The sneakiest are application-layer attacks: a comparatively tiny stream of perfectly legitimate-looking requests, each engineered to be expensive: the search page, the report generator, the login endpoint that hashes passwords. Ten thousand of those per second reads like enthusiasm, not attack, right up until the database dies.

The uncomfortable economics: attacks are rentable for pocket money ("booter" services sell them by the hour), while standing up your own absorption capacity costs a fortune. Which is why virtually everyone now makes the same move: put a global edge network (Cloudflare, Akamai, Fastly, and friends) in front of everything, and let the flood land on infrastructure built to soak entire terabits. This blog does exactly that, and the static-site trick is part of the same defence: pre-rendered HTML has no expensive endpoints to exhaust. You can't overload a database that isn't there.

The harder question: which "visitor" is a person?

Blocking floods is mostly a solved procurement problem. The subtler daily work is classification, because bots aren't one category. Some you want (search crawlers, your uptime monitor, RSS readers). Some are neutral-to-annoying (scrapers, AI-training crawlers: a policy choice more than a security one). Some are hostile: credential-stuffers replaying leaked passwords, card testers, inventory hoarders, vulnerability scanners probing for /wp-admin.

Nobody separates these with one trick; real systems layer weak signals into a verdict:

Declared identity, verified. Honest bots announce themselves and can be cryptographically or network-verified (Googlebot resolves to Google's ranges). Lesson one of bot work: User-Agent is a claim, and hostile bots claim to be Chrome.

Protocol fingerprints. Before a single page loads, the TLS handshake and HTTP/2 behaviour of a Python script look measurably different from a real browser. Fingerprinting techniques (JA3/JA4 and successors) catch impersonators whose plumbing doesn't match their claimed identity.

Behavioural tells. Humans are messy: they move cursors in curves, dwell, scroll unevenly, make typos. Automation is clean, fast, and tireless: hitting fifty URLs in perfect sequence at 3 a.m. without ever loading an image. Modern bot management scores these micro-signals continuously rather than asking once.

Progressive challenges. When confidence is low, escalate cheaply: an invisible JavaScript proof-of-work most automation fails silently, then a managed challenge, and only rarely the dreaded CAPTCHA, which deserves its dying reputation, since modern AI solves image puzzles better than tired humans do. The industry's quiet consensus is friction proportional to suspicion, not tollbooths for everyone.

Rate shape, not just rate. Naive rate-limiting punishes office NATs where hundreds of humans share one IP. Better limits key on session and behaviour, and protect expensive paths: five login attempts per account per minute matters more than a blanket requests-per-IP number.

The plot twist: good bots that act like attacks

Everything above assumed bot ≈ suspect. The AI-agent era breaks that assumption: increasingly, a "bot" is someone's personal agent doing a legitimate errand: comparing prices, booking an appointment, reading this very blog on a human's behalf. It behaves like automation because it is, but blocking it now blocks a customer.

The emerging answer is the one security always lands on: identity over anatomy. Standards for agents to cryptographically prove who operates them (signed requests, verified bot registries) are being built right now, shifting the question from "are you a machine?" (increasingly meaningless) to "whose machine are you, and do they stand behind you?" Which is, not coincidentally, the same identity-first argument I've been making about the agents inside your own org. The perimeter question and the traffic question are converging on the same answer.

If you run anything public

The practical floor is short: put an edge network in front (free tiers exist), turn on its managed bot rules, keep expensive endpoints behind rate limits keyed to sessions, and write down which good bots you welcome. Then watch your analytics with the right prior: that a visitor is, more likely than not, no one at all.

The flood isn't coming; it's the baseline. The craft is serving humans smoothly while it rains machines.