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

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

49. 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?

50. 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