Distributed Denial of Service Defense Tactics

Abstract

This paper details some practical strategies that can be used by system administrators to help protect themselves from distributed denial of service attacks as well as protect themselves from becoming unwitting attack nodes against other companies.

Audience

The intended audience of this paper is system administrators, IS managers, and other technical and semi-technical people with an interest in learning more about defending against distributed attacks.

History

Distributed denial of service (DDoS) attacks have recently become mainstream, although they have actually been around for a while. The first rumoured attacks occurred in Australia and Europe, but the first fairly well documented attack occurred on August 17, 1999 against the University of Minnesota. Other U.S. locations followed, and as attacks were traced to the attacking machines, copies of the attacking software were discovered. Once the analysis of the software had begun by security researchers [1], copies of the source code used for DDoS began to appear along with detection methods [2]. The DDoS tools are Trinoo, TFN, TFN2K, and Stacheldraht.

A Quick Review of the Attack Model

                    *----------*
                    |          |
                    | Attacker |
                    |          |
                    *----------*
                          |
                          |
                    *----------*
                    |          |
                    |  Client  |
                    |          |
                    *----------*
                          |
                 (commands to nodes)
                          |
      *------------*------*------*------------*
      |            |             |            |
      |            |             |            |
      v            v             v            v
 *----------* *----------* *----------* *----------*
 |          | |          | |          | |          |
 |   Node   | |   Node   | |   Node   | |   Node   | 
 |          | |          | |          | |          | 
 *----------* *----------* *----------* *----------*
          \        \             /        /
           \        \           /        /
            \        \         /        /
          (any number of floods or attacks)
              \        \     /        /
               \        \   /        /
                \        \ /        /
                 V        V        V
              *-----------------------*
              |                       |
              |         Victim        |
              |                       |
              *-----------------------*

The attacker, sitting at home, uses client software to send commands to the nodes. The nodes in turn send floods of packets, or malformed packets to crash systems (or both) toward the victim.

Typically, the client software the attacker is using to direct these attacks is not on his/her home system, but sitting on another system (usually a compromised host several hops from the attacker's home system to help prevent authorities from tracking down the attacker). From here, a set of commands are currently sent using ICMP packets, with the data possibly encrypted. TFN2K advances this "stealth" mode of communication by allowing for remote one-way communication, decoy packets, and fairly sophisticated encryption.

The nodes themselves can number in the thousands. With one node, thousands of packets can be sent per minute, flooding the target. With a hundred nodes, millions of packets can be sent per minute, using up all of the available bandwidth a victim might have. With a thousand geographically dispersed nodes, *billions* of packets could certainly cripple virtually any victim, including victims with multiple ISPs, redundant Internet connections, server farms, and high-bandwidth routers.

Weaknesses in the Attack Model

By finding weaknesses in the attack model itself, one can possibly disrupt and thwart the attacks before they occur. A technical paper I wrote on January 21, 2000 [3] focused heavily on the attack model itself, and should be used as a technical reference. To outline some of the weaknesses, let's look at each component of the model.

Attacker

The biggest weakness for the attacker is two critical phases -- checking his/her work, and communications with the client. It is entirely possible that the attacker will do a DNS lookup of the address of the target, possibly ping or try to access the site via a web browser from the home machine right before or right after the attack starts [4]. These accesses may appear in log files at the target location.

If the client software is running on the home machine, it is possible that the nodes running the attack software will have telltale signs of the connectivity, such as the home machine's IP address viewable in a netstat listing.

The Client

Similar weaknesses exist for the client as to the attacker. If the attacker is running the client software on a remote machine, it is probable that the attacker may not have legitimate access to that machine, but may have left telltale signs of connectivity from the home machine.

The Nodes

The nodes, which could number in the thousands, are obviously housing and running the attack software that launches the denial of service. There exists software to detect if your system is running the attack software [5]. software locally [5] and remotely [8]. Commercial scanners such as HackerShield [9], and others have, or will shortly have checks for these. Ensuring that your system is secured with all of the known holes patched will help prevent a compromise that could turn you into a very bad Internet neighbor.

Communication Links

The communications links can be disrupted several different ways. For starters, you could try to tell the flood to stop, assuming the default settings have not been changed [6]. Also, to prevent communication channels from crossing into your network, fairly tight firewall rules should be in place to prevent the client from directing the nodes [3].

Floods and Attacks

By ensuring that your network does not send forged IP packets you could also set up your firewall rules to limit outbound packets to only the traffic you should be sending. This way if a distributed attack is being launched by your own computers, you could prevent the bad IP packets with forged source addresses from passing out your network [3],[7].

Most modern firewalls and IDSs are capable of at least identifying an attack against your site. Make sure you have configured them to detect and (in the case of firewalls) block such attacks, both inbound and outbound.

Defending Against Attacks

There are a few things you can do to help prevent becoming buried under a mountain of packets. First off, you need to be able to determine the source address of the rogue packets that are coming in. To do this you need to have *physical* access to a device or devices on the outer perimeter of your network. During the flood of packets, you will probably not be able to communicate with outer perimeter devices, so make sure you can get to the device.

This device can be a firewall, router, intrusion detection system, or network monitoring device (such as a sniffer) that will allow you to view the source and destination IP addresses of packets flying by. Once you have determined the source addresses, I recommend the following four steps (as simultaneously as possible):

Protect Your Own Network

Set up filters and rules in outer perimeter routers and firewalls to drop packets from the questionable addresses. Do not log the dropping of the packets! Logs will fill hard drives quickly. This will not gain back any bandwidth to the Internet, but it will help unclog your internal network. In the event servers were overwhelmed to the point of crashing or locking up, you can at least start working on getting your equipment back in working order. And while this step may seem pointless considering the next two steps, remember that while you should contact your ISP, if it takes 30 minutes to get a technician on the phone you've wasted time that could be used to recover crashed servers and routers.

Contact Your ISP

Contact your ISP and ask to have the offending addresses blocked at their end. The ISP should be able to block the addresses on their own Internet feeds. This will start freeing up some (if not most) of your bandwidth.

Your ISP's ISP

Encourage your ISP to contact any other second-tier Internet provider they use to ask them to block the addresses as well. Once this is done you should be able to see the Internet fairly clearly, and Internet users can start seeing you as well.

Take the Offensive

Depending on which DDoS is used, it is possible to send packets toward the offending addresses and cause the attack to shut down. By using the zombie_zapper program, it might be possible to shut off attacking DDoS nodes.

Act Fast

Do not wait to get a list of IP addresses before you start calling your ISP. Call them immediately and work with them to help determine IP addresses. You could possibly end up with a technician who can see what the addresses are, but personally lacks the access level or skill set to make the adjustments at the ISP.

Although the current DDos tools typically use overtly offensive packets, such as ICMP floods, it is entirely possible that the tools merely produce inflated amounts of legitimate traffic. It may therefore be difficult to determine the exact source of rogue traffic. It is also possible that packets have random source IP addresses, further restricting the ability to insert filters.

Thanks

I'd like to thank my wife for being patience during writing and coding on Valentine's Day, and the entire BindView RAZOR team for input into this paper. I'd especially like to thank Paul Ashton for some serious wordsmithing.

References

[1] David Dittrich (dittrich@cac.washington.edu) provided detailed analysis of three distributed denial of service tools found in the wild.

• "The DoS Project's 'trinoo' distributed denial of service attack tool" http://staff.washington.edu/dittrich/misc/trinoo.analysis;
• the "Tribe Flood Network" distributed denial of service attack tool" http://staff.washington.edu/dittrich/misc/tfn.analysis;
• the "stacheldraht" distributed denial of service attack tool http://staff.washington.edu/dittrich/misc/stacheldraht.analysis.

[2] Packetstorm archives, http://packetstorm.securify.com/distributed/

[3] "Strategies for Defeating Distributed Attacks" by Simple Nomad, submitted as an entry in the Packetstorm "Stormchaser 2000" contest, available from http://razor.bindview.com/publish/index.shtml.

[4] "Purgatory 101: Learning to cope with the SYNs of the Internet" by NightAxis and Rain Forest Puppy. http://packetstorm.securify.com/papers/contest/RFP.doc

[5] find_ddos, available from http://www.fbi.gov/nipc/trinoo.htm

[6] zombie_zapper, available from http://razor.bindview.com/tools/

[7] RFC 2267, "Network Ingress Filtering: Defeating Denial of Service Attacks", http://www.faqs.org/rfcs/rfc2267.html

[8] David Dittrich keeps remote detection software available at his home page at http://staff.washington.edu/dittrich.

[9] HackerShield from BindView, for more info see http://www.bindview.com/products/hackershield/.