1 / 28

Distributed Denial-of-Service Attacks and Practical Support for IP Traceback

Distributed Denial-of-Service Attacks and Practical Support for IP Traceback. Authors: Stefan Savage, David Wetherall, Anna Karlin, Tom Anderson Presenter: Stephen Ives. Outline. Background DDoS Attacks Current Solutions Proposed Solution: Probabilistic Marking Conclusion

sorcha
Download Presentation

Distributed Denial-of-Service Attacks and Practical Support for IP Traceback

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Distributed Denial-of-Service Attacks and Practical Support for IP Traceback Authors: Stefan Savage, David Wetherall, Anna Karlin, Tom Anderson Presenter: Stephen Ives 18-845: Internet Services

  2. Outline • Background • DDoS Attacks • Current Solutions • Proposed Solution: Probabilistic Marking • Conclusion • Problems & Questions 18-845: Internet Services

  3. Background • Distributed Denial-of-Service (DDoS) attacks increasingly popular among hackers • High-visibility impact with low threat of getting caught • Authorities want ability to trace attacks back to their origin • Traceback not natively supported by IPv4 18-845: Internet Services

  4. DDoS Attacks • Some common Internet DDoS-style attacks: • Buggy TCP/IP network stacks susceptible to unusual packets, usually causing system crashes • Flooding network with UDP or ICMP packets • Large numbers of TCP SYN packets sent to a host, flooding network and tying up system resources until connections time out 18-845: Internet Services

  5. DDoS Attacks - Examples • February: Yahoo, eBay, Amazon, Buy.com and others inaccessible due to DDoS attacks • FBI, police still haven’t caught hackers(?) • Advanced DDoS tools such as Trinoo, Stacheldraht, and Tribal Flood Network automated the attacks • Estimated downtime damages: ~$1.2 billion (Yankee Group research firm) 18-845: Internet Services

  6. DDoS Attacks - Tools • Hackers probe networks for security holes and gather lists of vulnerable machines • Usually automate process of compromising these hosts and installing DDoS tools • Current DDoS tools have two parts, “masters” and “daemons” 18-845: Internet Services

  7. DDoS Attacks – Tools (2) • Hackers connect to masters, which control and monitor the daemons • Master can tell daemons to DoS a number of hosts, ping daemons to determine which are currently running, instruct daemons to terminate, etc. • Masters and daemons include password protection to prevent unauthorized access 18-845: Internet Services

  8. DDoS Attacks – Tools (3) • Masters and daemons communicate on pre-determined ports using UDP packets • Masters sometimes encrypt daemon host list • Daemons usually flood targets with UDP packets • Some flaws in existing tools allow for easy detection • Not as stealthy as the Internet worm, but this will probably change in the near future 18-845: Internet Services

  9. Current Solutions DDoS solutions in use today: • Ingress filtering • Link testing • Logging 18-845: Internet Services

  10. Ingress Filtering • Used on routers to prevent IP spoofing • Routers check source addresses on incoming packets, drop invalid addresses • Problems: • Router has to examine each incoming packet • Hard to tell which addresses are invalid (e.g. Mobile IP) • Many ISPs must use ingress filtering to be effective • Doesn’t address traceback issue, just limits sources of DDoS traffic 18-845: Internet Services

  11. Link Testing • Have routers determine which upstream links are carrying the DDoS traffic • Start at router nearest victim, and recurse towards attacking hosts • Only works while attack in progress • Two main types of link testing: • Input debugging • Controlled flooding 18-845: Internet Services

  12. Input Debugging • Feature on some routers, maps traffic matching a filter on output ports to corresponding input ports • Requires an attack signature (some sort of common feature between all DDoS packets) • Usually requires human cooperation from upstream ISPs to install filters • This process is slow, may not catch attack in time 18-845: Internet Services

  13. Controlled Flooding • Look at how localized flooding by selected upstream hosts affects DDoS traffic • Changes in DDoS traffic rate imply a link carrying it is found (difficult in multiple link case) • Requires a pre-built map of Internet topology • Can make a bad situation worse (adding more packets to original DDoS traffic) • Need hosts on Internet willing to flood victims that request it (another DDoS opportunity?) 18-845: Internet Services

  14. Logging • Record packets at key routers • Use data-mining to determine attack paths • Can be done long after attack is over • Requires considerable computer resources, detailed knowledge of Internet topology • May not get traceback answer in time to catch hacker 18-845: Internet Services

  15. Proposed Solution: Probabilistic Marking • Have router randomly mark packets to associate packets with it • Doesn’t require significant router overhead • Can track multiple attacks • Post-mortem analysis is possible • Techniques include: • Node appending • Node sampling • Edge sampling 18-845: Internet Services

  16. Node Appending • Simply add router’s IP address to the end of the packet • Costly for routers to append data to traffic • Packet may not have sufficient space to list all routers • Attacker could insert arbitrary lists of routers before sending packet 18-845: Internet Services

  17. Node Sampling • Use one packet field in the to hold router address • Router records its address in packet with some probability p • Victim orders routers by number of samples received from each to reconstruct path • Not as costly for routers to implement • Attacker cannot fake routers in the valid path • Requires tens of thousands of packets to converge, doesn’t work against multiple attackers 18-845: Internet Services

  18. Edge Sampling • Use two packet fields to record edges between routers, and an associated distance field • Routers choose to mark packet with probability p • If the router marks the packet, fill in start field and set distance to zero • Otherwise, if distance is zero, fill in end field • Increment distance regardless • Attacker cannot insert routers into the valid path with this scheme 18-845: Internet Services

  19. Compressed Edge Fragment Sampling • Halve space requirement by storing the XOR of the two IP addresses involved in the edge 18-845: Internet Services

  20. Compressed Edge Fragment Sampling (2) • Divide address into k fragments, randomly encode one fragment (and offset) in packet • Fragment data not unique, so bit-interleave Address with Hash(Address) for error detection 18-845: Internet Services

  21. Compressed Edge Fragment Sampling (3) • To reconstruct address: • Combine k fragments • Deinterleave bits • Compare packet’s Hash(Address) with re-computed Hash(Address) • Use address if match 18-845: Internet Services

  22. Compressed Edge Fragment Sampling (4) • This method can reconstruct the complete path in a few thousand packets • Order of magnitude better than node sampling • However, amount of computation for reconstruction grows rapidly when multiple attacker paths diverge • Tradeoffs when choosing k: • Large k reduces per-packet space overhead • Small k decreases computation overhead 18-845: Internet Services

  23. Integration with IPv4 • Overload 16-bit identification field of IP header with offset, distance, and fragment data 18-845: Internet Services

  24. Integration with IPv4 (2) • Use of identification field backwards-compatible with existing IP stacks • Alignment with TTL field allows router to skip checksum computation when incrementing distance, decrementing TTL • Authors chose k = 8, and 5 bits for distance (most hosts are reachable in < 32 hops) 18-845: Internet Services

  25. Integration with IPv4 (3) • What happens with fragmented IP packets? • If fragmented upstream of marking router: • Different fragments of packet may not get marked, preventing datagram reassembly • Simple: don’t mark fragments, but attackers could exploit this • Instead, with probability q < p, prepend fragment with ICMP echo reply header and append full edge data • fragment data lost, but edge data is still received 18-845: Internet Services

  26. Integration with IPv4 (4) • If packet fragmented downstream of marking router: • Fragments may be lost, preventing reassembly • If future marked packets are fragmented, they may have an identical identification field and cause incorrect reassembly • So, set Don’t Fragment (DF) bit on all marked packets • May cause problems when not using MTU path discovery, but this is rare today 18-845: Internet Services

  27. Conclusion • Ability to perform IP traceback is important, especially for DDoS attacks • Compressed edge fragment sampling can find attackers with several thousand packets • Still requires direct assistance from routers • Still have to find attacking host once source network is found 18-845: Internet Services

  28. Problems & Questions • Do routers have to mark packets all the time (unnecessary when not under attack?) • ICMP packets in IP fragment workaround may get dropped by router policies (common at large sites) • Is there an easy way to get the victim’s kernel to relay traceback data to a user process? • XOR scheme requires contiguous path of marking routers starting at the victim or else path reconstruction fails 18-845: Internet Services

More Related