That is a quote from one of my favorite bands. Dave Gahan from Depeche Mode is a living proof that you can say the word “wrong” 65 times in 5 minutes and still be a rock star. Let’s see how that’s going to work for me.

One thing I know about people is that they just love geography.

You know, all those fancy maps and plans.

It is probably the reason why, when I dive into the “security” part of StackExchange, I frequently notice one common suggestion about cyberattacks prevention.

Say we, as a company, don’t expect Spanish Inquisition, errr… Chinese customers. Why don’t we just deny access to their IP addresses? We’re not Facebook, after all, and our services are available in limited regions only. Even Facebook is not available in China, why do we care?

Outside the IT world, such technique is sometimes referred to as redlining. It’s synonymous to literally drawing a red line on top of your favorite map and then stating that you don’t offer services outside of the resulting shape because you believe it’s not safe or cost effective for you to do so.

So we can do the same with IP addresses, right? Any IP address belongs to the country; therefore there’s an official database, supported by both IETF and RIPE, providing country allocation of every IP address.

Wrong!

If we stick just to the technical aspects, for now, the fact is that geodatabases are commercial products of commercial entities, that are gathering data in obscure ways. They might be used for statistical or research purposes, though providing a production service on the top of those is plain stupid due to countless reasons.

In the world of IPv4, due to the address space exhaustion, IP addresses get leased, sold and bought very frequently. They migrate across regions. They, surprise, are not bound to any single region and may be announced from numerous regions at the same time, in which case a geodatabase would give some random data. Also, RIPE and APNIC databases are not significantly more reliable due to the same reasons.

As a side note, your copyright law enforcement just got way more complicated.

Well, some of the above, but not all of them might be better with IPv6. However, as we speak of DDoS attacks, a true IPv6 DDoS era is something yet to come and, as we gain experience, there might be different issues around, so it’s a bit early to speak about it.

Though, speaking of DDoS, what if we know for sure that the remote party is doing some malicious stuff?

Here’s our setup: 40G of traffic, apparently DNS traffic since it comes from port 53.

As we know, such pattern is typical for DNS amplification attacks. Amplification attack uses a vulnerable server to, you know, amplify traffic, so the source IP address in such packet is the IP address of a vulnerable server.

What if we use whatever technology we have to deny access to those vulnerable servers? After all, let them finally patch all those DNS reflectors, so that they won’t be a threat, right?

Wrong!

This is a true story. The events depicted took place in Minnesota in 2014. At the request of the survivors, the names have been changed. Out of respect for the dead, the rest has been told exactly as it occurred.

So a company got those Gs of DNS traffic and decided to handle it with blocklists.

After two hours, attacked noticed that somehow and immediately changed the attack pattern. Their ability to run amplification attacks before was based on their ability to generate packets with spoofed IP sources, so that was that they did again but differently.

They have started to flood the victim directly, with source UDP port 53 and fake source IP addresses from the whole IPv4 address pool. The NetFlow script used by the company decided there still was an amplification attack and banned those sources.

As you may enumerate the whole IPv4 address space in hours, as you might guess, it didn’t take too long for the network equipment to run out of memory and shut down completely.

To increase damage, the attacker has started with some of the end-user access prefixes of ISPs most popular in the country, so the website access was unavailable long before the complete denial of service.

So here’s our lesson: don’t populate blocklists automatically if you haven’t verified the source IP address! Especially when dealing with amplification/reflection attacks. They might be not what they seem to be.

Afterward, one question arises.

What if we verify at least the fact that there actually is an amplifier on the remote side? Let’s scan the Internet and collect the IP addresses of potential amplifiers. Then if we see those in the packet sources, we block them, because in any case, they are amplifiers anyway, right?

Guess what? Wrong!

Again, there are numerous reasons why you should never do that. There are again millions of potential amplifiers across the Internet, and you’ll be easily tricked into blocking an excessive amount of IP addresses.

The funny thing here is that there is also a potential for only a false positive, but a false negative, due to, guess what?

Network redlining on the other side!

Because people hate scanners. They block them because their shiny IDS equipment marks those as a direct threat. They block them differently, and an attacker could use some of the amplifiers you won’t have access to. Nobody’s going to ask you preliminarily if your scanner is soft and warm. IDS doesn’t have the concept of a good scan.

Here are our key points:

• Do not do blocklisting before you are sure the remote side is not a fake;
• Do not apply blocklists where it is not necessary or appropriate;
• Finally, stop breaking the Internet in ways it wasn’t supposed to break!

Remember: a complicated solution is usually better than a simple one because simple solutions have complicated consequences.