An overview of Reflective Denial of Service attacks.
By: n3w7yp3


Okay, so you may be asking, "What the heck is a Reflective Denial of Service (DrDoS) attack?". Well, quite simply put, its a DDoS with a twist. As I'm sure you all know, to preform a DDoS such as a SYN flood, the attacker is usually required to have control over a large group of zombies (usually called a botnet) to launch the flood from. However, in a DrDoS attack, the attacker does not need to be in control.

So, how does it work?

Well, first the attacker finds large high bandwidth servers. While many script kiddies do this with thousands of `nmap -iR' scans, there are actually intelligent ways to do this. If you for whatever reason do feel the need to DrDoS something, you should pick a group of high powered servers close (in network terms) to the target. Try and pick ones with in one or two hops from the target, or in the same AS (although AS to IP ranges can bq quite big).

Once the attacker has found an appropriate group of servers, the mayhem begins. They have several options open to them at this point:

1. A TCP SYN attack (floods the targetwith SYN/ACKs, chewing up thier bandwidth).

2. ICMP storms (bandwidth consumption, not likley to work).

3. Flooding the target with DNS replies.

We'll breifly look over these three attacks.

1: The TCP SYN attack (aka: A SYN/ACK flood).

I'm sure that everyone here knows the TCP handshake. Its that famous sequence of SYN, SYN/ACK, ACK. I'm also equally certain that many people know how a SYN flood is preformed (blasting hte target with million's of SYN packets, all from spoofed source IPs). However, unless you have a large botnet, you won't be able to take down much with this attack. Consider the bandwidth of a typical server versus the bandwidth of a typical script kiddie packet box. not much comparison, is there? Sure, you may say that with a botnet, any server is toast, but inverse SYN cookies take care of that (these are beyond the scope of this article, to find out more about them, read the Paketto Kiertsu documentation). So, whats a packet kiddie to do? Why not kill the targets bandwidth? Thats exactly what the SYN/ACK flood does. The basic premis is quite simple:

1. Send a SYN with a spoofed source IP to a reflector server
2. The server will reply with a SYN/ACK, which goes to the target.

The packets should have the following "structure":

1. The source IP should be that of the target.
2. The source port is the port that you want to attack on the target.
3. The destination host is the reflector server.
4. The destination port must be open on the target.

This attack is ridiciously easy to implement (I coded a DrDoS script in Perl in about 5 minuets, with a nice CLI UI), and can be done even from a home broadband connection. You need an OS that supports raw sockets. Thats all.

2: ICMP storms.

These were popular back in the early days of DoS attacks. You'd send the target an ICMP packet from 127.0.0.1, and watch as the host DoSed itself off the Internet. The DrDoS version is similar. You send spoofed packets (similar to the packets described above, in the SYN/ACK flood section) to the reflector servers. Since you can (usually) send the packets faster then the target can reply, you'll eventually consume all the bandwidth. However, this is not likley to work, but it does open the door for more interesting ICMP attacks.

3: DNS reply floods.

These are a relativley new attack. First, the attacker generates a list of DNS servers (as before, big high bandiwdth ones are good, just do multiple lookups on domains like google.com, yahoo.com, etc), then they proceed to spoof DNS requests from the target. The packets are something like:

Destination IP: The DNS server.
Source IP: The target.
Destination Port: UDP 53
Soure port: any high port, it doesn't matter (unless there is a filtering device between you and the target).

At this point, the target is washed away with loads of DNS replies.

4: Conclusion.

There is nothing really new or cool about DrDoS. They're a class of attack that should have been predicted long ago, but were not. They're fairly hard to prevent, and the only way to stop them is to block traffic from the reflector servers. Imagine if the attacker did a SYN/ACK flood, using the core BGP peers as the reflectors. The admins on the vitcim network would be forced to drop the packets, and thus possibly miss out on important BGP updates. The same applies for the DNS reply floods.

5: Links.

http://grc.com/dos/drdos.htm.

6: Disclaimer:

All the information provided was strictly for informational purposes only. The author cannot, and will not be held responsible for any damages that result from attempting the techniques contained herein. Furthermore, the author neither endorses nor supports Denial of Service Attacks. In short, they're lame. Don't use them.