Your SlideShare is downloading. ×
Disegno e contromisure per attacchi DDoSeffettuati da Botnet-DDoS mitigation through a collaborativetrust-based request pr...
AcknowledgmentsThe nancial assistance of EU project CoMiFin (Communication Middlewarefor Monitoring Financial Critical Inf...
ii     I am in indebted to Stefan, who welcomed me more like a friend thana collegue.    I thank him for all chats we had ...
iii   I thank Ekaterina, Ameed, Herve for deep chats and sharing in thekitchen, for accomodation in student residence, to ...
iv
Contents1 Introduction                                                                     12 DDoS and Existing Countermea...
vi                                                                      CONTENTS           3.2.1   Detection     . . . . ....
CONTENTS                                                                               vii          5.4.3   SEER        . ...
viii   CONTENTS
Chapter 1IntroductionScalability and openness are among the main principles that inspired the de-sign of the Internet, as ...
2                                        CHAPTER 1.         INTRODUCTION    In 2010, several Bollywood companies hired Aip...
3ware vulnerabilities of a target by sending malformed packets that cause theattacked service to crash.   As opposed to th...
4                                        CHAPTER 1.    INTRODUCTION    The implementation of the proposed solution is desc...
Chapter 2Distributed Denial of ServiceAttacks and ExistingCountermeasuresIn this chapter we describe rst a brief survey of...
6         CHAPTER 2.      DDOS AND EXISTING COUNTERMEASURES              Figure 2.1: DDoS Agent Handler Attack model    Th...
2.1.   SURVEY OF DDOS ATTACKS                                                7IRC-Based DDoS Attack ModelInternet Relay Ch...
8          CHAPTER 2.      DDOS AND EXISTING COUNTERMEASURES2.1.2 Taxonomy of DDoS AttacksThere are a wide variety of DDoS...
2.1.   SURVEY OF DDOS ATTACKS                                                92.1.3 Bandwidth Depletion AttacksThere are t...
10         CHAPTER 2.     DDOS AND EXISTING COUNTERMEASURESICMP Flood Attacks.Internet Control Message Protocol (ICMP) pac...
2.1.   SURVEY OF DDOS ATTACKS                                              11routers servicing the packets within the netw...
12          CHAPTER 2.       DDOS AND EXISTING COUNTERMEASURESProtocol Exploit AttacksTCP SYN Attacks.             In TCP ...
2.1.   SURVEY OF DDOS ATTACKS                                              13TCP buer (regardless of whether or not the bu...
14         CHAPTER 2.       DDOS AND EXISTING COUNTERMEASURES2.2      Survey of DDoS CountermeasureAmong various proposals...
2.2.   SURVEY OF DDOS COUNTERMEASURE                                         15   •   Its very powerful when the source ad...
16         CHAPTER 2.      DDOS AND EXISTING COUNTERMEASURESto guarantee access to a web server for a large number of prev...
2.2.   SURVEY OF DDOS COUNTERMEASURE                                        17The main positive points of this solution ar...
18               CHAPTER 2.    DDOS AND EXISTING COUNTERMEASURES         overlay. The alert contains the IP address of the...
2.2.   SURVEY OF DDOS COUNTERMEASURE                                         19   •   Filtering of trac is not ne-grain (H...
20         CHAPTER 2.      DDOS AND EXISTING COUNTERMEASURES                     Figure 2.6: OverDoSe basic protocol     T...
2.2.   SURVEY OF DDOS COUNTERMEASURE                                        212.2.6 Portcullis (2006)Portcullis aims to pr...
22            CHAPTER 2.       DDOS AND EXISTING COUNTERMEASURES     The architecture of Stop-it is shown in gure 2.7 wher...
2.2.   SURVEY OF DDOS COUNTERMEASURE                                           232.2.8 TVA: Trac Validation Architecture (...
24          CHAPTER 2.      DDOS AND EXISTING COUNTERMEASURESto the legitimate clients. Its main goal is to provide adequa...
2.3.   RELEVANT COLLABORATIVE INFRASTRUCTURE SYSTEMS 25       to this kind of trac.   It means that when the attacker deci...
26         CHAPTER 2.       DDOS AND EXISTING COUNTERMEASURES2.3.1 CoMiFINCommunication Middleware for Monitoring Financia...
2.3.   RELEVANT COLLABORATIVE INFRASTRUCTURE SYSTEMS 27contribute and analyze data.    Input data can be real time securit...
28         CHAPTER 2.      DDOS AND EXISTING COUNTERMEASURESspecic bank in a specic country in order to provide partners w...
2.3.   RELEVANT COLLABORATIVE INFRASTRUCTURE SYSTEMS 29                        Figure 2.10: SGNET framework   A source is ...
30         CHAPTER 2.      DDOS AND EXISTING COUNTERMEASURESroot cause. All malicious sources involved in a same phenomeno...
2.3.   RELEVANT COLLABORATIVE INFRASTRUCTURE SYSTEMS 31   Both of these dierent approaches are a possible solution to the ...
32        CHAPTER 2.      DDOS AND EXISTING COUNTERMEASURESinformation can be compiled into a null-routing blacklist to im...
Chapter 3Models Overview3.1     Attacker and Victim ModelIn this section we describe rst the victim model, in other words,...
34                                     CHAPTER 3.       MODELS OVERVIEW                       Figure 3.1: Target Architect...
3.1.   ATTACKER AND VICTIM MODEL                                             353.1.2 Attacker ModelMost powerful attack sc...
36                                     CHAPTER 3.       MODELS OVERVIEW       types. The attacker can obtain the informati...
3.2.   DEFENSE STRATEGIES                                                      37   Our defense model consists of dierent ...
38                                     CHAPTER 3.        MODELS OVERVIEWalready known attacks signatures[46, 47]. Proling ...
3.2.   DEFENSE STRATEGIES                                                     39trough a statistical system at Layer-7 wit...
40                                      CHAPTER 3.     MODELS OVERVIEW3.2.3 ResponseAfter having classied the incoming tra...
Chapter 4Software ArchitectureIn this Chapter we present rst the logical description of our defense solu-tion proposal, th...
42                           CHAPTER 4.      SOFTWARE ARCHITECTURE4.1     Logical DescriptionIn the picture 4.1 you see th...
4.1.   LOGICAL DESCRIPTION                                                     434.1.1 DetectionWe agree with Mirkovic et ...
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
DDoS mitigation through a collaborative trust-based request prioritization
Upcoming SlideShare
Loading in...5
×

DDoS mitigation through a collaborative trust-based request prioritization

2,021

Published on

Master Thesis

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,021
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
24
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "DDoS mitigation through a collaborative trust-based request prioritization"

  1. 1. Disegno e contromisure per attacchi DDoSeffettuati da Botnet-DDoS mitigation through a collaborativetrust-based request prioritizationFaculty of Mathematical, Physical and Natural SciencesMaster Degree in Computer ScienceCandidate:Davide PaltrinieriID Number 1225725 Co-advisors:Advisor: Prof. Neeraj SuriProf. Massimo Bernaschi Ing. Mirco MarchettiAcademic Year 2009/2010
  2. 2. AcknowledgmentsThe nancial assistance of EU project CoMiFin (Communication Middlewarefor Monitoring Financial Critical Infrastructures (IST-225407)) towards thisresearch is hereby acknowledged. Expressed opinions and reached conclusions are those of the author andare not necessarily attribuitable to CoMiFin. Preface I would like to express my sincere appreciation to a number of peopleand institutions for their support, useful comments and suggestions. Thefollowing are included: I thank Professor Massimo Bernaschi for his passion and skills in teachingthe course on operating systems II. I would like to thank him in particularfor the incredible freedom and availability to me, demonstrated throughoutthe course of this study. I am heartily thankful to Mirco Marchetti for the gratuitousness withwhich he heard me out from the beginning, I thank him because withouthis condence, my thesis proposal would never have taken a real shape. Ithank him for his competences, because any comparison with him have alwaysbrought great results; for his time and willingness to receive me in spite ofholidays and closure of the department. It is an honour for me to thank Professor Neeraj Suri for his trust. Heallowed me to complete this study in absolute freedom and discretion. Iwould like to thank him especially for the soul that he has managed to passto his DEEDS research group. From the DEEDS group I would like to thank Majid Khelil and HamzaGhani, for leaving me free to explore and to deepen a research eld of myinterest, for helping me to formulate the model on the basis of all the ideasI had in my mind. Their ability to read my mind was certainly not a trivialundertaking. i
  3. 3. ii I am in indebted to Stefan, who welcomed me more like a friend thana 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...), formaking me understand that there are no suitable weather conditions for goodhome-made icecream. Im very thankful to him and Maria for having openedtheir home doors for me as you do usually for an old friend. Id like to thank Thorsten, because even if he did not follow me till thenal step, without his encouragement I could never nish the DarmstadtMarathon. I thank him for being my stounch companion from the rst tothe last day in oce, and especially for being a friend inside and outside theoce 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 farewellparty place. I would like to thank Daniel because without his assistance I could nevereat at the best worscht in town until getting to the FBI level. My great thanks to Marco for his sympathy, and for his managing meduring my rst steps in the DEEDS group. Im greatful to all other DEEDS members, for all those cakes and beersthat 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. Imvery 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 withpersonally. They helped me a lot to solve the problems that surfaced duringthe implementation phase. My special thanks to Corrado Leita for helping me to understand in moredetails the operation of WOMBAT, till the point of having shared with methe results of one of his articles before its publication. I thank him for givingme the credentials for access to HARMUR and SGNET datasets, throughWAPI, and for letting me touch the power of WOMBAT. I thank SMT2 OWA developers for helping me in debugging the errorsdue to some esoteric implementations of my project. I would like to show my gratitude to Stefano Zanero and all other membersof the Italian Chapter of IISFA for sharing with me their opinions and pointsof views, in particularly the Privacy issues. Id 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 itshuman and relational aspects.
  4. 4. iii I thank Ekaterina, Ameed, Herve for deep chats and sharing in thekitchen, for accomodation in student residence, to be short, for being thebest possible atmates ever. My heartfelt thanks to all those who have accompanied me in these yearsand helped me to achieve my goal. Finally, I oer my regards and blessings to all those who supported mein any respect during the completion of the project. Davide
  5. 5. iv
  6. 6. Contents1 Introduction 12 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 . . . . . . . . . . . . . 313 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
  7. 7. vi CONTENTS 3.2.1 Detection . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.2.2 Classication . . . . . . . . . . . . . . . . . . . . . . . 38 3.2.3 Response . . . . . . . . . . . . . . . . . . . . . . . . . 404 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 Models 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 . . . . . . . . . . . . . . . . . . . . . . . 615 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
  8. 8. CONTENTS vii 5.4.3 SEER . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 5.4.4 Custom Script . . . . . . . . . . . . . . . . . . . . . . . 81 5.4.5 Local test porting to DETERlab . . . . . . . . . . . . 826 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.3.1 Rening priority after rst attack . . . . . . . 98 6.2.4 Large botnet . . . . . . . . . . . . . . . . . . . . . . . 100 6.2.4.1 Rening priority after rst attack . . . . . . . 101 6.2.5 Auditing Process . . . . . . . . . . . . . . . . . . . . . 103 6.3 Test Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067 Conclusion and Future Work 109 7.1 Conlusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 7.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110A 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 Nodess 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) . . . . . . . . . . . . . . . . . . . . . . 138Bibliography 139
  9. 9. viii CONTENTS
  10. 10. Chapter 1IntroductionScalability 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, asignicant drawback of the open design of the Internet is represented by thelack of inherent security guarantees. On the Internet, anyone can send anypacket to anyone without being authenticated, including unsolicited packetsthat deliver useless or even malicious payloads. Moreover, the lack of authen-tication means that attackers can hide their real identity, making it dicultfor victims and for law enforcement agencies to pinpoint the real source ofthe attack. All systems connected to the Internet are potential targets forattacks since the openness of the Internet makes them accessible to malicioustrac. A Denial of Service (DoS) attack aims to prevent legitimate clients toaccess a service by making it unavailable. When the trac of a DoS attackcomes from multiple sources, possibly geographically distributed across theInternet, we call it a Distributed Denial of Service (DDoS) attack. By usingmultiple attack sources it is possible to amplify the amount of attack trac,therby increasing the eectiveness of a DDoS attack and making it extremelydicult to defend against it. The rst DDoS attacks date back to 1988 with the release of the Morrisworm [52]. Since that time DDoS attacks have drastically increased in termsof both frequency and impact. Many DDoS attacks are motivated by politicalreasons, and recently several instances of DDoS attacks targeted well knownweb sites and nancial institutions. Their eectiveness is also testied by theemphasis with which DDoS attacks are often described in the news. 1
  11. 11. 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 rms 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-
  12. 12. 3ware vulnerabilities of a target by sending malformed packets that cause theattacked service to crash. As opposed to that, the second kind of DDoSuse massive volumes of useless trac to occupy all the resources of the at-tacked server, thus preventing it from serving requests coming from legitimateclients. While it is relatively simple to protect a server against the rst formof attack (by patching known vulnerabilities), the second form of attack isnot so easily prevented. Any server instantly becomes a potential target assoon as its connection to the public Internet makes it reachable by any otherconnected host. The attacked resources are typically the bandwidth available to the targetweb server, or the server-farm/data-center resources, such as Hard Disks,CPUs and Databases. In particular, it is possible to carry out eectiveDDoS attacks that only require relatively small trac volumes by issuingseveral requests that require access to slow resources (such as databases) orthat cause the server to perform resource-intensive computations. Recentresearch [53] shows that attackers are able to nd such bottlenecks, and toexploit them. For example, if they nd a bottleneck in the database they will try tostu the database and put it in a lock state. They will also make attackrequests as similar as possible to requests coming from legitimate clients,thus making it impossible to defend against the attack through trivial requestltering techniques. The urgent need for eective solutions against such kindof 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 eectiveand cause extensive damage. The aim of this thesis is to design and evaluate new tools to defend againstapplication layer DDoS attacks [53]. A comprehensive survey of DDoS attack and mitigation strategies alreadypresented in the scientic literature is provided in Chapter 2. In the samechapter we also describe other relevant research projects that focus on col-laborative defense approaches, even though they do not focus specically onDDoS 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 theattacked server(s) and not the saturation of their bandwidth. Their strengthlies in the fact that it is very dicult to distinguish them from the tracgenerated by legitimate clients. We also dene a new attack mitigation modelby 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.
  13. 13. 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 theeectiveness of the proposed solution.
  14. 14. Chapter 2Distributed Denial of ServiceAttacks and ExistingCountermeasuresIn this chapter we describe rst a brief survey of the best known and mostpopular DDoS attacks, while in the part 2.2, we provide a description inliterature of the state of the art for mitigation solutions with a brief analysisof their pros and cons. Finally, in the last section we will mention somecollaborative infrastructure projects which have inspired and contributed tothe development of the solution we propose in this study.2.1 Survey of DDoS AttacksBelow we will speak rst of the methods mostly used by attackers to formarmies (botnet) and to wage attacks from it, and after we will describe indetails the most popular DDoS attacks.2.1.1 Attack organizationAgent-Handler modelAn Agent-Handler DDoS attack network consists of clients, handlers, andagents as shown in gure 2.1 5
  15. 15. 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 restof the DDoS attack network. The handlers are software packages located oncomputing systems throughout the Internet that the attacker uses to commu-nicate indirectly with the agents. The agent software exists in compromisedsystems that will eventually carry out the attack on the victim system. Theattacker communicates with any number of handlers to identify which agentsare up and running, when to schedule attacks, or when to upgrade agents.Depending on how the attacker congures the DDoS attack network, agentscan be instructed to communicate with a single handler or multiple handlers.Usually, attackers will try and place the handler software on a compromisedrouter or network server that handles large volumes of trac. This makes itharder to identify messages between the client and handler and between thehandler and agents. The communication between attacker and handler andbetween the handler and agents can be via TCP, UDP, or ICMP protocols.The owners and users of the agent systems typically have no knowledge thattheir 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 smallamount of resources (both in memory and bandwidth), so that the users ofthese computers experience minimal change in performance. In descriptionsof DDoS tools, the terms handler and agents are sometimes replaced withmaster and daemons respectively. Also, the systems that have been violatedto run the agent software are referred to as the secondary victims, while thetarget of the DDoS attack is called the (primary) victim. An Agent-HandlerDDoS attack network consists of clients, handlers, and agents (see Figure2). The client platform is where the attacker communicates with the rest ofthe DDoS attack network. The handlers are software packages located oncomputing systems throughout the Internet that the attacker uses to com-municate indirectly with the agents. The agent
  16. 16. 2.1. SURVEY OF DDOS ATTACKS 7IRC-Based DDoS Attack ModelInternet Relay Chat (IRC) is a multi-user, on-line chatting system. It allowscomputer users to create two-party or multi-party interconnections and typemessages in real time to each other [13]. IRC network architectures consistof IRC servers that are located throughout the Internet with channels tocommunicate with each other across the Internet. IRC chat networks allowtheir users to create public, private and secret channels. Public channelsare channels where multiple users can chat and share messages and les.Public channels allow users of the channel to see all the IRC names andmessages of users in the channel. Private and secret channels are set up byusers to communicate with only other designated users. Both private andsecret channels protect the names and messages of users that are logged onfrom users who do not have access to the channel. Although the contentof private channels is hidden, certain channel locator commands will allowusers not on the channel to identify its existence, whereas secret channels aremuch 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 attackmodel except that instead of using a handler program installed on a networkserver, an IRC communication channel is used to connect the client to theagents. By making use of an IRC channel, attackers using this type of DDoSattack architecture have additional benets. For example, attackers can use legitimate IRC ports for sending commands to the agents[13]. This makestracking the DDoS command packets much more dicult. Additionally, IRCservers tend to have large volumes of trac making it easier for the attackerto hide his presence from a network administrator. A third advantage isthat the attacker no longer needs to maintain a list of agents, since he cansimply log on to the IRC server and see a list of all available agents[13]. Theagent software installed in the IRC network usually communicates to theIRC channel and noties the attacker when the agent is up and running. Afourth advantage is that IRC networks also provide the benet of easy lesharing. File sharing is one of the passive methods of agent code distributionthat we discuss in Section 4. This makes it easier for attackers to securesecondary victims to participate in their attacks. In an IRC-based DDoSattack architecture, the agents are often referred to as Zombie Bots or Bots . In both IRC-based and Agent-Handler DDoS attack models, we willrefer to the agents as secondary victims or zombies.
  17. 17. 8 CHAPTER 2. DDOS AND EXISTING COUNTERMEASURES2.1.2 Taxonomy of DDoS AttacksThere are a wide variety of DDoS attack techniques. We propose a taxonomyof the main DDoS attack methods in Figure 2.2. There are two main classesof DDoS attacks: bandwidth depletion and resource depletion attacks[12].A bandwidth depletion attack is designed to ood the victim network withunwanted trac that prevents legitimate trac from reaching the (primary)victim system. A resource depletion attack is an attack that is designed to tieup the resources of a victim system. This type of attack targets a server orprocess on the victim system making it unable to process legitimate requestsfor service. Figure 2.2: DDoS Taxonomy There are two main classes of DDoS attacks: bandwidth depletion andresource depletion attacks. A bandwidth depletion attack is designed to oodthe victim network with unwanted trac that prevents legitimate trac fromreaching the (primary) victim system. A resource depletion attack is anattack that is designed to tie up the resources of a victim system. This typeof attack targets a server or process on the victim system making it unableto process legitimate requests for service.
  18. 18. 2.1. SURVEY OF DDOS ATTACKS 92.1.3 Bandwidth Depletion AttacksThere are two main classes of DDoS bandwidth depletion attacks. A oodattack involves the zombies sending large volumes of trac to a victim sys-tem, to congest the victim systems bandwidth. An amplication attackinvolves either the attacker or the zombies sending messages to a broadcastIP 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 ampliesmalicious trac that reduces the victim systems bandwidth.Flood AttacksIn 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 itdown, crashes the system or saturates the network bandwidth. This preventslegitimate users from accessing the victim.UDP Flood Attacks.User Datagram Protocol (UDP) is a connectionless protocol. When datapackets are sent via UDP, there is no handshaking required between senderand 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 saturatethe network, depleting the bandwidth available for legitimate service requeststo the victim system. In a DDoS UDP Flood attack, the UDP packets aresent to either random or specied ports on the victim system. Typically,UDP ood attacks are designed to attack random victim ports. This causesthe victim system to process the incoming data to try to determine whichapplications have requested data. If the victim system is not running anyapplications on the targeted port, then the victim system will send out anICMP packet to the sending system indicating a destination port unreach-able message. Often, the attacking DDoS tool will also spoof the sourceIP address of the attacking packets. This helps hide the identity of the sec-ondary victims and it insures that return packets from the victim systemare not sent back to the zombies, but to another computer with the spoofedaddress. UDP ood attacks may also ll the bandwidth of connections lo-cated around the victim system (depending on the network architecture andline-speed). This can sometimes cause systems connected to a network neara victim system to experience problems with their connectivity.
  19. 19. 10 CHAPTER 2. DDOS AND EXISTING COUNTERMEASURESICMP Flood Attacks.Internet Control Message Protocol (ICMP) packets are designed for networkmanagement features such as locating network equipment and determiningthe number of hops or round-trip-time to get from the source location to thedestination. For instance, ICMP_ECHO_REPLY packets ( ping ) allow theuser to send a request to a destination system and receive a response withthe round trip time. A DDoS ICMP ood attack occurs when the zombiessend large volumes of ICMP_ECHO_REPLY packets to the victim system.These packets signal the victim system to reply and the combination of tracsaturates the bandwidth of the victims network connection. As for the UDPood attack, the source IP address may be spoofed.Amplication AttacksA DDoS amplication attack is aimed at using the broadcast IP addressfeature found on most routers to amplify and reect the attack (see gure2.3). Figure 2.3: Amplication Attacks This feature allows a sending system to specify a broadcast IP addressas the destination address rather than a specic address. This instructs the
  20. 20. 2.1. SURVEY OF DDOS ATTACKS 11routers servicing the packets within the network to send them to all the IPaddresses within the broadcast address range. For this type of DDoS attack,the attacker can send the broadcast message directly, or the attacker can usethe agents to send the broadcast message to increase the volume of attackingtrac. If the attacker decides to send the broadcast message directly, thisattack provides the attacker with the ability to use the systems within thebroadcast network as zombies without needing to inltrate them or installany agent software. We further distinguish two types of amplication attacks,Smurf and Fraggle attacks.Smurf Attacks. In a DDoS Smurf attack, the attacker sends packetsto a network amplier (a system supporting broadcast addressing), with thereturn address spoofed to the victims IP address. The attacking packets aretypically ICMP ECHO REQUESTs, which are packets (similar to a ping )that request the receiver to generate an ICMP ECHO REPLY packet. Theamplier sends the ICMP ECHO REQUEST packets to all of the systemswithin the broadcast address range, and each of these systems will return anICMP ECHO REPLY to the target victims IP address. This type of attackamplies the original packet tens or hundreds of times.Fraggle Attacks. A DDoS Fraggle attack is similar to a Smurf attack inthat the attacker sends packets to a network amplier. Fraggle is dierentfrom Smurf in that Fraggle uses UDP ECHO packets instead of ICMP ECHOpackets [56]. There is a variation of the Fraggle attack where the UDP ECHOpackets are sent to the port that supports character generation (chargen, port19 in Unix systems), with the return address spoofed to the victims echoservice (echo, port 7 in Unix systems) creating an innite loop [56]. The UDPFraggle packet will target the character generator in the systems reached bythe broadcast address. These systems each generate a character to send tothe echo service in the victim system, which will resend an echo packet backto the character generator, and the process repeats. This attack generateseven more bad trac and can create even more damaging eects than just aSmurf attack.2.1.4 Resource Depletion AttacksDDoS resource depletion attacks involve the attacker sending packets thatmisuse network protocol communications or sending malformed packets thattie up network resources so that none are left for legitimate users.
  21. 21. 12 CHAPTER 2. DDOS AND EXISTING COUNTERMEASURESProtocol Exploit AttacksTCP SYN Attacks. In TCP SYN Attack the attacker sends a successionof SYN requests to a targets system. When a client attempts to start a TCPconnection to a server, the client and server exchange a series of messageswhich 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 everyconnection established using the TCP protocol. The TCP SYN attack worksif a server allocates resources after receiving a SYN, but before it has receivedthe ACK. In a DDoS TCP SYN attack, the attacker instructs the zombies to sendsuch bogus TCP SYN requests to a victim server in order to tie up theservers processor resources, and hence prevent the server from respondingto legitimate requests. The TCP SYN attack exploits the three-way hand-shake between the sending system and the receiving system by sending largevolumes of TCP SYN packets to the victim system with spoofed source IPaddresses, so the victim system responds to a non-requesting system. Even-tually, if the volume of TCP SYN attack requests is large and they continueover 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 toa 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 canrequest the receiving system to unload the contents of the buer before thebuer becomes full by sending a packet with the PUSH bit set to one. PUSHis a one-bit ag within the TCP header [13]. TCP stores incoming datain large blocks for passage on to the receiving system in order to minimizethe processing overhead required by the receiving system each time it mustunload a non-empty buer. The PUSH + ACK attack is similar to a TCPSYN 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 setto one. These packets instruct the victim system to unload all data in the
  22. 22. 2.1. SURVEY OF DDOS ATTACKS 13TCP buer (regardless of whether or not the buer is full) and send anacknowledgement when complete. If this process is repeated with multipleagents, the receiving system cannot process the large volume of incomingpackets and it will crash.Malformed Packet AttacksA malformed packet attack is an attack where the attacker instructs thezombies to send incorrectly formed IP packets to the victim system in orderto crash the victim system. There are two types of malformed packet attacks.In an IP address attack, the packet contains the same source and destinationIP addresses. This can confuse the operating system of the victim systemand cause the victim system to crash. In an IP packet options attack, amalformed packet may randomize the optional elds within an IP packetand set all quality of service bits to one so that the victim system must useadditional processing time to analyze the trac. If this attack is multipliedusing enough agents, it can shut down the processing ability of the victimsystem.Application Layer AttackIn a just-released report on botnet-generated DDoS attacks, Prolexic notedthat attackers are quickly tweaking their botnets to make attack trac lookincreasingly similar to legitimate, routine trac.Instead of the huge burst of trac that marks when an attack begins, tracwill begin to ramp up slowly as bots join the attack at random intervals witheach bot varying its attack style, making it increasingly dicult to separatereal users from bots, the report said [64]. There are several tools that automatically launch Layer 7 DDoS Attacks.Really interesting is theApache L7DA (Layer 7 DDoS Attacks) The tool works by exhaustingApache processes; this is done by sending incomplete request headers soApache keeps waiting for the nal header line to arrive, the tool instead justsends a bogus header to keep the connection open. Besides Apache (bothversions 1.x and 2.x), Squid is also aected. Knowing how many serversrunning on Apache there are, this makes the tool very dangerous since itdoesnt require absolutely any knowledge from the attacker. All he/she hasto do is run the tool and the target site goes down.
  23. 23. 14 CHAPTER 2. DDOS AND EXISTING COUNTERMEASURES2.2 Survey of DDoS CountermeasureAmong various proposals, we can see mainly two schools of thought: thecapability-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, butdier signicantly in methodology. The capability approach proposes to leta receiver explicitly authorize the trac it desires to receive, while the lterapproach proposes to let a receiver install dynamic network lters that blockthe trac it does not desire to receive. Advocates of lters have argued that capabilities are neither sucient nor necessary to combat DoS [9], whileproponents of capabilities strongly disagree [6]. In this section we are going to explore the most relevant solutions thatwere 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 torate limit the attacker as close is possible to the source. As it is shown ingure 2.4 the congested router asks its adjacent upstream router to rate-limitthe 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 similarto the detected aggregate, then also the neighbors can propagate Pushbackrecursively to the upstream routers. The most relevant benets introduced with this solution are:
  24. 24. 2.2. SURVEY OF DDOS COUNTERMEASURE 15 • Its very powerful when the source address cant 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. • Cant work in non-contiguous deployment. • If the sources 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 ifthe 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 tocounter 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 inmany browsers through downloadable applets . The goal of this solution is
  25. 25. 16 CHAPTER 2. DDOS AND EXISTING COUNTERMEASURESto guarantee access to a web server for a large number of previously unknownusers, without requiring preexisting trust relationships between users and thesystem. WebSOS acts as a distributed rewall eliminating communication pinch-points and thus preventing the Target Servers Routers from being congested.Clients need to connect securely to an Access Point (Figure 2.5) and theoverlay network route him to the actual Target Server. The Target serverallows only the secret servlet (or a set of secret servlets) to connect throughthe ltered Area. The ltering is done using elds that a router can lterfast (e.g. the IP address of the secret servlet). The secret servlets locationcan 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.
  26. 26. 2.2. SURVEY OF DDOS COUNTERMEASURE 17The 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 cancollaborate in DDoS detection and response. The nodes in the DefCOMoverlay are classied into three categories, based on the functionality theyprovide 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
  27. 27. 18 CHAPTER 2. DDOS AND EXISTING COUNTERMEASURES overlay. The alert contains the IP address of the attacks victim and species a desired rate limit, e.g., the size of the victims 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 itsresources and the authorization within the overlay, but the placement ofnodes 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) its 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:
  28. 28. 2.2. SURVEY OF DDOS COUNTERMEASURE 19 • 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). Withspeak-up, a victimized server encourages all clients, resources permitting, toautomatically send higher volumes of trac. Speak-up is based on the as-sumption that attackers are already using most of their upload bandwidth socannot react to the encouragement. Good clients, however, have spare up-load bandwidth and will react to the encouragement with drastically highervolumes of trac. The intended outcome of this trac ination is that thegood clients crowd out the bad ones, thereby capturing a much larger fractionof the servers resources than before. The experiment described in the paper [21] demonstrate that speak-upcauses the server to spend resources on a group of clients in rough proportionto their aggregate upload bandwidth. While the authors of this originalsolution declare that the test result makes the defense viable and eectivefor a class of real attacks we denitely disagree. Indeed a scenario in which attacks came from a botnet of compromisedweb server like in [62] with Speak-up active could be even more dangerous incomparison with it disabled. Its obvious that the upload available bandwidthof 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 therequest channel. When a client wishes to connect to a server, it rst sendsa request to a name server to resolve the IP address of the server (step 1 inFigure 2.6).
  29. 29. 20 CHAPTER 2. DDOS AND EXISTING COUNTERMEASURES Figure 2.6: OverDoSe basic protocol The name server returns a list of IP addresses of overlay nodes (step 2 inFigure 2.6). The client selects an overlay node to which it sends a connectionrequest (step 3 in Figure 2.6). In response to a clients connection request, theoverlay node replies with the latest puzzle seed released by the server, as wellas a puzzle diculty level specied by the server (step 4 in Figure 2.6). Theclient is expected to solve a 3 puzzle at or above the specied diculty level inorder to successfully set up a connection. The client generates a puzzle basedon the puzzle seed, solves the puzzle, and sends the puzzle solution to theoverlay node (step 5 in Figure 2.6). At this point the overlay node validatesthe 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 (step7 in Figure 2.6). The ow specication is a set of rules the overlay node mustenforce for regulating an established ow. The ow specication is updateddynamically by the server. The overlay node then replies to the client withthe cookie, successfully completing connection setup. The client attachesthe cookie to all subsequent packets to the server. The overlay node thenroutes trac between the client and the server, and polices the clients owaccording to the ow specication.
  30. 30. 2.2. SURVEY OF DDOS COUNTERMEASURE 212.2.6 Portcullis (2006)Portcullis aims to provide a defense against large-scale DDoS attacks: evenwhen under attack, a legitimate sender can successfully initiate a connectionwith the receiver and communicate with low packet loss. Portcullis is basedon a new puzzle-based protection for capability request packets. Hence, themain goal of the solution is to design a Denial-of-Capability resistant re-quest channel for a capability system. This design is based on computationalpuzzles, which we prove can provide optimal fairness for the request channel.As a result, Portcullis strictly bounds the delay a collection of attackers canimpose on legitimate clients. To achieve per-computation fairness Portcullisleverage a novel puzzle based mechanism, which enables all routers to easilyverify 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 theattackers ooding rate. The Achilles heel of Portcullis as well as other capability proposals, isthat it uses puzzle, and we will describe more in details in paragraph 3.2.2the weakness of these kind of solutions.2.2.7 Stop-It (2008)Stop-it is designed as lter-based DoS defense architecture. StopIt employs anovel closed-control and open-service architecture to combat various strate-gic attacks at the defense system itself, and to enable any receiver to blockthe undesired trac it receives[2]. StopIt is resistant to strategic lter ex-haustion attacks and bandwidth ooding attacks that aim to prevent thetimely installation of lters. Figure 2.7: StopIt architecture
  31. 31. 22 CHAPTER 2. DDOS AND EXISTING COUNTERMEASURES The architecture of Stop-it is shown in gure 2.7 where a dashed circlerepresents an AS boundary. The gure depict also the steps to install aStopIt 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 veriesthis request to conrm that the source Hs is attacking the destination Hdand sends a router-server request to the ASs StopIt server S d. At point 3 ofgure 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 blockthe ow (H S ,H d ) for the chosen period of time. In step 4 of gure 2.7 thesource StopIt server SS locates the access router RS of the attacking sourceHS, and sends a server-router request to the access router. A StopIt serverignores inter-domain StopIt requests that block itself to prevent deadlocks. Inthe 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 sourceHS. After receiving this request, a compliant host HS installs a local lterto stop sending to H d. The StopIt mitigation system focuses basically on two families of DDoSattacks: Destination Flooding Attacks and Link Flooding Attacks. In the Destination Flooding Attacks the Attackers send trac oods to adestination in order to disrupt the destinations communications. The LinkFlooding Attacks instead aims to congest a link and disrupt the legitimatecommunications 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.
  32. 32. 2.2. SURVEY OF DDOS COUNTERMEASURE 232.2.8 TVA: Trac Validation Architecture (2009)Trac Validation Architecture (TVA)[8] is a network architecture that limitsthe impact of Denial of Service (DoS) oods from the outset. TVA is basedon the notion of capabilities like SOS and Speak-UP [5, 21]. In TVA insteadof sending packets to any destination at any time, senders must rst obtainpermission to send from the receiver, which provides the permission in theform of capabilities to those senders whose trac it agrees to accept. Thesenders then include these capabilities in packets. This enables vericationpoints distributed around the network to check that trac has been autho-rized by the receiver and the path in between, and hence to cleanly discardunauthorized trac. TVA addresses a wide range of possible attacks againstcommunication 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 applicationfrom layer-7 DDoS attacks. These attacks mimic legitimate clients and over-whelm the system resources, thereby substantially delaying or denying service
  33. 33. 24 CHAPTER 2. DDOS AND EXISTING COUNTERMEASURESto the legitimate clients. Its main goal is to provide adequate service to le-gitimate clients even during the attack. The defense model of DDoS-Shieldconsists of mitigation system integrated into a reverse-proxy that schedulesor drops attack requests before they reach the web-cluster tier. The DDoS-Shield examines requests belonging to every session, parses them to obtainthe request type and maintains the workload- and arrival- history of requestsin the session. Figure 2.8: DDoS-Shield Model In gure 2.2.9 is shown the system architecture for DDoS-Shield thatconsists 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 inspiredmost part of our proposal. By the way, after analysing this solution we thinkto prone the following issues:legitimate proles poisoning: They dont 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
  34. 34. 2.3. RELEVANT COLLABORATIVE INFRASTRUCTURE SYSTEMS 25 to this kind of trac. It means that when the attacker decides that its 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- temsHereby we will present the main collaborative infrastructures that have beentaken into account in our study, even if none of them make part of the projectsspecically dedicated to DDoS mitigation. We take this solution in consideration, because we tough fundamentalto combat cyber crime sharing reports regarding the recorded attacks onits infrastructure. From received attacks it is possible to extract a lot ofinformation, that may be useful to understand the dynamics behind them.Thanks to sharing this information between trusted partners it is possibleto form a basic that permits to strengthen their defenses and to be betterprepared against future attacks. The rst project presented here is CoMiFIN, which purpose is exactlythe one described above, restricted to the world of Financial Institution (FI).Then comes a paragraph about WOMBAT - another project funded by theEuropean community, that similarly aims to provide tools to analyze andunderstand the existing and emerging threats targeting the Internet economyand 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 inthe Internet to a central database. Finally, a brief description of FIRE - a service to identify rogue networksand Internet Service Providers close the chapter.
  35. 35. 26 CHAPTER 2. DDOS AND EXISTING COUNTERMEASURES2.3.1 CoMiFINCommunication Middleware for Monitoring Financial Critical Infrastructureis an EU project funded by the Seventh Framework Programme (FP7),started in September 2008 and continuing for 30 months. The research areais Critical Infrastructure Protection (CIP), focusing on the Critical FinancialInfrastructure (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 orderto exploit Internet business continuity. The system facilitates the sharing ofcritical events among interested parties, which can in turn use these eventsto trigger the necessary local protection mechanisms in a timely fashion. Ascheme 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. Federationsare regulated by contracts and they are enabled through the Semantic Roomabstraction: this abstraction facilitates the secure sharing and processingof information by providing a trusted environment for the participants to
  36. 36. 2.3. RELEVANT COLLABORATIVE INFRASTRUCTURE SYSTEMS 27contribute and analyze data. Input data can be real time security events,historical attack data, logs, and other sources of information that concernother Semantic Room participants. Semantic Rooms can be deployed ontop of an IP network allowing adaptable congurations from peer-to-peer tocloud-centric congurations, according to the needs and the requirements ofthe Semantic Room participants. A key objective of CoMiFin is to provethe advantages of having a cooperative approach in the rapid detection ofthreats. Specically, CoMiFin demonstrates the eectiveness of its approachby addressing the problem of protecting nancial critical infrastructure. Thisallows groups of nancial actors to take advantage of the Semantic Roomabstraction 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 WarningsThis information is consumed by the event processing engines installed ateach participating site. These event engines leverage the computing andstorage capabilities available in the local data center to discover maliciousattack 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 dierentlevels of trust requirements. At one extreme there could be SRs formed bynancial institutions that trust each other implicitly (e.g., branches of thesame bank), and consequently trust the information being processed andshared in those SRs. At the other extreme, there could be SRs whose mem-bership includes participants that are potential competitors in the nancialmarket. In this case, the issue of trusting the information circulating ina semantic room becomes a point of great importance and if this issue isnot adequately addressed, the semantic room abstraction will be infeasibleas nancial institutions will refrain from becoming members of it. For in-stance, processed data in the SR related to DDoS attacks on FIs can beused by a more specialized SR such as DDoS attacks on banks in a countrywhose data can be, in turn, used by the SR related to DDoS attacks on a
  37. 37. 28 CHAPTER 2. DDOS AND EXISTING COUNTERMEASURESspecic bank in a specic country in order to provide partners with richerservices[42] . A possible scenario of usage of the shared events information could be togenerate fast and accurate intruder blacklist. The philosophy of sharing suchkind of critical information as in CoMiFIN[31] gaves us a lot suggestion onthe designing phase of our proposal.2.3.2 WOMBATThe WOMBAT project is a collaborative European funded research projectthat aims at providing new means to understand the existing and emergingthreats that are targeting the Internet economy and the net citizens. Theapproach carried out by the partners include a data collection eort as wellas some sophisticated analysis techniques. The Leurré.com project was initially launched in 2003 and has since thenbeen integrated and further improved (SGNET) and developed within theWOMBAT 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 pictureof certain classes of threats happening on the Internet by collecting unbiasedquantitative 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 somecontextual information and with meta-data describing the observed attacksessions. A simple example of the interaction between some components ofWOMBAT is shown in gure 2.10.
  38. 38. 2.3. RELEVANT COLLABORATIVE INFRASTRUCTURE SYSTEMS 29 Figure 2.10: SGNET framework A source is dened in SGNET/WOMBAT as the contiguous activityon an IP address. Due to the bias introduced by dynamic addressing an IPaddress cannot be generally reliably considered as a good way to identify anattacker. There are a number of situations for which IP A.A.A.A at day XIs 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 addresswhen its not separated by a long silence time. If IP A.A.A.A is observedattacking one of them honeypot sensors, and then is silent for more than 25hours, and then is witnessed again, its considered as a dierent source sincewe have no evidence that we are still dealing with the same machine. The meta-data collected in the database help to dene what they callattack events [38], a representation of specic activities over limited periodof times. The attack events enables to observe the evolution of what theyhypothesize to be armies of zombies, some of them remaining visible for morethan 700 days. The attack events highlights the existence of coordinated attacks launchedby a group of compromised machines, i.e. a zombie army. They computeaction set as a set of attack events that are likely due to same army. Throughthe action set they are able to derive the size and the lifetime of the zombiearmies. The researchers involved in the WOMBAT project present a new attackattribution method [37]. This analytical method aims at identifying largescale attack phenomena composed of IP sources that are linked to the same
  39. 39. 30 CHAPTER 2. DDOS AND EXISTING COUNTERMEASURESroot cause. All malicious sources involved in a same phenomenon constitutewhat they call a Misbehaving Cloud (MC). When an huge amount of data are collected, a big issue remain on theway its possible to get useful information out of the database. For solvingthis 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 thatallow an integrated access to dierent attack dataset. Every single datasethas his own maintainer that handles certicates for accessing the database. We think that the information coming from such huge database could bea powerful instrument useful for a lot of dierent investigation scenarios.2.3.3 DShieldDshield is a community-based collaborative rewall log correlation system.It receives logs from volunteers world wide and uses them to analyze attacktrends. It is used as the data collection engine behind the SANS InternetStorm Center (ISC). It is one of the public most dominating attack correlationengine with worldwide coverage. DShield is regularly used by the media tocover current events. Analysis provided by DShield has been used in the earlydetection of several worms. DShield data is regularly used by researchers toanalyze attack patterns. The goal of the DShield project is to allow accessto its correlated information to the public at no charge to raise awarenessand provide accurate and current snapshots of internet attacks. Several datafeeds are provided to users to either include in their own web sites or to useas 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 rewallparsable lters of these lists to help the Internet community ght back.DShield represents a centralized approach to blacklist formulation, with morethan 1000 contributors providing a daily perspective of the malicious back-ground radiation that plagues the Internet. The published GWOL capturesa snapshot of those class C subnets whose addresses have been logged bythe greatest number of contributors. Another common practice is for a localnetwork to create its own local worst oender list (LWOL) of those sites thathave attacked it the most. LWOLs have the property of capturing repeatoenders that are indeed more likely to return to the local site in the fu-ture. LWOLs are by denition completely reactive to new encounters withpreviously unseen attackers. The GWOL strategy, on the other hand, hasthe potential to inform a local network of highly prolic attackers, it also hasthe potential to provide a subscriber with a list of addresses that will simplynever be encountered.
  40. 40. 2.3. RELEVANT COLLABORATIVE INFRASTRUCTURE SYSTEMS 31 Both of these dierent approaches are a possible solution to the sameproblem encountered in WOMBAT regarding a way for extract meaningfuldata 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 sharingrepositories, such as DShield. The objective of HPB is to construct a cus-tomized blacklist per repository contributor that reects the most probableset of addresses that may attack the contributor over a prediction windowthat may last several days. The HPB enumerate all sources of reported at-tackers and assign each of them a ranking score relative to its probabilityto attack the contributor in the future. The ranking score is based on ob-servation of the particular attackers past activities, as well as the collectiveattack patterns exhibited by all other attackers in the alert repository. Thisis another key dierence between our HPB algorithm and the other blackliststrategies. 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, incontrast, takes a collective approach. HPB attacker selection is inuenced byboth an attackers own attack patterns and the full set of all attack patternsfound within the dataset. A correlations among the contributors introducedby the collection of attackers is here introduced, i.e., the amount of attackeroverlap between each pair of contributors. The ranking score in HPB caresnot only how many contributors have reported the attacker but also whogave the reports. It favors attackers reported by many contributors that arealso correlated (have many common attackers) with the contributor underconsideration. The contributor correlation used in HPB is inspired by a workof Katti et al [29].2.3.4 FIRE: FInding RoguE NetworksFIRE[41] is a novel system to identify and expose organizations and ISPsthat demonstrate persistent, malicious behavior. FIRE can help isolate net-works that tolerate and aid miscreants in conducting malicious activity onthe Internet. To make this possible, FIRE actively monitors botnet commu-nication channels, drive-by-download servers, and phishing web sites. Thisdata is rened and correlated to quantify the degree of malicious activity forindividual organizations. With respect to root cause analysis, these resultscan be used to pinpoint and to track the activity of rogue organizations,preventing criminals from establishing strongholds on the Internet. Also, the
  41. 41. 32 CHAPTER 2. DDOS AND EXISTING COUNTERMEASURESinformation can be compiled into a null-routing blacklist to immediately halttrac from malicious networks.
  42. 42. Chapter 3Models Overview3.1 Attacker and Victim ModelIn this section we describe rst the victim model, in other words, the targetsystem that we assume. Second we describe the attacker model: the strate-gies used by the attacker to make the attack successful. Finally we describeour proposed defense model.3.1.1 Victim ModelWe consider a general victim model as a multiple resources pool of servers. Inour 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. Atthe top there is a Border Router that is commonly used within a companysinfrastructure as components between Internet and the internal network. Below the Border router a Load balancer has the duty of balancing therequests that need to be forwarded to the replicated WebServers. As WS tierwe 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.1sessions are persistent connections and allow a client to send requests andretrieve responses from the web-cluster without incurring the overhead ofopening a new TCP connection for request. A legitimate HTTP/1.1 sessionconsists 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 requestand then waits for the response before sending the next request. Otherwise 33
  43. 43. 34 CHAPTER 3. MODELS OVERVIEW Figure 3.1: Target Architecturethey 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 theserver. A page is typically retrieved by sending one main request for thetextual content and several embedded requests for the image-les embeddedwithin the main page. The main requests are typically dynamic and involveprocessing at the database tier while embedded requests are usually static asthey 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 resourceutilization reports as well as overall system statistics at the application layer,such as throughput and response time. Its said that the system is under aresource attack when a surge in a resources usage is accompanied by reduc-tion in throughput and has an increase in response time without a DDoSattack detected at lower layers.
  44. 44. 3.1. ATTACKER AND VICTIM MODEL 353.1.2 Attacker ModelMost 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 resourcestherefore legitimate clients experience high delays or lower throughput therebyreducing or eliminating the capacity of the servers to its intended clients. Theattacker uses the application interface in order to issue requests that canmimic legitimate client requests, but whose only goal is to consume serverresources. We assume that the application interface presented by the serversis 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 theattacker has commandeered a large number of machines distributed acrossdierent geographical areas, organized into server farms known as botnets.To start a TCP session, an attacker can either use the actual IP address of thecompromised machine or spoof that address with one chosen from botnetsaddresses. 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
  45. 45. 36 CHAPTER 3. MODELS OVERVIEW 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 asit also can be connected through HTTPS authenticated session. A possiblescenario here is when only a subset of the botnets nodes is connected beforethe real attack, and only when the attacker wants to launch the DDoS, allthe nodes are used, (maybe for a very short period of time). This situationcan 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 solutionsthat tag under attack as legitimate the clients that are connected when thesystem is not under attack. We assume that the worst case scenario is when the attacker knows the fullproling data, and therefore can select requests that maximize the amountof server resources consumed. However, in general, this type of informationcan only be obtained through proling and timing the server responses fromoutside. 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 puzzletest either directly or through a forwarding system[48]. In the previously presented model of attack the requests can be generatedin 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 mouses movements from the origin to the target position, random links following, random elds lling.3.1.3 Defense ModelWe introduce a new collaborative counter-DDoS mechanism to protect theapplication from layer-7 DDoS attacks and provide adequate service to legit-imate clients even during the attack.
  46. 46. 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 corecomponents here are: the Smartproxy, Advanced Deep Logger, and the Rep-utation Database. The smartproxy prioritizes the incoming request on the base of the trustlevel 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 ofthe information which are typically stored on the Web Server logs, that makeeasier the auditing process during and after the attack. The Reputational Database is owned and updated by a group of trustedpartner that want to share useful information of malicious clients that havetried to attack his own systems. In this database all the information aboutthe trust level of the malicious clients are collected and continuously updatedwith the information coming from the most recent attacks. Information onthe trust level might also be aected by attacks information coming fromtrusted third-party entities. Even if the situation described above is just asimple attack attribution techniques, we had to make some assumptions inour 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 spoofedor not and we assume that they are used on the network infrastructure ofthe ISP or own network before the webserver (as described in [24, 25]). Further we will extend the detection process used in DDoS-Shield[22] bychecking periodically how many IP sources (that make part of our database)are connected, and nd a threshold that can suggest our system to improvethe level of ltering. For example, we can achieve it being more restrictedwith the resources given to clients in the scheduler policy, or by asking tolter the malicious IP as far as possible from the web server.3.2 Defense StrategiesThe studied solution is mainly based on three phases: the detection of theDDoS on the protected system, the classication of the incoming requestsbetween legitimate and (possible) malicious trac, and the response againstthe detected attack.3.2.1 DetectionThe 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 anomalydetection by the trac distribution or volume [45, 33], or by the detection of
  47. 47. 38 CHAPTER 3. MODELS OVERVIEWalready known attacks signatures[46, 47]. Proling a legitimate behavior isnot easy, as well we cannot know every attacks signature since there will bealways a new one, never seen/known before. Both of these approaches arenot helpful in our attacker model, considering that we assume the attackersbehavior as a well-chosen human generated sequence of actions. Since thiscan be a real scenario (submitted from a legitimate user) it must not bedetected as a bad behavior, maybe only because it is far from the comparedlegitimate proles. Otherwise it means that the sets of good proles are toosmall to allow possible application usage. In other words, it will reect in anhigher 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 kindof 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 customand safe environment (usually used for testing and production). This setupmakes impossible to put bad data on it, but that means also that some goodbehavior (for anomaly-based systems), or attackers signature (in the case ofsignature-based systems), is not included in the initial training set because itis impossible to cover all these kinds of behavior. This issue will be inevitablyreected in detection of false positives or negatives. On the other hand, the on-line family is prone to poison attacks, in thesense that the attacker has a chance to inject customized data to the systemuntil they become a part of the legitimate training set. Thats also theproblem of DDoS Shield, that we want to improve and extend. Our approach for detection is based more on the user perception than onthe variation on the QoS like in [16] but we extend this process monitoringalso the workload of the single critical components of our architecture (CPU,Disk, Memory Load) and thanks to a new metric, that we propose, based onthe number of suspected clients concurrently connected to our system in acertain time frame.3.2.2 ClassicationOne of the main problems to distinguish legitimate from malicious tracis commonly reduced to the problem of distinguishing DDoS from a Flash-Crowds. During the last years the bots interaction with the application hasbecome very close to the human behavior. This issue makes very dicult todistinguish bots from humans. As we have already discussed the leaks of statistical approaches in thedetection of a DDoS, such kind of system may suer the same issues in theclassication process. In fact, distinguish legitimate users from malicious
  48. 48. 3.2. DEFENSE STRATEGIES 39trough a statistical system at Layer-7 without detecting false positives ornegatives is a big challenge. One of the main alternatives to distinguish humans from bots is to giveto the clients a reverse Turing test to solve, i.e. captcha or more in general apuzzle-based test. Unfortunately, there are a lot of studies about techniquesthat makes these tests solvable by a bot. When the puzzle is too hard to besolved in an automatic way, the attacker can also hire people for solving that(slow approach but eective anyway in spamming scenarios), or it can simplyforward this information to popular website that oers resources illegallylike movies, music and copyrighted software. Since the only cost that isrequired for accessing this (expensive) resources is to solve an easy puzzle,every user that is interested in such kind of resources becomes unwittingaccomplice of the DDoS attack. Then it doesnt matter how hard are thesepuzzles to be solved. Puzzle-based solutions are commonly used in capability systems, in whichafter some active (i.e. puzzle) or passive analysis the client gets a booleanaccess to the protected system. Unfortunately, this approach can be verydangerous because the bots are becoming really smart and if they are ableto solve the puzzle, as we have described above, in proposed solutions theyget a capability to access the system. They can access the system until thecapability expires. We think that the best approach is to use a ne-grain level of suspicionthat has to be assigned to suspected clients. That allows our system to reducethe problems related to the detection of false positive clients like in [22]. Butinstead of classifying clients thanks to a comparison with some good proles,we rely on information in a collaborative and shared database, in whichpartners of the collaborative infrastructure can share information about thesources of detected attacks and from which they can get information aboutthe suspicion level of clients. To improve the database and to reduce the detection of false negatives, weuse some known automatic techniques, like crawler trap for detecting unfaircrawler or some randomized bots actions. In order to improve the detectionof other unknown attacks we increase the collected data from the users, inthe logs, with other information, like the users actions, keystrokes, mousemovements. Thanks to this information we aid an auditor in perpetrating aforensic analysis for detecting malicious actions and the sources from whichthat was generated.
  49. 49. 40 CHAPTER 3. MODELS OVERVIEW3.2.3 ResponseAfter having classied the incoming trac, the common approaches to handlethe malicious one are to redirect or to drop it. Dropping the trac couldbe dangerous in case of false positive detected, as well as redirect trac forfurther analysis can be interesting like in Roaming Honeypots [44] for furtheranalysis. In our scenario, in which the attacker has a high interaction withthe applications, we cannot be absolutely sure about the legitimate/maliciousintention 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 ourattacker model since we assume that the attacker is protocol compliant andis 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 thanksto what we call Smart Proxy, and in case there are not enough resourcesavailable for that suspected clients, to drop these requests. Nevertheless, our suspicion assignment method is completely dierent andit is based on the reputation of the clients. Furthermore, to reduce the tracand computation on the Smart Proxy we use also a Pushback[4] approachon the border router of the company that is hosting the server farm. In thisway, we are able to shape the trac that comes from the already suspectedclients as close as it is possible to the source of the trac, so the Smart Proxycan get a benet from it. At the end of the attack in any case it will be possible to do a forensicsanalysis thanks to actions collected from the clients that can be correlatedwith the data in the collaborative database for speeding-up the auditingprocess and then for nding all the sources of the attack; the submission ofthis data to the database gives the benet to the target as well as to all themembers of the collaborative database to be ready for further attacks fromthat sources.
  50. 50. Chapter 4Software ArchitectureIn this Chapter we present rst the logical description of our defense solu-tion proposal, then in the second section we describe the features of everycomponent. 41
  51. 51. 42 CHAPTER 4. SOFTWARE ARCHITECTURE4.1 Logical DescriptionIn 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 asdetection, classication and response. Figure 4.1: Model Overview
  52. 52. 4.1. LOGICAL DESCRIPTION 434.1.1 DetectionWe agree with Mirkovic et al.[16] regarding the importance of measuring theperception of service quality from a clients perspective. As usually humanusers are the rst victim aected by a denial of service on a server, sincethey can perceive a degradation of service due to the DoS. Measuring thisperception is not the main focus of this study and we think that the existingmetrics based on QoS proposed by Mirkovic et al. can be very useful in ourscenario as well. Wed 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 metricsproposed 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 applications 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 transactions 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

×