Re Ate Guard

8/8/2019 Re Ate Guard

http://slidepdf.com/reader/full/re-ate-guard 1/8

RateGuard: A Robust Distributed Denial of Service

(DDoS) Defense System

Huizhong Sun

ECE. Polytechnic Institute of NYUBrooklyn, USA

[email protected]

Wingchiu Ngan


[email protected]

H. Jonathan Chao


[email protected]

Abstract —One of the major threats to cyber security is the

Distributed Denial-of-Service (DDoS) attack. In this paper, we

focus on three kinds of sophisticated DDoS attacks that seriously

cripple the current DDoS defense systems and have not been

solved yet. In Fast Adaptive Attacks (FAAs), attackers adaptively

generate attacking traffic based on the feedback from a victim in

Round Trip Time (RTT). Almost all proposed rules-based

filtering schemes cannot effectively defend against FAAs, since

they need a relatively long time (compared to RTT) to update

filtering rules. In Adaptive Attacks with statistical filtering rules

Scanning (AAS), attackers circumvent the defense system bydiscovering the statistical filtering rules of the defense system and

then generating flooding traffic to mimic nominal traffic. In Low-

Rate TCP Attacks (LRAs), attackers send periodic attack pulses

to overflow a router’s buffer and force the legitimate TCP flow to

a low throughput while staying under the radar with a very low

average rate.

In this paper, we propose a Leaky-Bucket (LB) based highly

robust DDoS defense system, called RateGuard. It can react to

FAAs and LRAs by rate-limiting excessive traffic in real-time

according to the victim’s nominal traffic profile. Moreover, by

associating an LB with each joint attribute value, the huge space

required for possible joint attribute values makes it almost

impossible for attackers to scan the victim’s nominal traffic

profiles and, thus, makes it highly robust to cope with AAS and

other sophisticated attacks.

Keywords- Distributed Denial-of-Service Attack; Statistical

Filtering Rules; Fast Adaptive Attacks; Low-Rate TCP Attacks.

I. I NTRODUCTION

One of the major threats to cyber security is the Distributed

Denial-of-Service (DDoS) attack in which the victim network

elements are bombarded with high volumes of attacking traffic.

The aim of the DDoS attack is to overload the victim and

render it incapable of performing normal communications or

transactions. Since the attacking traffic can be of various forms

including fictitious email messages, file transfers, http requests,

as well as TCP, UDP, ICMP, and TCP-SYN packet flood withrandom packet attribute values, it is difficult to differentiate the

attacking packets from legitimate ones. Worse still, such

attacking traffic often originates from a large number of

compromised machines, possibly with spoofed source IP

addresses or innocent “zombie” hosts under the control of

hackers. Here we further describe three kinds of sophisticated

DDoS attacks that seriously threaten the current Internet and

have not been solved yet.

(1) Fast Adaptive Attack (FAA): Most of the current DDoS

defense systems utilize a binary rule or statistical filtering

policy to differentiate attacking from legitimate traffic. When a

packet arrives, the defense system checks the packet header

and decides whether to drop or pass it based on the binary rule

or statistical filtering policy. The rule or policy is either

manually configured or automatically generated periodically.

However, a sophisticated attacker can send probing packets

and observe the corresponding response from the victim to

infer whether the probing packets successfully go through the

defense system. If a probing packet successfully passes thedefense system, the attackers can then generate millions of

attacking packets with the same format, resulting in a problem

called “Fail Once Fail Anytime (FOFA).” In other words,

attackers can bombard victims when they just find one pattern

that can pass through the defense system. Obviously, only if

the interval of updating the defense system’s rule or policy is

much less than RTT, can the defense system defeat the attacker

by quickly reacting to various attacking patterns.

Unfortunately, most of the existing DDoS defense systems take

a relatively long time to react to FAA, perform relatively

statically, and fail to defend against FAA.

(2) Adaptive Attacks with statistical filtering rules Scanning

(AAS): The viability of those aforementioned statisticalfiltering approaches [1]-[7] is based on the premise that

attackers do not know the victim’s nominal traffic profile and

cannot fake legitimate traffic. However, once the statistical

filtering rules-based DDoS defense systems are widely

deployed, DDoS attack tools may be invented to learn the

statistical filtering rules of the defense system or the victim’s

nominal traffic profile. For instance, probing packets are

crafted and sent to the victim. By observing the corresponding

responses or performance degradation from the victim network,

the attacker can estimate the victim’s nominal traffic profiles.

Attackers then start controlling zombies to generate flooding

traffic according to the learned traffic profiles. Under this

intelligent attack, those statistical filtering rules-based DDoSdefense systems will fail to function (as shown in Section V).

This is because attacking and legitimate packets share the same

statistical property and the only thing that the defense system

can do is to rate-limit traffic to the victim’s available

bandwidth by randomly dropping packets.

(3) Low-Rate TCP Attack (LRA): A few kinds of LRAs

have recently been presented, including the Shrew attack [8],

Reduction of Quality (RoQ) attack [9], and Pulsing DoS

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE "GLOBECOM" 2009 proceedin

978-1-4244-4148-8/09/$25.00 ©2009

Authorized licensed use limited to: Annasaheb Chudaman Patil College of Engineering. Downloaded on July 26,2010 at 04:22:10 UTC from IEEE Xplore. Restrictions apply.



(PDoS) attack [10]. They all send periodic attack pulses (i.e.,

short bursts of traffic with high rate) to overflow a router’s

buffer and render packet loss. By synchronizing the attacking

period to the Retransmission Timeout (RTO) duration, the

attacker can force TCP flows on the congested link to

frequently enter a timeout state and leads to low throughput.

These kinds of attacks could become major threats to the

Internet's stability as they can significantly impact network

throughput while staying under the radar by sending attack pulses with a low average rate.

This paper is organized as follows. In Section II, we

describe related works in defending against DDoS attacks. In

Section III, we propose a Leaky-Bucket (LB) based robust

DDoS defense system, called RateGuard, which can react to

FAAs and LRAs by rate-limiting excessive traffic in real-time

according to the victim’s nominal traffic profile. By associating

LB with joint attribute value, the huge space of possible joint

attribute values makes it almost impossible for attackers to scan

the victim’s nominal traffic profile, an effective way to defend

AAS. In Section IV, we evaluate the RateGuard by using real

Internet traffic. We conclude in Section V.

II. R ELATED WORK

Most Internet Service Providers (ISPs) rely on manual

intervention for DDoS attacks. This results in poor response

time and may fail to protect the victim before severe

performance degradation and revenue losses are realized.

Schemes proposed in [11]-[15] focus on traffic marking and

traceback. A victim identifies attacking packets and

reconstructs the attacking path based on the information that

each router marks into the packets. However, these schemes

need ISP’s cooperation, complex calculations, and long

convergence times for path reconstruction. The D-WARD

approach [16] detects abnormal asymmetrical behavior of two-

way traffic and aims to stop DDoS attacks near the attackingsources. Unfortunately, there is little incentive for an ingress

network administrator to bear the complexity and cost only to

protect others' networks. Pushback mechanisms [17]-[19] have

been proposed to extract attacking signatures by rate-limiting

the suspicious traffic destined to the congested link. The

information about ongoing attacks is propagated to upstream

routers so that attacking traffic can be filtered out early.

However, the effectiveness is contingent on the ability to

extract a precise characterization of the attacking packets;

otherwise, the legitimate traffic will be equally affected by the

pushback mechanism.

There are also commercial products, e.g., Asta Networks

[20], which detect and mitigate specific types of known DDoSattacks, especially those generated by well-known DDoS attack

tools. Arbornetworks’ product [21] mitigates DDoS attacks by

using a traceback approach, but requires the precise

characterization of the attacking packets. Mazu, Cisco

(Riverhead), and Cyberoperations’ products [22]-[24] are built

on statistics-based adaptive filtering techniques. However,

most of these solutions do not fully automate packet or

filtering. Instead, they only recommend a set of binary filter

rules to the network administrator. In generally, the rule set is

often too complex to be comprehensible, let alone to be

debugged or modified.

In a low-rate TCP attack, as attacking packets reach the

egress line card, studies show that using today’s buffer

management schemes, such as random early diction (RED),

cannot effectively stop this kind of low-rate TCP attack [25]

without substantially increasing the buffer size. A dynamic

time warping (DTWP)-based [26] and a spectrum-based [27]

algorithm are proposed to defend a Shrew attack [8]. A discretewavelet transform (DWTM)-based approach [10] was

proposed to defend against a PDoS attack. However, they were

designed for a specific kind of low-rate TCP attack and may

not be effective for detecting other kinds of low-rate attacks.

Our prior work [5]-[7] and other statistical filtering based

approaches [1]-[4] defend against DDoS attacks by

distinguishing attacking packets from legitimate ones via a

fine-grain traffic profile comparison between the measured

current traffic profile and victim’s nominal traffic profile.

These schemes can block most DDoS attacks as long as the

attackers cannot precisely mimic the victim’s traffic

characteristics. However, the complex process for generating

statistical filtering rules, and the fact that a victim’s nominaltraffic profile can be obtained by an attacker make these

schemes fail to defend against FAAs and AAS, respectively. In

[4], a statistical filtering based approach similar to our prior

work (Conditional Legitimate Probability (CLP) scheme [5]) is

proposed. The author pointed out the problem of adaptive

DDoS attacks but offered no solutions.

III. R ATEGUARD: A R OBUST DDOS DEFENSE SYSTEM

A. Architecture of the RateGuard

In this section, we propose an LB-based robust DDoS

defense system – RateGuard, which can be implemented in the

line cards of edge or core routers to protect potential victimsfrom being flooded, as shown in Fig. 1. For each potential

victim, RateGuard first periodically builds nominal traffic

profiles when there is no DDoS attack in the network. Upon

detecting a DDoS attack, RateGuard is activated to

dynamically rate-limit suspicious traffic according to the

victim’s target rate and nominal traffic profile.

Traffic

Manager

Network Processor

IP route Lookup

Packet Classification

Framer Switch

Fabric

MemoryCPU

Route

Controller

10Gbps10Gbps

Inbound

Pass/Drop packets

Based on the

overflow of LBs

RateGuard

Outbound

Provide information

to each ingress linecard to adjust the

drain rate of LBs

Line card 1

Line card N

Traffic

Manager

Network Processor

IP route Lookup

Packet Classification

Framer Switch

Fabric

MemoryCPU

Route

Controller

10Gbps10Gbps

Inbound

Pass/Drop packets

Based on the

overflow of LBs

RateGuard

Outbound

Provide information

to each ingress linecard to adjust the

drain rate of LBs

Line card 1

Line card N

Figure 1. RateGuard is implemented at ingress and egress line cards.

LB-based rate control has been widely used in ATM

networks and in Differentiated Services (DiffServ) in IP

networks. Because of its simple operation, it can quickly rate-

limit any excessive traffic beyond the predetermined rate set

according to the nominal traffic profile without the need for

complex processing. In other words, the response time of


978-1-4244-4148-8/09/$25.00 ©2009




RateGuard, a LB-based dynamic rate-limiting system, can be

much smaller than RTT; thus, it can avoid the FOFA problem

and react to FAA in real-time. RateGuard can effectively

mitigate LRA by rate-limiting the attacking traffic at the

ingress line cards. Thus, excess attacking traffic that would

have congested a router’s output link is now discarded at the

ingress line cards before reaching the egress line card.

RateGuard controls and monitors ingress and egress traffic

at the ingress and egress line cards, respectively, as shown inFig. 1. At the ingress line cards, an LB is assigned to each joint

attribute value. As soon as a packet destined to the identified

victim arrives, the associated LBs are updated in their

occupancy by plus one, where the drain rates, set by the

nominal traffic profile, are also used to reduce their occupancy.

If the newly arriving packet will cause any of the LBs to

overflow, it will be discarded; otherwise the packet passes. At

the egress line card, an aggregated rate to the victim is

measured and sent to the ingress line cards periodically, e.g., at

the period of a fraction of RTT. The ingress line cards can thus

dynamically adjust the LBs’ drain rate so as to bring the

aggregated rate to the victim closer to its targeted rate.

B. Nominal Traffic Profile with Sequential Bloom Filters

The huge space required by possible joint attribute values

makes it very hard for attackers to learn the nominal traffic

profile. On the other hand, it also makes the defense system

very costly as it has to store the large nominal traffic profile

and keep track of the large number of LBs. In viewing the

correlation among the packet’s attributes and the storage

requirement, we monitor traffic based on two sets of joint

attributes: Source IP prefix and TTL value (denoted as ST); IP

protocol-type, server port number, TCP Flag, and packet size

(denoted as ISFP). The strong correlations between Source IP

prefix and TTL value, and among the IP protocol-type, server

port number, TCP Flag, and packet size significantly reduces

the storage requirement of the nominal traffic profile.

To further reduce the storage requirement, we propose to

use Sequential Bloom Filters (SBF) to group multiple joint

attribute values into an LB. Obviously, if a joint attribute value

with large traffic volume shares the same LB with another one

with small volume, the flows with the small volume will be

adversely affected by those with the large volume. Instead, we

partition a nominal traffic profile with joint attribute values into

one of H +1 levels, based on their relative frequencies, as

shown in Fig. 2, where there are H thresholds.

Joint attribute value, e.g., Source IP subnet & TTL

PDF

Thd1

. . . . . .

Thd2

Thdh-1

Thdh

BF1

BFh-1

BFh

Joint attribute value, e.g., Source IP subnet & TTL

PDF

Thd1

. . . . . .

Thd2

Thdh-1

Thdh

BF1

BFh-1

BFh

Figure 2. Joint attribute values are separated based on traffic volume.

In the SBF, we use BF h to store the joint attribute values

whose relative frequencies are larger than Thd h as shown in

Fig. 2 and 3. More specifically, the joint attribute values are

used as keys and are hashed into multiple locations in the BF.

During a later query, the joint attribute value of an incoming

packet is first hashed into BF 1. If all the hashed locations have

been set (query result is yes), it will be further queried in the

BF 2. Until the query result is negative in the BF i, the incoming

packet will be mapped to one of the LBs associated with that

BF i by a hash function Hashi. As shown in Fig. 3, there is a set

of LBs associated with each BF and indexed by a hash.

If the first query in BF 1 gives a negative matching result, itmeans that the relative frequency of the joint attribute value is

either less than Thd 1 or the joint attribute value never exists in

the nominal traffic profile. Then those packets with a negative

query result in the BF 1 are mapped into a set of LBs associated

with each individual attribute value, as shown in Fig. 3.

BF1 BF2 BFh

Packet’s joint attribute value ST

Yes Yes Yes No No No

...

LBh-1,1

LBh-1,2

LBh-1,m

LBh,1

LBh,2

LBh,n

Hash2 Hashh Hashh+1

LB1,1

LB1,2 …

LB1,j

… …

LB1

LB2

LB256

LBip1

LBip2

LBipx

TTL value Source IP prefix

. . . … …

Hash1

LBsLBs associated with joint attribute STassociated with joint attribute STLBsLBs associated withassociated with

individual attributeindividual attribute

BF1 BF2 BFh

Packet’s joint attribute value ST

Yes Yes Yes No No No

...

LBh-1,1

LBh-1,2

LBh-1,m

LBh,1

LBh,2

LBh,n

Hash2 Hashh Hashh+1

LB1,1

LB1,2 …

LB1,j

… …

LB1

LB2

LB256

LBip1

LBip2

LBipx

TTL value Source IP prefix

. . . … …

Hash1

LBsLBs associated with joint attribute STassociated with joint attribute STLBsLBs associated withassociated with

individual attributeindividual attribute Figure 3. LBs grouped by Sequential Bloom Filters (SBF) to rate-limit

suspicious incoming traffic.

There are cases where joint attribute values of legitimate

packets are not recorded in the nominal traffic profile with joint

attributes. For instance, a change in network topology may

cause legitimate packets to possess new joint attribute values of

ST. To reduce the probability of mistakenly discarding these

legitimate packets whose joint attribute values do not appear in

the nominal traffic profile, we would examine their attribute

values individually instead of joint attribute values. In other words, two different sets of LBs are used to associate each

individual attribute (e.g., TTL values and source IP prefixes).

By associating LBs with individual attributes, RateGuard

tolerates those legitimate packets that possess new joint

attribute values and the suspicious traffic will be further rate-

limited according to the nominal traffic profile of each

individual attribute, as shown in the left dashed box in Fig. 3.

LB Size S i,j

Occupancy ui,j

Drain rate DRi,j

Arriving packets

Occupancy updating

timer ∆t i,j

LB Size S i,j

Occupancy ui,j

Drain rate DRi,j

Arriving packets

Occupancy updating

timer ∆t i,j

Figure 4. Parameters of Leaky Bucket (LB) of joint attribute i with value j.

C. Operations of Leaky Buckets (LBs)

An LB is associated with joint attribute value (or individual

attribute value associated with BF 1). As shown in Fig. 4, each

LB has four parameters: Drain Rate ( DRi,j), Occupancy (ui,j),


978-1-4244-4148-8/09/$25.00 ©2009




Occupancy updating timer ( ∆t i,j), and Size (S i,j), associated with

attribute i with value j in the nominal traffic profile. When

detecting a DDoS attack, aggregated rate ( Ra) is higher than the

victim’s targeted rate ( Rv), RateGuard starts the rate-limiting

process. Every incoming packet is then mapped into the

corresponding LBs based on the packet’s joint attribute values,

as shown in Fig. 3 and 5. The leaky-bucket occupancy ui,j is

updated as (1) when a packet destined to the victim arrives.

( ) ( ) ( ) ( )( )

1i j i j i j i j

i j i j

u k u k-1 DR k-1 t k

0 u k S

= + − × Δ

≤ ≤(1)

where ∆t i,j(k ) is the time interval between the arrival of the

current and previous packet. Obviously, ui,j(k ) is bounded by

the bucket size S i,j. If ui,j(k ) is less than S i,j, the packet passes.

Otherwise, RateGuard discards it and ui,j(k ) is equal to the

bucket size S i,j. For the two sets of joint attributes, ST and

ISFP, if an incoming packet causes any associated LB

overflows, it will be dropped as shown in Fig. 5.

LB11

. . . . . .

. . . . . .

Incoming Packet

Drop the packet, if

any LB overflows.

Otherwise, pass

the packet.

IP protocol-type, Server Port, TCP Flag, and Packet size (ISFP)

Source IP prefix and TTL value (ST)

LB12 LB1m

LB21 LB22 LB2n

S 12

u12

DR12

Query ST in SFB and Hashi (ST)

Query ISFP in SFB and Hash j (ISFP)

LB11

. . . . . .

. . . . . .

Incoming Packet

Drop the packet, if

any LB overflows.

Otherwise, pass

the packet.

IP protocol-type, Server Port, TCP Flag, and Packet size (ISFP)

Source IP prefix and TTL value (ST)

LB12 LB1m

LB21 LB22 LB2n

S 12

u12

DR12

Query ST in SFB and Hashi (ST)

Query ISFP in SFB and Hash j (ISFP)

Figure 5. Associate a leaky bucket (LB) to each joint (or separated) attribute

value to perform rate limiting in real-time.

LB’s drain rate DRi,j is proportional to the relative

frequency of attribute i with value j in the nominal traffic

profile. It is dynamically adjusted to bring the aggregated rate

of the victim to its targeted rate. DRi,j is initially set as (2).

However, it will be adjusted periodically from the aggregated

rate at the egress line card. Details are described below.

( )ij n i v DR P A j R= = × (2)

where ( )n i P A=j is the relative frequency of attribute i with

value j in the nominal traffic profile. S i,j should be chosen largeenough not to overflow the LB when feeding the defense

system with the traffic traces that were used to generate the

nominal traffic profile. More specifically, S i,j is set to the

maximal possible bucket occupancy during the above

calibration process so as to accommodate the burstiness of the

legitimate traffic but can rate-limit the bursty attacking traffic

from LRA. In general, the bursty volume of LRA attacking

traffic is much larger than that in the nominal traffic.

D. LB’s Drain Rate Update

This section describes how the drain rate is periodically

updated, with a period of, for instance, a fraction of the RTT in

the Internet. As the period is around 1ms, the update could be

done by a general purpose processor.

If Rv > Ra, the drain rate of each LB should be increased to

bring the aggregated rate of the victim closer to its targeted

rate. Since only the heavily occupied LBs can drain out more

traffic, we cannot simply increase the drain rate by the amount

of ( Rv > Ra)/ N , where N is the total number of LBs. Similarly, if

Rv < Ra, the drain rate should be decreased for those LBs that

are non-empty. Again, the drain rate cannot simply be

decreased by the amount of ( Ra - Rv)/ N . Rather, they are

increased or decreased as follows.

Let us assume the drain rate is updated at time q. Each

ingress line card first calculates the sum of the relative

frequencies of the corresponding LBs that are heavily occupied

(e.g., ui,j(q) reaches 95% of the bucket size S i,j), and the sum is

denoted as F h(q). Each ingress line card also calculates the sum

of the relative frequencies of the corresponding LBs that are

non-empty (e.g., above 5% S i,j). The second sum is denoted as

F n(q). More specifically, these two sums are calculated as

follows.

( ) ( ) ( ) 95h n i ij ij

F q = P A = j , if u q > % S ×∑ (3)

( ) ( ) ( ) 5n n i ij ij

F q = P A = j , if u q > % S ×∑ (4)

Each ingress line card sends the two calculated sums to the

egress line card. It then aggregates these two sums,

respectively, from each ingress line card, and sends back the

aggregated sums along with the aggregated traffic rate Ra(q) to

all ingress line cards. The aggregated sums are denoted as AF h(q) and AF n(q). Each ingress line card compares Ra(q) with Rv and proportionally adjusts its LBs’ drain rates as follows.

( )

( ) ( ) ( )( )( )

( )

v a

n i

ij ij v a

h

if R R q , P A j

DR q DR q-1 G R - R q AF q

>

== + × ×

(5)

( )

( ) ( ) ( )( )( )

( )

v a

n i

ij ij v a

n

if R R q ,

P A j DR q DR q-1 G' R - R q

AF q

<

== + × ×

(6)

where G and G’ are constant, called gain coefficient. The

gain coefficient can be decided with the trade-off between

small convergence time and system stability throughsimulations and training with real network traces.

E. Effective Defense against Three Kinds of Attacks

As mentioned before, the vulnerability of statistical filtering based defense systems is that their nominal traffic profile can

be learned by sophisticated attackers. RateGuard uses jointattribute values to construct the potential victim’s nominal

traffic profile to make it almost impossible for the attacker tolearn the profile. The attacker will either be discouraged in

trying to learn the profile due to the very long time required to

learn it or be caught during the learning process.

Most binary rule or statistical filtering based DDoS defense

systems are slow to react to fast adaptive attacks due to the


978-1-4244-4148-8/09/$25.00 ©2009




complex rule/policy update process. However, RateGuard can

effectively mitigate any fast adaptive attack in real-time by

rate-limiting the attacking traffic based on a pre-establishednominal traffic profile. Even if an attacker sends probing

packets and successfully learns some packet attribute values

that can pass RateGuard and then send hundreds and thousands

packets with those attribute values, most of them will be

discarded because their corresponding LBs will be overflowed.

RateGuard can effectively mitigate LRA by using jointattribute based LB to rate-limit the attacking traffic at the

ingress line cards. Thus, bursty attacking traffic that would

have congested a router’s output link is now discarded at the

ingress line cards. To affect the legitimate TCP flows destinedto the victim, the attacker can overflow a router’s output buffer

by periodically sending attack pulses with arbitrary destinationaddresses as long as they share the same output buffer with the

legitimate traffic to the victim. This kind of LRA is called the

infrastructure DDoS attack as opposed to the end-system

attack, which occurs as aggregated traffic toward the victim

exceeds that victim’s targeted rate. The former is very hard to

detect as its statistical characteristics are difficult to extract. To

defend these two kinds of attacks, RateGuard will need twodifferent kinds of nominal traffic profiles, one associated with

each potential victim and one associated with each output link.If the aggregated rate destined to the victim is larger than its

targeted rate, it is a sign of an end-system attack. Then,RateGuard will activate to rate-limit incoming traffic according

to the victim’s traffic profile as described above. On the other

hand, if the buffer at the egress line card is overflowed, it is a

sign of an infrastructure DDoS attack. Then, RateGuard will

activate to rate-limit the incoming traffic destined to the egress

line card according to the traffic profile associated with eachoutput link. If these two kinds of attacks are launched at the

same time, RateGuard will first rate-limit the incoming traffic

according to the victim’s traffic profile. However, if the buffer at an egress line card overflows even after the above ratelimiting, the RateGuard will further rate limit incoming traffic

destined to the egress line card based on the output link profile.

IV. PERFORMANCE EVALUATION

In this section, we evaluate the performance of the

proposed RateGuard scheme in a standalone setting viasimulation and compare it with our previous work on a CLP-

based packet filtering scheme [5]. The simulation setting isdescribed in Subsection A. From the simulation results in

Subsection B, we can see that both RateGuard and CLP-based

methods can effectively defend against various static attacks

including: random attack, SYN flood attack, SQL worm

slammer attack, nominal attack, and mixed attack. In

Subsection C, we have evaluated and compared the performance of RateGuard and CLP-based defense schemes

against dynamic attacks. In Subsection D, we show that the

CLP-based system fails to defend against AAS but RateGuard

significantly reduces the false positive rate and makes thedefense system more robust. In Subsections E and F, we show

the performance of RateGuard when defending against FAAand LRA, respectively.

A. Simulation Setting

To establish a fair comparison, all simulations have the

same overall common internal settings, input traffic, andattacking traffic (generated in the exact same way). Unless

stated otherwise, the default settings for the simulation are

summarized as follows.

We used the Internet trace archive of traffic destined to

Polytechnic University to obtain 15-minute duration traces

between 11:00 am and 11:15 am of each day. We built thenominal traffic profile by using the trace on April 17, 18, and

19, 2007 and used the trace on April 20 as legitimate traffic.

Our study shows that the legitimate traffic is relatively static

when compared to the nominal traffic profile with joint

attribute. For instance, the nominal traffic profile of jointattribute values ST and ISFP covers 89.6% and 80.1% of thelegitimate traffic, respectively. The total storage requirement

for a nominal traffic profile is significantly reduced to 663

Kbytes (including the storage for BFs and the LBs) by using

SFB to group multiple joint attribute values into an LB.

The average rate of the legitimate traffic is about 6,526 pps,

the victim’s targeted rate is 20,000 pps, and the attackingtraffic rate is 90,909 pps (about 14 times the legitimate traffic

rate). In simulation, RateGuard updates the drain rate of each

LB every 20ms.

We adopted the following three items as performance

criteria for the simulations: false positive rate, false negativerate, and effectiveness of the overload control. False positive

rate represents the percentage of legitimate packets that aremistakenly discarded, while false negative rate represents the

percentage of attacking packets admitted. To evaluate the

effectiveness of the overload controls, we compare the actual

aggregated output rate ( Ra) against the victim’s targeted rate( Rv). Ideally, the Ra/ Rv ratio should be very close to one (either

above or below).

The defense schemes can be classified into RateGuard and

our previous proposed PacketScore scheme, which assigns a

score for each arriving packet based on the so-called

Conditional Legitimate Probability (CLP) [5], and passes or discards the packet if its score is above or below the threshold.

The CLP is calculated based on the ratio of the attribute value’s

relative frequency between the nominal traffic profile and themeasured traffic profile when the latter is under attack. In

simulation, the CLP-based defense system builds the currenttraffic profile for each individual attribute and updates a

scorebook every 10 sec, for calculating each packet’s score.

B. Defend against Static Attacks

In this Subsection, we evaluate and compare the performance of RateGuard/CLP-based defense schemes against

the following types of static attacks:

(1) Random attack: all attribute values of the attacking

packets are uniformly randomized over their corresponding

allowable ranges; (2) SQL Slammer Worm attack; (3) TCP-

SYN Flood attack; (4) Nominal attack: all attacking packets

resemble the most dominant type of legitimate packets

observed in practice, i.e., 1500-byte TCP packets with server


978-1-4244-4148-8/09/$25.00 ©2009




port 80, TCP flag set to ACK, and uniformly random source IP

addresses; (5) Mixed attack: equally combines the above 4

types of attacks while keeping the overall attack rate to 14times that of the legitimate traffic rate.

Although random attack randomizes the attribute values in

flooding traffic to disguise the attacking characteristic, and

nominal attack mimics the dominant type of legitimate traffic

observed in practice, both RateGuard and CLP-based packet-

filtering schemes effectively filter out attacking traffic withoutsignificant impact on legitimate traffic. Even in the worst case

of using RateGuard defending against mixed attack, the false

positive rate is still kept below 0.123%. The corresponding

results of the performance under different types of attacks aredepicted in Table I.

TABLE I. PERFORMANCE OF R ATEGUARD/CLP-BASED SCHEMES AGAINST

VARIOUS STATIC ATTACKS

Type of

Attack

Type of

Defense

% False

+ve

% False

-ve Ra/ Rv

Random attack RateGuard 0.003 15.540 1.033

CLP 0.002 15.431 1.027

SQL Slammer

Worm

RateGuard 0.069 15.781 1.043

CLP <0.001 15.012 1.008

TCP-SYN

Flood

RateGuard 0.057 15.686 1.039

CLP <0.001 15.013 1.008

Nominal

attack

RateGuard <0.001 15.599 1.035

CLP <0.001 14.980 1.006

Mixed attack RateGuard 0.123 16.004 1.053

CLP 0.065 14.920 1.003

C. Defend against Dynamic Attacks

Dynamic attacks: similar to mixed attacks except that the

different types of attacks take turns. An attack type (one of random, SQL slammer worm, TCP-SYN flood, and nominal

attacks) is randomly selected and continues for anexponentially distributed period.

TABLE II. PERFORMANCE OF R ATEGUARD/CLP-BASED SCHEMES AGAINST

DYNAMIC ATTACKS

Type of Attack Type of

Defense

% False

+ve

% False

-ve Ra/ Rv

Dynamic attack

(30 sec)

RateGuard 0.039 15.532 1.041

CLP 1.815 14.007 0.965

Dynamic attack

(10 sec)

RateGuard 0.057 15.562 1.043

CLP 5.349 15.863 1.038

Dynamic attacks are more challenging due to their

complex, time-varying attacking packet characteristics. In our simulation, the measurement/scorebook generation interval of

CLP-based scheme is 10 sec and the average change-period of dynamic attack is either 10 or 30 sec. When the average

change-period of attack is much longer than the

measurement/scorebook generation interval (30 sec vs. 10 sec),

the change in attacking packet characteristics can readily betracked by the CLP-based scheme as shown in Table II.

However, when such changes occur at the same (or shorter)

time-scale of the measurement update interval, the CLP-basedscheme can be misled to defend against some no-longer-

existing attacking packets and thus cause a high false positive

rate 5.349%. Since our proposed RateGuard scheme can react

to various attacking traffic in real-time and the drain rateupdate very quickly (20ms), it can effectively defend against

dynamic attacks and is not sensitive to the change-period of

dynamic attacks as shown in Table II.

D. Defend against Adaptive Attacks with Statistical Filtering

Rules Scanning (AAS)

In this Subsection, we apply statistical filtering rulesscanning techniques to adaptively attack and evaluate and

compare the performance of RateGuard/CLP-based defense

schemes against AAS.

1) Statistical Filtering Rules Scanning

Here we describe the Statistical Filtering Rules Scanning

(SFRS) techniques that an attacker can use to learn a victim’snominal traffic profile. First, the attacker controls the zombies

to keep randomly generating a large volume of flooding traffic

destined to the victim. If the volume is larger than the victim’stargeted rate, the DDoS defense system will be activated with

the statistical filtering rules to drop the suspicious attacking

packets. Second, the attacker commands some zombies to send probing packets destined to the victim and monitor the

response. For instance, to scan an attribute (e.g., TTL value),

zombies first determine the values of the other attributes of the

probing packets, such as server port number with 80, protocol

type with TCP, packet size with 1500, and flag with ACK …,to mimic the major nominal traffic in the Internet. Zombies

then generate a given number (e.g., 30) of packets to the victim

with any possible TTL value and listen for acknowledgmentsfrom the victim. This way, the attacker can know which

attribute value can pass the defense system and which cannot.

To obtain the ratio among the possible attribute values innominal traffic profile, the attacker controls zombies to keep

increasing probing traffic rate for a particular attribute valueuntil the defense system reacts to those probing traffic to drop

them. In the statistics-based DDoS defense scheme [4]-[7], the

ratio of the Probability Distribution Function (PDF) for each

attribute value between nominal and current traffic is utilizedas distinguishing metrics. The defense scheme compares the

ratio with a threshold to decide if the packet should pass when

higher than the threshold or drop when lower. By increasing

the probing traffic rate for a particular attribute value, thelikelihood of those probing packets passing the statisticalfiltering based defense system decreases. The attacker detects

the dropping point for each attribute value and then uses this to

build the nominal traffic profile in PDF, which is proportional

to the dropping point.We use the TTL value 56 as an example. First, the zombies

keep sending probing packets with TTL value 56 with a givenrate (e.g., 1k packets/sec). Second, if most probing packets get

ACK back, the zombies send more (e.g., 2k packets/sec) with

TTL value 56. If most probing packets still can get ACK back,

the launching rate is increased exponentially until the attacker

observes the defense system begin to drop most of those probing packets. The attacker keeps the sending rate of probing

traffic at the dropping point for each possible TTL value and


978-1-4244-4148-8/09/$25.00 ©2009




then uses this to build the nominal traffic profile for the

attribute TTL. Based on this method, an attacker can estimate

the nominal traffic profile with great accuracy. An example of the SFRS results for the TTL value and the corresponding

nominal traffic profile of Polytechnic University’s trace are

shown in Figs. 7 and 6, respectively. We can see that the

attacker can successfully learn the majority of the nominal

traffic profile, even though there are some scanning errors

caused by variations of legitimate or random flooding traffic.

0

0.015

0.03

0.045

0.06

0.075

0.09

1 21 41 61 81 101 121 141 161 181 201 221 241

Figure 6. Nominal Traffic Profile of TTL Value

0

0.015

0.03

0.045

0.06

1 21 41 61 81 101 121 141 161 181 201 221 2 41

Figure 7. Scanning Profile of TTL Value by SFRS

2) Performance of Defending against AAS

In simulation, the attacker controls zombies to launch

random attacking traffic (90,909 pps) to overwhelm the victim

and send probing traffic (20,000 pps) to scan the nominaltraffic profile with attributes: TTL value, packet size, protocol

type, TCP flag, and server port number. We let SFRS scan the

attribute packet size and server port number only in the range

from 0 to 1500 bytes, and from 0 to 1024, respectively. This is because most packets fall into those two ranges. By this way,

the attacker can significantly reduce the scanning periods andget a more accurate scanning profile.

In AAS, the attacker controls zombies to generate flooding

traffic (90,909 pps) according to the PDF in discovered profile,

which is obtained by SFRS. The attribute source IP prefix with

16 bits was randomized over its allowable range.

TABLE III. PERFORMANCE OF R ATEGUARD/CLP-BASED SCHEMES AGAINST

ADAPTIVE ATTACKS WITH SFRS

Type of

Attack

Type of

Defense

% False

+ve

% False

-ve Ra/ Rv

AASRateGuard 0.010 15.542 1.033

CLP 29.603 17.359 1.018

In Table III, we show the performance of RateGuard/CLP-

based schemes against AAS. For CLP-based schemes, the false positive rate under AAS dramatically increases to 29.603%.

However, RateGuard is very robust under AAS and the false

positive rate is kept as below as 0.01%. The reason why the

RateGuard scheme is more robust is that it filters out attacking

packet based on the joint attribute values. As a result, it isdifficult for AAS to seriously degrade the performance of

RateGuard, unless AAS try to learn the nominal traffic profile

with joint attribute. However, the huge space required for

possible joint attribute values makes such joint attribute based

filtering rules scanning almost impossible.

E. Defend against Fast Adaptive Attack

In this Subsection, we evaluate the performance of RateGuard against FAA. In the simulation, attackers keep

sending probing packets destined to the victim at a rate of

10,000 pps. For those probing packets with responses from a

victim, the corresponding joint attribute value with sixaforementioned attributes will be stored in an attacking poolwith size 200, 2000, and 20,000. When the pool is full, the

oldest joint attribute value will be replaced by a new one. The

attacking traffic (90,909 pps) is launched by randomly

choosing the joint attribute values in the attacking pool.

TABLE IV. PERFORMANCE OF R ATEGUARD VS. FAST ADAPTIVE ATTACKS

Type of

Attack

Size of

Attack Pool

% False

+ve

% False

-ve Ra/ Rv

FAA 200 0.358 14.269 1.045

FAA 2,000 3.298 14.398 1.042

FAA 20,000 0.868 14.139 1.037

Since the CLP-based schemes need relative long time(compared to RTT) to build current traffic profile and update

the scorebook, it can not defend FAA in real-time. Table IVonly shows the result of RateGuard.

RateGuard effectively mitigated FAA in real-time by rate-

limiting the suspicious traffic based on a pre-establishednominal traffic profile. Even in the worst case, the false

positive rate is still kept below 3.3%, while that for other cases

are kept less than 1%. Unlike other DDoS defense systems that

based on binary rules or statistical filter policies, RateGuard

does not suffer from problem of FOFA and can rapidly react tovarious attacking traffic as long as the attacked LBs overflow.

From our simulation, we find that the false positive rate peaked

when the size of attacking pool is about 2,000. This is becausewhen the size of attacking pool is small, the attacking traffic

will be aggregated into a small number of LBs. On the other hand, when the size of attacking pool is large, some learned

joint attribute values in the attacking pool are too old. For

instance, when the size of attacking pool is 20,000, a learned

joint attribute value in the attacking pool needs more than 100

sec to be replaced by a new one. In general, the new learned

joint attribute value can lead the attacking traffic to be mapped

into an LBs having not overflow. However, the old one maylead to attack some LBs already overflowed with waste of

attacking traffic.

Period of the pulse: 1 secPeriod of the pulse: 1 sec

Length of the pulse: 200 msLength of the pulse: 200 ms

Magnitude of Magnitude of

the pulse:the pulse:

90,90990,909 pps pps

A t t a c k i n g r a t e i n


p p s

p p s

TimeTimePeriod of the pulse: 1 secPeriod of the pulse: 1 sec

Length of the pulse: 200 msLength of the pulse: 200 ms

Magnitude of Magnitude of

the pulse:the pulse:

90,90990,909 pps pps



p p s

p p s

TimeTime

Figure 8. Low-Rate TCP Attack


978-1-4244-4148-8/09/$25.00 ©2009




F. Defend against Low-Rate TCP Attack

In this Subsection, we have evaluated the performance of

RateGuard against LRA. In simulation, attackers keep sending periodic attack pulses, short bursts of random attacking traffic,

to overflow a router’s output link. The length, period, and

magnitude of the attacking pulses are set in RTT timescales

(200 ms), RTO timescales (1 sec), and 90,909 pps, respectively

as shown in Fig. 8. By synchronizing the attacking period to

the RTO duration, the attacker can force legitimate TCP flowson the congested output link to frequently enter the timeout

state and lead to low throughput.

Since LRA has very low average attacking traffic rate and

thus the CLP-based scheme can not defend LRA, Table V only

shows the result of RateGuard. In Table V, we can see thatRateGuard effectively defends against LRA with false negative

below 0.001%. By setting the LBs’ size according to the

method introduced in Section III, RateGuard accommodates

the most burstiness of the legitimate traffic while rate-limiting

the attacking pulse to the victim’s targeted rate. In general, the

bursty volume of LRA attacking traffic is much larger than that

of nominal traffic. Furthermore, the attacking traffic of LRA

does not follow the nominal traffic profile with joint attributes,making it easy to be filtered out.

TABLE V. PERFORMANCE OF R ATEGUARD VS. LOW-R ATE TCP ATTACKS

Type of

Attack

Type of

Defense

% False

+ve

% False

-ve Ra/ Rv

LRA RateGuard 0.001 16.090 1.061

V. CONCLUSION

In this paper, we presented the vulnerability of the current

DDoS defense systems and focus on three kinds of

sophisticated DDoS attacks (FAA, AAS, and LRA) that

seriously threat the current Internet and have not been solved

yet. Our study and simulation result shows that these kinds of intelligent attacks seriously degrade the performance of thestatistical filtering rules-based schemes, including our previouswork, the PacketScore scheme.

We propose a Leaky-Bucket (LB) based highly robust

DDoS defense system, called RateGuard. It extracts nominal

traffic profiles with joint attributes. By associating an LB with

each joint attribute value, the huge space required by possible joint attribute values makes it almost impossible for attackers

to scan the victim’s nominal traffic profiles and, thus, makes it

highly robust and flexible to cope with AAS and other

sophisticated attacks. LBs can react to FAA and LRA by rate-

limiting excessive traffic in real-time according to the victim’s

nominal traffic profile. Our results show that our proposedRateGuard scheme can effectively filter out attacking packets

from legitimate ones, when defending against various staticand dynamic attacks, FAA, AAS, and LRA.

R EFERENCES

[1] C. Jin, H. Wang, K. G. Shin, "Hop-count filtering: An effective defenseagainst spoofed DDoS traffic," in Proc. 10th ACMConf. Comput.Commun. Security, Oct. 2003, pp. 30–41.

[2] C.C. Zou,, N. Duffield, D. Towsley, W. Gong, "Adaptive DefenseAgainst Various Network Attacks," in IEEE J-SAC high-speed network

security –architecture, algorithms, and implementation, Oct. 2006.

[3] L. Kencl, C. Schwarzer, "Traffic-Adaptive Packet Filtering of Denial of Service Attacks," in Proceedings of the 2006 International Symposiumon WOWMOM , June 2006.

[4] Q Li, EC Chang, MC Chan, "On the Effectiveness of DDoS Attacks onStatistical Filtering," Proc. IEEE INFOCOM , 2005.

[5] Y. Kim, W. Lau, M. Chuah, J. Chao, "PacketScore: Statistical-basedOverload Control against Distributed Denial-of-Service Attacks," in

Proceedings of Infocom, 2004.

[6] P. Ayres, H. Sun, H. Chao, Wing C. Lau, "A Distributed Denial-of-Service Defense System Using Leaky-Bucket-Based PacketScore,"

ACNS 2005, New York, June 2005.

[7] P. Ayres, H. Sun, H. Chao, "ALPi: A DDoS Defense System for High-Speed Networks," accepted by IEEE J-SAC high-speed network security

–architecture, algorithms, and implementation , 2006.

[8] A. Kuzmanovic, E. Knightly. "Low-rate TCP-targeted denial of serviceattacks (the shrew vs. the mice and elephants)," In Proc. ACM SIGCOMM , Aug. 2003.

[9] M. Guirguis, A. Bestavros, I. Matta. "Exploiting the transients of adaptation for RoQ attacks on Internet resources," In Proc. IEEE ICNP ,2004.

[10] X. Luo, R. Chang. "On a new class of pulsing denial-of-service attacksand the defense," in Proc. Network and Distributed System Security

Symposium (NDSS), Feb. 2005.[11] M. Adler, "Trade-offs in probabilistic packet marking for IP traceback,"

in Journal of the ACM (JACM) , Volume 52 Issue 2, March 2005.

[12] U. Kiran, Tupakula, and V. Varadharajan, "Analysis of traceback techniques," in Proceedings of the ACSW , January 2006.

[13] B. Duwairi, A. Chakrabarti, and G. Manimaran, "An Efficient PacketMarking Scheme for IP Traceback," in Proc. of Networking 2004,Athens, Greece.

[14] Y. Xiang, and W. Zhou, "A defense system against DDOS attacks bylarge-scale IP traceback," in Information Technology and Applications,July 2005.

[15] T.K.T. Law, J.C.S. Lui, and D.K.Y. Yau, "You can run, but you can'thide: an effective statistical methodology to trace back DDoS attackers,"in Parallel and Distributed Systems, IEEE Transactions on, pp. 799 -813, Sep 2005.

[16] J. Mirkovic, G. Prier, and P. Reiher, "Attacking DDoS at the Source," in Proceedings of 10th IEEE International Conference on Network Protocols, November 2002.

[17] S. Floyd, S.M. Bellovin, J. Ioannidis, K. Kompella, R. Mahajan, and V.Paxson, "Pushback Messages for Controlling Aggregates in the

Network," draft-floyd-pushback-messages-00.txt, Internet draft, work in progress, July 2001.

[18] J. Ioannidis and S.M. Bellovin, "Implementing Pushback: Router-BasedDefense Against DDoS Attacks," In Proceedings of Network and

Distributed System Security Symposium, February 2002.

[19] M. Cai, Y. Chen, Y.-K. Kwok, and K. Hwang, "A Scalable Set-UnionCounting Approach to Pushing Back DDoS Attacks," USC GridSecTechnical Report TR-2004-21, Oct. 2004.

[20] Asta Networks Inc., http://www.astanetworks.com

[21] Arbor Networks Inc., http://www.arbornetworks.com

[22] Mazu Networks Inc., http://www.mazunetworks.com

[23] Riverhead Networks Inc., http://www.riverheadnetworks.com

[24] CyberOperations Inc, http://www.cyberoperations.com/

[25] S. Sarat, A. Terzis, "On the Effect of Router Buffer Sizes on Low-RateDenial of Service Attacks," in Proceedings of the ICCCN, Oct. 2005.

[26] H. Sun, J. Lui, and D. Yau, "Defending against low-rate TCP attack:Dynamic detection and protection," in Proc. IEEE ICNP , 2004.

[27] Y. Chen, and K. Hwang, and Y. Kwok, "Collaborative defense against periodic Shrew DDoS attacks in frequency domain," Technical Report TR 2005-11, USC Internet and Grid Computing Lab, 20.

978-1-4244-4148-8/09/$25.00 ©2009

Documents

Re Ate Guard