distributed denial of service attacks and practical support for ip traceback n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Distributed Denial-of-Service Attacks and Practical Support for IP Traceback PowerPoint Presentation
Download Presentation
Distributed Denial-of-Service Attacks and Practical Support for IP Traceback

Loading in 2 Seconds...

play fullscreen
1 / 28

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


  • 228 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Distributed Denial-of-Service Attacks and Practical Support for IP Traceback' - sorcha


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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

18-845: Internet Services

outline
Outline
  • Background
  • DDoS Attacks
  • Current Solutions
  • Proposed Solution: Probabilistic Marking
  • Conclusion
  • Problems & Questions

18-845: Internet Services

background
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
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
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
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
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
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
Current Solutions

DDoS solutions in use today:

  • Ingress filtering
  • Link testing
  • Logging

18-845: Internet Services

ingress filtering
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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