Best Current Practice No. 38: Defy the DDoS
DDoS attacks are exploding around the globe, with 73 percent of organizations admitting to having suffered a DDoS attack during the year according to the latest Neustar report, and the fallout is expensive. It is estimated that one DDoS attack could cost a company more than $1.6 million.
Those attacks have been escalating because cybercriminals have now found the path to coordinating Internet-of-Things devices to increase the impact of the attack. Preparing to battle these DDoS attacks might be as simple as employing Best Current Practice No. 38, put forth by the Internet Engineering Taskforce (IETF).
What is BCP38? It basically says that you should not allow packets to come from your network that don’t originate from your assigned address space. It is also known as Source Address Validation. This prevents someone from lying about who they are (spoofing) when sending data over the Internet. By pretending to have a different IP address, return traffic goes to the spoofed address, not back to the hacker. It’s like wearing a virtual hacker hoodie! This makes it exceedingly easy for people to send a lot of traffic somewhere without anyone knowing where it came from.
Surprisingly, source address validation isn’t something that service provider network operators concern themselves with. With so many service providers allowing this traffic to pass, it is now impossible to get service providers to implement Source Address Validation without laws being imposed. It may be that it’s more lucrative to forward traffic to the destination it is headed for; or the answer might be that operators want to keep router configurations as simple as possible, or a combination of both.
All the reasons for allowing spoofed traffic is one issue, but I’m sure service provider network operators did not intend it to be used by the dark corners of the 4chan nation; however, the reality is that that’s exactly what happens in most cases.
For cybercriminals using botnets, spoofing becomes a powerful tool that allows them to launch attacks without their bots being detected. Furthermore, cybercriminals can be even more disruptive by sending DNS requests that have responses that are exponentially larger than the original packet. This is called an amplification attack. These types of attacks are generally hundreds of gigabits per second.
Operators that provide service directly to consumers are the ideal place to implement BCP38. It’s unrealistic to expect consumers to tackle this problem. The place to address this problem is where the data aggregates at the service provider. These service provider operators can literally prevent billions of dollars in damage just by using this best practice. Additionally, DDoS mitigation for non-spoofed traffic wouldn’t be as expensive.
An easier way to determine if customers are spoofing IP addresses is just by using plain old NetFlow. By monitoring for things like RFC1918 addresses and reverse path violations on the external network, network operators can help customers figure out if they are infected or if they are participating in a botnet. Admins can then remove the infection from their computers, resulting in huge bandwidth savings.
Spoofing traffic certainly isn’t the only vector used by DDoS attackers. The recent Mirai layer seven attack against Brian Krebs was unprecedented for its kind. Shifting to infecting IOT devices shows how adaptable these people can be when faced with effective DDoS mitigation. Fortunately, network security analysts can leverage flow data generated by existing investments to keep on top of these ever-changing methodologies.
About the Author
Mike Krygeris is a senior field engineer for Plixer International. He is an expert at all things Flexible NetFlow/IPFIX and has configured Cisco routers and firewalls to export everything from round trip time and URLs to actual packet captures. Having an aptitude for unwanted network behaviors, Mike has developed many threat detection algorithms and helped to advise network vendors on flow export strategies. Mike has trained thousands worldwide and implemented network management and security solutions for hundreds of companies. He began his 20-year career at Cabletron Systems as an engineer before joining the Plixer team.
Edited by Alicia Young