Attacking DDoS at the Source
Jelena Mirkovi´c Gregory Prier Peter Reiher
University of California Los Angeles
Computer Science Department
3564 Boelter Hall
Los Angeles, CA 90095, USA
Abstract
Distributed denial-of-service (DDoS) attacks present an
Internet-wide threat. We propose D-WARD, a DDoS de-
fense system deployed at source-end networks that au-
tonomously detects and stops attacks originating from these
networks. Attacks are detected by the constant monitoring
of two-way traffic flows between the network and the rest
of the Internet and periodic comparison with normal flow
models. Mismatching flows are rate-limited in proportion
to their aggressiveness. D-WARD offers good service to le-
gitimate traffic even during an attack, while effectively re-
ducing DDoS traffic to a negligible level. A prototype of the
system has been built in a Linux router. We show its effec-
tiveness in various attack scenarios, discuss motivations for
deployment, and describe associated costs.
1. Introduction
Distributed denial-of-service attacks are comprised of
packet streams from disparate sources. These streams con-
verge on the victim, consuming some key resource and ren-
dering it unavailable to legitimate clients. The cooperation
of distributed machines that generate attack flows makes
traceback and mitigation very challenging. Some defense
mechanisms concentrate on detecting the attack close to the
victim machine, characterizing it and filtering out the attack
packets. While the detection accuracy of these mechanisms
is high, the traffic is usually so aggregated that it is difficult
to distinguish legitimate packets from attack packets. More
importantly, the attack volume can be larger than the system
can handle. Several distributed DDoS defense systems have
been proposed that cooperate among core routers to sup-
press attack streams. These routers are augmented to mon-
itor traffic and grant requests for rate-limiting or filtering
This work is funded by DARPA under contract number N66001-
01-1-8937. The authors can be contacted at
sunshine, greg, rei-
her
@cs.ucla.edu.
of the streams they deliver to their peers. Even when par-
tially deployed, these mechanisms can significantly reduce
attack volume and lessen impact on the victim. Unfortu-
nately, core routers can spare only limited resources for at-
tack detection and response, and therefore legitimate flows
are often marked as suspicious and suffer collateral dam-
age. The required cooperation of routers is hard to achieve
due to distributed Internet management, and securing and
authenticating this communication incurs high cost.
Ideally, DDoS attacks should be stopped as close to the
sources as possible. In this paper we propose a DDoS de-
fense system called D-WARD that is deployed at the source-
end networks (stub networks or ISP networks) and pre-
vents the machines from participating in DDoS attacks. D-
WARD is configured with a set of addresseswhose outgoing
traffic should be policed (its police address set), and moni-
tors two-way traffic between the police address set and the
rest of the Internet. Online traffic statistics are compared
to predefined models of normal traffic, and non-complying
flows are rate-limited. The imposed rate limit is dynami-
cally adjusted as flow behavior changes, facilitating fast re-
covery of misclassified legitimate flows while severely lim-
iting ill-behaved aggressive flows that are likely part of an
attack. D-WARD strives to guarantee good service to legiti-
mate traffic by profiling individual connections and serving
those that are classified as good, regardless of the imposed
rate limit.
The D-WARD approach requires that many routers at
different network entry points each independently run the
system, since each D-WARD router only polices data flows
originating from its own network. However, incremental
deployment brings incremental benefit, since each deployed
D-WARD router reduces the number of effective attack ma-
chines available on the Internet. The major challenge to a
D-WARD deployment is incentive, since the direct benefit
of the system is felt by the victim, not by the deploying net-
work.
Section 2 of this paper describes the proposed D-WARD
system, specifically its monitoring, detection and response
strategy. Section 3 describes the implementation of the sys-
tem in a Linux router, presents several experiments, and dis-
cusses the performance results and deployment cost. Sec-
tion 4 investigates security issues, and Section 5 discusses
motivation for deployment. Section 6 gives an overview of
related work. Section 7 discusses future work, and Section
8 concludes the paper.
2. D-WARD
Placing DDoS defenses close to the sources of the attack
has many advantages. The attack flows can be stopped be-
fore they enter the Internet core and blend with other flows,
thereby creating possible congestion. Being close to the
source can facilitate easier traceback and investigation of
the attack. The low degree of flow aggregation allows the
use of more complex detection strategies with higher accu-
racy. Also, routers closer to the sources are likely to relay
less traffic than core routers and can dedicate more of their
resources to DDoS defense.
The D-WARD system is installed at the source router
that serves as a gateway between the deploying network
(source network) and the rest of the Internet. We assume
that D-WARD is able to identify the police address set, ei-
ther through some protocol or through manual configura-
tion. We further assume that all machines from the police
address set use the source router as the “exit router” to reach
a particular set of destination networks and to receive traf-
fic from these destination networks. (Asymmetric routing
is discussed in Section 7.)
D-WARD monitors the behavior of each peer with whom
the source network communicates, looking for signs of
communication difficulties, such as a reduction in the num-
ber of response packets or longer inter-arrival times. D-
WARD periodically compares the observed values of the
two-way traffic statistics for each peer against a predefined
model of normal traffic. If the comparison reveals the possi-
bility of a DDoS attack, D-WARD responds by imposing a
rate limit on the suspicious outgoing flow for this peer. Sub-
sequent observation either confirms or refutes this hypothe-
sis. Upon confirmation, D-WARD restricts the allowed rate
limit further. Refutation leads to a slow increase of the al-
lowable traffic for the flow.
2.1. System architecture
D-WARD is a self-regulating reverse-feedback system.
It consists of observation and throttling components that can
be part of the source router itself, or can belong to a sepa-
rate unit that interacts with the source router to obtain traffic
statistics and install rate-limiting rules. Figure 1 depicts the
architecture corresponding to the second approach.
STATISTICS
MODELS
CLASSIFICATION
FLOW
CLASSIFICATION
OBSERVATION
COMPONENT
THROTTLING
COMPONENT
RATELIMIT
RULES
TRAFFIC
STATISTICS
SOURCE
NETWORK
INTERNET
SOURCE
ROUTER
D-WARD
Figure 1. D-WARD architecture.
The observation component monitors all packets passing
through the source router and gathers statistics on two-way
communication between the police address set and the rest
of the Internet. This monitoring can be performed, for ex-
ample, by sniffing the traffic at the source router interfaces.
Periodically, statistics are compared to models of normal
traffic and results are passed to the throttling component
which adjusts and transfers the new rate limit rules into the
source router. The imposed rate limits modify associated
traffic flows and thus affect future observations, closing the
feedback loop.
2.2. Monitoring and attack detection
The observation component monitors two-way traffic at
flow granularity in order to detect difficulties in communi-
cation that could be a sign of a DDoS attack. A flow is
defined as the aggregate traffic between the police address
set and a foreign host. Additionally, it monitors two-way
traffic at the connection level, attempting to identify legit-
imate connections that should receive good service in case
the associated flow becomes rate-limited. A connection is
defined as the aggregate traffic between two IP addresses
and port numbers, where one address belongs to the police
address set, and the other is a foreign address.
Flow classification. Flow statistics are stored at the
granularity of the IP address of the peer host. Keeping
a record for each existing IP address is infeasible, so the
records are kept in a limited-size flow hash table. The
flow record is deleted from the flow hash table if: (i)
no traffic is observed on the corresponding flow during a
interval, or (ii) the flow hash table is full. In
the case of overflow, the least frequently used records are
deleted until enough space has been reclaimed. The num-
ber of sent packets and the number of sent bytes determine
a record’s use frequency.
Each flow record contains statistics on three types of traf-
fic: TCP, UDP, and ICMP. These statistics include the num-
ber of packets and bytes sent to and received from the peer
during the observation interval, and the number of active
connections. Additionally, for TCP and ICMP traffic, D-
WARD keeps the smoothed ratio of the number of packets
sent to the peer and the number of packets received from the
peer.
D-WARD compares the statistics with normal flow mod-
els after every observation interval and classifies flows as
normal, suspicious or attack. If all comparisons match their
corresponding models, then the flow is compliant and will
be examined further. Otherwise, the flow is classified as an
attack flow. Compliant flows are further classified into sus-
picious and normal flows based on their past behavior. Sus-
picious flows are those flows that have recently been clas-
sified as attack. Even though the observations now indicate
compliance with the normal flow model, the imposed rate
limit must be carefully removed to prevent pulsing attacks
that could cause periodic disturbance to the victim. Section
2.3 explains this policy in greater detail.
TCP normal traffic model. During a TCP session, the
data flow from the source to destination host is controlled
by the constant flow of acknowledgments in the reverse di-
rection. D-WARD’s TCP flow model defines
! #"$
—the
maximum allowed ratio of the number of packets sent and
received in the aggregate TCP flow to the peer. The flow
is classified as an attack flow if its packet ratio is above the
threshold; otherwise, it is considered a compliant flow.
ICMP normal traffic model. The ICMP protocol speci-
fies many different message types. During normal operation
the “timestamp,” “information request,” and “echo” mes-
sages should be paired with the corresponding reply. Us-
ing this observation, the normal ICMP flow model defines
%
'&(
)"$
—the maximum allowed ratio of the number of
echo, time stamp, and information request and reply pack-
ets sent and received in the aggregate flow to the peer. The
frequency of other ICMP messages, such as “destination un-
reachable,” “source quench,” “redirect,” etc., is expected to
be so small that a predefined rate limit can be used to control
that portion of the traffic.
UDP normal traffic model. The UDP protocol is used
for unreliable message delivery and in general does not re-
quire any reverse packets for its proper operation. Many ap-
plications that communicate through UDP packets generate
a relatively constant packet rate, but the maximum rate de-
pends heavily on the underlying application. On the other
hand, UDP traffic usually occupies a small percentage of
all network traffic and is conducted via a few connections.
We use this observation to define the UDP flow model as
a set of thresholds:
'*
$#+,+
—an upper bound on the num-
ber of allowed connections per destination,
-
*
$#+,+
—a lower
bound on the number of allowed packets per connection,
and
.0/11 323"4
—a maximum allowed sending rate per con-
nection. The model classifies a flow as an attack when at
least one of these thresholds has been breached. The first
two thresholds help identify a UDP attack through spoofed
connections, while the third identifies a UDP attack through
a few very aggressive, non-spoofed connections. An at-
tacker can still get enough traffic past the thresholds to per-
petrate an attack if he chooses to spoof a small number of
addresses consistently and distributes the attack sufficiently
so that each source network sees only a small portion of the
traffic. We plan to address this issue in our future work.
Connection classification. Connection statistics are
stored in a limited-size connection hash table and include
the number of packets and bytes sent and received during
the observation interval. Each connection is classified as
good (complying to the model), bad (parameter values out-
side the model boundaries) or transient (not enough data to
perform a classification) according to the traffic type of its
protocol. The models defining good connections are sim-
ilar to those defining normal flows. The TCP and ICMP
connection models specify the maximum allowed packet ra-
tio. In addition to this, TCP connections must be responsive
to packet drops. The UDP connection model specifies the
maximum allowed sending rate
.5/6
*
$)+,+7 823"4
. Good con-
nections receive guaranteed good service during the rate
limit phase, while transient connections have to compete
with the attack traffic for the rate-limited bandwidth.
The connection record is deleted from the connection
hash table if: (i) The connection is classified as transient and
has been inactive for
9;:
<=>0)?60@
:
BA
,
(ii) the connection is classified as good and has been in-
active for
C
BBA?60@
:
BA
, or (iii) the connec-
tion hash table has filled to capacity. In the case of overflow,
records are deleted until enough space has been reclaimed.
Bad connection records are deleted first, and next are the
least frequently used transient connection records. Good
connection records are never deleted if the table overflows.
Since the connection hash table has limited size, it might
overflow if the attack is performed using spoofed packets.
This suggests the possibility of poor service offered to le-
gitimate connections that start during the attack, since they
are likely to be expelled from the connection hash table be-
fore their goodness has been established. New legitimate
connections may suffer packet losses even if they remain in
the table. During the time they are classified as transient,
they have to fight for the limited outgoing bandwidth with
more aggressive attack traffic. Both of these problems exist
because it is difficult to distinguish legitimate packets from
attack packets based on the first packet in the connection.
2.3. Attack response
The throttling component defines the allowed sending
rate for a particular flow based on the current flow charac-
terization and its aggressiveness. The problem of regulating
the sending rate of a one-way flow to the level manageable
by the receiver (or the route to the receiver) has been recog-
nized and addressed by the TCP congestion control mech-
anism. D-WARD strives to solve a similar problem at a
more aggregated scale. It needs to control the total flow to
the peer, or the portion of that flow that has been character-
ized as troublesome, and it infers the peer’s state from its
response packets. D-WARD’s rate-limiting strategy applies
modified TCP congestion control ideas to this problem: fast
exponential decrease of the sendingrate when the peer is not
sufficiently responsive, slow recovery of rate-limited flows
for a certain time period, and fast recovery once flows have
proved that they will behave. In addition to this, the flow
can be restrained more if it does not comply with the im-
posed rate limit, and tries to send more than it is allowed.
When the flow is classified as an attack flow for the first
time after a long period of normal activity, its rate is lim-
ited to a fraction of the offending sending rate. The size of
the fraction is specified by the configuration parameter
DE4
*
.
Subsequent classification of a flow as an attack restricts the
rate limit further, according to the formula:
:
FHGIKJ
:
ML
:
MBN
D
E4
*
O6P
4+,"
O
P
4+B"Q
O
E3 3$R3R=4ME
(1)
where
:
M
is the realized sending rate for the flow during
the previous observation interval,
:
is the current rate limit,
O
P
4M+B"
represents the number of bytes sent for this flow (af-
ter the rate limit is applied) during the interval, and
O
E3 8$R
is
the number of dropped bytes because of the imposed rate
limit. Thus, the last factor in the equation describes the
degree of misbehavior of the flow, and defines the restric-
tiveness of the rate limit. Flows that have worse behavior
are quickly restricted to very low rates, whereas this restric-
tion is more gradual for better-behaving flows. The lowest
rate limit that can be imposed is defined by the
S
T6M
configuration parameter so that at least some packets can
reach the destination and trigger a recovery phase. When
the flow becomes compliant it will be classified as suspi-
cious, at which point the recovery mechanism is triggered.
The recovery phase is divided into slow-recovery and fast-
recovery. During the slow-recovery phase, the allowed flow
rate is increased according to the formula:
:
F
:
Q
:
M>U
+
*
O
P
4+B"
O1P
4+B"
Q
O
E3 3$R3R=4ME
(2)
The speed of the recovery is defined by the
:
M
U
+
*
pa-
rameter, and the duration of the slow-recovery phase is de-
fined by the
@>VW@
:
BA
. Note that although the slow-
recovery phase limits the effectiveness of repeated attacks,
they can still take place, but with a pause duration larger
than
@>XVW@
:
BA
.
After the flow has been rate-limited and classified as
compliant for
@>XVW@
:
BA
consecutive observation in-
tervals, the fast-recovery phase is triggered. During the fast-
recovery phase the rate is increasedexponentially according
to the formula:
:
YF
:
J)Z
Q
D
U
+
*
O
P
4+B"
O
P
4+B"Q
O
E3 3$R3R=4ME
N
(3)
The speed of the recovery is defined by the
D
U
+
*
parameter,
and the rate increase is limited by the
S
[\T6M
configu-
ration parameter. As soon as the rate limit becomes greater
than
S
[\T6M
, the recovery phase is finished, and the rate
limit is removed.
3. Test results and analysis
We implemented the D-WARD system in a Linux soft-
ware router and tested it against several attack scenarios.
D-WARD is implemented partly at the application level and
partly as a kernel module. This dual implementation is nec-
essary since D-WARD’s memory requirements cannot be
satisfied at the kernel level, and the speed of the application-
level implementation cannot handle a large traffic volume
and therefore cannot be tested using real attack scenarios.
The application part acts as the monitoring and throttling
component. It uses the libpcap facility to capture informa-
tion about every packet and update the flow and connection
statistics. A separate thread classifies connections and flows
and determines the appropriate rate limit. Informationabout
good connections and the desired rate limit is inserted into
the kernel module through system calls. Themodule detects
and forwards packets belonging to good connections from
rate-limited flows and enforces the rate limit on the rest of
the flow. At large packet rates, the libpcap monitoring facil-
ity cannot capture all packets. More accurate statistics are
then obtained from the kernel module for rate-limited flows
and good connections.
In order to test different attack scenarios we devel-
oped a customizable DDoS attack tool. It uses a master-
slave architecture to coordinate attacks among multiple
slaves. Attack traffic mixture (relative ratio of TCP SYN,
ICMP
ECHO and UDP packets), packet size, attack rate,
target ports, spoofing techniques and attack dynamics can
be customized.
The test network consists of a source router deploying
D-WARD, the attacker and the legitimate client who both
belong to the source network and are part of the police ad-
dress set, and a foreign host playing the role of the victim.
Since D-WARD operates autonomously and analyzes only
its incoming and outgoing traffic, multiple attacking do-
mains would only affect the detection of the attack by mak-
ing the victim feel the attack sooner. The effect of deploying
multiple attack and legitimate client machines in the source
network is mimicked by using only two machines that gen-
erate high traffic loads. Since D-WARD analyzes all in-
coming and outgoing traffic seen by the router, the number
]0^_a`)bdcfehg i3^j1_a`MbkcKemlnol
Observation interval = 1 sec
pfq#rs=tvuxw=pfq#y3zx{8|
eI}~3M
zrWsuXq
eI}f5
s7YsuXq
eml)5>
##
eh~>n
8
el
r
c
=
el)~~
c
>
el
'_'`b
el)~5 '_
c
>
`b
eml)~~f5
t{8arsuxzq8pfq)y3zx{3|
eIg~3¡M
ysuXq
d
eh}f5
¢
y3sr£)zxq)ru¤a{8rrrsuxzq8pfq#y8zx{3|
eml)}~3M
¥
{3{8|=¤a{#rrrs=uxzq8pfq)y3zx{3|
ehg~3¡)
Table 1. Test parameters.
of machines generating the traffic is transparent to the sys-
tem. The parameters for the test were estimated from traffic
traces gathered from our network and are listed in Table 1.
3.1. Attack and legitimate bandwidth
In these tests we evaluate the ability of D-WARD to
detect and restrain the attack, while offering good service
to legitimate traffic. Each test run lasts for 12 minutes.
We generate several TCP connections between legitimate
clients and the victim and interleave them with the attack
traffic. The attack is started at 25 seconds and lasts until
625 seconds. Legitimate connections are started at 0, 5,
125, 626, 627, 628 and 629 seconds. In the measurements
we vary the attack parameters and note the system’s behav-
ior.
Attack dynamics. The goal of this test is to illustrate the
behavior of the system under various attacks. We generate
TCP SYN flood attacks with a maximum rate of 500KBps,
and test with four attack rate dynamics:
¦
Constant rate attack. The maximum rate is achieved
immediately and maintained until the attack is stopped.
¦
Pulsing attack. The attack rate oscillates between the
maximum rate and zero. The duration of the active and
inactive period is the same: 100 seconds.
¦
Increasing rate attack. The maximum rate is
achieved gradually over 300 seconds and is maintained
until the attack is stopped.
¦
Gradual pulse attack. The maximum rate is achieved
gradually over 300 seconds, maintained for 20 seconds
and then gradually decreased to zero over 10 seconds.
The inactive period lasts for 40 seconds, and then the
attack begins again.
Figure 2 gives the results of these tests. The solid line
represents the attack bandwidth passed to the victim, and
the dotted line represents the actual attack bandwidth of-
fered to D-WARD. In all four cases, the attack is detected
and severely rate-limited (less than 1% of the maximum at-
tack rate is allowed to pass) within several seconds. Note
that gradually increasing attacks take a longer time to be de-
tected than attacks that start off at the maximum rate. That is
to be expected since gradual attacks create less disturbance
in the observed statistics. Also note that since the inactiv-
ity period is much larger than the
@>XVW@
:
BA
, periodic
attacks appear to the system as new attack instances.
In all tests legitimate traffic experienced around 1% of
drops. Good packets were only dropped at times when a
new connection attempted to start during or immediately af-
ter the attack, and only during a few seconds until the good-
ness of the connection could be established.
Maximum attack rate. We next tested the relation-
ship between the effectiveness of the system and the max-
imum attack rate. We generated TCP SYN, ICMP ECHO,
and UDP attacks with continuous and gradually increasing
rates, varying the maximum rate from 100KBps to 2MBps,
and measuring the cumulative attack and good traffic that
was delivered to the victim during the test.
Figure 3 gives results of these tests, with 95% confidence
interval. A solid line represents the traffic passed to the
victim in the case of a UDP attack, a dotted line represents
the case of a TCP attack, and a dash-dotted line represents
the case of an ICMP attack. UDP and TCP attacks use a
fixed packet size of 1KB whereas ICMP attacks use a packet
size of 100B. Since all attacks are generated from a single
machine, the maximum rate that can be generated in the
ICMP attack case is lower than the maximum rate generated
in the TCP and UDP case. This is reflected in the dash-
dotted line reaching only to half of the rate axis.
Constant rate attacks pass similar amounts of the attack
traffic for both UDP and TCP cases. This is due to the sud-
den onset of the attack, which creates a sufficient distur-
bance in the network to be quickly detected and controlled.
ICMP attacks can pass undiscovered if the maximum at-
tack rate is small (100KBps). At higher attack rates, they
are detected with an efficiency similar to UDP and TCP at-
tacks, and quickly constrained. The total attack traffic that
the victim receives increases linearly with the maximum at-
tack rate. Most of the attack traffic is passed in the first few
seconds, while the smoothed statistics have not sufficiently
changed enough to affect attack detection. If the attack rate
is higher during this interval, this will be reflected in the
total attack traffic that reaches the victim.
In the case of attacks with gradually increasing rates,
UDP attacks get detected more quickly than TCP attacks
at lower attack rates. Since D-WARD detects the occur-
rence of spoofed UDP packets, it can detect the UDP attack
as soon as the attacker sends enough spoofed packets. In
the TCP attack case, however, D-WARD detects the dis-
turbance at the victim through a decrease in the response
packet rate. This occurs with a larger delay for small rate
attacks and thus slows down the detection. ICMP attacks
experience an even larger detection delay than TCP attacks
