Three DDoS Flood Attacks
by Scott RegisterCheck out our Rethink DDoS Testing Methodology for more information or to learn how to replicate a variety of DDoS and botnet attacks.
In our previous blog post on Distributed Denial of Service (DDoS) attacks, we’ve talked about HTTP application-layer attacks. For this post, we'll focus on some less subtle, but more common attacks: SYN Flood, Connection Flood, and ICMP Flood. Even though they've been around for a long time, they can still be very difficult to defend against, and the only way to truly know you are prepared is to create the conditions.
Exercise 1: SYN Flood
First, some context: most TCP connections start with a 3-way handshake. The client sends the server a TCP packet with the SYN bit set, the server answers with a packet with both SYN and ACK bits set, and finally the client responds with an ACK packet. Because the TCP connection is stateful, the server must remember the state of the each open connection beginning with the initial SYN packet. And that’s where the opening for attack occurs: forcing the server to keep memory open for a large number of malicious connections can exhaust its resources and block legitimate connections. This attack is even more dangerous because, unlike application-based attacks, it requires no exchange of packets between attacker and server—meaning that the attacking clients can use spoofed IP addresses.
Setting this up is pretty easy; I'll create a new scenario with Session Sender and use the "1Gbps SYN Flood" preset.
This scenario uses only the Session Ramp Up phase (which is preset to 60 seconds, but can be changed) because we don't want the spoofed IP 3-way handshakes to actually complete. The Session Ramp Up behavior is set to “SYN Only”, meaning the attacking clients won't respond to any SYN-ACKs they receive—so the impact on the server side is the same as an attack from spoofed IPs.
Hooking up your target device between ports, or using the External Interface option, will let you validate your own inline device(s) or server against a spoofed-IP SYN flood attack.
Exercise 2: Connection Flood
Some DDoS mitigation devices are pretty smart about blocking attacks; they'll do things like proxying the 3-way handshake, returning a SYN-ACK to the client and waiting for the final ACK before relaying the connection to the server. But botnets offer an easy way for attackers to mount distributed network flood attacks from legitimate IPs, which we'll model next.
The only changes we'll need to make to our previous test are to the steady-state behavior and timing. I'll change my scenario to have a 5-second ramp-up followed by 55 seconds of steady-state with the behavior set to “Hold Sessions Open.” This allows the 3-way handshake to complete, as it would when an attack is coming from valid IP addresses.
A quick glance at the Real Time Stats will verify when we hit our target, which can be up to 15 million concurrent sessions per blade.
With only a few minor changes, I’ve adapted my scenario to generate a real DDoS connection flood attack from legitimate IP addresses, which leaves connections open.
If I want to be even more sinister, I can direct my Connection Flood against a particular port, such as 80 or 443.
I could also change my Network Neighborhood settings to place my attack targets at a specific IP or range of IPs.
Exercise 3: ICMP Flood
In our final example, we’ll leverage a new way in the BreakingPoint Firmware Release 2.1 to generate a flood of ICMP Echo Request (“ping”) packets. These packets can come from legitimate or spoofed IP addresses, and are frequently used to overwhelm a server or network segment with sheer packet volume as each request generates an immediate response from the target.
The new way of doing this in the 2.1 firmware is the capability to quickly configure and generate attacks such as ICMP floods (and TCP SYN floods) directly from the Routing Robot component for extremely high performance.
I’ll also reconfigure my Network Neighborhood to simulate a small network of 32 hosts to serve as my victim network:
When I generate this attack, I see that I’m able to easily saturate the full capacity of the network with transmitted Ping packets:
With just a few clicks, I’ve generated a very realistic, intense burst of ICMP Echo Requests coming from a large range of source IP addresses which could be real or spoofed. This flood of packets is directed at a small pool of addresses that represent a realistic server farm. You can easily use this scenario to see how your servers or DDoS mitigation system withstand common, lower-layer DDoS attacks.
Stay tuned for future DDoS posts. Meanwhile, please feel free to share your own DDoS findings in the comment threads here or for the earlier posts on HTTP DDoS Flood Simulation and using server cache to hack retail shopping carts.
blog comments powered by Disqus
