Back in 2013, volumetric denial of service (DoS) attacks targeting networks were all the rage. Alleged hacktivists effectively used the tactic first against Fortune-class banks, largely knocking down major banking brands for days at a time. But these big companies adapted quickly and got proficient at defending themselves, so attackers then bifurcated their attacks. On one hand they went after softer targets like public entities (the UN, et al) and smaller financial institutions. They also used new tactics to take on content delivery networks like CloudFlare with multi-hundred-gigabyte attacks, just because they could. In our Defending Against Denial of Service Attacks research we described network-based DoS attacks: Network-based attacks overwhelm the network equipment and/or totally consume network capacity by throwing everything including the kitchen sink at a site – this interferes with legitimate traffic reaching the site. This volumetric type of attack is what most folks consider Denial of Service, and it realistically requires blasting away from many devices, so current attacks are called Distributed Denial of Service (DDoS). If your adversary has enough firepower it is very hard to defend against these attacks, and you will quickly be reminded that though bandwidth may be plentiful, it certainly isn’t free. Application-based attacks are different – they target weaknesses in web application components to consume all the resources of a web, application, or database server to effectively disable it. These attacks can target either vulnerabilities or ‘features’ of an application stack to overwhelm servers and prevent legitimate traffic from accessing web pages or completing transactions. The motivation for these attacks hasn’t changed much. Attackers tend to be either organized crime factions stealing money via ransom attacks, or hacktivists trying to make a point. We do see a bit of competitor malfeasance and Distributed DoS (DDoS) to hide exfiltration activities, but those don’t seem to be primary use cases any more. Regardless of motivation, attackers now have faster networks, bigger botnets, and increasingly effective tactics to magnify the impact of DDoS attacks, forcing most organizations to devote attention to implementing plans to mitigate these attack. After digging deeper into the application side of denial of service in Defending Against Application Denial of Service Attacks, we now turn our attention to the network side of the house. We are pleased to start this new series, entitled Defending Against Network Distributed Denial of Service Attacks. As with all our public research, we will build the series using our Totally Transparent Research model. Before we get going we would like to thank A10 Networks, as they have agreed to potentially license this research at the end of the project. It’s Getting Easier If anything, it is getting easier to launch large-scale network-based DDoS attacks. There are a few main reasons: Bot availability: It’s not like fewer devices are being compromised. Fairly sophisticated malware kits are available to make it even easier to compromise devices. As a result there seem to be millions of (predominately consumer) devices compromised daily, adding to the armies which can be brought to bear in DoS attacks. Faster consumer Internet: With a bandwidth renaissance happening around the world, network speeds into homes and small offices continue to climb. This enables consumer bots to blast targets with growing bandwidth, and this trend will continue as networks get faster. Cloud servers: It is uncommon to see 50mbps sustained coming from a consumer device. But that is quite possible at the server level. Combine this with the fact that cloud servers (and management consoles) are Internet-facing, and attackers can now use compromised cloud servers to blast DDoS targets as well. This kind of activity is harder to detect because these servers should be pumping out more traffic. Magnification: Finally, attackers are getting better at magnifying the impact of their attacks, manipulating protocols like DNS and ICMP which can provide order-of-magnitude magnification of traffic hitting the target site. This makes far better use of attacker resources, allowing them to use each bot sporadically and with more lightly (in terms of bandwidth) to better hide from detection. Limitations of Current Defenses Before we dive into specifics of how these attacks work we need to remind everyone why existing network and security devices aren’t particularly well-suited to DDoS attacks. It’s not due to core throughput – we see service provider network firewalls processing upwards of 500gbps of traffic, and they are getting faster rapidly. But the devices aren’t architected to deal with floods of legitimate traffic from thousands of devices. Even with NGFW capabilities providing visibility into web and other application traffic; dealing with millions of active connection requests can exhaust link, session, and application handling capacity on security devices, regardless of their maximum possible throughput. IPS devices are in the same boat, except that their job is harder because they are actively looking for attacks and profiling activity to find malicious patterns. So they are far more compute-intensive, and have an even harder time keeping pace with DDoS bandwidth. In fact many attackers target firewalls and IPS devices with DDoS attacks, knowing the devices typically fail closed, rendering the target network inoperable. You should certainly look to service providers to help deal with attacks, first by over-provisioning your networks. This is a common tactic for networking folks: throw more bandwidth at the problem. Unfortunately you probably can’t compete with a botmaster leveraging the aggregate bandwidth of all their compromised hosts. And it gets expensive to provision enough unused bandwidth to deal with a DDoS spike in traffic. You can also look at CDNs (Content Delivery Networks) and/or DoS scrubbing service. Unfortunately CDN offerings may not offer full coverage of your entire network and are increasingly DDoS targets themselves. Scrubbing centers can be expensive, and still involve downtime as you shift traffic routes to the scrubbing center. Finally, any scrubbing approach is inherently reactive – you are likely to already be down by the time you learn you have a problem. Further complicating things is the fundamental challenge of simply detecting the onset of a DDoS attack. How can you tell the difference between a temporary spike in traffic and a full-on blitzkrieg on your
