By Pavel
In September 1996 a New York internet provider called Panix went down under a flood of a few hundred forged connection requests per second. Its engineers spent days trying to filter the traffic. On the NANOG operators’ mailing list, someone asked how to tell the attack packets apart from real ones, and one answer was “I don’t think you can, there’s no pattern.” Twenty-nine years later, in December 2025, Cloudflare absorbed an attack from the Aisuru botnet that peaked at 31.4 terabits per second.
Between those two points sits the history of distributed denial of service, and it shows one steady trend. Every few years attackers found a new way to multiply their traffic, and every time the defence moved one step further away from the server being attacked. Today a site that relies on its own firewall to stop a DDoS is defending in the wrong place. To see why, it helps to look at how the attack and the defence changed together.
1996-2000: when one server could be knocked over by one person
The Panix attack was a SYN flood. A TCP connection starts with a three-step handshake, and the server sets aside memory for every connection that has opened but not finished. Send enough opening packets from forged addresses and never finish them, and the server runs out of room for real visitors. The technique had been published in the hacker magazines 2600 and Phrack only weeks before. It needed no botnet and very little bandwidth. It exploited a design assumption: the protocol trusted that whoever started a handshake meant to finish it.
The fix also came from the protocol. SYN cookies, which let a server avoid storing state until the handshake completes, were developed within months and are still on by default in most operating systems. That set the pattern for the first era. Attacks targeted the server’s own resources, so defence happened on the server.
That model broke in February 2000. A 15-year-old in Montreal calling himself Mafiaboy used networks of machines he had already compromised to take Yahoo offline, then eBay, CNN, Dell and Amazon, over a single week. The traffic came from hundreds of hosts at once. No single source looked abnormal, and the combined volume overloaded the victims’ network links before their servers had a chance to object. Hardening the server could not help. The attack had become distributed, and the problem had moved upstream to the network pipe.
2007-2013: botnets, then amplification
For the next decade the main weapon was the botnet: thousands, then hundreds of thousands, of infected home PCs controlled from one place. The 2007 attacks on Estonia’s government, banks and media showed that DDoS had become a tool of geopolitics as well as extortion and grudges. They also showed that a target on an ordinary network connection had no realistic answer to that much traffic.
The next step change did not need more infected machines. It came from turning other people’s servers into amplifiers. In March 2013 the anti-spam organisation Spamhaus came under an attack that reached about 300 Gbps. The attackers sent small DNS queries, roughly 36 bytes each, to tens of thousands of open DNS resolvers, forging Spamhaus’s address as the sender. Each resolver replied with about 3,000 bytes, so the traffic was amplified around a hundred times, all of it aimed at the victim.
Amplification exposed the root cause that is still with us today: the internet lets a sender lie about its own address. The fix has been known since 2000 as BCP 38, which asks networks to drop outgoing packets whose source address could not have come from inside them. It has never been deployed universally, because the network that does the filtering pays the cost while the benefit goes to someone else. Every amplification attack since, through NTP, SSDP, CLDAP and memcached, has relied on that gap.
2016-2018: the internet of things and the terabit
In September 2016 the security journalist Brian Krebs’s site was hit with about 620 Gbps, the largest attack recorded at the time. Akamai, which had been protecting it for free, had to drop it. The source was Mirai, malware that scanned the internet for cameras, video recorders and routers still using factory passwords and enlisted them by the hundred thousand. About ten days later its author published the source code. On 21 October 2016 a Mirai botnet hit Dyn, a major DNS provider, and Twitter, Reddit, Netflix and dozens of other sites became unreachable for much of the US East Coast. None of those sites was attacked directly. Their shared dependency was.
Eighteen months later, in February 2018, GitHub received 1.35 Tbps from exposed memcached servers, which multiply small requests by a factor of tens of thousands. The attack is remembered less for its size than for how short it was. Within about ten minutes GitHub’s monitoring had routed its traffic through Akamai’s Prolexic scrubbing network, which dropped everything coming from the memcached port, and the site was back to normal. GitHub did not out-muscle 1.35 Tbps. It had arranged in advance for someone with more capacity to stand between it and the internet.
2023-2026: attacks on the application, at a scale only clouds can absorb
As network-level floods became something large providers absorbed routinely, attackers moved back up the stack, to the applications themselves. The attacks began in August 2023, and in October Google, AWS and Cloudflare jointly disclosed HTTP/2 “Rapid Reset” (CVE-2023-44487), a technique that opens a request and cancels it immediately, over and over, on the same connection. Google measured a peak of more than 398 million requests per second, over five times the previous record. It was the SYN flood again, 27 years later: an attack on a protocol’s assumption that a client who starts something intends to finish it.
Volumetric attacks have kept growing as well. Cloudflare’s report for the first half of 2026 counted 935 network-layer attacks above 1 Tbps in six months. Terabit attacks used to make headlines. Now they are routine enough to be counted.
The same report shows the other side of the picture, which matters more to most businesses: 96.6% of network-layer attacks were under 500 Mbps, and 90.6% were over in less than ten minutes. The typical attack is not a record. It is a short burst big enough to fill a small company’s uplink, timed for a product launch or a sale, or sent as a demonstration before a ransom note. It is over before a human could get through the first step of a manual runbook.
What thirty years of DDoS teach about protection
Put the eras side by side and the direction is plain. Defence started on the server (SYN cookies), moved to the network edge (firewalls and rate limits at the provider), then to dedicated scrubbing centres (Prolexic and its peers), and finally to globally distributed anycast networks that absorb attacks close to where they start. Each move happened because attack traffic outgrew the capacity of the layer below. Several lessons follow for anyone responsible for keeping a service online.
Capacity has to come from someone bigger than you
No individual company can provision bandwidth for a 30 Tbps attack, and none should try. The practical question is not whether to use an upstream DDoS protection service but which one, and whether it is already in the traffic path or has to be switched on during an incident. An always-on CDN or proxy protects from the first packet. On-demand scrubbing that needs DNS or BGP changes leaves a gap, and the attacks most likely to hit you will already be over before that gap closes.
Hide the origin
Upstream protection only works if attackers cannot go around it. An origin server whose real IP address appears in an old DNS record, a mail header or a forgotten subdomain can be attacked directly, and the CDN in front of it will not see a thing. Restricting the origin so that it only accepts traffic from the protection provider’s address ranges is one of the cheapest and most often skipped steps.
Automate detection and response
When nine out of ten attacks end within ten minutes, a response that starts with a phone call does not work. GitHub’s 2018 recovery took minutes because detection and rerouting were automatic. Mitigation rules, alert thresholds and who has authority to act should be decided before an attack, not during one.
Protect the application layer separately
Volumetric floods are a capacity problem. Application-layer attacks such as Rapid Reset, cache-busting floods and login-endpoint abuse are a logic problem. They need rate limiting per endpoint, bot management and caching that keeps expensive pages away from the database. For a WordPress site that means not leaving wp-login.php and xmlrpc.php open to anyone, since both are frequent targets. Our WordPress security work usually starts there.
Map your shared dependencies
The Dyn attack took down companies that were never targeted. DNS, authentication providers, payment gateways and the CDN itself are all single points of failure unless there is a second provider or a tested fallback. A DDoS plan that covers only your own servers covers only part of the risk.
We saw most of these lessons in one engagement, described in our DDoS attack prevention case study: the attack was stopped by moving the defence upstream and closing the routes around it, not by tuning the server under fire.
The pattern is likely to continue. Each new protocol, from HTTP/3 to whatever comes after it, will contain an assumption that a client means well, and someone will find a way to abuse it. Each new class of cheap connected device will add to the botnets. The defence that has kept pace for thirty years does not depend on predicting the next technique. It depends on keeping the capacity to absorb an attack outside your own infrastructure, and having the response automated before the next attack arrives. If you are unsure where your own site stands, a security and compliance audit is a good place to start.
