Itnetic TechnologiesA botnet is rented, not built
The word suggests a hacker patiently assembling an army. The reality is a market. Someone else compromises the devices, someone else operates the command-and-control infrastructure, and the person attacking you is a customer who paid for an hour of it on a "stresser" or "booter" site with a checkout page and customer support. This is why small sites get attacked at all: the person aiming a botnet at your shop does not need to know how any of it works, and it costs them less than lunch.
That separation of roles is the single most useful thing to understand about botnets, because it tells you what the attacker optimises for. They are not attached to any particular device, address or technique. They are buying an outcome, and they will keep buying until the outcome stops arriving — or until it stops being cheap.
How a machine ends up in one
The recruitment methods have barely changed in a decade, because they keep working.
| Source | How it is recruited | What it contributes to an attack |
|---|---|---|
| IoT devices — cameras, routers, DVRs, NVRs | Default or reused credentials over Telnet and SSH; unpatched firmware that will never receive an update | Enormous numbers, modest bandwidth each, permanently online |
| Home and small-office routers | Exposed admin panels and known CVEs in vendor firmware | A real residential IP address, which is the valuable part |
| Cloud servers and VPS instances | Stolen API keys, weak SSH passwords, exposed container and orchestration APIs | Serious bandwidth and CPU — the machines that generate high request rates |
| Ordinary PCs | Malware loaders bundled with cracked software, phishing attachments | Real browsers, real cookies, the hardest traffic to classify |
| Phones and apps | SDKs embedded in free apps that resell the user’s connection as a "residential proxy" | Traffic that is technically consented-to, legally murky and indistinguishable from a customer |
The last row is worth sitting with. A large share of what gets called botnet traffic today is not malware at all — it is commercial proxy infrastructure, sold openly, sourced from millions of real consumer connections whose owners clicked through a free VPN’s terms of service. Defensively it behaves exactly like a botnet, and it cannot be blocked by reputation alone, because the address genuinely belongs to a genuine household that may also be a genuine customer.
The device count is the wrong number
Botnets are reported by size — 600,000 devices for Mirai in 2016, roughly a quarter of a million MikroTik routers for Mēris in 2021 — and size is the least useful figure in the report. What decides whether your site falls over is requests per second delivered, and that is a product of efficiency per bot, not population.
The clearest demonstration is the HTTP/2 Rapid Reset campaign of 2023: a botnet of roughly 20,000 machines generated request floods in the hundreds of millions per second, because each connection could open and instantly cancel streams faster than the server could discard them. Twenty thousand machines is a rounding error next to Mirai. The attack was two orders of magnitude larger.
| Botnet | Scale | What it actually exploited |
|---|---|---|
| Mirai (2016) | ~600,000 IoT devices | Default Telnet credentials; source code published, so every later variant inherited it |
| Mēris (2021) | ~250,000 routers | HTTP pipelining — many requests in flight per connection, ~17–22 million rps |
| Rapid Reset (2023) | ~20,000 machines | HTTP/2 stream cancellation; hundreds of millions of rps from a tiny fleet |
| Residential proxy networks (now) | Millions of consumer IPs | No exploit at all — traffic sold as a service, from addresses that look like customers |
Read that table as a trend line rather than a history lesson. Each generation needed fewer machines and looked more like legitimate traffic than the one before. Both directions run against any defense based on identifying who is sending, which is the entire case for defenses based on what it costs to send.
What a botnet looks like from your side
Volumetric floods announce themselves — the amplification and SYN flood families saturate links and connection tables. Botnet-driven Layer 7 traffic is quieter, and the signals are statistical rather than obvious:
- Per-source rates that look reasonable. Every individual address is sending two or three requests a second. Nothing is anomalous in isolation; the aggregate is 50,000 rps.
- A sudden, flat plateau. Human traffic ramps and wobbles. Botnet traffic arrives at full rate in one step and holds a suspiciously straight line.
- Uniformity where there should be variety. Identical header ordering, one TLS fingerprint across thousands of "different browsers", the same
Accept-Languageeverywhere, no conditional requests, no images fetched after the HTML. - The expensive endpoints, specifically. Search with random terms, login, cart, password reset, any URL with a cache-busting query string. A botnet aimed by someone competent targets whatever your origin cannot cache.
- Geography that does not match your business, or — with residential proxies — geography that matches it too perfectly.
- Origin CPU up, bandwidth ordinary. The graph everyone checks first stays flat while the application dies, exactly as it does in a low and slow attack.
Why blocking IP addresses fails
Every instinct says: collect the addresses, block the addresses. Against a botnet this consumes your incident and returns nothing, for three separate reasons.
The list is longer than your firewall. Tens of thousands of sources, rotating continuously. By the time a rule is deployed, the addresses in it are idle and new ones are live. You end up maintaining a growing table that is evaluated on every packet — work the attacker forces you to do for free.
Addresses are shared. Mobile carriers put thousands of real subscribers behind one CGNAT address. Universities, companies and whole countries sit behind a handful of egress IPs. Block one and you have not removed the bot, you have removed everyone who shares its exit — a self-inflicted outage indistinguishable from the one you are trying to prevent.
Residential proxies are, by construction, real homes. There is no blocklist that contains them, because the same address serves a real customer tomorrow. Reputation data helps you weight a decision; it cannot be the decision.
The conclusion is not that identity is useless — it is that identity has to be established per request, from behavior and client characteristics, rather than looked up from an address. That distinction is what separates DDoS mitigation from a firewall rule.
What actually works: make the traffic expensive
A botnet is an economic instrument. It wins by having more cheap senders than you have cheap ways to say no. Every effective defense inverts one of those terms.
- Invisible proof-of-work. Before a request reaches your application, the client is asked to burn a fraction of a second of CPU. A real visitor never notices — no image grid, no puzzle, no "select all the traffic lights". A botnet multiplying that cost across every request in a flood finds its rented hour buys a tenth of what it used to. This is the single highest-leverage defense against botnet traffic, and the reason CAPTCHAs are the wrong tool: they tax your customers to inconvenience a machine that can afford to solve them anyway.
- Behavioral signatures. Request path sequences, header shape and ordering, and TLS handshake fingerprints (JA4) describe how a client speaks, independently of where it speaks from. Ten thousand addresses sharing one fingerprint is a far stronger signal than any of the ten thousand addresses.
- Fingerprint reputation across many sites. A client signature seen attacking one host is a known quantity when it arrives at the next. Used to escalate a challenge rather than to block outright, it costs a false positive nothing more than a few milliseconds of CPU.
- Rate limiting keyed on identity, not on IP — a session, a token, an API credential — so that CGNAT and proxy pools stop being a way to launder request budget.
- Kernel-level drops for proven attackers. Once a source has been judged, it should cost nothing per packet thereafter. A block that still requires a userspace decision is a block the attacker can bill you for.
- Caching and absorption underneath all of it, so the requests that do get through are served from the edge rather than from your database.
You cannot wait for a takedown
Botnet takedowns are real and occasionally spectacular — Emotet’s infrastructure was seized in a coordinated international operation in 2021, and sinkholing operations have retired other large networks. They are also rare, slow, and irrelevant to your Tuesday afternoon. Mirai’s source code was published in 2016 and its descendants are still attacking things a decade later. The realistic planning assumption is that botnet capacity is permanently available to anyone with a payment method, and that your defense is entirely a question of what happens at your edge.
While you are here: check that you are not part of one. Cloud instances with weak SSH credentials, an exposed Docker or Kubernetes API, or a forgotten router with its default password are exactly the recruitment surface described above. Change default credentials, keep firmware current, do not expose admin interfaces to the internet, and watch outbound traffic — a machine sending a steady stream of requests to a target it has no business talking to is the clearest symptom there is.
How Itnetic handles botnet traffic
Itnetic’s edge is built around the assumption that the source address tells you nothing. Every layer below is in the path on every plan, including the free one — there is no tier where bot defense is an upgrade.
| Layer | What it does to a botnet |
|---|---|
| Adaptive under-attack detection | A per-host baseline trips into challenge mode within a second of a spike, decided at the edge without a control-plane round trip, and fans out to every other node |
| Two-stage proof-of-work challenge | An invisible redirect first, escalating to a visible solve under pressure. No CAPTCHA, no image grids — the cost lands on the botnet’s CPU budget, not on your visitors’ patience |
| Behavioral signatures | Path sequence, header shape and JA4 TLS fingerprint, so a fleet sharing one client implementation is recognised as one actor regardless of how many addresses it holds |
| Fingerprint reputation and ML scoring | Signatures seen attacking elsewhere arrive pre-judged. Both layers escalate to a challenge and never block outright, so a misjudged real visitor loses milliseconds, not access |
| Rate limiting on a key you choose | Token-bucket limits keyed on a credential or session header rather than the address, with correct 429 responses for machine clients instead of HTML |
| Kernel drop of proven attackers | Repeat offenders are held in an nftables set and cost nothing per packet from then on; an eBPF filter at the XDP hook handles packet floods before a socket is allocated |
| Volumetric absorption upstream | Frankfurt sits behind X4B, a network with 500 Gbps of mitigation capacity; Prague runs on Eternyx behind its own network-level protection; Toronto and Singapore run on Linode (Akamai) behind theirs. The current list is on the network page |
| Evidence | Per-request logs with status, latency, client fingerprint and the verdict applied, so the post-mortem is an export rather than a reconstruction |
Two commercial details decide whether this is affordable to leave switched on. Mitigated attack traffic is never metered against your bandwidth quota, so a botnet cannot spend your allowance as a second way of hurting you. And going live is two DNS records at your existing provider — no nameserver move, about five minutes, one hostname at a time if you want to watch it first. Itnetic’s DDoS protection has the rest of the mechanics.
A seven-point checklist
- Put your site behind an edge that challenges clients by cost rather than by CAPTCHA, and confirm real visitors never see an interstitial.
- Stop maintaining IP blocklists as a primary defense; keep reputation as a weighting signal only.
- Key your rate limits on a session, token or credential, not on the source address.
- Cache aggressively, and know which of your endpoints cannot be cached — those are the ones a botnet will find.
- Plot requests per second and origin CPU next to bandwidth. A botnet moves the first two and not the third.
- Firewall your origin so it accepts traffic only from your protection network, or the whole edge is optional from the attacker’s point of view — see how to hide your origin IP.
- Audit your own fleet for default credentials and exposed admin APIs, so none of this is describing you from the other side.
If a botnet is pointed at you right now, stop reading and work through how to stop a DDoS attack. When it is over, a written response plan is what makes the second one uneventful.