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

The basic model of the DDoS tools involves the following:
<PRE>
                    *----------*
                    |          |
                    | 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

 <P>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 (http://razor.bindview.com/publish/papers/dittrich%40cac.washington.edu                                        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; he "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/" http://www.bindview.com/products/hackershield/.