DDoS mitigation through a collaborative trust-based request prioritization

Disegno e contromisure per attacchi DDoS
effettuati da Botnet
-
DDoS mitigation through a collaborative
trust-based request prioritization

Faculty of Mathematical, Physical and Natural Sciences
Master Degree in Computer Science

Candidate:

Davide Paltrinieri
ID Number 1225725
Co-advisors:
Advisor: Prof. Neeraj Suri
Prof. Massimo Bernaschi Ing. Mirco Marchetti

Academic Year 2009/2010

Acknowledgments

The nancial assistance of EU project CoMiFin (Communication Middleware
for Monitoring Financial Critical Infrastructures (IST-225407)) towards this
research is hereby acknowledged.
Expressed opinions and reached conclusions are those of the author and
are not necessarily attribuitable to CoMiFin.

Preface
I would like to express my sincere appreciation to a number of people
and institutions for their support, useful comments and suggestions. The
following are included:

I thank Professor Massimo Bernaschi for his passion and skills in teaching
the course on operating systems II. I would like to thank him in particular
for the incredible freedom and availability to me, demonstrated throughout
the course of this study.
I am heartily thankful to Mirco Marchetti for the gratuitousness with
which he heard me out from the beginning, I thank him because without
his condence, my thesis proposal would never have taken a real shape. I
thank him for his competences, because any comparison with him have always
brought great results; for his time and willingness to receive me in spite of
holidays and closure of the department.
It is an honour for me to thank Professor Neeraj Suri for his trust. He
allowed me to complete this study in absolute freedom and discretion. I
would like to thank him especially for the soul that he has managed to pass
to his DEEDS research group.
From the DEEDS group I would like to thank Majid Khelil and Hamza
Ghani, for leaving me free to explore and to deepen a research eld of my
interest, for helping me to formulate the model on the basis of all the ideas
I had in my mind. Their ability to read my mind was certainly not a trivial
undertaking.

i

ii

I am in indebted to Stefan, who welcomed me more like a friend than
a collegue. I thank him for all chats we had during our run races in Her-
rengarten, for all kinds of beer we took (which I hope will never end...), for
making me understand that there are no suitable weather conditions for good
home-made icecream. I'm very thankful to him and Maria for having opened
their home doors for me as you do usually for an old friend.
I'd like to thank Thorsten, because even if he did not follow me till the
nal step, without his encouragement I could never nish the Darmstadt
Marathon. I thank him for being my stounch companion from the rst to
the last day in oce, and especially for being a friend inside and outside the
oce walls.
I thank Ute, for her high readiness to help, and her greatness of heart.
I Thank her for all the cakes and for oering me her home as my farewell
party place.
I would like to thank Daniel because without his assistance I could never
eat at the best worscht in town until getting to the FBI level.
My great thanks to Marco for his sympathy, and for his managing me
during my rst steps in the DEEDS group.
I'm greatful to all other DEEDS members, for all those cakes and beers
that they shares with from my rst days in Germany.

This thesis would not have being possible unless a help of Jelena Mirkovic,
the wealth of her studies, her passion and self-forgetfulness inspiration. I'm
very thankful to her because she taught me the importance of sharing re-
search results, because without her the DETERlab would probably not ex-
ist. I thank her and all the system administrator of DETERlab I worked with
personally. They helped me a lot to solve the problems that surfaced during
the implementation phase.
My special thanks to Corrado Leita for helping me to understand in more
details the operation of WOMBAT, till the point of having shared with me
the results of one of his articles before its publication. I thank him for giving
me the credentials for access to HARMUR and SGNET datasets, through
WAPI, and for letting me touch the power of WOMBAT.
I thank SMT2 OWA developers for helping me in debugging the errors
due to some esoteric implementations of my project.
I would like to show my gratitude to Stefano Zanero and all other members
of the Italian Chapter of IISFA for sharing with me their opinions and points
of views, in particularly the Privacy issues.
I'd like to thank all the friends of IISFA because they keep on transmit-
ting a style of professional growth that will never loose the importance of its
human and relational aspects.

iii

I thank Ekaterina, Ameed, Herve for deep chats and sharing in the
kitchen, for accomodation in student residence, to be short, for being the
best possible atmates ever.

My heartfelt thanks to all those who have accompanied me in these years
and helped me to achieve my goal.

Finally, I oer my regards and blessings to all those who supported me
in any respect during the completion of the project.

Davide

Contents

1 Introduction 1
2 DDoS and Existing Countermeasures 5
2.1 Survey of DDoS Attacks . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Attack organization . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Taxonomy of DDoS Attacks . . . . . . . . . . . . . . . 8
2.1.3 Bandwidth Depletion Attacks . . . . . . . . . . . . . . 9
2.1.4 Resource Depletion Attacks . . . . . . . . . . . . . . . 11
2.2 Survey of DDoS Countermeasure . . . . . . . . . . . . . . . . 14
2.2.1 Pushback (2002) . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Web-SOS (2004) . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 DefCOM (2003-2006) . . . . . . . . . . . . . . . . . . . 17
2.2.4 Speak-Up: DDoS Defense by Oense (2006) . . . . . . 19
2.2.5 OverDoSe: A Generic DDoS Protection Service Using
an Overlay Network (2006) . . . . . . . . . . . . . . . . 19
2.2.6 Portcullis (2006) . . . . . . . . . . . . . . . . . . . . . 21
2.2.7 Stop-It (2008) . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.8 TVA: Trac Validation Architecture (2009) . . . . . . 23
2.2.9 DDoS-Shield (2009) . . . . . . . . . . . . . . . . . . . . 23
2.3 Relevant Collaborative Infrastructure Systems . . . . . . . . . 25
2.3.1 CoMiFIN . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.2 WOMBAT . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.3 DShield . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.4 FIRE: FInding RoguE Networks . . . . . . . . . . . . . 31

3 Models Overview 33
3.1 Attacker and Victim Model . . . . . . . . . . . . . . . . . . . 33
3.1.1 Victim Model . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.2 Attacker Model . . . . . . . . . . . . . . . . . . . . . . 35
3.1.3 Defense Model . . . . . . . . . . . . . . . . . . . . . . 36
3.2 Defense Strategies . . . . . . . . . . . . . . . . . . . . . . . . . 37

v

vi CONTENTS

3.2.1 Detection . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.2 Classication . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.3 Response . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 Software Architecture 41
4.1 Logical Description . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.1 Detection . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.2 Classication . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.3 Response . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2 Model's Components Description . . . . . . . . . . . . . . . . 50
4.2.1 Border Router . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.2 SP: Smart Proxy . . . . . . . . . . . . . . . . . . . . . 51
4.2.3 SC: Suspicion Checking . . . . . . . . . . . . . . . . . . 52
4.2.4 ADL: Actions Deep Logger . . . . . . . . . . . . . . . 54
4.2.5 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.6 TCDB: Trust Collaborative Database . . . . . . . . . . 57
4.2.7 Auditing Room . . . . . . . . . . . . . . . . . . . . . . 59
4.2.8 Target Server . . . . . . . . . . . . . . . . . . . . . . . 61

5 Software Implementation 63
5.1 Required Software . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.1.1 SeleniumHQ . . . . . . . . . . . . . . . . . . . . . . . . 63
5.1.2 TC: Trac Control . . . . . . . . . . . . . . . . . . . . 65
5.1.3 SMT2: Simple Mouse Tracking . . . . . . . . . . . . . 67
5.1.4 OWA: Open Web Analytics . . . . . . . . . . . . . . . 67
5.1.5 Dosmetric . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.1.6 Other used software . . . . . . . . . . . . . . . . . . . . 68
5.2 Implementation Architecture Overview . . . . . . . . . . . . . 71
5.3 Implementation Components Description . . . . . . . . . . . . 72
5.3.1 Internet . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.3.2 Border Router . . . . . . . . . . . . . . . . . . . . . . 73
5.3.3 SmartProxy . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3.4 WS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.3.5 ADL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.3.6 Static Trust DataBase . . . . . . . . . . . . . . . . . . 76
5.3.7 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 76
5.3.8 Audit Room . . . . . . . . . . . . . . . . . . . . . . . . 77
5.4 Testbed description . . . . . . . . . . . . . . . . . . . . . . . . 77
5.4.1 DETERlab: cyber-DEfense Technology Experimental
Research laboratory Testbed . . . . . . . . . . . . . . . 78
5.4.2 Hardware Cluster Details . . . . . . . . . . . . . . . . . 78

CONTENTS vii

5.4.3 SEER . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.4.4 Custom Script . . . . . . . . . . . . . . . . . . . . . . . 81
5.4.5 Local test porting to DETERlab . . . . . . . . . . . . 82

6 Test Evaluation 85
6.1 Test Description . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.1.1 Single Run Experiment . . . . . . . . . . . . . . . . . . 85
6.1.2 Parameters Tuning . . . . . . . . . . . . . . . . . . . . 88
6.2 Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.2.1 Legitimate Client only . . . . . . . . . . . . . . . . . . 90
6.2.2 Small botnet . . . . . . . . . . . . . . . . . . . . . . . 90
6.2.2.1 Rening priority after rst attack . . . . . . . 92
6.2.3 Medium botnet . . . . . . . . . . . . . . . . . . . . . . 94
6.2.4 Large botnet . . . . . . . . . . . . . . . . . . . . . . . 100
6.2.5 Auditing Process . . . . . . . . . . . . . . . . . . . . . 103
6.3 Test Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

7 Conclusion and Future Work 109
7.1 Conlusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

A Custom Script s 113
A.1 Bots Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
A.1.1 batchlib.cfg . . . . . . . . . . . . . . . . . . . . . . . . . 114
A.1.2 wt.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
A.1.3 Latency.sh . . . . . . . . . . . . . . . . . . . . . . . . . 120
A.1.4 botd-known.sh . . . . . . . . . . . . . . . . . . . . . . . 122
A.1.5 Legitimate client session . . . . . . . . . . . . . . . . . . 126
A.2 DETERlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
A.2.1 test-4.ns . . . . . . . . . . . . . . . . . . . . . . . . . . 128
A.2.2 Nodes's cluster deployment . . . . . . . . . . . . . . . . . 132
A.3 SmartProxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
A.3.1 tc.c (before DDoS) . . . . . . . . . . . . . . . . . . . . . 136
A.3.2 TC rules . . . . . . . . . . . . . . . . . . . . . . . . . . 137
A.3.3 tc.c (Post DDoS) . . . . . . . . . . . . . . . . . . . . . . 138

Bibliography 139

Chapter 1

Introduction

Scalability and openness are among the main principles that inspired the de-
sign of the Internet, as well as two critical factors in its success. However, a
signicant drawback of the open design of the Internet is represented by the
lack of inherent security guarantees. On the Internet, anyone can send any
packet to anyone without being authenticated, including unsolicited packets
that deliver useless or even malicious payloads. Moreover, the lack of authen-
tication means that attackers can hide their real identity, making it dicult
for victims and for law enforcement agencies to pinpoint the real source of
the attack. All systems connected to the Internet are potential targets for
attacks since the openness of the Internet makes them accessible to malicious
trac.

A Denial of Service (DoS) attack aims to prevent legitimate clients to
access a service by making it unavailable. When the trac of a DoS attack
comes from multiple sources, possibly geographically distributed across the
Internet, we call it a Distributed Denial of Service (DDoS) attack. By using
multiple attack sources it is possible to amplify the amount of attack trac,
therby increasing the eectiveness of a DDoS attack and making it extremely
dicult to defend against it.

The rst DDoS attacks date back to 1988 with the release of the Morris
worm [52]. Since that time DDoS attacks have drastically increased in terms
of both frequency and impact. Many DDoS attacks are motivated by political
reasons, and recently several instances of DDoS attacks targeted well known
web sites and nancial institutions. Their eectiveness is also testied by the
emphasis with which DDoS attacks are often described in the news.

1

2 CHAPTER 1. INTRODUCTION

In 2010, several Bollywood companies hired Aiplex Software to launch DDoS
attacks on websites that did not respond to software take-down notices.
Piracy activists then created Operation Payback in September 2010 in retal-
iation. The original plan was to attack Aiplex Software directly, but upon
nding some hours before the planned DDoS that another individual had
taken down the rm's website, Operation Payback moved to launching at-
tacks against the websites of the copyright stringent organizations Motion
Picture Association of America (MPAA) and International Federation of the
Phonographic Industry, giving the two websites a combined total downtime
of 30 hours [50].
Later, in December 2010, WikiLeaks came under intense pressure to stop
publishing secret United States diplomatic cables. Corporations such as
Amazon, PayPal, BankAmerica, PostFinance, MasterCard and Visa either
stopped working with or froze donations to WikiLeaks, some due to political
pressure. In response, those behind Operation Payback directed their activ-
ities against these companies for dropping support to WikiLeaks. Operation
Payback launched DDoS attacks against PayPal, the Swiss bank PostFinance
and the Swedish Prosecution Authority. In December a coordinated DDoS
attack by Operation Payback brought down both the MasterCard and Visa
websites too [55].

Figure 1.1: Operation Payback results

There are two main kinds of DDoS attacks. The rst kind leverages soft-

3

ware vulnerabilities of a target by sending malformed packets that cause the
attacked service to crash. As opposed to that, the second kind of DDoS
use massive volumes of useless trac to occupy all the resources of the at-
tacked server, thus preventing it from serving requests coming from legitimate
clients. While it is relatively simple to protect a server against the rst form
of attack (by patching known vulnerabilities), the second form of attack is
not so easily prevented. Any server instantly becomes a potential target as
soon as its connection to the public Internet makes it reachable by any other
connected host.
The attacked resources are typically the bandwidth available to the target
web server, or the server-farm/data-center resources, such as Hard Disks,
CPUs and Databases. In particular, it is possible to carry out eective
DDoS attacks that only require relatively small trac volumes by issuing
several requests that require access to slow resources (such as databases) or
that cause the server to perform resource-intensive computations. Recent
research [53] shows that attackers are able to nd such bottlenecks, and to
exploit them.
For example, if they nd a bottleneck in the database they will try to
stu the database and put it in a lock state. They will also make attack
requests as similar as possible to requests coming from legitimate clients,
thus making it impossible to defend against the attack through trivial request
ltering techniques. The urgent need for eective solutions against such kind
of attacks is therefore evident.
Even though there are many books that deal with the subject and com-
mercial solutions available, these types of attacks continue to prove eective
and cause extensive damage.
The aim of this thesis is to design and evaluate new tools to defend against
application layer DDoS attacks [53].
A comprehensive survey of DDoS attack and mitigation strategies already
presented in the scientic literature is provided in Chapter 2. In the same
chapter we also describe other relevant research projects that focus on col-
laborative defense approaches, even though they do not focus specically on
DDoS attacks.
In Chapter 3 we dene the model of the attacks that we try to mitigate.
The aim of these attacks is the exhaustion of hardware resources of the
attacked server(s) and not the saturation of their bandwidth. Their strength
lies in the fact that it is very dicult to distinguish them from the trac
generated by legitimate clients. We also dene a new attack mitigation model
by taking the inspiration from previous solutions.
In Chapter 4 we present the logical description of the proposed solution,
and we provide details on the inner working of each component.

4 CHAPTER 1. INTRODUCTION

The implementation of the proposed solution is described in Chapter 5,
while Chapter 6 describes the experiments carried out to demonstrate the
eectiveness of the proposed solution.

Chapter 2

Distributed Denial of Service
Attacks and Existing
Countermeasures

In this chapter we describe rst a brief survey of the best known and most
popular DDoS attacks, while in the part 2.2, we provide a description in
literature of the state of the art for mitigation solutions with a brief analysis
of their pros and cons. Finally, in the last section we will mention some
collaborative infrastructure projects which have inspired and contributed to
the development of the solution we propose in this study.

2.1 Survey of DDoS Attacks

Below we will speak rst of the methods mostly used by attackers to form
armies (botnet) and to wage attacks from it, and after we will describe in
details the most popular DDoS attacks.

2.1.1 Attack organization
Agent-Handler model

An Agent-Handler DDoS attack network consists of clients, handlers, and
agents as shown in gure 2.1

5

6 CHAPTER 2. DDOS AND EXISTING COUNTERMEASURES

Figure 2.1: DDoS Agent Handler Attack model

The client platform is where the attacker communicates with the rest
of the DDoS attack network. The handlers are software packages located on
computing systems throughout the Internet that the attacker uses to commu-
nicate indirectly with the agents. The agent software exists in compromised
systems that will eventually carry out the attack on the victim system. The
attacker communicates with any number of handlers to identify which agents
are up and running, when to schedule attacks, or when to upgrade agents.
Depending on how the attacker congures the DDoS attack network, agents
can be instructed to communicate with a single handler or multiple handlers.
Usually, attackers will try and place the handler software on a compromised
router or network server that handles large volumes of trac. This makes it
harder to identify messages between the client and handler and between the
handler and agents. The communication between attacker and handler and
between the handler and agents can be via TCP, UDP, or ICMP protocols.
The owners and users of the agent systems typically have no knowledge that
their system has been compromised and will be taking part in a DDoS attack.
When participating in a DDoS attack, each agent program uses only a small
amount of resources (both in memory and bandwidth), so that the users of
these computers experience minimal change in performance. In descriptions
of DDoS tools, the terms handler and agents are sometimes replaced with
master and daemons respectively. Also, the systems that have been violated
to run the agent software are referred to as the secondary victims, while the
target of the DDoS attack is called the (primary) victim. An Agent-Handler
DDoS attack network consists of clients, handlers, and agents (see Figure
2). The client platform is where the attacker communicates with the rest of
the DDoS attack network. The handlers are software packages located on
computing systems throughout the Internet that the attacker uses to com-
municate indirectly with the agents. The agent

2.1. SURVEY OF DDOS ATTACKS 7

IRC-Based DDoS Attack Model

Internet Relay Chat (IRC) is a multi-user, on-line chatting system. It allows
computer users to create two-party or multi-party interconnections and type
messages in real time to each other [13]. IRC network architectures consist
of IRC servers that are located throughout the Internet with channels to
communicate with each other across the Internet. IRC chat networks allow
their users to create public, private and secret channels. Public channels
are channels where multiple users can chat and share messages and les.
Public channels allow users of the channel to see all the IRC names and
messages of users in the channel. Private and secret channels are set up by
users to communicate with only other designated users. Both private and
secret channels protect the names and messages of users that are logged on
from users who do not have access to the channel. Although the content
of private channels is hidden, certain channel locator commands will allow
users not on the channel to identify its existence, whereas secret channels are
much harder to locate unless the user is a member of the channel. An IRC-
Based DDoS attack network is similar to the Agent-Handler DDoS attack
model except that instead of using a handler program installed on a network
server, an IRC communication channel is used to connect the client to the
agents. By making use of an IRC channel, attackers using this type of DDoS
attack architecture have additional benets. For example, attackers can use
legitimate IRC ports for sending commands to the agents[13]. This makes
tracking the DDoS command packets much more dicult. Additionally, IRC
servers tend to have large volumes of trac making it easier for the attacker
to hide his presence from a network administrator. A third advantage is
that the attacker no longer needs to maintain a list of agents, since he can
simply log on to the IRC server and see a list of all available agents[13]. The
agent software installed in the IRC network usually communicates to the
IRC channel and noties the attacker when the agent is up and running. A
fourth advantage is that IRC networks also provide the benet of easy le
sharing. File sharing is one of the passive methods of agent code distribution
that we discuss in Section 4. This makes it easier for attackers to secure
secondary victims to participate in their attacks. In an IRC-based DDoS
attack architecture, the agents are often referred to as Zombie Bots or
Bots . In both IRC-based and Agent-Handler DDoS attack models, we will
refer to the agents as secondary victims or zombies.


2.1.2 Taxonomy of DDoS Attacks
There are a wide variety of DDoS attack techniques. We propose a taxonomy
of the main DDoS attack methods in Figure 2.2. There are two main classes
of DDoS attacks: bandwidth depletion and resource depletion attacks[12].
A bandwidth depletion attack is designed to ood the victim network with
unwanted trac that prevents legitimate trac from reaching the (primary)
victim system. A resource depletion attack is an attack that is designed to tie
up the resources of a victim system. This type of attack targets a server or
process on the victim system making it unable to process legitimate requests
for service.

Figure 2.2: DDoS Taxonomy

There are two main classes of DDoS attacks: bandwidth depletion and
resource depletion attacks. A bandwidth depletion attack is designed to ood
the victim network with unwanted trac that prevents legitimate trac from
reaching the (primary) victim system. A resource depletion attack is an
attack that is designed to tie up the resources of a victim system. This type
of attack targets a server or process on the victim system making it unable
to process legitimate requests for service.


2.1.3 Bandwidth Depletion Attacks
There are two main classes of DDoS bandwidth depletion attacks. A ood
attack involves the zombies sending large volumes of trac to a victim sys-
tem, to congest the victim system's bandwidth. An amplication attack
involves either the attacker or the zombies sending messages to a broadcast
IP address, using this to cause all systems in the subnet reached by the broad-
cast address to send a message to the victim system. This method amplies
malicious trac that reduces the victim system's bandwidth.

Flood Attacks

In a DDoS ood attack the zombies ood the victim system with IP trac.
The large volume of packets sent by the zombies to the victim system slows it
down, crashes the system or saturates the network bandwidth. This prevents
legitimate users from accessing the victim.

UDP Flood Attacks.

User Datagram Protocol (UDP) is a connectionless protocol. When data
packets are sent via UDP, there is no handshaking required between sender
and receiver, and the receiving system will just receive packets it must pro-
cess. A large number of UDP packets sent to a victim system can saturate
the network, depleting the bandwidth available for legitimate service requests
to the victim system. In a DDoS UDP Flood attack, the UDP packets are
sent to either random or specied ports on the victim system. Typically,
UDP ood attacks are designed to attack random victim ports. This causes
the victim system to process the incoming data to try to determine which
applications have requested data. If the victim system is not running any
applications on the targeted port, then the victim system will send out an
ICMP packet to the sending system indicating a destination port unreach-
able message. Often, the attacking DDoS tool will also spoof the source
IP address of the attacking packets. This helps hide the identity of the sec-
ondary victims and it insures that return packets from the victim system
are not sent back to the zombies, but to another computer with the spoofed
address. UDP ood attacks may also ll the bandwidth of connections lo-
cated around the victim system (depending on the network architecture and
line-speed). This can sometimes cause systems connected to a network near
a victim system to experience problems with their connectivity.


ICMP Flood Attacks.
Internet Control Message Protocol (ICMP) packets are designed for network
management features such as locating network equipment and determining
the number of hops or round-trip-time to get from the source location to the
destination. For instance, ICMP_ECHO_REPLY packets ( ping ) allow the
user to send a request to a destination system and receive a response with
the round trip time. A DDoS ICMP ood attack occurs when the zombies
send large volumes of ICMP_ECHO_REPLY packets to the victim system.
These packets signal the victim system to reply and the combination of trac
saturates the bandwidth of the victim's network connection. As for the UDP
ood attack, the source IP address may be spoofed.

Amplication Attacks
A DDoS amplication attack is aimed at using the broadcast IP address
feature found on most routers to amplify and reect the attack (see gure
2.3).

Figure 2.3: Amplication Attacks

This feature allows a sending system to specify a broadcast IP address
as the destination address rather than a specic address. This instructs the


routers servicing the packets within the network to send them to all the IP
addresses within the broadcast address range. For this type of DDoS attack,
the attacker can send the broadcast message directly, or the attacker can use
the agents to send the broadcast message to increase the volume of attacking
trac. If the attacker decides to send the broadcast message directly, this
attack provides the attacker with the ability to use the systems within the
broadcast network as zombies without needing to inltrate them or install
any agent software. We further distinguish two types of amplication attacks,
Smurf and Fraggle attacks.

Smurf Attacks. In a DDoS Smurf attack, the attacker sends packets
to a network amplier (a system supporting broadcast addressing), with the
return address spoofed to the victim's IP address. The attacking packets are
typically ICMP ECHO REQUESTs, which are packets (similar to a ping )
that request the receiver to generate an ICMP ECHO REPLY packet. The
amplier sends the ICMP ECHO REQUEST packets to all of the systems
within the broadcast address range, and each of these systems will return an
ICMP ECHO REPLY to the target victim's IP address. This type of attack
amplies the original packet tens or hundreds of times.

Fraggle Attacks. A DDoS Fraggle attack is similar to a Smurf attack in
that the attacker sends packets to a network amplier. Fraggle is dierent
from Smurf in that Fraggle uses UDP ECHO packets instead of ICMP ECHO
packets [56]. There is a variation of the Fraggle attack where the UDP ECHO
packets are sent to the port that supports character generation (chargen, port
19 in Unix systems), with the return address spoofed to the victim's echo
service (echo, port 7 in Unix systems) creating an innite loop [56]. The UDP
Fraggle packet will target the character generator in the systems reached by
the broadcast address. These systems each generate a character to send to
the echo service in the victim system, which will resend an echo packet back
to the character generator, and the process repeats. This attack generates
even more bad trac and can create even more damaging eects than just a
Smurf attack.

2.1.4 Resource Depletion Attacks
DDoS resource depletion attacks involve the attacker sending packets that
misuse network protocol communications or sending malformed packets that
tie up network resources so that none are left for legitimate users.


Protocol Exploit Attacks
TCP SYN Attacks. In TCP SYN Attack the attacker sends a succession
of SYN requests to a target's system. When a client attempts to start a TCP
connection to a server, the client and server exchange a series of messages
which normally runs like this:

1. The client requests a connection by sending a SYN (synchronize) mes-
sage to the server.

2. The server acknowledges this request by sending SYN-ACK back to the
client.

3. The client responds with an ACK, and the connection is established.

This is called the TCP three-way handshake, and is the foundation for every
connection established using the TCP protocol. The TCP SYN attack works
if a server allocates resources after receiving a SYN, but before it has received
the ACK.
In a DDoS TCP SYN attack, the attacker instructs the zombies to send
such bogus TCP SYN requests to a victim server in order to tie up the
server's processor resources, and hence prevent the server from responding
to legitimate requests. The TCP SYN attack exploits the three-way hand-
shake between the sending system and the receiving system by sending large
volumes of TCP SYN packets to the victim system with spoofed source IP
addresses, so the victim system responds to a non-requesting system. Even-
tually, if the volume of TCP SYN attack requests is large and they continue
over time, the victim system will run out of resources and be unable to re-
spond to any legitimate users.

PUSH + ACK Attacks. In the TCP protocol, packets that are sent to
a destination are buered within the TCP stack and when the stack is full,
the packets get sent on to the receiving system. However, the sender can
request the receiving system to unload the contents of the buer before the
buer becomes full by sending a packet with the PUSH bit set to one. PUSH
is a one-bit ag within the TCP header [13]. TCP stores incoming data
in large blocks for passage on to the receiving system in order to minimize
the processing overhead required by the receiving system each time it must
unload a non-empty buer. The PUSH + ACK attack is similar to a TCP
SYN attack in that its goal is to deplete the resources of the victim system.
The attacking agents send TCP packets with the PUSH and ACK bits set
to one. These packets instruct the victim system to unload all data in the


TCP buer (regardless of whether or not the buer is full) and send an
acknowledgement when complete. If this process is repeated with multiple
agents, the receiving system cannot process the large volume of incoming
packets and it will crash.

Malformed Packet Attacks
A malformed packet attack is an attack where the attacker instructs the
zombies to send incorrectly formed IP packets to the victim system in order
to crash the victim system. There are two types of malformed packet attacks.
In an IP address attack, the packet contains the same source and destination
IP addresses. This can confuse the operating system of the victim system
and cause the victim system to crash. In an IP packet options attack, a
malformed packet may randomize the optional elds within an IP packet
and set all quality of service bits to one so that the victim system must use
additional processing time to analyze the trac. If this attack is multiplied
using enough agents, it can shut down the processing ability of the victim
system.

Application Layer Attack
In a just-released report on botnet-generated DDoS attacks, Prolexic noted
that attackers are quickly tweaking their botnets to make attack trac look
increasingly similar to legitimate, routine trac.
Instead of the huge burst of trac that marks when an attack begins, trac
will begin to ramp up slowly as bots join the attack at random intervals with
each bot varying its attack style, making it increasingly dicult to separate
real users from bots, the report said [64].

There are several tools that automatically launch Layer 7 DDoS Attacks.
Really interesting is the

Apache L7DA (Layer 7 DDoS Attacks) The tool works by exhausting
Apache processes; this is done by sending incomplete request headers so
Apache keeps waiting for the nal header line to arrive, the tool instead just
sends a bogus header to keep the connection open. Besides Apache (both
versions 1.x and 2.x), Squid is also aected. Knowing how many servers
running on Apache there are, this makes the tool very dangerous since it
doesn't require absolutely any knowledge from the attacker. All he/she has
to do is run the tool and the target site goes down.


2.2 Survey of DDoS Countermeasure

Among various proposals, we can see mainly two schools of thought: the
capability-based approach[5, 21, 8, 6] and the lter-based approach [2, 3, 4].
Both advertise to enable a receiver to control the trac it receives, but
dier signicantly in methodology. The capability approach proposes to let
a receiver explicitly authorize the trac it desires to receive, while the lter
approach proposes to let a receiver install dynamic network lters that block
the trac it does not desire to receive. Advocates of lters have argued that
capabilities are neither sucient nor necessary to combat DoS [9], while
proponents of capabilities strongly disagree [6].
In this section we are going to explore the most relevant solutions that
were developed in the last years.

2.2.1 Pushback (2002)
Pushback is a cooperative mechanism that can be used to control an aggre-
gate upstream. The core idea behind Pushback is to congures routers to
rate limit the attacker as close is possible to the source. As it is shown in
gure 2.4 the congested router asks its adjacent upstream router to rate-limit
the aggregate of trac that seems to be malicious.

Figure 2.4: Pushback takes rate-limiting closer to the source(s).

This request is sent only to the neighbors that send more trac similar
to the detected aggregate, then also the neighbors can propagate Pushback
recursively to the upstream routers.
The most relevant benets introduced with this solution are:

2.2. SURVEY OF DDOS COUNTERMEASURE 15

• It's very powerful when the source address can't be trusted. In that case
indeed the congested router cannot narrow the congestion signature by
itself.

• Very good when the attackers are collocated on a path separate from
the legitimate trac.

The main weaknesses of Pushback are:

• Pushback does not completely block attack trac[2]. Instead, it aims
to rate limit the attack trac to its fair share of bandwidth.

• It absolutely needs high collaboration across router, so this is hard to
enforce in a realistic scenario as Internet.

• How to nd the perfect threshold as period of time in which the lter
on the aggregate is not needed anymore.

• When the attack is uniformly distributed, it cannot detect the aggre-
gate of the attack.

• If the attack can be sent from hosts on the same network of the victim,
push back has no eect on it.

• Can't work in non-contiguous deployment.

• If the source's IP addresses of the incoming request is not trust also
the aggregate upstream can be dicult to be well-determined. In this
case only the target could be trusted. The resulting lters then can
only be pushed halfway through the network between the target and
the sources of the attack.

In conclusion the ltering techniques of Pushback are really eective only if
the lters can be putted close to the source of the attack.

2.2.2 Web-SOS (2004)
Secure Overlay Services (SOS) is a network overlay mechanism designed to
counter the threats posed by Distributed Denial of Service attacks (DDoS).
WebSOS, is an adaptation of SOS for the Web environment that guar-
antees access to a web server that is targeted by a DDoS attack. The ap-
proach of WebSOS exploits two key characteristics of the web environment:
its design around a human-centric interface, and the extensibility inherent in
many browsers through downloadable applets . The goal of this solution is


to guarantee access to a web server for a large number of previously unknown
users, without requiring preexisting trust relationships between users and the
system.
WebSOS acts as a distributed rewall eliminating communication pinch-
points and thus preventing the Target Server's Routers from being congested.
Clients need to connect securely to an Access Point (Figure 2.5) and the
overlay network route him to the actual Target Server. The Target server
allows only the secret servlet (or a set of secret servlets) to connect through
the ltered Area. The ltering is done using elds that a router can lter
fast (e.g. the IP address of the secret servlet). The secret servlet's location
can be varied through time.

Figure 2.5: WebSOS ltering techniques

Below a consideration that comes from the related pubblicated paper[5]:

The disruption in the actual service depends on the number of
the secure overlay access points, the resources and distribution
of zombies of the actual attacker. The addition of the Graphic
Turing Tests allows us to accept non-authenticated trac which is
something that most web services require. Additionally Graphic
Turing tests (GTT) separate humans from automated attack scripts
and allow us more protection against naive automated attacks.
Finally GTTs provide the necessary time for the overlay heal
from the automated attacks. They prevent trac to penetrate
the overlay network and being routed to the Target server thus
making the actual Web service more resilient to DDoS attacks.


The main positive points of this solution are summarized in:

• Cooperation with other ISP/AS is not necessary;

• Autonomous decision for detecting and enforcing the defense mecha-
nism;

• No changes to protocol, web servers or browsers needed;

• Proactive approach to ghting Denial of Service (DoS) attacks;

• Overlay can self-heal when a participant node is attacked;

• Scalable access control.

While the weakness here are:

• Considerable overhead introduced: test shows that the latency increase
by a factor of 7 in some particular implementation[5];

• GTT can be guess [49, 48];

• Miss legacy solution: Its necessary to install an applet on each client.
Then not all the services/scenario of usage are allowed;

• Assumes, for security analysis, that no attack can come from inside the
overlay;

• Assumes that an attacker cannot mask illegitimate trac to appear
legitimate;

• To improve scalability, the number of SOAPs, Beacons, and Secret
Servlets are limited which lessens protection from DoS attacks;

2.2.3 DefCOM (2003-2006)
DefCOM[18] provides added functionality to existing defenses so they can
collaborate in DDoS detection and response. The nodes in the DefCOM
overlay are classied into three categories, based on the functionality they
provide during the attack:

1. Alert generator. The functionality is deployed on a native node (router)
close to the victim, which may have any sophisticated attack detection
mechanism. It receives an attack detection signal from its native node
and sends the alert message to all other DefCOM nodes through the


overlay. The alert contains the IP address of the attack's victim and
species a desired rate limit, e.g., the size of the victim's bottleneck
link.

2. Classier. The functionality is deployed on a native node close to the
source, which can perform trac dierentiation. A classier receives
packets from its native node, stamped with the legitimate or suspicious
mark it negotiated with this node. It re-stamps the packets with stamps
it negotiated with its peers, which ensures priority handling for stamped
trac downstream.

3. Rate-limiter. The functionality is deployed in a native node (router),
which performs a weighted fair share algorithm for prioritization be-
tween legitimate and suspicious trac class, and to drop unstamped
trac. The rate limiter reclassies trac it receives based on incoming
trac stamps and the amount of trac received from each peer. Trac
is reclassied as legitimate, suspicious or unstamped and it is given to
the weighted fair share algorithm.

Each native node can deploy one or more functionalities, depending on its
resources and the authorization within the overlay, but the placement of
nodes facilitates some functionalities better than others.
Below we itemize the main benets of this solution:

• Hybrid solution that can be improved and upgraded by design (add-on
friendly);

• Can lead to a wide range of DDoS threat (depending on the included
kind of defense mechanism);

• wide deployment (source-end/core-network/victim-end);

• Classiers and rate limiters are active only during an attack;

• The stamp on a packet (High/Low priority) it's periodically negotiated
with other peers;

• Security:

Global CA for joining the peer network of DefCOM;

Messages has the signature of the owner.

On the other hands DefCOM suers on these weakness:


• Filtering of trac is not ne-grain (HIGH/LOW priority);

• The active testing for detect if HIGH-stamped trac is really legiti-
mate, is simply based on a congestion responsive check. Because of
that for some scenario is not eective.

• Legitimate trac from legacy networks competes with attack for band-
width.

2.2.4 Speak-Up: DDoS Defense by Oense (2006)
Speak-up[21] is a defense against application-level distributed denial-of-service
(DDoS), in which attackers cripple a server by sending legitimate-looking re-
quests that consume computational resources (e.g., CPU cycles, disk). With
speak-up, a victimized server encourages all clients, resources permitting, to
automatically send higher volumes of trac. Speak-up is based on the as-
sumption that attackers are already using most of their upload bandwidth so
cannot react to the encouragement. Good clients, however, have spare up-
load bandwidth and will react to the encouragement with drastically higher
volumes of trac. The intended outcome of this trac ination is that the
good clients crowd out the bad ones, thereby capturing a much larger fraction
of the server's resources than before.

The experiment described in the paper [21] demonstrate that speak-up
causes the server to spend resources on a group of clients in rough proportion
to their aggregate upload bandwidth. While the authors of this original
solution declare that the test result makes the defense viable and eective
for a class of real attacks we denitely disagree.

Indeed a scenario in which attacks came from a botnet of compromised
web server like in [62] with Speak-up active could be even more dangerous in
comparison with it disabled. It's obvious that the upload available bandwidth
of web servers is incredibly bigger than those of common clients.

2.2.5 OverDoSe: A Generic DDoS Protection Service
Using an Overlay Network (2006)
OverDoSe uses a computational puzzle scheme to provide fairness in the
request channel. When a client wishes to connect to a server, it rst sends
a request to a name server to resolve the IP address of the server (step 1 in
Figure 2.6).


Figure 2.6: OverDoSe basic protocol

The name server returns a list of IP addresses of overlay nodes (step 2 in
Figure 2.6). The client selects an overlay node to which it sends a connection
request (step 3 in Figure 2.6). In response to a client's connection request, the
overlay node replies with the latest puzzle seed released by the server, as well
as a puzzle diculty level specied by the server (step 4 in Figure 2.6). The
client is expected to solve a 3 puzzle at or above the specied diculty level in
order to successfully set up a connection. The client generates a puzzle based
on the puzzle seed, solves the puzzle, and sends the puzzle solution to the
overlay node (step 5 in Figure 2.6). At this point the overlay node validates
the puzzle solution and forwards the request and the solution to the server
(step 6 in Figure 2.6). The server assigns a cookie to the requesting client,
and replies to the overlay node with the cookie and a ow specication (step
7 in Figure 2.6). The ow specication is a set of rules the overlay node must
enforce for regulating an established ow. The ow specication is updated
dynamically by the server. The overlay node then replies to the client with
the cookie, successfully completing connection setup. The client attaches
the cookie to all subsequent packets to the server. The overlay node then
routes trac between the client and the server, and polices the client's ow
according to the ow specication.


2.2.6 Portcullis (2006)
Portcullis aims to provide a defense against large-scale DDoS attacks: even
when under attack, a legitimate sender can successfully initiate a connection
with the receiver and communicate with low packet loss. Portcullis is based
on a new puzzle-based protection for capability request packets. Hence, the
main goal of the solution is to design a Denial-of-Capability resistant re-
quest channel for a capability system. This design is based on computational
puzzles, which we prove can provide optimal fairness for the request channel.
As a result, Portcullis strictly bounds the delay a collection of attackers can
impose on legitimate clients. To achieve per-computation fairness Portcullis
leverage a novel puzzle based mechanism, which enables all routers to easily
verify puzzle solutions and uses the existing DNS infrastructure to dissem-
inate trustworthy and veriable fresh puzzle challenges. By enforcing per-
computation fairness in the request channel, Portcullis severely limits the
attacker's ooding rate.
The Achilles heel of Portcullis as well as other capability proposals, is
that it uses puzzle, and we will describe more in details in paragraph 3.2.2
the weakness of these kind of solutions.

2.2.7 Stop-It (2008)
Stop-it is designed as lter-based DoS defense architecture. StopIt employs a
novel closed-control and open-service architecture to combat various strate-
gic attacks at the defense system itself, and to enable any receiver to block
the undesired trac it receives[2]. StopIt is resistant to strategic lter ex-
haustion attacks and bandwidth ooding attacks that aim to prevent the
timely installation of lters.

Figure 2.7: StopIt architecture


The architecture of Stop-it is shown in gure 2.7 where a dashed circle
represents an AS boundary. The gure depict also the steps to install a
StopIt lter.
First when a destination Hd detects the attack trac from a source H s,
it invokes the StopIt service (Router Rd ) to block the attack ow (H s ,H d )
for a desired period of time. In the second step the access router veries
this request to conrm that the source Hs is attacking the destination Hd
and sends a router-server request to the AS's StopIt server S d. At point 3 of
gure 2.7 the StopIt server Sd in the destination H d 's AS forwards an inter-
domain StopIt request to the StopIt server SS in the source H s 's AS to block
the ow (H S ,H d ) for the chosen period of time. In step 4 of gure 2.7 the
source StopIt server SS locates the access router RS of the attacking source
HS, and sends a server-router request to the access router. A StopIt server
ignores inter-domain StopIt requests that block itself to prevent deadlocks. In
the last step (5 of gure 2.7) the access router RS veries the StopIt request,
installs a lter, and sends a router-host StopIt request to the attacking source
HS. After receiving this request, a compliant host HS installs a local lter
to stop sending to H d.
The StopIt mitigation system focuses basically on two families of DDoS
attacks: Destination Flooding Attacks and Link Flooding Attacks.
In the Destination Flooding Attacks the Attackers send trac oods to a
destination in order to disrupt the destination's communications. The Link
Flooding Attacks instead aims to congest a link and disrupt the legitimate
communications that share that link.
The main eorts of the StopIt service are:

• Possibility of a wide incremental deployment;

• It includes a mechanism for prevent IP-Spoong[20] (trough BGP an-
nouncements and ingress ltering);

• Highly scalable.

On the other hands StopIt suers from the following weaknesses:

• If the attack does not reach the victim, but congests a link shared by
the victim, the lter are not installed. In this scenario a capability
based system outperforms Stop-IT.

• Sensible to uniformly distributed attacks: in such scenario the lters
cannot be implemented by design. In a realistic scenario in which a
botnet is uniformly distributed, bots could be detected as legitimate.


2.2.8 TVA: Trac Validation Architecture (2009)
Trac Validation Architecture (TVA)[8] is a network architecture that limits
the impact of Denial of Service (DoS) oods from the outset. TVA is based
on the notion of capabilities like SOS and Speak-UP [5, 21]. In TVA instead
of sending packets to any destination at any time, senders must rst obtain
permission to send from the receiver, which provides the permission in the
form of capabilities to those senders whose trac it agrees to accept. The
senders then include these capabilities in packets. This enables verication
points distributed around the network to check that trac has been autho-
rized by the receiver and the path in between, and hence to cleanly discard
unauthorized trac. TVA addresses a wide range of possible attacks against
communication between pairs of hosts, including spoofed packet oods, net-
work and host bottlenecks, and router state exhaustion.
The main benets of TVA are:

• Scalability: Incrementally deployable in the current Internet.

• No changes to Internet or legacy routers are needed.

• Use path identier for mitigate the problem of IP spoong.

• Fine-grain capabilities.

• Legitimate users are isolated from the attack trac through hierarchi-
cally fair queues.

The main weaknesses of TVA instead are:

• The path identier mechanism is also vulnerable to tags forging.

• vulnerable to ood of authorized trac: it simple share the bandwidth
for all using a fair-queuing approach based on the IP of the destination.
If the number of attackers is larger than the legitimate users the services
will be liable to the DDoS.

• Client with low request rate cannot be well protected due to the router
queues like in every capability based system [19].

2.2.9 DDoS-Shield (2009)
DDoS-Shield[22] is a counter-DDoS mechanism to protect the application
from layer-7 DDoS attacks. These attacks mimic legitimate clients and over-
whelm the system resources, thereby substantially delaying or denying service


to the legitimate clients. Its main goal is to provide adequate service to le-
gitimate clients even during the attack. The defense model of DDoS-Shield
consists of mitigation system integrated into a reverse-proxy that schedules
or drops attack requests before they reach the web-cluster tier. The DDoS-
Shield examines requests belonging to every session, parses them to obtain
the request type and maintains the workload- and arrival- history of requests
in the session.

Figure 2.8: DDoS-Shield Model

In gure 2.2.9 is shown the system architecture for DDoS-Shield that
consists of:

1. Suspicion assignment mechanism that uses session history to assign a
suspicion measure to every client session;

2. DDoS-resilient scheduler that decides which sessions are allowed to for-
ward requests and when depending on the scheduling policy and the
scheduler service rate.

The main idea behind DDoS-Shield is really interesting and it inspired
most part of our proposal. By the way, after analysing this solution we think
to prone the following issues:

legitimate proles poisoning: They don't incorporate the attack where
the attacker sends a large number of completely normal sessions (same
session- arrival rate, same workload prole and same request arrival
rate.

legitimate proles poisoning if we consider an always- or frequently- con-
nected botnet that lightly injects the same - or a set of similar session
pattern - the learning system starts to give a low level of suspicion

2.3. RELEVANT COLLABORATIVE INFRASTRUCTURE SYSTEMS 25

to this kind of trac. It means that when the attacker decides that
it's time to start the attack, the trac generated by botnet might be
detected as a low rate suspicion. Such kind of requests take an high
priority in the scheduler dispatching policy.
In this scenario the power of the attack can be even worser than without
using that mitigation technique.

Wide-spread Legitimate session when all bots are submitting the same
or a similar sequence of legitimate session that can be indistinguish-
able from a humans generated one. The power and broadness of a large
botnet can confuse the detection system used in DDoS-Shield then by-
pass its defenses.

2.3 Relevant Collaborative Infrastructure Sys-

tems

Hereby we will present the main collaborative infrastructures that have been
taken into account in our study, even if none of them make part of the projects
specically dedicated to DDoS mitigation.

We take this solution in consideration, because we tough fundamental
to combat cyber crime sharing reports regarding the recorded attacks on
its infrastructure. From received attacks it is possible to extract a lot of
information, that may be useful to understand the dynamics behind them.
Thanks to sharing this information between trusted partners it is possible
to form a basic that permits to strengthen their defenses and to be better
prepared against future attacks.

The rst project presented here is CoMiFIN, which purpose is exactly
the one described above, restricted to the world of Financial Institution (FI).
Then comes a paragraph about WOMBAT - another project funded by the
European community, that similarly aims to provide tools to analyze and
understand the existing and emerging threats targeting the Internet economy
and the net Citizens.

The third paragraph is about public project DShield, that like WOMBAT,
consists of a network of sensors that collect information about anomalies in
the Internet to a central database.

Finally, a brief description of FIRE - a service to identify rogue networks
and Internet Service Providers close the chapter.


2.3.1 CoMiFIN
Communication Middleware for Monitoring Financial Critical Infrastructure
is an EU project funded by the Seventh Framework Programme (FP7),
started in September 2008 and continuing for 30 months. The research area
is Critical Infrastructure Protection (CIP), focusing on the Critical Financial
Infrastructure (CFI).
CoMiFin does not perturb or require any changes to existing client infras-
tructures or proprietary networks. It is an add-on middleware layer struc-
tured as a stack of overlay networks built on top of the Internet in order
to exploit Internet business continuity. The system facilitates the sharing of
critical events among interested parties, which can in turn use these events
to trigger the necessary local protection mechanisms in a timely fashion. A
scheme of the communication structure in CoMiFIN is shown in gure 2.9.

Figure 2.9: CoMiFIN Framework

Subset of participants are commonly grouped in federations. Federations
are regulated by contracts and they are enabled through the Semantic Room
abstraction: this abstraction facilitates the secure sharing and processing
of information by providing a trusted environment for the participants to


contribute and analyze data. Input data can be real time security events,
historical attack data, logs, and other sources of information that concern
other Semantic Room participants. Semantic Rooms can be deployed on
top of an IP network allowing adaptable congurations from peer-to-peer to
cloud-centric congurations, according to the needs and the requirements of
the Semantic Room participants. A key objective of CoMiFin is to prove
the advantages of having a cooperative approach in the rapid detection of
threats. Specically, CoMiFin demonstrates the eectiveness of its approach
by addressing the problem of protecting nancial critical infrastructure. This
allows groups of nancial actors to take advantage of the Semantic Room
abstraction for exchanging and processing information.
Some of these shared information may include:

• Technical: Fault Notication

• Service Related: Interruptions, Updates

• Infrastructure: Power, Network Faults

• Security: Threat Notication, Phishing info, Detected Frauds, Intru-
sions, DoS Attacks

• Others: General Warnings

This information is consumed by the event processing engines installed at
each participating site. These event engines leverage the computing and
storage capabilities available in the local data center to discover malicious
attack patterns and other impending threats in a timely fashion.
Such sharing of information raises trust issues with respect to the infor-
mation owing in the SR. There can exist dierent types of SRs with dierent
levels of trust requirements. At one extreme there could be SRs formed by
nancial institutions that trust each other implicitly (e.g., branches of the
same bank), and consequently trust the information being processed and
shared in those SRs. At the other extreme, there could be SRs whose mem-
bership includes participants that are potential competitors in the nancial
market. In this case, the issue of trusting the information circulating in
a semantic room becomes a point of great importance and if this issue is
not adequately addressed, the semantic room abstraction will be infeasible
as nancial institutions will refrain from becoming members of it. For in-
stance, processed data in the SR related to DDoS attacks on FIs can be
used by a more specialized SR such as DDoS attacks on banks in a country
whose data can be, in turn, used by the SR related to DDoS attacks on a


specic bank in a specic country in order to provide partners with richer
services[42] .

A possible scenario of usage of the shared events information could be to
generate fast and accurate intruder blacklist. The philosophy of sharing such
kind of critical information as in CoMiFIN[31] gaves us a lot suggestion on
the designing phase of our proposal.

2.3.2 WOMBAT

The WOMBAT project is a collaborative European funded research project
that aims at providing new means to understand the existing and emerging
threats that are targeting the Internet economy and the net citizens. The
approach carried out by the partners include a data collection eort as well
as some sophisticated analysis techniques.

The Leurré.com project was initially launched in 2003 and has since then
been integrated and further improved (SGNET) and developed within the
WOMBAT project. It is based on a worldwide distributed system of honey-
pots running in more than 30 dierent countries covering the ve continents.
The main objective with this infrastructure is to get a more realistic picture
of certain classes of threats happening on the Internet by collecting unbiased
quantitative data in a long-term perspective.

WOMBAT records all packets sent to its sensor machines, on all plat-
forms, and it stores the whole trac into a database, enriched with some
contextual information and with meta-data describing the observed attack
sessions. A simple example of the interaction between some components of
WOMBAT is shown in gure 2.10.


Figure 2.10: SGNET framework

A source is dened in SGNET/WOMBAT as the contiguous activity
on an IP address. Due to the bias introduced by dynamic addressing an IP
address cannot be generally reliably considered as a good way to identify an
attacker. There are a number of situations for which IP A.A.A.A at day X
Is likely to be associated to a completely dierent machine at day Y.
For this reason, they dene a source as the activity of a given IP address
when it's not separated by a long silence time. If IP A.A.A.A is observed
attacking one of them honeypot sensors, and then is silent for more than 25
hours, and then is witnessed again, it's considered as a dierent source since
we have no evidence that we are still dealing with the same machine.
The meta-data collected in the database help to dene what they call
attack events [38], a representation of specic activities over limited period
of times. The attack events enables to observe the evolution of what they
hypothesize to be armies of zombies, some of them remaining visible for more
than 700 days.
The attack events highlights the existence of coordinated attacks launched
by a group of compromised machines, i.e. a zombie army. They compute
action set as a set of attack events that are likely due to same army. Through
the action set they are able to derive the size and the lifetime of the zombie
armies.
The researchers involved in the WOMBAT project present a new attack
attribution method [37]. This analytical method aims at identifying large
scale attack phenomena composed of IP sources that are linked to the same


root cause. All malicious sources involved in a same phenomenon constitute
what they call a Misbehaving Cloud (MC).
When an huge amount of data are collected, a big issue remain on the
way it's possible to get useful information out of the database. For solving
this problem it was developed a set of API for query on WOMBAT database.
WAPI is a set of API developed by the project partners of WOMBAT that
allow an integrated access to dierent attack dataset. Every single dataset
has his own maintainer that handles certicates for accessing the database.
We think that the information coming from such huge database could be
a powerful instrument useful for a lot of dierent investigation scenarios.

2.3.3 DShield
Dshield is a community-based collaborative rewall log correlation system.
It receives logs from volunteers world wide and uses them to analyze attack
trends. It is used as the data collection engine behind the SANS Internet
Storm Center (ISC). It is one of the public most dominating attack correlation
engine with worldwide coverage. DShield is regularly used by the media to
cover current events. Analysis provided by DShield has been used in the early
detection of several worms. DShield data is regularly used by researchers to
analyze attack patterns. The goal of the DShield project is to allow access
to its correlated information to the public at no charge to raise awareness
and provide accurate and current snapshots of internet attacks. Several data
feeds are provided to users to either include in their own web sites or to use
as an aide to analyze events.
Sites such as DShield.org not only compile global worst oender lists
(GWOLs) of the most prolic attack sources, they regularly post rewall
parsable lters of these lists to help the Internet community ght back.
DShield represents a centralized approach to blacklist formulation, with more
than 1000 contributors providing a daily perspective of the malicious back-
ground radiation that plagues the Internet. The published GWOL captures
a snapshot of those class C subnets whose addresses have been logged by
the greatest number of contributors. Another common practice is for a local
network to create its own local worst oender list (LWOL) of those sites that
have attacked it the most. LWOLs have the property of capturing repeat
oenders that are indeed more likely to return to the local site in the fu-
ture. LWOLs are by denition completely reactive to new encounters with
previously unseen attackers. The GWOL strategy, on the other hand, has
the potential to inform a local network of highly prolic attackers, it also has
the potential to provide a subscriber with a list of addresses that will simply
never be encountered.


Both of these dierent approaches are a possible solution to the same
problem encountered in WOMBAT regarding a way for extract meaningful
data from such huge database. To this end a techniques called HPB[40]
(Highly Predictive Blacklisting) was developed.

Highly Predictive Blacklisting Highly Predictive Blacklisting is a dier-
ent approach to blacklist formulation in the context of large-scale log sharing
repositories, such as DShield. The objective of HPB is to construct a cus-
tomized blacklist per repository contributor that reects the most probable
set of addresses that may attack the contributor over a prediction window
that may last several days. The HPB enumerate all sources of reported at-
tackers and assign each of them a ranking score relative to its probability
to attack the contributor in the future. The ranking score is based on ob-
servation of the particular attacker's past activities, as well as the collective
attack patterns exhibited by all other attackers in the alert repository. This
is another key dierence between our HPB algorithm and the other blacklist
strategies. In the compilation of GWOL and LWOL or their like, each black-
list entry is selected solely based on its own attack history. HPB strategy, in
contrast, takes a collective approach. HPB attacker selection is inuenced by
both an attacker's own attack patterns and the full set of all attack patterns
found within the dataset. A correlations among the contributors introduced
by the collection of attackers is here introduced, i.e., the amount of attacker
overlap between each pair of contributors. The ranking score in HPB cares
not only how many contributors have reported the attacker but also who
gave the reports. It favors attackers reported by many contributors that are
also correlated (have many common attackers) with the contributor under
consideration. The contributor correlation used in HPB is inspired by a work
of Katti et al [29].

2.3.4 FIRE: FInding RoguE Networks
FIRE[41] is a novel system to identify and expose organizations and ISPs
that demonstrate persistent, malicious behavior. FIRE can help isolate net-
works that tolerate and aid miscreants in conducting malicious activity on
the Internet. To make this possible, FIRE actively monitors botnet commu-
nication channels, drive-by-download servers, and phishing web sites. This
data is rened and correlated to quantify the degree of malicious activity for
individual organizations. With respect to root cause analysis, these results
can be used to pinpoint and to track the activity of rogue organizations,
preventing criminals from establishing strongholds on the Internet. Also, the


information can be compiled into a null-routing blacklist to immediately halt
trac from malicious networks.

Chapter 3
Models Overview

3.1 Attacker and Victim Model

In this section we describe rst the victim model, in other words, the target
system that we assume. Second we describe the attacker model: the strate-
gies used by the attacker to make the attack successful. Finally we describe
our proposed defense model.

3.1.1 Victim Model
We consider a general victim model as a multiple resources pool of servers. In
our experiments, we focus on a Portal Content Management System (CMS)
application hosted on a web cluster, which consists of multiple-tiers for pro-
cessing requests as shown in g. 3.1.
In the gure it is possible to see all the tiers of the architecture. At
the top there is a Border Router that is commonly used within a company's
infrastructure as components between Internet and the internal network.
Below the Border router a Load balancer has the duty of balancing the
requests that need to be forwarded to the replicated WebServers. As WS tier
we intend the layer of the WebServer Software, i.e Apache, IIS, Nginx.
We dene a portal session as HTTP/1.1 session over a TCP socket con-
nection that is initiated by a client with the web server tier. The HTTP/1.1
sessions are persistent connections and allow a client to send requests and
retrieve responses from the web-cluster without incurring the overhead of
opening a new TCP connection for request. A legitimate HTTP/1.1 session
consists of multiple requests sent during the lifetime of the session. These re-
quests are either sent in a closed-loop fashion, i.e., the client sends a request
and then waits for the response before sending the next request. Otherwise

33

34 CHAPTER 3. MODELS OVERVIEW

Figure 3.1: Target Architecture

they are pipelined, i.e., the client can send several requests without wait-
ing for their response and thus have more than one pending requests on the
server. A page is typically retrieved by sending one main request for the
textual content and several embedded requests for the image-les embedded
within the main page. The main requests are typically dynamic and involve
processing at the database tier while embedded requests are usually static as
they involve processing only at the web-cluster tier.

Every tier in the system consists of multiple limited resources, such as:
computation, storage and network bandwidth. We assume that all tiers mon-
itor continuously the resources in the tier and generate periodically resource
utilization reports as well as overall system statistics at the application layer,
such as throughput and response time. It's said that the system is under a
resource attack when a surge in a resource's usage is accompanied by reduc-
tion in throughput and has an increase in response time without a DDoS
attack detected at lower layers.

3.1. ATTACKER AND VICTIM MODEL 35

3.1.2 Attacker Model
Most powerful attack scenarios are an extension of those in DDoS-Shield[22]
and described below.
The goal of the attacker is to overwhelm one or more server resources
therefore legitimate clients experience high delays or lower throughput thereby
reducing or eliminating the capacity of the servers to its intended clients. The
attacker uses the application interface in order to issue requests that can
mimic legitimate client requests, but whose only goal is to consume server
resources. We assume that the application interface presented by the servers
is known (e.g., HTTP, XML, SOAP) or can be discovered (e.g., UDDI[58]
or WSDL[57]). We consider session-oriented connections to the server, e.g.,
HTTP/1.1 session on a TCP connection with the server. We assume that the
attacker has commandeered a large number of machines distributed across
dierent geographical areas, organized into server farms known as botnets.
To start a TCP session, an attacker can either use the actual IP address of the
compromised machine or spoof that address with one chosen from botnet's
addresses.
Based on the workload parameters that the attacker can leverage to exe-
cute layer-7 attacks, we divide these attacks into the following three classes,
according to DDoS-Shield[22]:

1) Request Flooding Attack: where each attack session issues requests
at an increased rate as compared to a non-attacking session.

2) AsymmetricWorkload Attack: where every attack session sends a hi-
gher proportion of requests that are more taxing on the server in terms
of one or more specic resources. The request rate within a session
is not necessarily higher than normal. This attack diers from the
request-ooding attack in that it causes more damage per request by
selectively sending heavier requests. Moreover, this attack can be in-
voked at a lower request rate, thereby requiring less work from the
attacker and making detection increasingly dicult.

3) Repeated One-Shot Attack: it is a degenerate case of the asymmetric
workload attack, in which the attacker sends only one heavy request in
a session instead of sending multiple heavy requests per session. Thus,
the attacker spreads its workload across multiple sessions instead of
across multiple requests in a few sessions. The main benets of this
spreading is that the attacker is able to evade detection and potential
service degradation to the session by closing it immediately after send-
ing the request. The asymmetric request ooding attack and its vari-
ants exploit the heterogeneity in processing times for dierent request


types. The attacker can obtain the information about server resources
consumed by dierent legitimate request types through monitoring and
proling.

It is not really relevant if the user is logged into the system or not, as well as
it also can be connected through HTTPS authenticated session. A possible
scenario here is when only a subset of the botnet's nodes is connected before
the real attack, and only when the attacker wants to launch the DDoS, all
the nodes are used, (maybe for a very short period of time). This situation
can confuse a large number of defense techniques that are based on the de-
tection of peaks of never seen before clients, and in general all the solutions
that tag under attack as legitimate the clients that are connected when the
system is not under attack.
We assume that the worst case scenario is when the attacker knows the full
proling data, and therefore can select requests that maximize the amount
of server resources consumed. However, in general, this type of information
can only be obtained through proling and timing the server responses from
outside. For instance, to obtain the average server processing time per re-
quested page, the attacker uses a web-crawler to obtain the total (network
+ server) delay in processing the request.
We assume that each bot is clever enough to solve every kind of puzzle
test either directly or through a forwarding system[48].
In the previously presented model of attack the requests can be generated
in dierent manners, and we generalize them in:

1. Frantic Crawler: An automatic software running on single or multiple
distributed nodes, that follows every link it nds, or a subset of them.

2. Cloned Legitimate Recorded Session: A sequence of requests that can
come from a recorded legitimate session, and that is forwarded to each
member of the botnet.

3. Randomized Legitimate Recorded Session: Like a legitimate recorded
session, but more smart. It includes random noise inside the session
like random mouse's movements from the origin to the target position,
random links following, random elds lling.

3.1.3 Defense Model
We introduce a new collaborative counter-DDoS mechanism to protect the
application from layer-7 DDoS attacks and provide adequate service to legit-
imate clients even during the attack.

3.2. DEFENSE STRATEGIES 37

Our defense model consists of dierent components that all together im-
prove the reliability of the Web application during the attack. The core
components here are: the Smartproxy, Advanced Deep Logger, and the Rep-
utation Database.
The smartproxy prioritizes the incoming request on the base of the trust
level of the source that generates it, before they reach the web-cluster tier.
The Advanced Deep Logger is a set of tools that improve the collection of
the information which are typically stored on the Web Server logs, that make
easier the auditing process during and after the attack.
The Reputational Database is owned and updated by a group of trusted
partner that want to share useful information of malicious clients that have
tried to attack his own systems. In this database all the information about
the trust level of the malicious clients are collected and continuously updated
with the information coming from the most recent attacks. Information on
the trust level might also be aected by attacks' information coming from
trusted third-party entities. Even if the situation described above is just a
simple attack attribution techniques, we had to make some assumptions in
our model for logging the real source of the request and not just a spoofed one.
There are some existing techniques that can detect whether the IP is spoofed
or not and we assume that they are used on the network infrastructure of
the ISP or own network before the webserver (as described in [24, 25]).
Further we will extend the detection process used in DDoS-Shield[22] by
checking periodically how many IP sources (that make part of our database)
are connected, and nd a threshold that can suggest our system to improve
the level of ltering. For example, we can achieve it being more restricted
with the resources given to clients in the scheduler policy, or by asking to
lter the malicious IP as far as possible from the web server.

3.2 Defense Strategies

The studied solution is mainly based on three phases: the detection of the
DDoS on the protected system, the classication of the incoming requests
between legitimate and (possible) malicious trac, and the response against
the detected attack.

3.2.1 Detection
The detection of a DDoS attack is not easy and has a lot of dierent ap-
proaches. A lot of dierent approaches are mainly based on an anomaly
detection by the trac distribution or volume [45, 33], or by the detection of


already known attack's signatures[46, 47]. Proling a legitimate behavior is
not easy, as well we cannot know every attacks signature since there will be
always a new one, never seen/known before. Both of these approaches are
not helpful in our attacker model, considering that we assume the attacker's
behavior as a well-chosen human generated sequence of actions. Since this
can be a real scenario (submitted from a legitimate user) it must not be
detected as a bad behavior, maybe only because it is far from the compared
legitimate proles. Otherwise it means that the sets of good proles are too
small to allow possible application usage. In other words, it will reect in an
higher number of detected false negatives.
A statistical system, which bases its decision on a starting training set,
usually has a trade-o on how exible it should be. We can split such kind
of statistical system in two main families: o-line and on-line.
In the rst (o-line) case the training set is commonly built in a custom
and safe environment (usually used for testing and production). This setup
makes impossible to put bad data on it, but that means also that some good
behavior (for anomaly-based systems), or attackers signature (in the case of
signature-based systems), is not included in the initial training set because it
is impossible to cover all these kinds of behavior. This issue will be inevitably
reected in detection of false positives or negatives.
On the other hand, the on-line family is prone to poison attacks, in the
sense that the attacker has a chance to inject customized data to the system
until they become a part of the legitimate training set. That's also the
problem of DDoS Shield, that we want to improve and extend.
Our approach for detection is based more on the user perception than on
the variation on the QoS like in [16] but we extend this process monitoring
also the workload of the single critical components of our architecture (CPU,
Disk, Memory Load) and thanks to a new metric, that we propose, based on
the number of suspected clients concurrently connected to our system in a
certain time frame.

3.2.2 Classication
One of the main problems to distinguish legitimate from malicious trac
is commonly reduced to the problem of distinguishing DDoS from a Flash-
Crowds. During the last years the bots interaction with the application has
become very close to the human behavior. This issue makes very dicult to
distinguish bots from humans.
As we have already discussed the leaks of statistical approaches in the
detection of a DDoS, such kind of system may suer the same issues in the
classication process. In fact, distinguish legitimate users from malicious

3.2. DEFENSE STRATEGIES 39

trough a statistical system at Layer-7 without detecting false positives or
negatives is a big challenge.

One of the main alternatives to distinguish humans from bots is to give
to the clients a reverse Turing test to solve, i.e. captcha or more in general a
puzzle-based test. Unfortunately, there are a lot of studies about techniques
that makes these tests solvable by a bot. When the puzzle is too hard to be
solved in an automatic way, the attacker can also hire people for solving that
(slow approach but eective anyway in spamming scenarios), or it can simply
forward this information to popular website that oers resources illegally
like movies, music and copyrighted software. Since the only cost that is
required for accessing this (expensive) resources is to solve an easy puzzle,
every user that is interested in such kind of resources becomes unwitting
accomplice of the DDoS attack. Then it doesn't matter how hard are these
puzzles to be solved.

Puzzle-based solutions are commonly used in capability systems, in which
after some active (i.e. puzzle) or passive analysis the client gets a boolean
access to the protected system. Unfortunately, this approach can be very
dangerous because the bots are becoming really smart and if they are able
to solve the puzzle, as we have described above, in proposed solutions they
get a capability to access the system. They can access the system until the
capability expires.

We think that the best approach is to use a ne-grain level of suspicion
that has to be assigned to suspected clients. That allows our system to reduce
the problems related to the detection of false positive clients like in [22]. But
instead of classifying clients thanks to a comparison with some good proles,
we rely on information in a collaborative and shared database, in which
partners of the collaborative infrastructure can share information about the
sources of detected attacks and from which they can get information about
the suspicion level of clients.

To improve the database and to reduce the detection of false negatives, we
use some known automatic techniques, like crawler trap for detecting unfair
crawler or some randomized bot's actions. In order to improve the detection
of other unknown attacks we increase the collected data from the users, in
the logs, with other information, like the user's actions, keystrokes, mouse
movements. Thanks to this information we aid an auditor in perpetrating a
forensic analysis for detecting malicious actions and the sources from which
that was generated.


3.2.3 Response
After having classied the incoming trac, the common approaches to handle
the malicious one are to redirect or to drop it. Dropping the trac could
be dangerous in case of false positive detected, as well as redirect trac for
further analysis can be interesting like in Roaming Honeypots [44] for further
analysis. In our scenario, in which the attacker has a high interaction with
the applications, we cannot be absolutely sure about the legitimate/malicious
intention of the user from the beginning. In fact, as we have discussed before,
giving a test to all the clients, or to their suspected subset, help mitigate our
attacker model since we assume that the attacker is protocol compliant and
is able to solve these kind of tests.
Similar to DDoS-Shield[22] we think that the best solution is to sched-
ule the incoming requests on the base of a ne-grain suspicion level thanks
to what we call Smart Proxy, and in case there are not enough resources
available for that suspected clients, to drop these requests.
Nevertheless, our suspicion assignment method is completely dierent and
it is based on the reputation of the clients. Furthermore, to reduce the trac
and computation on the Smart Proxy we use also a Pushback[4] approach
on the border router of the company that is hosting the server farm. In this
way, we are able to shape the trac that comes from the already suspected
clients as close as it is possible to the source of the trac, so the Smart Proxy
can get a benet from it.
At the end of the attack in any case it will be possible to do a forensics
analysis thanks to actions collected from the clients that can be correlated
with the data in the collaborative database for speeding-up the auditing
process and then for nding all the sources of the attack; the submission of
this data to the database gives the benet to the target as well as to all the
members of the collaborative database to be ready for further attacks from
that sources.

Chapter 4

Software Architecture

In this Chapter we present rst the logical description of our defense solu-
tion proposal, then in the second section we describe the features of every
component.

41

42 CHAPTER 4. SOFTWARE ARCHITECTURE

4.1 Logical Description

In the picture 4.1 you see the model overview of our solution. In the fol-
lowing subsections we describe each aspect of our proposal categorizing it as
detection, classication and response.

Figure 4.1: Model Overview

4.1. LOGICAL DESCRIPTION 43

4.1.1 Detection
We agree with Mirkovic et al.[16] regarding the importance of measuring the
perception of service quality from a client's perspective. As usually human
users are the rst victim aected by a denial of service on a server, since
they can perceive a degradation of service due to the DoS. Measuring this
perception is not the main focus of this study and we think that the existing
metrics based on QoS proposed by Mirkovic et al. can be very useful in our
scenario as well. We'd like to summarize it here:

A transaction represents a higher-level task whose completion
is perceptible and meaningful to a user. A transaction usually
involves a single request-reply exchange between a client and a
server, or several such exchanges that occur close in time.

A transaction is successful if it meets all the QoS requirements of its corre-
sponding application. If at least one QoS requirement is not met, a transac-
tion is considered failed. Transaction success/failure is the core of the metrics
proposed by [16] for measuring the perception of the user.
The transaction success/failure measures are aggregated into several in-
tuitive composite metrics:

Percentage of failed transactions (pft) per application type. This met-
ric directly captures the impact of a DoS attack on network services by
quantifying the QoS experienced by users. For each transaction that
overlaps with the attack, we evaluate transaction success or failure.

DoS-hist metric shows the histogram of pft measures across applications,
and is helpful to understand each application's resilience to the attack.
The DoS-level metric is the weighted average of pft measures for all
applications of interest. This metric may be useful to produce a single
number that describes the DoS impact but is highly dependent on the
chosen application weights and thus can be biased.

QoS-ratio is the ratio of the dierence between a transaction's trac mea-
surement and its corresponding threshold, divided by this threshold.
The QoS metric for each successful transaction shows the user-perceived
service quality, in the range (0, 1], where higher numbers indicate bet-
ter quality. It is useful to evaluate service quality degradation during
attacks.

Like Mirkovic we compute it by averaging QoS-ratios for all trac measure-
ments of a given transaction that have dened thresholds. For failed trans-
actions, we compute the related QoS-degrade metric, to quantify severity of

DDoS mitigation through a collaborative trust-based request prioritization

DDoS mitigation through a collaborative trust-based request prioritization

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie DDoS mitigation through a collaborative trust-based request prioritization

Ähnlich wie DDoS mitigation through a collaborative trust-based request prioritization (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

DDoS mitigation through a collaborative trust-based request prioritization