280 likes | 559 Views
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
E N D
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
Outline • Background • DDoS Attacks • Current Solutions • Proposed Solution: Probabilistic Marking • Conclusion • Problems & Questions 18-845: Internet Services
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
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
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
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
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
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
Current Solutions DDoS solutions in use today: • Ingress filtering • Link testing • Logging 18-845: Internet Services
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
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
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
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
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
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
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
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
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
Compressed Edge Fragment Sampling • Halve space requirement by storing the XOR of the two IP addresses involved in the edge 18-845: Internet Services
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
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
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
Integration with IPv4 • Overload 16-bit identification field of IP header with offset, distance, and fragment data 18-845: Internet Services
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
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
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
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
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