The Biggest DDoS Ever that “Almost Broke the Internet”?

“If the Internet felt a bit more sluggish for you over the last few days in Europe, this may be part of the reason why.” Well, “a bit more sluggish” for limited sets of communications in parts of Europe for a few days is not a broken internet, and is certainly not close to a critical infrastructure disaster.

There’s been a lot of attention for the recent reports regarding a DDoS attack against Spamhaus which reached a peak of 300gbps.
Yes, such enormous amount of throughput definitely makes this one of the biggest DDoS attacks ever seen. DDoS attacks have seen an increase in popularity in recent times and there’s no sign they’ll go away anytime soon. Cyber-criminals, competitors, hacktivists and nation-state sponsored actors all have their motives to use DDoS attacks. In this case, a suspected entity behind these attacks is a Dutch hosting company called CyberBunker, whose owner denies being responsible, but claims to be a spokesman for the attackers. The conflict between Spamhaus and CyberBunker goes back to 2011 and has now escalated after Spamhaus denylisted CyberBunker earlier this month. The timing and conflict is uncanny. And, Spamhaus is certainly under attack from some determined group capable of generating massive amounts of traffic, forcing them to move to hosting provider CloudFlare, known for effectively dissipating large DDoS attacks.

So how are the attackers managing to produce 300 gigabit/sec worth of traffic and what can be done about it? The primary answers lie with DNS amplification attacks and re-configuring open DNS resolvers.
By sending specially crafted DNS requests an attacker can send a pretty small request which will result in a response sent back to the target that’s several orders of magnitude bigger. In the past, network traffic amplification schemes used other protocols, and network administrators eventually configured their network routers so that their networks couldn’t be misused in what were called “smurf attacks”. And currently, there are other forms of DDoS attacks in use that are very troublesome, if not more so. But, these types of attacks are certainly not new, and we hope that the attention for this incident may very well function as a catalyst for DNS server administrators to better configure and secure their assets. More than 30,000 of these servers were misused for this particular set of attacks, so the proverbial cat is out of the bag and the urgency is here. If you run DNS servers, please check your ip address here and fix immediately if your assets are listed. With DNS amplication attacks, the advantage is very clearly with the attacker. We need a more level playing field. It is great to see that many ISPs are acting on this problem more urgently now to help level that field.

In relation to the shocking headlines suggesting the narrow aversion of a critical infrastructure disaster, while there clearly is a problem and solution at the technical level with the availability of 30,000 online DNS resolvers and their misuse, the internet did not almost break. We see bold claims being corrected over the past couple of days related to explanations of why CloudFlare customers saw any disruption over the past few days, softening the statement “From our perspective, the attacks had the largest effect on LINX which for a little over an hour on March 23 saw the infrastructure serving more than half of the usual 1.5Tbps of peak traffic fail” to “From our perspective, the attacks had the largest effect on LINX which caused impact over the exchange and LINX’s systems that monitor the exchange, as visible through the drop in traffic recorded by their monitoring systems”, along with no change in the claim that ” As problems were detected on the IX, we would route traffic around them. However, several London-based CloudFlare users reported intermittent issues over the last several days. This is the root cause of those problems.” All the while, it seems that LINX hasn’t seen enough of a problem to make a public statement about traffic flowing through the exchange. This is further evidenced by the list of IXs by size which shows that the AMS-IX should have been able to withstand such an attack, while LINX would be cutting it pretty close in terms of maximum load.

Don’t get us wrong, CloudFlare has a lot of talented people running an effective service and we are simply examining changing statements on a blog. But along with responsibly identifying that there is a present threat posed by the current availability of open recursive resolvers, let’s keep headlines in proportion and keep the focus on fixing the problem.