by Rik Farrow <rik@spirit.com>
It has been over a year since the infamous Distributed Denial of Service attacks (DDoS) blocked access to several prominent e-commerce and Web sites. These attacks caused quite a furor, which quickly diminished as the media and public promptly forgot all about the week the "Internet stopped working". But DDoS lives on.
Since the first DDoS tool was captured and analyzed in the fall of 1999, eight new tools have been discovered. These tools build on the feature sets of older tools, adding new attacks, communication techniques, and 'ease-of'use' features for the attackers. And these tools have been used since February 2000--but not on targets as prominent as CNN or eBay. [Note: After this article was written, Microsoft's DNS servers were shutdown for a day at the end of January 2001 by DDoS. Rik]
How have these tools evolved over the past year? And have defenses against them gotten any better? The answers to these questions are pretty grim in tone. But there are things that you can still do to better defend your networks, and to avoid being part of the problem.
The advent of DDoS marked an escalation in IRC wars. IRC, Internet Relay Chat, relies on networks of linked servers, and presents to IRC users a set of channels, chat rooms, that they can join and use to exchange ideas, pictures, sounds, and programs. The ruler of each channel is called the channel operator, and is assigned by default to the creator of a channel, to someone who gets passed channel operator privileges, or simply by asking for it (if no one currently is the channel operator). For example, if the current channel operator leaves the channel without passing on the mantle of control, someone else may assume take control. Or, if a channel operator choses to share privileges with another user, that user can then kick the first operator out of the channel.
IRC has many uses, but the one that has bearing on DDoS are channels devoted to hacking. Turf wars over control of these channels erupt over time, as different users struggle to become the channel operator, so they can kick out people they don't like and allow their friends into the channel. One easy way to take over a channel (for the not-so-polite) is to launch a denial of service attack on the user's computer or network connection. If a user becomes inactive, he or she is dropped from the channel, and a DoS attack against that user that crashes the computer being used achieves that goal almost instantly. A DoS attack that floods the user's network connection will have a similar affect, if the flooding prevents packets from reaching the IRC server to keep alive the victim's connection.
One technique that has been used is for a group of IRC users to communicate over one channel to coordinate an attack against a channel operator on another channel. By coordinating a flood of packets from several sources, it is relatively easy to knock someone off the 'net.
DDoS is the answer for the attacker who cannot round up enough cohorts to flood someone effectively. DDoS tools allow a single attacker to multiply the effectiveness of the attack manyfold, because a single attacker, working through a handler, controls tens or even hundreds of agents, which can all be used to launch floods against the victim. In this sense, DDoS was simply an escalation in IRC channel wars, and not initially targeted at e-commerce sites.
The earliest DDoS tools were pretty primitive. Trinoo, the tool that overwhelmed the pair of DS3's connecting the University of Minnesota to the Internet for three days, did nothing more than send a flood of UDP packets. Trinoo did not attempt to spoof source addresses, making tracing of agents easier. Trinoo agents were so buggy that the installation script included commands to restart the agent once per minute.
The next round of tools, including TFN, TFN2k, and stacheldraht, had several methods for flooding, and better control mechanisms. TFN included UDP floods, ICMP floods, and SYN floods. TFN2k added encrypted, one-way control communication, so that someone who discovered an agent could not easily trace it back to the handler. Stachdraht evolved from TFN, had a Blowfish-algorithm encrypted control channel, and the ability to be remotely updated, something that also appeared in TFN2k.
Stacheldraht has appeared in several variants, with the latest version (v1.666) including as new attacks floods of TCP packets with no flags set or just the ACK flag set. Mstream is a simple TCP ACK flooding tool that as a side effect can overwhelm the tables used in fast routing routines in some routers. Omega adds IGMP floods to the list of packet types that can be sent.
Shaft (as well as Omega) adds the ability to return statistics from agents to the handler. Apparently this represents a desire by the authors of these tools to keep track of the effectiveness of the attacks they are launching. Statistics include the number of packets sent from each agent, providing the attacker with the volume of packets sent during an attack, perhaps also alerting the attacker when agents are discovered and taken off line.
All of these tools can spoof source addresses. When flooding a target, getting back responses is not only unnecessary, but actually a bad thing, as the responses flood the agents' networks. Also, when source addresses are not spoofed, the addresses found in the floods lead back to the agents. So, the agents spoof (lie about) their source addresses. Some tools do this better than others. For example, TFN2k handlers can send a command to test source address spoofing by sending a test packet, with spoofed source address, to the handler. If the test packet isn't received, the agent is told to spoof only the lower eight bits of the network address, something which will not be blocked by egress filtering (more on that later).
Tools like Mstream, Omega, and Shaft don't do very well at spoofing, as they use random 32 bit values for IP addresses, and produce lots of unusual addresses (first byte of 0, 127, or greater than 239).
There are really two ways of defending against DDoS attacks. The first thing to address is to assure that your systems will not be used as hosts for agents or handlers. During the attacks against University of Minnesota, thousands of systems were used to run the agent software. And many thousands more systems have been used in other attacks, and still more have had agents installed but not yet used.
Just as the agents are used in mass attacks, the systems used as hosts were victims of mass, automated attacks themselves. Based on scripts found on compromised hosts by Dave Dittrich and others (see Resources), hosts for agents or handlers were discovered first by probing huge address spaces looking for systems with a service listening at a specific port address. Next, a different system than one doing the scanning launches a specific attack against each potential system with that service running, and any server that is vulnerable to the attack is passed a program or script to execute. This program or script then downloads, installs, and launches the agent software. Once the agent is running, a handler can send a command to the agent to download a new copy of the agent software.
It is this last feature that potentially makes DDoS agents so dangerous. As new techniques and 'better' agent software becomes availble, agents can be updated. While most of the attacks we have seen so far simply involve floods of packets, the potential is there for resource depletion attacks. A CERT advisory, as well as a vendor bulletin from BindView, suggests that attacks that do not rely on floods, but instead use a much smaller barrage of packets to simulate the opening of connections and sending of requests, can be used to either slow down or crash servers.
Agents can be discovered before they attack by either using ID tools to listen for commands from handlers to agents, or to use a tool like RID that can simulate handler commands to agents, detecting agents when they respond.
Agents can be discovered while they are flooding by using ID systems, networking monitoring tools like Argus, or simply by noticing that your network or Internet connection has apparently failed. A single agent with a moderately fast processor and good network interface card can saturate your own network while flooding. But, if you are not prepared to sniff your own network, or have a tool monitoring your network, you will not be able to uncover the attacker in your midst. Most DDoS agents are designed to spew packets for no more than several minutes at a time, so your network might mysteriously recover from its temporary 'outage' all by itself, only to go down again hours later.
Another important defensive technique is to filter packets leaving your network to prevent source address spoofing. Egress filtering (RFC 2267) prevents your network from being the source of spoofed packets, which also makes it easier for you to uncover the source of any internal agents.
When you are the target of a flood, your options are fewer. The periods of flooding might be short and sporadic, or last for days. Tracking packets back to their source is problematic, as most DDoS tools generate packets with spoofed source addresses. Tracking back packets with spoofed source addresses is possible, but does require cooperation between the various companies providing network access. One trick involves creating access lists on routers that permit all traffic through a specific interface but log the source interface for each packet. This technique makes it possible to backtrack flows of spoofed packets from one interface to another, and eventually back to the source network.
Another router-based defense is to filter packets. This only works when it is possible to separate real traffic from floods, something that is easier if source addresses are not spoofed, or the tool sends packets to random port addresses (which is done by several of the tools). If your site is being flooded with ICMP packets, rate limiting, a method where the router drops all the packets of a particular protocol type above a certain percentage, can limit the effects of some attacks.
Back in February 2000, many of the sites under attack didn't know it. A common response when you are the victim of a DoS attack is to check for failed servers or network hardware. In the February attacks, some sites thought that their Web servers had crashed, or the Internet connection was down. Without some tool that can monitor network traffic and provide at least a rough profile of the type of traffic seen, it is not possible to know for certain if you are the victim of a flood, or simply suffering a brief moment of fame, leading to a surge of people attempting to reach your Web site.
In all these cases, the key is to be prepared. Use firewalls to prevent people from scanning your networks for potential hosts for agents. Install patches so that systems are not vulnerable to old, automated attacks. Use egress filtering to stop source address spoofing. Setup monitoring so you can detect attacks when they occur. Experiment with packet filtering and rate limiting commands in routers, so if a flood does occur, you are ready to do something about it. Once you are under attack, it is too late for reading manuals. Be prepared.
Dave Dittrich of the University of Washington has a wealth of material and links on DDoS: http://staff.washington.edu/dittrich/misc/ddos/
RFC 2267, which explains egress filtering: http://www.landfield.com/rfcs/rfc2267.html
CERT Advisory regarding resource depletion: http://www.cert.org/advisories/CA-2000-21.html
Source for Argus, a free network monitoring tool: ftp://ftp.sei.cmu.edu/pub/argus/
BindView advisory about resource depletion attacks: http://razor.bindview.com/publish/advisories/adv_NAPTHA.html