Distributed Denial of Service Defense Tactics - 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.
d0f80557044b2a18453f2dc7582595ddb3ce718da4f6063550bdaf18440afa5b<!DOCTYPE HTML PUBLIC "html.dtd">
<HTML>
<!doctype html public "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META CONTENT="text/html;CHARSET=iso-8859-1" HTTP-EQUIV="Content-Type">
<SCRIPT SRC="http://razor.bindview.com/snippets/navmenu.js" LANGUAGE="javascript">
</SCRIPT>
<TITLE>Distributed Denial of Service Defense Tactics</TITLE>
</HEAD>
<BODY BACKGROUND="http://razor.bindview.com/images/background.jpg" TOPMARGIN="0" VLINK="#F0F0F0" TEXT="white" MARGINHEIGHT="0" BGCOLOR="black" LEFTMARGIN="0" MARGINWIDTH="0" LINK="white" ALINK="red">
<TABLE VSPACE="0" HSPACE="0" CELLSPACING="0" CELLPADDING="0" FRAME="void" BORDER="0">
<TR VALIGN="TOP">
<TD VALIGN="top" BGCOLOR="#000000" HEIGHT="73"><A HREF="http://razor.bindview.com/index.shtml"><IMG WIDTH="178" SRC="http://razor.bindview.com/images/razorlogo.gif" HEIGHT="73" ALIGN="LEFT" BORDER="0"></A><A HREF="http://www.bindview.com/"><IMG WIDTH="135" ALT="Sponsored by BindView" VSPACE="20" SRC="http://razor.bindview.com/images/bvlogo.jpg" HEIGHT="56" ALIGN="RIGHT" BORDER="0"></A></TD>
</TR>
<TR VALIGN="TOP">
<TD ALIGN="right">
<TABLE WIDTH="100%" CELLSPACING="0" CELLPADDING="0" ALIGN="right" BORDER="0">
<TD WIDTH="25%" NOWRAP HEIGHT="26" ALIGN="right"><IMG WIDTH="55" SRC="http://razor.bindview.com/images/toolBarRamp.jpg" HEIGHT="26" ALIGN="middle" BORDER="0"></TD>
<TD WIDTH="14%" BGCOLOR="#666666"> </TD>
<TD WIDTH="60%" NOWRAP BGCOLOR="#666666" HEIGHT="26" ALIGN="left"><IMG WIDTH="50" ALT="Razor Home" NAME="image1" SRC="http://razor.bindview.com/images/menu/homeicon.gif" HEIGHT="26" ALIGN="middle" BORDER="0"><A ONMOUSEOVER="changeImages('image1', 'image1on')" HREF="http://razor.bindview.com/index.shtml" ONMOUSEOUT="changeImages('image1', 'image1off')"><FONT SIZE="2" FACE="Verdana, Arial, Helvetica, sans-serif"><B>Razor
Home</B></FONT></A><IMG WIDTH="50" ALT="Papers & Advisories" NAME="image3" SRC="http://razor.bindview.com/images/menu/papersicon.gif" HEIGHT="26" ALIGN="middle" BORDER="0"><A ONMOUSEOVER="changeImages('image3', 'image3on')" HREF="http://razor.bindview.com/publish/index.shtml" ONMOUSEOUT="changeImages('image3', 'image3off')"><FONT SIZE="2" FACE="Verdana, Arial, Helvetica, sans-serif"><B>Papers
& Advisories</B></FONT></A><IMG WIDTH="50" ALT="Razor Tools" NAME="image4" SRC="http://razor.bindview.com/images/menu/toolsicon.gif" HEIGHT="26" ALIGN="middle" BORDER="0"><A ONMOUSEOVER="changeImages('image4', 'image4on')" HREF="http://razor.bindview.com/tools/index.shtml" ONMOUSEOUT="changeImages('image4', 'image4off')"><FONT SIZE="2" FACE="Verdana, Arial, Helvetica, sans-serif"><B>Tools</B></FONT></A><IMG WIDTH="20" SRC="http://razor.bindview.com/images/clear.gif" HEIGHT="10"></TD>
<TD WIDTH="1%" BGCOLOR="#666666"> </TD>
</TR></TABLE>
</TD>
</TR>
<TR VALIGN="TOP">
<TD><IMG WIDTH="413" SRC="http://razor.bindview.com/images/headers/publish.gif" HEIGHT="32" ALIGN="BOTTOM" BORDER="0"></TD>
</TR>
<TR VALIGN="TOP">
<TD>
<TABLE WIDTH="95%" CELLSPACING="0" CELLPADDING="12" BORDER="0">
<TR><TD>
<H2><FONT FACE="arial, helvetica, sans-serif" COLOR="blue">Distributed Denial of Service Defense Tactics</FONT></H2>
<A HREF="mailto:thegnome@bos.bindview.com">Simple Nomad</A><BR>
BindView RAZOR Team<BR>
14 Feb 2000<BR>
<A HREF="mailto:thegnome@razor.bindview.com">thegnome@razor.bindview.com</A>
<BR><BR><H3>Abstract</H3>
<P>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.
<BR><BR><H3>Audience</H3>
<P>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.
<BR><BR><H3>History</H3>
<P>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.
<BR><BR><H3>A Quick Review of the Attack Model</H3>
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 |
| |
*-----------------------*
</PRE>
<P>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.
<P>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.
<P>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.
<BR><BR><H3>Weaknesses in the Attack Model</H3>
<P>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.
<BR><BR><H3> Attacker</H3>
<P>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.
<P> 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.
<BR><BR><H3> The Client</H3>
<P>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.
<BR><BR><H3> The Nodes</H3>
<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.
<BR><BR><H3> Communication Links</H3>
<P>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].
<BR><BR><H3> Floods and Attacks</H3>
<P>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].
<P>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.
<BR><BR><H3>Defending Against Attacks</H3>
<P>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.
<P>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):
<BR><BR><H3> Protect Your Own Network </H3>
<P>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.
<BR><BR><H3> Contact Your ISP </H3>
<P>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.
<BR><BR><H3> Your ISP's ISP</H3>
<P>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.
<BR><BR><H3> Take the Offensive</H3>
<P>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.
<BR><BR><H3>Act Fast</H3>
<P>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.
<P>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.
<BR><BR><H3>Thanks</H3>
<P>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.
<BR><BR><H3>References</H3>
<BLOCKQUOTE>
<BR><DT>[1] David Dittrich (<A HREF="http://razor.bindview.com/publish/papers/dittrich%40cac.washington.edu">dittrich@cac.washington.edu</A>) provided detailed
analysis of three distributed denial of service tools found in the wild.
<UL>
<LI> "The DoS Project's 'trinoo' distributed denial of service attack tool"
http://staff.washington.edu/dittrich/misc/trinoo.analysis; <LI>the "Tribe
Flood Network" distributed denial of service attack tool"
http://staff.washington.edu/dittrich/misc/tfn.analysis; <LI>the
"stacheldraht" distributed denial of service attack tool
http://staff.washington.edu/dittrich/misc/stacheldraht.analysis.</UL>
<BR><BR><DT>[2] Packetstorm archives, http://packetstorm.securify.com/distributed/
<BR><BR><DT>[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.
<BR><BR><DT>[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
<BR><BR><DT>[5] find_ddos, available from http://www.fbi.gov/nipc/trinoo.htm
<BR><BR><DT>[6] zombie_zapper, available from http://razor.bindview.com/tools/
<BR><BR><DT>[7] RFC 2267, "Network Ingress Filtering: Defeating Denial of Service
Attacks", http://www.faqs.org/rfcs/rfc2267.html
<BR><BR><DT>[8] David Dittrich keeps remote detection software available at his
home page at http://staff.washington.edu/dittrich.
<BR><BR><DT>[9] HackerShield from BindView, for more info see
<A HREF="http://www.bindview.com/products/hackershield/">http://www.bindview.com/products/hackershield/</A>.
</BLOCKQUOTE>
</TD></TR>
</TABLE>
</TD>
</TR>
<TR>
<TD VALIGN="top" ALIGN="center">
<BR><BR><B><FONT SIZE="2" FACE="Arial, Helvetica, sans-serif">Contact:</FONT></B><FONT SIZE="2" FACE="Arial, Helvetica, sans-serif">
</FONT><A HREF="mailto:info@razor.bindview.com"><FONT SIZE="2" FACE="Arial, Helvetica, sans-serif">info@razor.bindview.com</FONT></A>
<B><FONT COLOR="#CC0000">|</FONT></B> <B><FONT SIZE="2" FACE="Arial, Helvetica, sans-serif">Fax:</FONT></B><FONT SIZE="2" FACE="Arial, Helvetica, sans-serif"> 508-485-0737</FONT> <B><FONT COLOR="#CC0000">|</FONT></B> <A HREF="http://www.bindview.com/"><FONT SIZE="2" FACE="Arial, Helvetica, sans-serif">Bindview Home</FONT></A><BR><BR>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed