Profiling a DDoS Attack: Direct Connect, Redirected
by Chuck McAuleyDuring a recent customer engagement, we were tasked with creating a test scenario that successfully created a Direct Connect Redirected DDoS attack. Direct Connect is a peer-to-peer protocol that has many of the features of IRC but also includes Napster-style file sharing. Since I hadn’t had any exposure to this protocol before, I wanted to share my experience in analyzing it and then building a test to simulate a DDoS attack that uses it.
If you’re responsible for defending your network from DoS and DDoS, you can follow a similar approach with the attacks of your choice. The tests you create will help you determine how your infrastructure devices—firewalls, server load balancers, servers, and so on—will respond to these attacks and whether your DoS mitigation efforts are working as they should.
How a Direct Connect DDoS Attack Works
Direct Connect is a system similar to Napster for file sharing, in which all the clients connect to a central server, which is referred to in this system as a hub. The most popular client for Direct Connect is an open source one called DC++. You have a variety of choices for hub server software; the one I chose for my lab was verlihub. Users connect via clients like DC++ to these hubs and then have a variety of chat rooms available. To perform file sharing, you can send a search command to a hub, which in turn sends the search off to all the clients connected and then returns the results back to the initial client. You can also use file sharing by browsing a specific user’s shared directory and downloading specific files.
The Direct Connect protocol has the unique ability to redirect all users to another hub. An administrator uses the command !protoall_redir [IP] to redirect all hub users to the new IP address. This feature was probably created either to relieve a host from too many clients (i.e., too much load) or to alert the clients that the authorities are closing in. But this feature can also be used to make file-sharing clients part of an unwitting botnet by redirecting them to another unrelated server such as a targeted Web server. A hacker who has broken into a hub via exploit, password guessing, or some other means can execute the redirect command to start the DDoS attack.
Analyzing DDoS Attack Traffic
Now we have the information we need to start our analysis. Set up the following:
- A hub server running verlihub.
- Two clients, one acting as the file sharing guest (running DC++) and another as the administrator.
- A victim Web server.
Since we are interested in the traffic that the victim Web server sees at the end of all this exchange, we run Wireshark there to capture the traffic and use that as the basis for building our simulation.
We issue a simple tcpdump command from the command line on the victim Web server:
tcpdump –i vr0 –n –s 1500 –w /tmp/dc_attack.pcap port 80
Next, we connect our file-sharing user playing the role of unwitting attacker:
We then issue the command to move over to the new server—the victim Web server that we are DDoSing—from the admin account:
We can see the user getting redirected:
Now we pull off the packet capture from the server to see what the impact was from a network level. This is the meat of what we are getting at: we need to see what the overall impact is on the server, what kind of messages are being sent, and any patterns we need to be aware of.
This traffic is simple enough to reproduce. The client connects a socket to the server and then apparently waits for a message to come from the server first. This causes an awkward situation when you stick these two different systems together, because an HTTP server expects the client to talk first. The net effect, traffic-wise, of this DDoS attack is the same as a botnet-driven “stateful” connect() flood, where the bots complete the three-way handshake with the server, putting the server into the ESTABLISHED state. This is as opposed to another popular DDoS attack known as a SYN flood, where the server is bombarded with SYN packets from random crafted IP addresses, putting the server into SYN_RECV state.
Re-Creating a DDoS Attack with the BreakingPoint CTM
The next step is to re-create this attack through our BreakingPoint user interface. This kind of attack is rather straightforward. (Remember, we are interested only in the effect on the server from this attack, not on how the botnet command-and-control server operates.)
First we create a new test and add a Session Sender component, which gives us direct control over Layer 4 traffic and is an ideal approach for this type of DDoS simulation.
We set the number of payload (data) packets per session to 0. We also want our ramp-up profile to be set to Full Open, which will complete the three-way handshake but not close or run data traffic. For the steady-state period, we set the socket behavior to Hold Open. Then we set the ramp-down to 0 seconds so sockets are not closed at all.
The last step for test setup is to specify the maximum number of connections and the connections per second. For a test like this, these terms can be interchangeable with “zombie” clients and attacks per second, respectively. In this case, I set it to 10 million zombies and 300,000 attacks per second.
Now we add in some of the normal background traffic you would expect to see on the network. In this case, I started with our standard Enterprise Application mix, which includes several of the most common application protocols found in enterprise networks, and then added extra BitTorrent traffic to represent benign background file sharing.
Finally, I set a delayed start of 30 seconds on the Session Sender component. This allows the background traffic from the Application Simulator to get up and running before launching the attack traffic.
Now we run the test. Looking at the graph in the screenshot below, you see the spike in TCP connections as the attack traffic kicks in at 30 seconds. The boxes on the right of the screenshot show the huge number of connections that have been established.
Here is another graph from our summary statistics showing the concurrent flows spiking:
And finally, here’s a graph showing the instant increase in sessions per second from the time the DDoS started until the test hits the maximum number of sessions (10 million) that we configured earlier:
This process is easy to set up and run, and the data you get back will show the dramatic effects of an attack like this on network traffic. This is information you can use to fine-tune your network so it will continue to perform in the face of these DDoS attacks.
Related Content:
- How-To Guide: DDoS Attack Simulation
- Test Methodology: How to Test DDoS Mitigation
- SIP INVITE Flood: Testing an Asterisk VoIP Server against a DDoS Attack
