The Spamhaus DDoS Attack (2013)

In March 2013, the anti-spam organization Spamhaus came under a sustained distributed denial-of-service attack that began around March 18 and ultimately peaked at approximately 300 Gbps by March 27 — making it, at the time, the largest publicly disclosed DDoS attack in the history of the internet. The attack was triggered by a dispute with a Dutch hosting provider called CyberBunker, and its effects rippled far beyond the original target. Upstream transit providers, Internet Exchange Points, and even ordinary users experienced degraded connectivity as the attack's traffic spilled across the global routing infrastructure.

The Spamhaus incident remains a landmark case study in how DNS amplification works, why open resolvers are dangerous, and how a single attack can threaten the stability of the internet itself.

What is Spamhaus?

Spamhaus is a nonprofit organization that maintains real-time blocklists (DNSBLs) used by email servers worldwide to filter spam. When Spamhaus lists an IP address or network, mail servers that subscribe to its blocklists will reject email from those addresses. For spammers and the hosting providers that tolerate them, being listed by Spamhaus is devastating — it effectively cuts off their ability to deliver email to most of the internet.

Spamhaus operates its infrastructure across multiple countries and relies heavily on CDN and anycast technology to distribute its DNS-based blocklist queries globally. By 2013, Spamhaus was one of the most influential anti-spam organizations in existence, and its blocklists were trusted by a large fraction of the internet's mail servers.

CyberBunker and the Dispute

CyberBunker was a Dutch hosting provider that operated out of a decommissioned NATO bunker in the Netherlands. The company advertised a policy of hosting anything except child pornography and terrorism-related content. This permissive stance attracted a range of controversial clients, including spammers.

In 2011, Spamhaus added CyberBunker's IP address ranges to its blocklists after identifying significant volumes of spam originating from the provider's network. CyberBunker's operator, Sven Olaf Kamphuis, disputed the listing and accused Spamhaus of overstepping its authority by acting as a de facto censor of the internet. When Spamhaus refused to remove the listing, the situation escalated.

A group calling itself the "STOPhaus" movement — aligned with CyberBunker — launched a series of DDoS attacks against Spamhaus's infrastructure beginning in mid-March 2013. What started as a relatively modest volumetric attack quickly escalated into something unprecedented.

DNS Amplification: The Attack Technique

The Spamhaus attack relied on DNS amplification, a reflection attack technique that exploits the fundamental asymmetry in DNS query and response sizes. The technique requires two ingredients: a list of open DNS resolvers (recursive resolvers that will answer queries from anyone on the internet), and the ability to spoof source IP addresses.

Here is how it works:

1. Spoofed queries -- The attacker sends DNS queries to tens of thousands of open resolvers, but sets the source IP address on each packet to the target's IP (Spamhaus's address). Because DNS uses UDP, and UDP has no handshake, the resolvers have no way to verify that the query actually came from Spamhaus.
2. Large responses -- The queries are crafted to produce the largest possible responses. The attacker typically uses the ANY query type, which asks the resolver to return all records for a domain. A 64-byte query can produce a response of 3,000 bytes or more.
3. Amplification -- The resolvers send their large responses not to the attacker, but to the spoofed source address: Spamhaus. An amplification factor of roughly 50x means that an attacker with 6 Gbps of outbound bandwidth can generate 300 Gbps of attack traffic directed at the victim.

The beauty (from the attacker's perspective) of DNS amplification is that the attacker never communicates directly with the target. Every byte of attack traffic comes from legitimate DNS resolvers that are unwitting participants. This makes the attack extremely difficult to trace and even harder to filter, because the flood of traffic consists of valid DNS response packets from thousands of different source IPs.

Why Open Resolvers Were the Problem

The attack was only possible at this scale because millions of DNS resolvers on the internet were configured to accept and answer recursive queries from any source address. These "open resolvers" — misconfigured home routers, unpatched servers, and neglected infrastructure — served as the unwitting amplifiers.

In 2013, the Open Resolver Project estimated that approximately 28 million open DNS resolvers existed on the internet. Each one was a potential amplifier. The attackers needed to control only a modest amount of bandwidth themselves; the open resolvers did the rest, multiplying the traffic by a factor of 50 and redirecting it toward Spamhaus.

The root cause was a combination of two protocol-level weaknesses:

• UDP source address spoofing -- The IP protocol does not inherently prevent a sender from forging the source address on a packet. While BCP38 (network ingress filtering) recommends that ISPs filter spoofed packets at their network borders, many networks did not implement this in 2013, and a significant number still do not today.
• DNS response amplification -- DNS responses are often much larger than queries. The ANY query type was particularly exploitable because it returned all record types for a zone, producing responses 50 to 70 times larger than the query.

Timeline of the Attack

The attack unfolded over approximately ten days, escalating in both scale and scope:

Cloudflare Steps In

On March 19, Spamhaus reached out to Cloudflare (AS13335) for help. Cloudflare placed Spamhaus behind its anycast network, distributing the attack traffic across Cloudflare's data centers worldwide. Because Cloudflare announced Spamhaus's IP prefixes via BGP from dozens of locations, the attack traffic was spread across all those points of presence rather than concentrated on a single location.

The anycast approach was effective. Instead of 300 Gbps hitting one data center, each Cloudflare PoP absorbed only a fraction of the total. At any individual location, the volume was manageable. The attack against Spamhaus's web presence was largely mitigated — the site stayed online.

But the attackers adapted.

Escalation: Targeting the Infrastructure

When direct attacks against Spamhaus (now behind Cloudflare) failed to take the site down, the attackers changed tactics. Instead of targeting Spamhaus's IP addresses, they began targeting the networks upstream of Cloudflare — the Tier 1 transit providers and Internet Exchange Points that carried Cloudflare's traffic.

This was a critical escalation. By flooding the transit links and IX ports that connected Cloudflare to the rest of the internet, the attackers could cause collateral damage far beyond Spamhaus. The approach targeted specific IP addresses of routers at IXPs and on transit provider networks, attempting to congest the shared infrastructure that many networks depended on.

The London Internet Exchange (LINX) was one of the IXPs that reportedly experienced congestion during this phase of the attack. LINX is one of the largest IXPs in the world, carrying traffic for hundreds of connected networks. When its switching fabric became congested, the effects were felt by every network peering there — not just Cloudflare or Spamhaus, but banks, media companies, cloud providers, and ordinary ISPs.

This is what made the Spamhaus attack qualitatively different from previous DDoS events. Earlier attacks had been bilateral: an attacker flooding a target. The Spamhaus attack demonstrated that by targeting shared infrastructure, a DDoS could become a threat to the broader internet.

300 Gbps: Scale in Context

To understand why 300 Gbps was significant in 2013, consider the context. At the time, many major IXPs had total aggregate throughput measured in hundreds of gigabits per second. A 300 Gbps flood was comparable to the total traffic volume of some of the world's largest exchange points. Individual transit links between Tier 1 providers were typically 10 Gbps or 100 Gbps; a 300 Gbps attack could saturate multiple such links simultaneously.

For comparison:

• The previous largest publicly reported DDoS attacks had peaked in the range of 50-100 Gbps.
• A typical large enterprise internet connection in 2013 was 1-10 Gbps.
• Many hosting providers' entire network capacity was well below 300 Gbps.

The jump from ~100 Gbps to 300 Gbps demonstrated the terrifying scalability of amplification attacks. The attacker's own bandwidth was a small fraction of the total — the amplification factor did the rest.

The Arrest of Sven Olaf Kamphuis

On April 25, 2013, approximately one month after the attack, Spanish police arrested Sven Olaf Kamphuis in Barcelona. Kamphuis, a Dutch citizen, had been publicly claiming credit for the attacks and had been vocal in his opposition to Spamhaus. He was found in a mobile bunker — a van equipped with computing equipment and multiple network connections — suggesting he had been directing attack operations while moving to avoid detection.

Kamphuis was extradited to the Netherlands, where he was tried and convicted in 2015 for his role in the attack. He received a sentence that, while relatively modest by the standards of the damage caused, sent a clear message that DDoS attacks of this magnitude would be treated as serious criminal offenses.

Technical Lessons

The Spamhaus attack exposed several weaknesses in the internet's infrastructure and led to concrete improvements:

Open Resolver Cleanup

The attack put a spotlight on the millions of misconfigured open DNS resolvers around the world. After Spamhaus, a concerted effort by the networking community reduced the number of open resolvers significantly. The Open Resolver Project catalogued these servers and pressured ISPs and equipment manufacturers to change default configurations. Modern DNS resolver software ships with recursion disabled for external queries by default.

BCP38 and Source Address Validation

DNS amplification requires IP source address spoofing. BCP38 (RFC 2827) — published in 2000, thirteen years before the Spamhaus attack — recommends that ISPs implement ingress filtering to prevent their customers from sending packets with spoofed source addresses. The Spamhaus attack renewed urgency around BCP38 adoption. The MANRS (Mutually Agreed Norms for Routing Security) initiative, launched in 2014 partly in response to incidents like this, includes anti-spoofing as one of its core pillars.

Deprecation of DNS ANY Queries

The ANY query type was central to achieving high amplification factors. RFC 8482, published in 2019, effectively deprecated the ANY query type by allowing DNS servers to respond with a minimal answer instead of dumping all records. This significantly reduced the amplification potential for DNS-based attacks.

Response Rate Limiting (DNS RRL)

DNS server software began implementing Response Rate Limiting, which detects when a large number of similar responses are being sent to the same destination address and throttles them. This reduces the effectiveness of a resolver as an amplifier, even if it is misconfigured as open.

How Anycast Saved Spamhaus

Cloudflare's use of BGP anycast was central to the mitigation strategy. In an anycast deployment, the same IP prefix is announced via BGP from many locations around the world. When attack traffic arrived at the internet's routing fabric, it was naturally distributed across all Cloudflare PoPs based on BGP's shortest-path routing.

This was one of the first high-profile demonstrations that CDN-style anycast networks were effective DDoS mitigation platforms. The key insight was that the same BGP routing mechanism that distributes legitimate traffic across a CDN's edge also distributes attack traffic. A 300 Gbps attack split across 23 data centers (Cloudflare's size at the time) became roughly 13 Gbps per location — well within each site's capacity to absorb and discard.

Legacy and Lasting Impact

The Spamhaus attack of 2013 was a watershed moment for internet security. It proved that DNS amplification could produce attack volumes that threatened shared infrastructure, not just individual targets. Several lasting changes trace back to this event:

• DDoS mitigation became an industry -- Cloudflare, Akamai, and other providers expanded their DDoS mitigation offerings. Being able to absorb large volumetric attacks became a key selling point for CDN providers.
• Open resolver reduction -- The number of open DNS resolvers on the internet dropped significantly in the years following the attack, though millions still exist.
• BCP38 awareness -- The importance of source address validation became widely understood outside the networking community for the first time.
• DNS protocol hardening -- Changes like RFC 8482 (deprecating ANY queries) and response rate limiting were direct responses to the amplification problem.
• Attack scale normalization -- The 300 Gbps record stood only briefly. By 2014, attacks exceeding 400 Gbps were observed. By 2018, memcached amplification produced attacks over 1.7 Tbps. By the 2020s, multi-terabit attacks are common. The Spamhaus attack was the beginning of an arms race that continues today.

The BGP Perspective

From a BGP routing standpoint, the Spamhaus attack illustrates several important concepts:

• Anycast as defense -- Anycast routing, where the same prefix is announced from multiple locations, provides natural load distribution for both legitimate and attack traffic. This is why major DNS resolvers and CDNs use anycast extensively.
• Transit and peering fragility -- The attack's second phase, targeting upstream providers and IXPs, showed that peering and transit links are potential bottlenecks. Congesting a single IXP port or transit link can cause collateral damage to many unrelated networks.
• The role of AS paths -- Traffic engineering via BGP can help during an attack by shifting traffic away from congested links. Networks can deprioritize or withdraw routes through affected paths to reroute traffic.

You can explore the networks involved in this story using the looking glass:

• AS13335 -- Cloudflare, which mitigated the attack
• AS8714 -- LINX, the London Internet Exchange affected by the attack
• 1.1.1.1 -- Cloudflare's anycast DNS, built on the lessons from this era

Try It Yourself

The Spamhaus attack demonstrated how DNS, BGP, and internet infrastructure interconnect in ways that matter during a crisis. Explore the routing and DNS data for the networks involved:

• Look up Cloudflare (AS13335) -- see the anycast network that absorbed the attack
• Look up LINX (AS8714) -- the IXP that experienced collateral congestion
• Look up 8.8.8.8 -- Google's public DNS resolver, one example of a well-secured anycast DNS service
• Look up DE-CIX (AS6695) -- another major IXP, illustrating IXP routing structure