COMMAND
DDoS (Distributed DoS)
SYSTEMS AFFECTED
All systems
PROBLEM
To undestand following issue, please read following advisories:
http://oliver.efri.hr/~crv/security/bugs/mUNIXes/dos3.html
http://oliver.efri.hr/~crv/security/bugs/mUNIXes/dos5.html
http://oliver.efri.hr/~crv/security/bugs/mUNIXes/dos6.html
The problem with DDOS:
- It is infeasible to secure the entire net.
- Scanners for DDOS daemons are being built but still require
efforts from uniterested parties to run the scans. Frequency
of scanning will be an issue too.
- The attackers are often systems that are unattended or
neglected as far as security. This makes it even harder to
reach someone at the site to stop the attack.
- The ones who are motivated to do something about DDOS are
the victims not the attack relays.
- The ISPs are also greatly motivated to ensure that their
services are not disrupted.
- The problem with disabling the attack is that the victim has
to contact many, many systems to notify them that they have
been breached and convince the administrators and take
measures agains the attacker software now embedded in their
system.
As this is an industry wide issue, it is doubtful a single source
commercial antidote to all the potential DDOS problems can be
found with a single countermeasure. So I propose a collaboration
between service providers - an Anti-ddos ISP Coalition to remedy
the problem.
In particular these attacks were of the bandwidth consumption
type. Some of the network providers involved claim to have been
upwards of 1 Gb/s traffic.
SOLUTION
A number of meetings have been held to discuss the attacks and
search for possible solutions. These include CERT
Distributed-Systems Intruder Tools Workshop back in November and
the two recent Birds of Feather (BOF) sessions organized by the
ICSA at the RSA and NANOG conferences.
You can find David's notes on the CERT workshop at:
http://staff.washington.edu/dittrich/talks/cert/
You can find the results of the CERT workshop at:
http://www.cert.org/reports/dsit_workshop.pdf
CERT has also issued an advisory last month on the problem:
http://www.cert.org/advisories/CA-2000-01.html
These attack are made possible because of fundamental design
decisions at the IP protocol level. It does not provide strong
authentication of the source of a packet, and it only provides a
best effort service with no resource allocation protocol. To date
no one has come up with a "silver bullet" solution to the problem.
That being said, the are a number of options to mitigate it.
Elias Levy mentioned a few following.
Network Ingress Filtering:
==========================
All network access providers should implement network ingress
filtering to stop any of their downstream networks from injecting
packets with faked or "spoofed" addressed into the Internet.
Although this does not stop an attack from occurring it does make
it much easier to track down the source of the attack and
terminate it quickly. For information on network ingress
filtering read RFC 2267:
http://info.internet.isi.edu/in-notes/rfc/files/rfc2267.txt
Egress Filtering
================
Chris Brenton reminded us of the flip coin of ingress filtering,
egress filtering. It can be used by networks connecting to the
Internet to make sure they are not a source of spoofed packets.
You can find information about it at:
http://www.sans.org/y2k/egress.htm
Spoofed Packet Tracing
======================
Chris also pointed out a presentation by Robert Stone from UUNET
given at NANOG on CenterTrack. CenterTrack is an overlay network
that allows you easily determine the ingress network edge router
of packets. This makes it easy to track down the source of
spoofed packets. You can find the presentation slides at:
http://www.nanog.org/mtg-9910/robert.html
Rate Limit Some Network Traffic:
================================
A number of routers in the market today have features that allow
you you limit the amount of bandwidth some type of traffic can
consume. This is sometimes referred to as "traffic shaping". In
Cisco IOS software this feature is called Committed Access Rate
(CAR). CAR allows you to enforce a bandwidth policy against
network traffic that matches an access list. This can be used in
a proactive way if you know most of your network traffic will be
of some particular type. For example if you are running a web
farm you can configure the system such as any web traffic gets as
much bandwidth as it requires while limiting all other traffic to
smaller manageable rate. It can also be used in a reactive way
if you can craft an access rule that will match some of the
network traffic using by the DDOS attack. For example if the
attack is employing ICMP packets or TCP SYN packets you could
configure the system to specificly limit the bandwidth those
types of packets will be allowed to consume. This will allow
some of these packets which may belong to legitimate network
flows to go through.
Because of the avalanche effect of the DDOS attacks for this
option to be effective it must be deployed as depth into the
network as possible (closer to the source of the attack packets).
You may need to ask your network access provider to implement
these filters for you in their routers. This will not be
possible for many organizations for a number of reasons.
Furthermore, DDOS attack tools can generate random packets such
as that matching them with a set of access list rules can become
difficult unless you do so by using negative space (by defining
normal traffic and assuming everything else is DDOS traffic).
To find out more about CAR go to:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/qos_c/qcpart4/qcpolts.htm
http://www.cisco.com/warp/public/707/newsflash.html
Intrusion Detection Systems
===========================
Use an Intrusion Detection System to detect attackers that are
communicating with the "slave", "master" or "agent" machines.
This will allow you to know whether some machine in your network
is being used to launch a known attack but will probably not
detect new variations of these attacks and the tools that
implement them. Most IDS vendors have signatures available to
detect Trinoo, TNF or Stacheldraht network traffic.
Axent has released an updated signature for NetProwler to detect
DDOS attacks and communication with the DDOS agents.
http://www2.axent.com/swat/3download_np.htm
ISS's RealSecure 3.2.1 will detect DDOS attacks and communication
to with the DDOS agents.
Host Auditing Tools
===================
A number of file scanning tools are available that attempt to
detect the existence of known DDOS tool client and server binaries
in your system. A number of host auditing tool vendors have
updated their tools to include these signatures. Just like
antivirus software the tools become obsolete as new DDOS tools
are developed or modified.
The NIPC has made available a tool called "find_ddos" that
searches the filesystem for the Trinoo, TNF, TNF2K and
Stacheldraht DDOS tools. The tool is available for Solaris (Sparc
and Intel) and Linux (Intel) operating systems. Beware that the
NIPC does not provide source code to this program. You can find
the program at:
http://www.fbi.gov/nipc/trinoo.htm
Network Auditing Tools
======================
A number of network scanning tools are available that attempt to
detect the presence of DDOS agents running on hosts on your
network. A number of network auditing tool vendors have updated
their products to include the tests. Just like antivirus software
these tools become obsolete as new DDOS tools are developed or
modified.
Dave Dittrich, Marcus Ranum, and others have developed "gag".
This tool detects Stacheldraht agents. Its available for Unix
systems. You can find the program at:
http://staff.washington.edu/dittrich/misc/sickenscan.tar
Dave Dittrich, Marcus Ranum, George Weaver, David Brumley, and
others have developed "dds". This tool detects Trinoo, TFN and
Stacheldraht agents. You can find the program at:
http://staff.washington.edu/dittrich/misc/ddos_scan.tar
David Brumley pointed out the is at least one other free scanning
tool called RID that will detect the presence of Trinoo, TFN, or
Stacheldraht clients. You can find this tool at:
http://theorygroup.com/Software/RID/
Axent has released an updated test for NetRecon to find hosts with
DDOS agents.
http://www2.axent.com/swat/News/nr30su1.htm
ISS's Internet Scanner 6.01 will find hosts with DDOS agents.
Automated Network Tracing Tools
===============================
Tracing streams of packets with faked or "spoof" address through
the network is a time consuming tasks that requires the
cooperation of all networks carrying the traffic and that must be
completed while the attack is in progress.
If you recall when SYN flooding DOS attacks became fashionable
back in 1997 MCI developed a tool called DoSTracker that automated
a lot of the work required for them to trace the source of an
attack through their network. Tools need to be developed to
automate the tracing process within a network under the same
authority as well as tools that can request traces to be performed
across network authority boundaries.
Emergency Data Centers
======================
One can also think of these attacks as some type of natural
disaster. It is common to have as part of your disaster
contingency plans access to an offsite emergency data center that
can be brought online in a short period of time to resume partial
or full operational capacity. Organizations with enough resources
should consider such site as a mitigating factor to the risk of a
DDOS attack.
Insurance
=========
A number of insurance companies are now providing computer and
computer security related policies. Under some circumstances this
may provide a better return on investment (ROI) that some of the
other measures presented here. Example of companies providing
some type of computer security insurance are:
http://www.tricityins.com/cc_insurance.htm
http://www.securitydealers.com/protection/sedgwick.htm
http://www.insuretrust.com/insurance.html
http://www.aig.com/corpsite/pr2/pro04_17_97.html
The Obvious
===========
Secure your machines. It won't stop you from being a victim of a
DDOS attack but it will stop someone using you as a launching
point for the attacks. You may be found liable if someone uses
your network and hosts to attack someone else.
Snake Oil
=========
You should also be aware the are a number of companies out there
that claim to have solutions to DDOS attacks that they will
happily sell you. You should be skeptical of anyone peddling a
"silver bullet" solution. Caveat emptor.
10 Proposed 'first-aid' security measures against Distributed
Denial Of Service attacks by Mixter:
http://packetstorm.securify.com/distributed/firstaid.txt