There’s been a bit of discussion about how much this DDOS actually slowed down the Internet globally. Fact is that the Internet didn’t come to a halt but the large amount of new traffic that had to be handled by some of the carriers did result in congestion and significant packet loss by some of the Tier1 carriers last weekend. In this blog post we’ll look at this event from the routing perspective, what effects did this have on the Internet Exchanges and we’ll also look at some BGP hijacks related to this attack.

BGP hijack affecting Spamhause
The majority of the attack towards SpamHaus and cloudflare was a brute-force DDOS of attack. But in an attempt to affect spamhause services different techniques were used, one of them was a BGP hijack by the alleged initiator of the attack. Greenhost.nl has a great description on their blog about how AS34109 Cyberbunker/CB3Rob (the alleged organizer of the spamhause attack), announced a more specific route for one of the spamhaus servers: 0.ns.spamhaus.org with IP address 204.16.254.40/32.

As this was a more specific route everyone receiving this route would have routed to the Cyberbunker server where each spamhaus query was then reported as a spammer.

Cyberbunker/CB3Rob announced this prefix on the NL-IX an Internet Exchange in the Netherlands. This means that networks that peer with 34109 on the NLIX would have received this prefix and most likely used this “fake” spamhaus server.
It’s obvious that an attack like this takes very little resources (as compared to the large scale DDOS) and can be very effective.

When we look at the history of AS34109 and AS51787, both assigned to Cyberbunker, we see that there were previous BGP incidents. We recorded two recent incidents during which AS34109 announced prefixes that are not assigned to them (Hijack). On January 9 AS34109 briefly announced 205.189.74.0/24 and between March 7 and March 21 the prefix 205.19.72.0/23 was announced by AS34109. This prefix is assigned to the US department of Defense and normally not announced to the Internet. It’s currently listed in spamhaus so it’s likely that this prefix was used to send spam.

Cyberbunker prefixes have also been on the other side of the story, on February 6th some of their IP addresses in the 84.22.106.0/24 range were announced as /32’s inside the TATA communications (AS6453) network most likely because these were being null routed by TATA.

Internet Exchange point route announcements
One of the things that made this attack unique as compared to previous DDOS attacks was that the attackers decided to attack critical Internet infrastructure such as Internet Exchange points that are used by cloudflare and its upstream providers. This allowed the attacker to bypass the Anycast infrastructure of Cloudflare and focus the attack towards a limited set of devices resulting in a lot of (new) traffic towards a very specific point on the Internet.

Normally these addresses used on the Exhange points should not be globally reachable or at least do it in such a way that it can easily be controlled and withdrawn. This is done specifically to prevent attacks towards the Internet Exchanges. Unfortunately this was not the case for two of the major Internet Exchanges in London, which was one of the reasons why these attacks towards the cloudflare routers was so intrusive.
Looking at the BGP data for the last few days we can see that both London Internet exchanges have now de-aggregated their announcements so that it’s easier to control announcements for the peering networks in London. Now all that remains is stopping members from announcing this prefix.

This week we’ve seen that DDOS are a big problem on the Internet and it’s unlikely this will go away any time soon, in fact the volume just keeps growing. This event also showed that DDOS can sometimes hide other attacks, as DDOS are very visible and intrusive it will typically get the attention of network and security engineers with the risk that it can be used to hide other forms of attacks such as intrusion attempt and in this case BGP hijacks.

3 comments

maybe we can create some kind of ‘snort-rule’ to search for any scanning for DNS? imo this could helps to prevent this types of attack (as ‘try if dns is vulnerable via some scanning, fingerprint of version, you name it).