BIGGEST DDoS ATTACK IN HISTORY hammers Spamhaus
Anti-spam organisation Spamhaus has recovered from possibly the largest DDoS attack in history.
A massive 300Gbps was thrown against Spamhaus’ website but the anti-spam organisation was able to recover from the attack and get its core services back up and running. CloudFlare, the content delivery firm hired by Spamhaus last week to guard against an earlier run of DDoS attacks, was also hit, forcing it into taking the highly unusual step of dropping London as a hub in its network – as a Twitter update by CloudFlare on Monday explained.
Our peering in London has been dropped due to a large attack. Modifying routes to avoid degradation. Affecting location: London, GB
Spamhaus supplies lists of IP addresses for servers and computers on the net linked to the distribution of spam. The blacklists supplied by the not-for-profit organisation are used by ISPs, large corporations and spam filtering vendors to block the worst sources of junk mail before other spam filtering measures are brought into play.
Spammers, of course, hate this practice so it’s no big surprise that Spamhaus gets threatened, sued, and DDoSed regularly. Those affected by what they regard as incorrect listings also object about Spamhaus’ alleged vigilante tactics.
The latest run of attacks began on 18 March with a 10Gbps packet flood that saturated Spamhaus’ connection to the rest of the Internet and knocked its site offline. Spamhaus’s blocklists are distributed via DNS and widely mirrored in order to ensure that it is resilient to attacks. The website, however, was unreachable and the blacklists weren’t getting updated.
The largest source of attack traffic against Spamhaus came from DNS reflection, launched through Open DNS resolvers rather than directly via compromised networks. Spamhaus turned to CloudFlare for help and the content delivery firm was able to mitigate attacks that reached a peak of 75Gbps, as explained in a blog post here.
Things remained calm for a few days before kicking off again with even greater intensity – to the extent that collateral damage was seen against services such as Netflix, the New York Times reports.
Spamhaus’ site remains available at the time of writing on Wednesday. Steve Linford, chief executive for Spamhaus, told the BBC that the scale of the attack was unprecedented.
“We’ve been under this cyber-attack for well over a week.But we’re up – they haven’t been able to knock us down. Our engineers are doing an immense job in keeping it up – this sort of attack would take down pretty much anything else,” he said.
Turning up the volume of DDoS attacks
A blog post by CloudFlare, written last week before the latest run of attacks, explains the mechanism of the attack against Spamhaus and how it can be usde to amplify packet floods.
The basic technique of a DNS reflection attack is to send a request for a large DNS zone file with the source IP address spoofed to be the intended victim to a large number of open DNS resolvers. The resolvers then respond to the request, sending the large DNS zone answer to the intended victim. The attackers’ requests themselves are only a fraction of the size of the responses, meaning the attacker can effectively amplify their attack to many times the size of the bandwidth resources they themselves control.
In the Spamhaus case, the attacker was sending requests for the DNS zone file for ripe.net to open DNS resolvers. The attacker spoofed the CloudFlare IPs we’d issued for Spamhaus as the source in their DNS requests. The open resolvers responded with DNS zone file, generating collectively approximately 75Gbps of attack traffic. The requests were likely approximately 36 bytes long (e.g. dig ANY ripe.net @X.X.X.X +edns=0 +bufsize=4096, where X.X.X.X is replaced with the IP address of an open DNS resolver) and the response was approximately 3,000 bytes, translating to a 100x amplification factor.
CloudFlare reckons 30,000 unique DNS resolvers have been involved in the attack against Spamhaus.
“Because the attacker used a DNS amplification, the attacker only needed to control a botnet or cluster of servers to generate 750Mbps – which is possible with a small sized botnet or a handful of AWS instances,” it explains. ®