1. Distributed Denial of ServiceThe current state and counter measures Juergen BrendelCTO & ArchitectEsphion Ltd.The University of Auckland, June 3, 2003 The University of Auckland, 2003

2. Agenda • DoS attacks: Background • DDoS techniques and tools • Attack detection • Possible defenses • Filters • Specialized DDoS solutions The University of Auckland, 2003

3. Agenda • DoS attacks: Background • DDoS techniques and tools • Attack detection • Possible defenses • Filters • Specialized DDoS solutions The University of Auckland, 2003

4. The nature of DoS • DoS: Denial of Service, NOT intrusion or data theft! • Aim: Making sure that legitimate users of the site / server / resource cannot be served • Effects: • Business is essentially ‘closed’ • Disgruntled customers • Damaged customer/partner relationships • Bad press • Loss in advertising revenue • Higher bandwidth-cost for victim (some attacks) The University of Auckland, 2003

5. The two natures of DoS • Attacks on specific weaknesses: • Using OS or application bugs to crash routers or servers • Poisoning DNS • Reconfiguring routers • Resource consuming attacks: • Memory on servers • Router packet forwarding capacity • Name servers • Network bandwidth • Often accomplished by flooding The University of Auckland, 2003

6. Flood attacks • Massive amounts of packets result in: • Clogged network connections • Crashed routers or servers • Higher bandwidth cost for victim • “Parking 500 cars in your driveway…” • Typically cannot be defended against with patches • Often using many compromised systems as traffic generators (“Zombies” , “Agents” or “Bots”) • Distributed Denial of Service (DDoS) attacks • Tools available for download • Result: Flood attacks are easy (ScriptKiddies)! The University of Auckland, 2003

7. Targets • ISPs • News sites • E-commerce sites • Financial institutions • Government sites • Dialup accounts and other home users (!) • IRC servers (!) • Network infrastructure (!) The University of Auckland, 2003

8. Motivation • Sabotage • Terrorism • Blackmailing • Political protest • Boredom • Thrill and headlines (bragging rights) • Misdirected, clueless anger The University of Auckland, 2003

9. Attack history • Feb 2000 estimated US$100 million in lost revenue • Done by 15 year old Canadian hacker: Mafiaboy • Yahoo 3 hours • Buy.com 3 hours • eBay 90 minutes • CNN 120 minutes • Amazon.com 1 hour • E-trade 90 minutes • Datek 30 minutes • ZDNet 3 hours • Was only caught because he bragged about it The University of Auckland, 2003

10. Harsh punishment… The University of Auckland, 2003

11. Attack history (continued) • Jan 2001 US$10 million damage by Microsoft attack • May 2001 Whitehouse site down for 6 hours • June 2001 CERT downed twice for more than seven hours • Aug 2001 Whitehouse targeted by CodeRed (fizzles) • Nov 2001 Latest trend: Attacking routers • June 2002 Fox network web-site attacked • Today 4000 flood-style DoS attacks per week (!) The University of Auckland, 2003

12. Agenda • DoS attacks: Background • DDoS techniques and tools • Attack detection • Possible defenses • Filters • Specialized DDoS solutions The University of Auckland, 2003

13. Making a zombie / agent / bot • Compromise an unsuspecting host: • RootKits • Trojans • Worms / Viruses • Preferred target: • ‘Always On’ systems • Connected via cable-modem, DSL, etc. • Mostly home-computers, servers if possible • More Windows machines • Two-stage attack • First the Zombie is compromised, tools are installed… • … followed by the actual DDoS attack on another victim The University of Auckland, 2003

14. Attack network Attacker Handler Handler Handler Agent Agent Agent Agent Agent Agent Victim The University of Auckland, 2003

15. Spoofing the source address • Two reasons for spoofing: • Attack is difficult to track • A third party can get into trouble • Can be used to utilize third-party (SMURF, Reflection) • Not all DDoS attacks use spoofed addresses: • Some UDP flood tools don’t spoof the source • SYN-flood always spoofs • SMURF attack packets have proper source, but reply to a spoofed address The University of Auckland, 2003

16. UDP flood Source address not always spoofed, so that root access is not necessary SYN flood Starts TCP-handshake, without completing Server sends ACK packet and allocates memory Consumes bandwidth and memory resource Fragmentation attack Missing fragments overload reassembly queues on server ICMP flood Sending large number of ICMP packets SMURFs Send a spoofed ICMP-Echo-Request packet to a ‘SMURF amplifier’ network Directed broadcast All hosts in amplifier network reply to spoofed address: The actual victim More TCP floods Stream attack Null flood Mixed flags Reflection attack Types of flood attacks The University of Auckland, 2003

17. UDP flood Source address not always spoofed, so that root access is not necessary SYN flood Starts TCP-handshake, without completing Server sends ACK packet and allocates memory Consumes bandwidth and memory resource Fragmentation attack Missing fragments overload reassembly queues on server ICMP flood Sending large number of ICMP packets SMURFs Send a spoofed ICMP-Echo-Request packet to a ‘SMURF amplifier’ network Directed broadcast All hosts in amplifier network reply to spoofed address: The actual victim More TCP floods Stream attack Null flood Mixed flags Reflection attack Types of flood attacks The University of Auckland, 2003

18. SYN flood • Normal TCP connection via three-way handshake: Client Server SYN reservememory connectionestablishment SYN+ACK ACK movememory ACK+PUSH request… The University of Auckland, 2003

19. SYN SYN SYN SYN SYN SYN SYN SYN SYN SYN SYN SYN SYN SYN SYN SYN SYN+ACK SYN+ACK SYN+ACK SYN+ACK SYN+ACK SYN+ACK SYN+ACK SYN+ACK SYN+ACK SYN+ACK SYN+ACK SYN+ACK SYN+ACK SYN+ACK SYN+ACK SYN+ACK SYN flood (continued) • Open many connections, but do not close them: Server Out of Memory The University of Auckland, 2003

20. UDP flood Source address not always spoofed, so that root access is not necessary SYN flood Starts TCP-handshake, without completing Server sends ACK packet and allocates memory Consumes bandwidth and memory resource Fragmentation attack Missing fragments overload reassembly queues on server ICMP flood Sending large number of ICMP packets SMURFs Send a spoofed ICMP-Echo-Request packet to a ‘SMURF amplifier’ network Directed broadcast All hosts in amplifier network reply to spoofed address: The actual victim More TCP floods Stream attack Null flood Mixed flags Reflection attack Types of flood attacks The University of Auckland, 2003

21. SMURF • Send PING via subnet-directed broadcast address to some network (SMURF amplifier), pretend to be victim: Attacker Badlyadministerednetwork Victim The University of Auckland, 2003

22. UDP flood Source address not always spoofed, so that root access is not necessary SYN flood Starts TCP-handshake, without completing Server sends ACK packet and allocates memory Consumes bandwidth and memory resource Fragmentation attack Missing fragments overload reassembly queues on server ICMP flood Sending large number of ICMP packets SMURFs Send a spoofed ICMP-Echo-Request packet to a ‘SMURF amplifier’ network Directed broadcast All hosts in amplifier network reply to spoofed address: The actual victim More TCP floods Stream attack Null flood Mixed flags Reflection attack Types of flood attacks The University of Auckland, 2003

23. SYN(pretend from victim) SYN+ACK SYN+ACK SYN+ACK SYN+ACK Reflection attack • Flood victim with SYN+ACKs from well-known servers: Attacker yahoo.com cnn.com ebay.com amazon.com Victim The University of Auckland, 2003

24. Tools of the trade The University of Auckland, 2003

25. Agenda • DoS attacks: Background • DDoS techniques and tools • Attack detection • Possible defenses • Filters • Specialized DDoS solutions The University of Auckland, 2003

26. Statistical detection: Volume • An increased number of packets of a particular type can indicate an attack • But: Increased legitimate demand can cause an increase as well • And: Need to adjust volume monitoring to regularly changing patterns The University of Auckland, 2003

27. Statistical detection: Volume The University of Auckland, 2003

28. Statistical detection: Volume The University of Auckland, 2003

29. Statistical detection: Addresses • Normal distribution of source addresses is not random, but clustered • Certain IP address ranges are not public(for example 192.0.0.0) • ‘Dissolving’ clusters can be an indication of a DDoS attack with randomly spoofed source addresses • But: Influx of new clients, or routing problems can dissolve established clusters The University of Auckland, 2003

30. Clusters of addresses Statistical detection: Addresses The University of Auckland, 2003

31. Statistical detection: Packet size • Histogram of packet sizes represents one ‘fingerprint’ of a network / site • Fingerprint depends on traffic profile • Change in size-histogram may indicate an attack • But: Increased legitimate demand for particular files / service can also change histogram The University of Auckland, 2003

32. Large packets Small packets Statistical detection: Packet size The University of Auckland, 2003

33. Statistical detection: Ratio • Attackers typically can only control the incoming traffic • Monitoring the ratio of certain incoming vs. outgoing packets can help identifying an attack more surely • A form of ‘remote host-based’ detection! • But: Volume attacks based on legitimate requests can go undetected The University of Auckland, 2003

34. Statistical detection: Ratio The University of Auckland, 2003

35. Statistical detection: Ratio The University of Auckland, 2003

36. Agenda • DoS attacks: Background • DDoS techniques and tools • Attack detection • Possible defenses • Filters • Specialized DDoS solutions The University of Auckland, 2003

37. Preventive measures • Stopping the spread of attack tools: • Anti-Virus software • Trip-wire • Use fire-wall to stop communication in attack network • Keep system current with latest patches • Hardening the network: • Don’t allow incoming subnet-directed broadcast • Don’t allow outgoing packets with external IP addresses(anti-spoof) The University of Auckland, 2003

38. Defensive measures? • Train for the emergency • After attack is detected, characterize it(protocol, source addresses, type of packet, etc.) • Implement filters on your routers to keep network attack-traffic free (ingress filtering). Works better on some routers than on others. • Get more bandwidth The University of Auckland, 2003

39. Defensive measures? • Call your up-stream provider and hope for the best… • Hard to find the proper contact • Filters may reduce performance for other customers • They still like to bill you for the used bandwidth • Maintain relationship with provider • Know who to contact • Ask provider what they would be willing to do • Choose up-stream providers, which have DDoS solutions installed or at least some sort or strategy: • Either they offer it as add-on for extra fee, always on… • …or you can rent the protection when you need it The University of Auckland, 2003

40. Agenda • DoS attacks: Background • DDoS techniques and tools • Attack detection • Possible defenses • Filters • Specialized DDoS solutions The University of Auckland, 2003

41. What are we filtering? • Tricky… • Site-specific knowledge • “This protocol is not used by that client” • “These ports are not in use” • Etc. • Patterns in floods • Many floods have patterns, but not all do… • Session-state • Very powerful • Very CPU/memory intensive • Difficult in asymmetric routing environments The University of Auckland, 2003

42. Where to place filters? • Not an easy question • Some floods attack the bandwidth • Other floods attack servers or routers • Example: Yahoo!’s bandwidth was not maxed out (multiple OC-12). Instead, their routers crashed because of high packet rate. • Example: Attack on dial-up user requires only some 50 – 60 kbit/s to succeed. Nobody will crash, but the line is effectively dead. The University of Auckland, 2003

43. Filtering at the target Resource Maximum available resource Legitimate Traffic Time The University of Auckland, 2003

44. Filtering at the target Resource Maximum available resource Attack Traffic Legitimate Traffic Time The University of Auckland, 2003

45. Filtering at the target Resource All available resources utilized Maximum available resource Attack Traffic Legitimate Traffic Time The University of Auckland, 2003

46. Filtering at the target Resource All available resources utilized Maximum available resource Attack Traffic Legitimate Traffic Time The University of Auckland, 2003

47. Resource All available resources utilized Maximum available resource Attack Traffic Remaining statistical trickle… Legitimate Traffic Time Filtering at the target The University of Auckland, 2003

48. Resource All available resources utilized Activating filters Maximum available resource Attack Traffic Legitimate Traffic Time Filtering at the target The University of Auckland, 2003

49. Resource All available resources utilized Activating filters Maximum available resource Attack Traffic Legitimate Traffic Time Filtering at the target: Pros/Cons • Protects internal network/computing resources • Network remains operational • Can be deployed in ‘your’ network • The link is still maxed out! The University of Auckland, 2003

50. Excess Bandwidth Filtering higher up Resource Activating filters Maximum available resource Attack Traffic Legitimate Traffic Time The University of Auckland, 2003