Recent media coverage has focused on a series of Distributed Denial of
Service (DDOS) attacks against a number of high profile sites. In
general, these sites have been E-Commerce related. Previous years
have seen concentrated Denial of Service (DOS) attacks against other
industry groups, particularly ISPs, universities and other agencies
throughout the world.
Media reports have speculated on cost, although to date there are no
firm figures on the true cost. The cost of these attacks will be
incurred through network traffic, loss of availability, time to
respond and repair, and loss of reputation and commercial opportunity.
Some indication of the impact of these attacks is discussed in Section
2 below.
Denial of Service tools in general meet their goal through one of the
following mechanisms. One form of a DOS attack may look to exploit an
implementation error (eg the Ping of Death, see [CA1996-26]). In general such an error is not
difficult to fix.
The second class of attacks are based on the consumption of finite
resources (eg network bandwidth). This is more problematic, and the
latest series of attacks fall into this class. These kinds of attacks
can never be addressed to extinction. So long as any resource is
finite, a DOS attack against it is possible. The attacks can be
managed, but this unfortunately requires all machines on the Internet
to meet certain requirements. This is the core problem in a network
of over 50 million interconnected systems whose owners have varying
motives and agendas.
A series of DDOS tools have been released since mid-1999. These tools
are all based on common ideas expressed in the first of them, the
Tribal Flood Network (TFN). They build on the methods of DOS tools,
expanding them to take advantage of a distributed environment.
Detailed descriptions of these tools can be found in
[DITTRICH-1],
[DITTRICH-2],
[DITTRICH-3], and
[AXENT].
The CERT Coordination Center has also produced a technical paper about
DOS attacks ([CERT-1]), and a further paper on
DDOS ([CERT-2]) attacks. These papers provide
useful background information, with [CERT-1] in
particular providing some pragmatic advice.
On an apparently separate thread, there has been over the past year or
so a noticeable increase in the number of sites throughout the world
reporting widespread scanning. This has been in part due to the
availability of sophisticated scanning tools. Tools such as sscan
([AL1999-01]) allow a person to not only mount
such a scan but also to automatically launch preconfigured attacks.
It is possible that this scanning activity was the precursor to the
outbreak of the DDOS attacks.
The Y2K period also saw some unusual ICMP activity (involving ICMP
Time Exceeded packets with spoofed addresses) which we advised members
about on 2 January 2000. It is yet to be determined whether this
activity was also related to impending DDOS attacks.
These DDOS tools have been proven effective, and this effectiveness is
due to a number of factors which are discussed below. None of these
factors in themselves are new, although their combination in this
manner is relatively recent. While all of them can be managed to some
extent, the real pain for the end victim comes from the difficulty in
identifying the sources of attacks and the lack of control over these
systems.
NUMBERS
In January 2000, AusCERT processed 521 incidents. Of these, 485 were
scans and probes, and only 2 were DOS attacks. At the time of writing
(16 February), AusCERT has processed over 350 incidents for February,
of which 293 were scans and probes, and 2 were DOS attacks. There has
been a noticeable increase in overall reports from Australian and New
Zealand academic institutions since December 1999, and from Australian
and New Zealand commercial sites in February 2000.
However, AusCERT is aware that some Australian sites are experiencing
DOS problems. Discussions with various organisations have indicated
that a number of DOS attacks are unreported. Spikes in network
traffic graphs for some Australian sites during the period Wednesday 9
February through Friday 11 February suggest that there is a
possibility that these sites may have been attacked during the peak
period of activity.
However in the absence of any significant number of DOS reports
directly to AusCERT, it is difficult to determine if these are the
result of DDOS tools. We encourage any members requiring assistance
to report activity to us and tell us how we can assist them.
Some statistics are available for the United States' experience.
Keynote ([KEYNOTE]) reports the following
degradation of performance:
These tools are obviously undergoing active development. This can be
seen in the evolution of new programs, along with updates of existing
programs (such as TFN and TFN2K).
A number of organisations have reported that these programs are being
installed as part of a kit. The rest of the kit is used to hide the
existence of the DDOS tool. While this is not a new concept
(rootkit first appeared in 1993), stealth technology has
advanced since then (eg. twhack, [HALFLIFE]).
Several techniques have been employed across the array of tools in
order to hide their existence at a network level. These techniques
include the use of one-way communication protocols, optionally forged
addresses, randomised protocols, and decoy packets.
THE "GOOD" NEWS
There are some aspects that attenuate the problem. In some cases this
is implementation-dependent, and so there is no guarantee that these
will not change with time.
In their current form, the tools require the attacker to gain
privileged access to the systems housing the handler and
agent software. This means that well-secured sites can at
least ensure that they will not become a relay site.
The number of systems that can currently be used to attack is limited
by the portability of the code. The tools have been developed for use
with Solaris and Linux. There are varying reports of their
reliability with Linux. TFN2K also states that it can be used
with Windows/NT.
The set of attacks commonly used are generally well understood. The
major attacks used are:
SYN Flood: A series of SYN packets are sent to a machine in
order to create a series of half-open connections, preventing new,
legitimate connections being established. These half-open
connections wait for the completion of a three-way handshake which
never occurs. (See [CA1996-21])
UDP Flood: A flood of UDP packets are sent to a (random)
variety of ports. Under some circumstances, resulting ICMP
unreachable messages increase the traffic volume. (An example of
a UDP-based attack is described in
[CA1996-01].)
ICMP Flood: A flood of ICMP echo request packets are sent to a
broadcast address in an intermediate network, triggering an equal
flood of echo replies. The smurf attack, which is included
with some of these tools, uses such a broadcast address to
increase the amplification. This attack is described in
[CA1998-01].
A variety of modifications to these attacks have also been utilised,
including the use of malformed packets to take advantage of longer
processing times or to exploit implementation errors in some IP
stacks.
All of the tools in use have a set of fingerprints and these
fingerprints can be used to identify the possible existence of the
tool. The fingerprints exist at both the host level and network
level.
There are two caveats to this though. The first is that some of these
fingerprints may change with the particular values that the attacker
chooses to modify when the tools are built. This means that it is not
sufficient to simply rely on default values when searching for
fingerprints. The second caveat is that as further stealth technology
is included with the toolkits, the DDOS tools will become more
difficult to find.
MITIGATION
There are a number of steps that sites can take to reduce the effect
if targeted by a DDOS attack. Be aware that it is almost impossible
to totally prevent falling victim to these attacks without effectively
cutting off network connectivity. The best that most sites can do is
reduce their impact.
However, it is important that all sites take steps to ensure they are
not a handler or agent in the attack architecture. It
is only through all sites taking care to avoid this involvement that
the impact of the DDOS tools can be reduced. By taking steps to avoid
involvement as an intermediary site, sites avoid DOS attacks
themselves, avoid loss of reputation, and avoid loss of service due to
other sites blocking traffic.
In almost all of the cases below, the steps described have been known
for a lengthy period. The prevalence of these attacks is an indicator
that many sites have not taken these steps.
The Most Important Step
In order to avoid being a handler site or agent site,
the single most important thing any site can do is to avoid being
compromised to a privileged level. This can be achieved by ensuring
that operating system patches are maintained and that the system is
securely configured. A document that is widely used in configuring
UNIX systems is the AusCERT UNIX Security Checklist
([AUSCERT]).
Configure Network Traffic Controls
A number of steps can be taken to reduce network impact.
Many sites are using rate limiting caps to limit bandwidth of
particular packet types, such as ICMP and SYN packets.
[CISCO] provides an example of this. If possible,
when setting any rate limits do not set the threshold so low as to
either trigger a series of false positives (in the automatic
notification of staff when threshold is reached) or completely block
legitimate packets.
Some documents suggest that ICMP_ECHOREQUEST and ICMP_ECHOREPLY
(particularly the latter) be blocked at boundary network devices.
While this is a reasonable suggestion, sites should be aware that this
will affect some network applications that depend on this traffic, such
as ping.
If possible, consider using redundant network connections and
load-balanced server arrays. This helps distribute the increased load
among a series of machines. This step will not eliminate a DOS
attack, but it helps to reduce its impact.
Address-based filtering
There are a number of address filtering steps that sites can take.
All sites, or their network providers, should be taking steps to apply
filters to block spoofed (forged) packets. This applies to both
incoming traffic (for local protection) and outgoing traffic (for the
protection of other Internet sites). This is discussed in [RFC2267]
A step discussed by Cisco Systems ([CISCO]) is to
install reverse path filtering. This is essentially an anti-spoofing
measure. If the source IP address being processed by a router does
not have a route that points back to the same interface on which the
packet arrived, the router drops the packet. Users of other network
devices should check with their vendor.
Finally, all RFC1918 ([RFC1918]) packets should
also be blocked from emerging from the local network. These addresses
are reserved for network testing and similar activities. This
practice should be enforced regardless of DDOS attacks.
Followup on Scanning Activity
For a significant period of time incident response teams have noticed
a significant increase the number of sites being scanned for
vulnerabilities. There has been a noticeable increase in overall
reports from Australian and New Zealand academic institutions since
December 1999, and from Australian and New Zealand commercial sites in
February 2000. This increase is due mostly to an increased number of
reports of scans.
It is our belief that this widespread scanning is closely linked to
DDOS attacks that have already been executed or are planned. These
tools provide valuable intelligence for attackers, and some tools can
be configured to mount attacks if the user desires. An example of
such a tool is discussed in [AL1999-01].
In the current environment, sites are strongly encouraged to look for
signs of scanning and confirm whether this activity is likely to have
uncovered any local vulnerabilities or attacks.
Look for Network Indicators
Aside from the actual attack packets, there are a number of network
indicators that can be used to detect DDOS tools. A range of TCP, UDP
and ICMP traffic to various ports is an indicator of communication -
this activity is discussed in [DITTRICH-1],
[DITTRICH-2],
[DITTRICH-3] and
[AXENT], and summarised concisely in [CISCO]. As with host-based indicators, the
reliability of this as a detection method depends somewhat on any
changes (or lack of) the attacker chooses to make to the software
during installation.
Other network traffic, such as rcp connections, or shells available on
port 1524 (ingreslock) may be indicators of tools being installed.
This is discussed in [DITTRICH-1],
[DITTRICH-2],
[DITTRICH-3] and [AXENT].
A number of vendors sell tools that can assist in detecting these
network indicators. Examples are Axent Technologies
(http://www.axent.com) and Internet
Security Systems (http://www.iss.net).
(Note: These are provided as examples only and do not constitute
endorsement. AusCERT has no vendor affiliations.)
Look for Host Indicators
All of the tools in use have a set of fingerprints and these
fingerprints can be used to identify the possible existence of the
tool on particular systems. These fingerprints are discussed in
[DITTRICH-1],
[DITTRICH-2],
[DITTRICH-3] and [AXENT].
There are two caveats to this though. The first is that some of these
fingerprints may change with the particular values that the attacker
chooses to modify when the tools are built. This means that it is not
sufficient to simply rely on default values when searching for
fingerprints. The second caveat is that as further stealth technology
is included with the toolkits, the DDOS tools will become more
difficult to find.
Even so, a number of tools are available to assist in detecting these
host indicators. The National Infrastructure Protection Center in the
United States has made such a tool available
([NIPC]).
Some commercial vendors also sell tools that can similarly assist.
