Download document 8927327

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Distributed firewall wikipedia , lookup

Airborne Networking wikipedia , lookup

Lag wikipedia , lookup

Internet protocol suite wikipedia , lookup

Piggybacking (Internet access) wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

IEEE 1355 wikipedia , lookup

List of wireless community networks by region wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Zero-configuration networking wikipedia , lookup

Everything2 wikipedia , lookup

Transcript
11/19/14 19. DDoS – Mechanisms ENEE 757 | CMSC 818V Prof. Tudor Dumitraș Assistant Professor, ECE University of Maryland, College Park http://ter.ps/757 https://www.facebook.com/SDSAtUMD Today’s Lecture •  Where we’ve been –  AuthenCcaCon and access control –  Network security –  Exploits –  Worms •  Where we’re going today –  Denial of service •  Where we’re going next –  More denial of service 2 1 11/19/14 Network Denial of Service (DoS) •  Goal: take out a large site with liMle compuCng work •  DoS can happen at any layer •  Link •  TCP/UDP •  ApplicaCon •  DoS soluCons for one layer cannot always be replicated at other layers –  This means that DoS cannot be solved with end-­‐to-­‐end soluCons –  Need cooperaCon from the network •  Sad truth: –  Current Internet not designed to handle DDoS aMacks 3 Types of DoS AOacks •  We’ve seen –  TCP SYN Floods –  TCP Con Floods –  DoS by connecCon reset –  UDP flood –  DNS amplificaCon •  Some common paMerns –  DoS by sending junk packets –  Hide aMacker locaCon by spoofing IP addresses –  Use a botnet to conduct Distributed Denial of Service (DDoS) –  Take advantage of protocols that reflect and amplify traffic (e.g. DNS, NTP) 4 2 11/19/14 Largest Recorded DoS AOack [Czyz, Kallitsis, Gharaibeh, Papadopoulos, Bailey, Karir, 2014] NTP: up to x1,000,000 amplificaXon monlist: “Give me the addresses of the last 600 machines you talked to” Spoofed SrcIP: DoS target 600 addresses DoS Source NTP (Network Time Protocol) server DoS Target •  10 Feb 2014: 325 Gbps aMack against French target hMp://www.arbornetworks.com/asert/2014/02/ntp-­‐aMacks-­‐welcome-­‐to-­‐the-­‐hockey-­‐sCck-­‐era/ –  Several similar aMacks between Dec 2013 – Feb 2014 •  Exceeded previous peak throughputs by 200% –  NTP monlist amplifier populaCon dropped by 93% between Jan–Apr 2014 •  Likely a result of noCficaCon campaign by researchers 5 TradiXonal DDoS Trade-­‐Off •  DDoS AMacks are either Persistent or Scalable to N Servers –  N x traffic to 1 server => high-­‐intensity traffic triggers network detecCon –  detecCon not triggered => low-­‐intensity traffic is insufficient for N servers 6 3 11/19/14 Example: DDoS AOack on Spamhaus (2013) •  Adversary: DDoS -­‐> 1 Spamhaus Server (3/16 – 3/18) persistent: ~ 2.5 days @ 10 Gpbs Adversary -­‐ 100K open DNS resolvers . . . •  Spamhaus -­‐> CloudFlare (3/19 – 3/22) non-­‐scalable: -­‐> 90-­‐120 Gbps traffic is diffused over N > 20 servers in 4 hours AOack traffic ` Anycast 7 7 Spamhaus AOack – Second Stage Adversary -­‐ 100K open DNS resolvers . . . AOack traffic IXP •  Adversary: DDoS -­‐> 4 IXPs (3/23) –  scalable: regionally degraded connecCvity some disconnecCon -  non-­‐persistent: aMack detected, pushed back & legiCmate traffic re-­‐routed in ~ 1 -­‐ 1.5 hours Anycast 8 8 4 11/19/14 Persistent and Scalable DDoS Through Link Flooding •  We’ve seen: opCmisCc acknowledgment aMack –  AMacker can saturate the return paths from legiCmate servers –  In theory, can cause Internet-­‐wide congesCon collapse •  Coordinated link-­‐flooding aMacks can degrade connecCvity of N-­‐
server areas persistently –  N = small (e.g. 1—1000 servers) –  N = medium (e.g. all servers in Maryland) –  N = large (e.g. the West Coast of the US) 10000
10000
"971108.out"
exp(7.68585) * x ** ( -2.15632 )
"980410.out"
exp(7.89793) * x ** ( -2.16356 )
1000
1000
100
100
10
10
1
1
10
1
100
1
10
9 100
Power Laws of Internet Topology [Faloutsos3, ‘On Power-­‐Law RelaConships of the Internet Topology’] •  Power law: y(x) = axk 10000
10000
"981205.out"
exp(8.11393) * x ** ( -2.20288 )
"routes.out"
exp(8.52124) * x ** ( -2.48626 )
Count –  80% of routes traverse 20% of routers 1000
100
•  Leverage this empirical observaCon to implement persistent and scalable link-­‐flooding aMacks 10
1
1
10
100
1000
100
10
1
1
10
100
Router out-­‐degree –  AMack traffic is indisCnguishable from legiCmate at target router –  AMack is “moving target” for same N-­‐server area •  Changes target links before triggering alarms 10 5 11/19/14 The Coremelt AOack [Studer and Perrig, 2009] N bots and O(N2) legi(mate flows flood core routers 10 Mbps Core Flooding Ex. N = 104 => 108 flows x 10 Kbps / flow => exhausts 100 x 10 Gbps links 11 Crossfire AOack [Kang, Lee & Gligor, 2013] 1 Mbps N bots M servers Link F looding @ chosen IP addresses NxM legi(mate-­‐looking flows Ex. N = 104, M = 100 => 106 flows x 10Kbps/flow => exhausts a 10 Gbps link 12 6 11/19/14 1-­‐Link Crossfire AOack Flows => IndisXnguishable from LegiXmate low-­‐rate flows …
Bots …
40 Gbps Decoy Servers (4 Kbps x 10K bots x 1K decoys) Use same links as real DDoS target 13 1-­‐Link Crossfire AOack Flows => IndisXnguishable from LegiXmate …
Bots …
changing sets of flows Decoy Servers 14 7 11/19/14 1-­‐Link Crossfire AOack Flows => Alarms Not Triggered …
Bots …
suspend flows in t < Tdet sec & resume later Decoy Servers link-­‐failure detecCon latency, Tdet IGP routers: 217 sec/80 Gbps – 608 sec/60 Gbps BGP routers: 1,076 sec/80Gbps – 11,119 sec/60 Gbps t = 40 – 180 sec => Alarms are Not Triggered 15 n-­‐Link Crossfire •  n links traversed by a large number of persistent paths to a target area. small n; e.g., 5 -­‐ 15 “Narrow Path Waist” (observed power law for Internet route paths) …
N servers target link set Alternate Good
RelaXvely good
“moving targets,” same N servers = suspend-­‐resume flooding of different link sets 16 8 11/19/14 AOack Step 1: Link-­‐Map ConstrucXon traceroute …
trace results …
persistent vs. transient links routers …
…
…
Internet …
servers target area Only persistent links are targeted 17 AOack Step 2: Target-­‐Link SelecXon Goal: Select n Target Links …
Find n links whose failure maximizes degradaCon raCo (DR) Internet servers => maximum coverage problem target area 18 9 11/19/14 AOack Step 3: Bot CoordinaXon Commands …
Low send/receive rates AOack Flows ~ 1 Mbps …
…
…
…
…
…
Internet …
…
servers …
target area decoy server 19 1
Degraded ConnecXvity 0.9
1
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
0
DegradaCon Degradation RatioraCo Degradation Ratio
0.8
0.9
Univ1 Univ1
0.8
Univ2 Univ1 Univ2
Univ2 New York New
York
New York
Pennsylvania Pennsylvania
Pennsylvania
Massachusetts
MassachuseMs Massachusetts
Virginia
Virginia Virginia
East Coast
(US)
West Coast
East (US)
Coast (US)
(US) East
Coast
0.7
0.6
0.5
0.4
0.3
0.2
West Coast
Coast (US)
(US) West
0.1
0
0
5
10
15
20
25
30
35
40
45
50
Number of target links
n target links 15
20
25
30
35
40
45
• 5DR =10 # degraded bot-­‐to-­‐target area paths / #50 all bot-­‐to-­‐target area Number of target links
•  Flooding a few target links causes high degradaCon (DR) –  10 links => DR: 74 – 90% for Univ1 and Univ2 –  15 links => DR: 53% (33%) for Virginia (West Coast) 20 10 11/19/14 EffecXve Independence of Bot DistribuXon < Bot distribuCon on the map > Se|ng: Experiments using 6 different bot distribuCons No significant difference in aMack performance DegradaCon raCo Result: 3 2 1 4 5 6 Univ1 Pennsylvania East Cost (US) Baseline Distr1 Distr2 Distr3 Distr4 Distr5 Distr6 n target links 21 Fundamental Causes of DoS AOacks •  Asymmetric state allocaCon –  Receiver must do more work than sender (e.g. TCP SYN flood) •  Persistent rate gap –  Max network line rate >> max server rate •  This gap has not changed much over Cme –  Allows an army of bots to flood public servers with junk traffic •  Power laws of the Internet topology –  Result in a narrow path waist to any potenCal target –  Enables crossfire aMack 22 11 11/19/14 Sources •  Various slides from Vitaly ShmaCkov and Virgil Gligor 23 Review of Lecture •  What did we learn? –  Trade-­‐offs and causes of DDoS aMacks –  The coremelt aMack –  The crossfire aMack •  Paper discussion: “Inferring Internet Denial-­‐of-­‐Service AcCvity” –  Discussion lead: Ahmed –  Scribe: Wei •  What’s next? –  More DDoS 24 12