Download document 8927325

11/24/14 20. DDoS – Detec,on and Protec,on 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 –  DDoS mechanisms •  Where we’re going today –  DDoS protecCon •  Where we’re going next –  Botnets 2 1 11/24/14 Network Denial of Service (DoS) •  Goal: take out a large site with liNle compuCng work –  Some DoS aNacks are possible because of bugs. These can be fixed. –  However, there are more fundamental causes for DoS •  Asymmetric state allocaCon in network protocols •  Persistent rate gap •  Power laws of the Internet topology •  DoS can happen at any layer •  Link •  TCP/UDP •  ApplicaCon •  Sad truth: –  Current Internet not designed to handle DDoS aNacks 3 DoS Mi,ga,on Techniques •  Client puzzles –  Goal: create more work for the aNacker 4 2 11/24/14 Client puzzles •  Idea: slow down aNacker •  Moderately hard problem: –  Given challenge C find X such that (
) n LSBn SHA-­‐1( C || X ) = 0
–  AssumpCon: takes expected 2n Cme to solve –  For n=16 takes about .3sec on 1GhZ machine –  Main point: checking puzzle soluCon is easy. •  During DoS aNack: –  Everyone must submit puzzle soluCon with requests –  When no aNack: do not require puzzle soluCon 5 Examples •  TCP connecCon floods [Juels and Brainard, 1999] –  Example challenge: C = TCP server-­‐seq-­‐num –  First data packet must contain puzzle soluCon •  Otherwise TCP connecCon is closed •  SSL handshake DoS: [Dean and Stubblefield, 2001] –  Challenge C based on TLS session ID –  Server: check puzzle soluCon before RSA decrypt. •  Same for applicaCon layer DoS 6 3 11/24/14 Benefits and limita,ons •  Hardness of challenge: n –  Decided adapCvely, based on DoS aNack volume. •  LimitaCons: –  Requires changes to both clients and servers –  Hurts low power legiCmate clients during aNack: •  Clients on cell phones and tablets cannot connect 7 Memory-­‐bound func,ons •  CPU power raCo: –  high end server / low end cell phone = 8000 ⇒ Impossible to scale to hard puzzles •  InteresCng observaCon: –  Main memory access Cme raCo: •  high end server / low end cell phone = 2 •  BeNer puzzles: –  SoluCon requires many main memory accesses •  Dwork-­‐Goldberg-­‐Naor, Crypto ‘03 •  Abadi-­‐Burrows-­‐Manasse-­‐Wobber, ACM ToIT ‘05 8 4 11/24/14 DoS Mi,ga,on Techniques •  Client puzzles •  CAPTCHAs –  Goal: survive organized DDoS aNacks that resemble flash crowds 9 2. CAPTCHAs •  Idea: verify that connecCon is from a human •  Applies to applicaCon layer DDoS [Kandula, Katabi, Jacob, Berger 2005] –  During aNack: generate CAPTCHAs and process request only if valid soluCon –  Present one CAPTCHA per source IP address. 10 5 11/24/14 DoS Mi,ga,on Techniques •  Client puzzles •  CAPTCHAs •  Source iden,fica,on –  Goal: idenCfy packet source –  UlCmate goal: block aNack at the source 11 Solu,on 1: Ingress filtering [RFC 2827, 3704] •  Big problem: DDoS with spoofed source IPs ISP Internet •  Ingress filtering policy: ISP only forwards packets with legiCmate source IP 12 6 11/24/14 Implementa,on problems •  ALL ISPs must do this. Requires global trust. –  If 10% of ISPs do not implement ⇒ no defense –  No incenCve for deployment •  2014: –  25% of Auto. Systems are fully spoofable (spoofer.cmand.org) –  13% of announced IP address space is spoofable •  A few networks that allow spoofing are enough for large aNacks –  The 2013 DDoS aNack against Spamhaus used only 3 networks 13 Solu,on 2: IP Traceback [Savage et al.’00] •  Goal: –  Given set of aNack packets –  Determine path to source •  How: change routers to record info in packets •  AssumpCons: –  Most routers remain uncompromised –  ANacker sends many packets –  Route from aNacker to vicCm remains relaCvely stable 14 7 11/24/14 Simple method •  Write path into network packet –  Each router adds its own IP address to packet –  VicCm reads path from packet •  Problem: requires space in packet –  Path can be long –  No extra fields in current IP packet format •  Changes to format too much to expect 15 Be`er idea •  DDoS involves many packets on A1 same path •  Store one link in each packet –  Each router probabilisCcally stores own address –  Fixed space regardless of path length A2 R6 A3 R7 A4 A5 R8 R9 R10 R12 V 16 8 11/24/14 Edge Sampling •  Data fields wriNen to packet: –  Edge: start and end IP addresses –  Distance: number of hops since edge stored •  Marking procedure for router R if coin turns up heads (with probability p) then write R into start address write 0 into distance field else if distance == 0 write R into end field increment distance field 17 Edge Sampling: picture •  Packet received –  R1 receives packet from source or another router –  Packet contains space for start, end, distance packet R1 s e d R2 R3 18 9 11/24/14 Edge Sampling: picture •  Begin wriCng edge –  R1 chooses to write start of edge –  Sets distance to 0 packet R1 0 R1 R2 R3 19 Edge Sampling " Finish wriCng edge n 
n 
R2 chooses not to overwrite edge Distance is 0 w  Write end of edge, increment distance to 1 packet R1 R1 R2 1 R2 R3 20 10 11/24/14 Edge Sampling " Increment distance n 
n 
R3 chooses not to overwrite edge Distance >0 w  Increment distance to 2 packet R1 R2 R1 R2 2 R3 21 Path reconstruc,on •  Extract informaCon from aNack packets •  Build graph rooted at vicCm –  Each (start,end,distance) tuple provides an edge •  # packets needed to reconstruct path E(X) < ln(d) p(1-­‐p)d-­‐1 where p is marking probability, d is length of path 22 11 11/24/14 Details: where to store edge •  IdenCficaCon field Version –  Used for fragmentaCon –  FragmentaCon is rare –  16 bits Flags edge chunk 0 2 3 7 8 15 Fragment Offset Time to Live Protocol Header Checksum •  Store edge in 16 bits? offset distance Header Length Type of Service Total Length IdenCficaCon Source Address of OriginaCng Host DesCnaCon Address of Target Host –  Break into chunks –  Store start + end OpCons Padding IP Data 23 More traceback proposals •  Advanced and AuthenCcated Marking Schemes for IP Traceback –  Song, Perrig. IEEE Infocomm ’01 –  Reduces noisy data and Cme to reconstruct paths •  An algebraic approach to IP traceback –  Stubblefield, Dean, Franklin. NDSS ’02 •  Hash-­‐Based IP Traceback –  Snoeren, Partridge, Sanchez, Jones, TchakounCo, Kent, Strayer. SIGCOMM ‘01 24 12 11/24/14 Problem: Reflector a`acks [Paxson’01] •  Reflector: –  A network component that responds to packets –  Response sent to vicCm (spoofed source IP) •  Examples: –  Web servers: TCP SYN 80 with vicCm.com source •  At vicCm: TCP SYN ACK packet –  DNS resolvers: UDP 53 with vicCm.com source •  At vicCm: DNS response –  NTP servers: monlist command with vicCm.com source •  At vicCm: large number of addresses that talked to the NTP server 25 Traffic Amplifica,on •  Single Master •  Many bots to generate flood •  Millions of reflectors to hide bots – Kills traceback and pushback methods 26 13 11/24/14 DoS Mi,ga,on Techniques •  Client puzzles •  CAPTCHAs •  Source idenCficaCon •  Capability-­‐based defense –  Goal: drop unwanted packets at routers 27 Capability Based Defense •  Basic idea: –  Receivers can specify what packets they want •  How: –  Sender requests capability in SYN packet •  Path idenCfier used to limit # reqs from one source –  Receiver responds with capability –  Sender includes capability in all future packets –  Main point: Routers only forward: •  Request packets, and •  Packets with valid capability 28 14 11/24/14 Capability Based Defense •  CapabiliCes can be revoked if source is aNacking –  Blocks aNack packets close to source R1 Source AS R2 R3 R4 Transit AS dest Dest AS ANack packets dropped 29 Capability Based Defense -­‐ References •  Anderson, Roscoe, Wetherall. –  PrevenCng internet denial-­‐of-­‐service with capabiliCes. SIGCOMM ‘04. •  Yaar, Perrig, and Song. –  Siff: A stateless internet flow filter to miCgate DDoS flooding aNacks. IEEE S&P ’04. •  Yang, Wetherall, Anderson. –  A DoS-­‐limiCng network architecture. SIGCOMM ’05 30 15 11/24/14 DoS Mi,ga,on Techniques •  Client puzzles •  CAPTCHAs •  Source idenCficaCon •  Capability-­‐based defense •  Pushback traffic filtering –  Goal: cut off network connecCon of DoS sources 31 Pushback Traffic Filtering •  AssumpCon: DoS aNack from few sources •  IteraCvely block aNacking network segments. 32 16 11/24/14 Pushback Filtering – References •  Mahajan, Bellovin, Floyd, Ioannidis, Paxson, Shenker. Controlling High Bandwidth Aggregates in the Network. Computer Communica0ons Review’02. •  Ioannidis, Bellovin. ImplemenCng Pushback: Router-­‐Based Defense Against DoS ANacks. NDSS’02 •  Argyraki, Cheriton. AcCve Internet Traffic Filtering: Real-­‐Time Response to Denial-­‐
of-­‐Service ANacks. USENIX’05. 33 Take home message: •  Denial of Service aNacks are real. Must be considered at design Cme. •  Sad truth: –  Internet is ill-­‐equipped to handle DDoS aNacks –  Commercial soluCons: CloudFlare, Prolexic •  Many proposals for core Internet redesign 34 17 11/24/14 Sources •  Various slides from Dan Boneh 35 Review of Lecture •  What did we learn? –  Client puzzles –  CAPTCHAs –  Source idenCficaCon –  Capability-­‐based defense –  Pushback traffic filtering •  Paper discussion: “STRIDE” –  Discussion lead: Zikai –  Scribe: BumJun •  What’s next? –  Botnets 36 18