1 / 54

An Overview of Denial-of-Service attacks on the Internet

An Overview of Denial-of-Service attacks on the Internet. Bill Cheswick Lumeta Corporation ches@lumeta.com or ches@cheswick.com. Any public service can be abused by the public.

jamesserra
Download Presentation

An Overview of Denial-of-Service attacks on the Internet

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. An Overview of Denial-of-Service attacks on the Internet Bill Cheswick Lumeta Corporation ches@lumeta.com or ches@cheswick.com

  2. Any public service can be abused by the public

  3. A denial-of-service attack seeks to disrupt normal operations by flooding a target with an unmanageable number of packets or queries.

  4. DOS attacks do not seek to obtain data • Therefore, a return packet flow is not needed • Therefore, packets can come from sources hidden by spoofed return addresses in the packets. • This complicates traceback operations. • How do you hunt down the source of anonymous packets? (We’ll get to that.) • Is it worth tracing them back?

  5. DOS attacks: other properties • One need not fashion clever packets • sheer volume can swamp the processors, or even the incoming links • This means that ISPs are involved in handling these attacks. • It can be hard to tell if an attack is underway • Heavy use Vs. attack • being “slash-dotted”

  6. DOS attacks • An attack can go on indefinitely. • There are no theoretical solutions, just mitigations • The ultimate solution is to throw more iron at the problem • It is hard to marshal enough resources to swamp a “monster” site

  7. Properties of DOS attacks • Can be hard to determine if malice is afoot • being “slash-dotted” • heavy volume to a newspaper web site on election night: normal traffic, or evil • no technical solutions, just mitigations • DOS attacks are here to stay, even if we fix all the software problems on the Internet

  8. Types of DOS attacks • Lethal packets • “ping-o-death” • High impact packets • SYN attacks • Public key and other expensive processing • Simple flooding • Amplified flooding • Distributed attacks

  9. Lethal packets

  10. Lethal attacks • Directed at bugs in the kernel or TCP/IP stack • TCP/IP stack is often >>25,000 lines of code, in the kernel • Hard to debug • Protocol testing is hard to do • e.g. ping-o-death • More likely on immature TCP/IP implementations

  11. High impact packets

  12. High impact attacks • High processing costs in the target • Crypto processing can be target of such an attack • I.e. SYN packet attacks

  13. SYN attacks: TCP connections • TCP servers are optimized for many connections • The half-open case was not well handled

  14. Normal TCP open Client Server SYN,SEQ0 SYN,ACK, SEQ0+1,SEQ0 ACK, SEQ0+1,SEQ0+1

  15. Normal TCP open Client half-open <300ms

  16. First seen at Panix.com in fall 1996 A sea of SYN packets, with varying return packets Half-open processing was implemented poorly Quadratic behavior Wasn’t much call for improving it We’d been expecting it The only thing we left out of our firewalls book … removed at the last minute We knew of no good solution We are sorry we left it out SYN Attacks

  17. SYN attack: the arms race • Filter on source address (West Point) • Filter on IP “ID” field • Filter on sequence number • anticipate random number generator • We helped them debug their software! • But we could have watched them watching… • “spread spectrum” “frequency hopping” defense?

  18. SYN attacks - solutions • Fix the kernel • Most implementations are probably resistant now • Malicious attacks on algorithm performance! • Can be hard to tell when it is happening.

  19. Attacks on TCP/IP stacks • There will be more attacks on TCP/IP implementations • lots of code involved • hard to test code in a kernel

  20. Simple flooding

  21. Simple flooding • Start a program and leave • Needs a collection of compromised hosts (see below)

  22. Amplified flooding

  23. Amplified attacks • Stimulated emission of packets • Spoofed stimulation packet directs response toward target • Amplification methods: • directed broadcasts • services that amplify packet size or numbers • social engineering • ping, UDP chargen, DNS, multicast! • I.e. smurf attacks

  24. Identify ping generatornetworks G G target G G G G

  25. Trigger packets withspoofed return address G G target G G G G packet cannon

  26. Generators flood the targetwith packets G G target G G G G packet cannon

  27. Directed broadcasts • External request to send a packet to all hosts on an Ethernet • These should be (and usually are) blocked from the Internet • Many services should ignore these queries, but some don’t

  28. Amplification factors • Standard UDP chargen amplifies roughly 2.5 times, but • NT implementation returns up to 5K packet for a simple 42 byte stimulation packet • Directed broadcast amplifications can easily be hundreds • One net in Lucent (directed broadcast plus broadcast storm) returned 977,000 packets for a single probe packet.

  29. Defenses • Directed broadcast requests and pings can be filtered • Packets to the target are not spoofed, so they can be filtered • But: • DNS can be used, especially with zone transfers • DNS can’t be blocked

  30. Distributed Denial-of-Service Attacks

  31. DDOS • Similar to smurf attacks, but we install agents (“zombies”) on donor networks • Master programs direct the actions of zombies • who to attack, and how • zombie software updates! • Master commands may be encrypted, and with spoofed return addresses • Zombies may be spoofed if privs. allow

  32. DDOS • Installation of zombies allows a slow buildup of massive force • Double link to attacker makes attacker harder to locate • Zombies installed by • hand • automated attacks • travelling programs...

  33. Another problem with strange programs

  34. DDOS attacks • Made the news in 1999 • tfn, trinoo, stacheldraht (“barbed wire”), others • Has taken down major sites • Attacks continue

  35. Recent attacks: MSFT last week • Originally, a software problem • Servers robust against these attacks • DDOS attacks on their DNS servers, which were all on one net, I am told.

  36. DDOS attacks on the Internet • Root DNS servers already attacked • Get enough of them, long enough, and the Internet will grind to a halt • Routing infrastructure is another potential target of a number of attacks, including DDOS.

  37. Defenses: more iron • Add more processing and network capacity

  38. Defenses: robust software • Can resist high-impact attacks • Older kernels tend to be more robust • Berkeley Unix Vs. MSFT or Linux • Keep up with patches, but • can you trust the source of the patch?

  39. Defenses: packet filtering • Block the bad packets, keep the good • Look for idiosyncrasies in the attacking packets • Only allow packets from sites you’ve done business with for the past few weeks • Filter far enough out to resist flooding the line

  40. Defenses: moving target • Change the IP address of your targets frequently • Look for consistent DNS lookups to find out who cares • Doesn’t scale to monster sites • Doesn’t work if the network link is flooded • Diversify server locations (a la akamai)

  41. Defenses: egress filtering • ISPs should not accept spoofed packets • Easy to do at most edges • Needs hardware assist for major links • Assymetric routing frustrates this • What can’t we all just be friends?

  42. Packet traceback

  43. Traceback: how can we do this • Anonymous packets mean that we have to trace back one hop at a time, usually • ISPs need to be involved, usually • We haven’t seen “whack-a-mole” attacks yet

  44. Traceback: an early experiment • Packet streams are constant • If we interrupt the stream, we can prune the tree • Interrupt with don’t-feed-me packet? • DOS is possible • requires infrastructure changes • selective DOS attack on links can perturb packet stream • tested on an intranet

  45. Internet maps may help

  46. Aside: another DOS attack

  47. Traceback: query routers • Ask router for statistics • DEBUG crashes many routers • Routers are too busy • Requires privileged access to the router • How do we trace from alien ISPs?

  48. Traceback: itrace • Internet draft proposal • router issues routing information packet once per 20,000 packets • contains tracing information about that packet • <0.1% of network traffic • Packets ignored by most hosts • Data is there if you need it

More Related