1. > Nicolas FISCHBACH IP Engineering Manager - COLT Telecom AG nico@securite.org - http://www.securite.org/nico/ version 1.0 (Distributed) Denial of Service attacks, detection and protection

2. © 2002 Sécurité.Org 2 Agenda » Denial of Service and Worms » Attacks >Architectures >Distributed attacks and agents >Local and remote network based attacks » Detection and protection >Locally >Internet » Conclusion

3. © 2002 Sécurité.Org 3 Definition (1) » Goal of DoS attacks >Eat up resources (bandwidth, CPU, memory, etc) to make a service slow or take it completely down : -File descriptors, sockets, state memory, PIDs -SSL sessions, IPsec encrypted VPNs -Dynamic web pages, SQL requests, downloads, SPAM -Fill up logs (make searching/parsing the logs more complex) >Take the service down by (continuously) exploiting a bug in the network, the system, the service or the application -- or even by destroying information >Easier for a script kiddie to launch a DoS attack than to break into a system : -agents/systems under control are traded on IRC -at the moment these kiddies focus on online game servers

4. © 2002 Sécurité.Org 4 Definition (2) » Goal of DoS attacks >Attack from a single source or multiple, distributed, sources >Source IP address spoofed or stepping stone to : -Hide the real source -Amplify the attack -Make filtering based on the source IP address useless -Fake a competitor attack >Unfortunately most of the attacks are and can still be used months, even years after their discovery : -« Part » of the protocol or the infrastructure -Solution or work-around not yet available or not yet deployed

5. © 2002 Sécurité.Org 5 Attacks : architecture (1) Bad guy Victim Compromised host » Basic attack >Some names : -(win)nuke, ping of death, land, teardrop, jolt, pepsi, bo(i)nk, nestea(2), naptha, 3wahas, stream, fraggle, or a mix of some attacks (targa/rape) >TCP -SYN flood -Use of several flags (FIN/SYN/RST/PSH/ACK/URG) -Attacks requiring an established TCP session >ICMP -Often ICMP echo and echo_reply messages >UDP Third parties

6. © 2002 Sécurité.Org 6 Attacks : architecture (2) Bad guy Victim Amplifiers Owned host » Amplified or reflectors based attacks >Basic attack, but amplified (factor 10-1000:1) and/or using reflectors (usually a 1:1 ratio) : -smurf, P2P clients/servers, DNS servers, broken TCP implementations with guessable ISNs, etc.

7. © 2002 Sécurité.Org 7 Attacks : architecture (3) Bad guy Master agent Victim (s) Slave agents (zombies, bots) Third parties Owned host » Distributed attack >Usually only one target : large packets (bandwidth), small packets (host resources)

8. © 2002 Sécurité.Org 8 Attacks : agents (1) » Slave agents >« Modified » servers, services and also network equipment (ie. routers) >Compromised servers run a (D)DoS agent : -Trinoo, TFN{(2,3)k}, omega, Stacheldrat*, Carko, Trinity, etc. -Trojan horse >P2P (peer-to-peer) tools » Agents are distributed >On the same network : school, company, ISP, cable/xDSL « area » >Same country or continent >Same « type » of network : IPv6 island, mbone, Internet2 >Completely distributed over the Internet

9. © 2002 Sécurité.Org 9 Attacks : agents (2) » Agents deployment and communications >« By hand » >Automated script (downloading data from a central server over HTTP/FTP/DCC/etc) >DDoS agents « deployed » using a worm or a virus and hidden using a {tool,root}kit (adore, t0rn, etc) : -Makes it easy and quick to collect and acquire a lot of systems -First sign of a « soon to be launched » attack -VBS/*, Win32/*, Code*, Nimda, 1i0n/ramen, slapper, etc. -(Bio)diversity helps to reduce exposure to a worm, but makes the IS more complex >Warez FTP servers >Fake update for a well known application >IRC, P2P tools, instant messaging, etc.

10. © 2002 Sécurité.Org 10 » Affected protocols >ARP : DoS and traffic redirection >CDP : DoS (next to information leak) >STP : create loops in the network or even take it down (block all ports) >VTP : change the VLANs configuration >DTP : transport VLANs over the network >DHCP/BOOTP : traffic redirection and DoS Attacks : the data link layer

11. © 2002 Sécurité.Org 11 Attacks : the network layer » Local attacks >IGPs (OSPF, (E)IGRP, IS-IS) » « Remote » attacks >TCP segment with specific flags >(Fragmented) UDP packets >(Fragmented) ICMP messages >Single packet containing a buffer overflow, format string, etc. >Inject routes into an eBGP session or try to break the TCP session

12. © 2002 Sécurité.Org 12 Detection (1) » Define metrics and describe, graph and monitor (ab)normal behaviour » At the network layer >New SMTP and/or HTTP flows >Size and fragmentation of packets >Protocols distribution (TCP/UDP/ICMP) >Line load, CPU load, free memory, response time, etc. >Advanced analysis of network traffic » On systems and at the application layer >Firewalls, xIDS, NMS >Logs >CPU load, memory usage, response time >State tables (TCP sessions state for example)

13. © 2002 Sécurité.Org 13 Detection (2) » Correlate data to ease detection >Locally by using multiple sources : xIDS/FW/ACLs with log- input/NMS/flows/honeypots -Improves the detection of false positive and false negatives >By taking part of or paying for services that analyze pseudo- anonymous logs and inform subscribers about on-going attacks >Packets, transactions, strange network behaviour (DNS lookups, nmap/queso/xprobe based scans, etc) » IA based anomaly detection >Still in the R&D labs ! >Is detection the real issue or is it the quantity of data to deal with ?

14. © 2002 Sécurité.Org 14 Detection (3) » How to find the source of an attack ? >Local logs >Logs of systems used as stepping stones >Public archives of routing information : -Which AS used to announce this network prefix -Which route server used to see the same thing, etc >Netflow exports (or RMON), S-train’s « source tracking » >Network traffic dumps : -Dumps are seldom (this gets even worse for layer 2 dumps) -Logs and dumps usually start _after_ the attack -Depending on the network architecture, capturing traffic can be a headache or even impossible >Hop-by-hop backtracing : what about AS boundaries and upstream tracing ?

15. © 2002 Sécurité.Org 15 Protection (1) » What are the issues ? >Spoofed source IP address(es) >The source of the attack is far away from a network point of view >Most of the time you can just sit down and wait : -You and your ISP are at the network edge -The source of the attack is in the APNIC zone -The network prefixes aren’t allocated and only routed for a short period of time >It may be complex to identify the type of traffic : try to be proactive >Your network is usually redundant, resilient, divided up into domains and able to fail-over in case of failure of a link or an equipment : take (D)DoS risks into account during design

16. © 2002 Sécurité.Org 16 Protection (2) » What are the solutions ? >There is no technical solution that makes you completely safe : -Configuration of the equipment and network architecture -Systems and applications up-to-date, audited and monitored >Attacks can be filtered at differents levels : -Switches, routers, firewalls, xIDS with « fireback » -Dedicated devices : commercial solutions (local and distributed) (still) require a human decision -Systems/applications (decode and filter parameters) >Should you drop this kind of traffic or react to it ? -RST in response to SYN ? -Don’t make the situation worse and more complex >Best Current Practices

17. © 2002 Sécurité.Org 17 Protection (3) » At the data link layer >Disable and filter (depends on your network architecture) all unused or useless protocols -CDP, STP, DTP, VTP >Monitor (or fix) ARP caches and tables on your systems and network devices

18. © 2002 Sécurité.Org 18 Protection (4) » At the network layer >Bandwidth -Talk to your ISP/upstream(s) -Why should you allow more than 64Kb/s of ICMP and/or UDP traffic on your Internet link ? Take normal traffic into account (DNS and Path MTU Discovery for example) -What if your bandwidth is charged on a UBB basis ? >Filter source and destination IP addresses -Your network prefixes -DSUA networks (RFC 1918, AutoDHCP, D/E classes, etc) -Only route and accept network from allocated blocks -etc.

19. © 2002 Sécurité.Org 19 Protection (5) » At the network layer >Decide not to route or not accept prefixes known to be source of problem a la *@{hotmail, yahoo}.com SMTP filtering >Stop to announce the PI space if possible (IRC servers ;-) or de-aggregate a large PA block into /24s and stop announcing the « affected » prefixes >Make sure you have some way to administer your network and the devices « out-of-band » >In some recent network designs engineers plan a second ISP (routing, addressing, NAT and DNS become an issue) >When possible think about using some non-routed prefixes when not needed

20. © 2002 Sécurité.Org 20 Protection (6) » At the network layer >Automatic « blacklisting » can make you quickly unreachable (large cable/DSL providers, proxy/caches) >Depending on the filtering you will implement you may not have any log/evidence : -Dynamic routing into null0 or reject -« Drop » ACL without logging, loose/strict uRPF -Upstream based filtering >Decide if you want to rate-limit the traffic only or redirect it to some dedicated device >Filter based on traffic or packet patterns (TTL, ip.id, ip.length, ISNs, ICMP message type, ports, etc) >Route dampening may not be your friend for a short period of time

21. © 2002 Sécurité.Org 21 Protection (7) » At the transport layer >TCP segments with the SYN flag -Use « cookies » (dito for IPsec) -Intercept the 3-way handshare on some dedicated device (router, firewall, DDoS filter) acting as a TCP Intercept like >Established TCP sessions : -Use load balancers to redirect part of the traffic (to reduce the impact, to redirect traffic into a black hole or towards a dedicated device) -Do we need a tool or device that monitors and tracks the full TCP session and related state changes (as far as FIN_WAITx)? » At the application layer >Use application layer proxies and filters (NBAR ?) >Use devices that recognize flows and can deal with them

22. © 2002 Sécurité.Org 22 Protection (8) » At the Internet « level » >ICMP Traceback (itrace) -Each router sends, with a low probability, a message to the destination of a packet it forwarded with information about the previous and next hop and part of the payload -“Works” only for larger (D)DoS attacks >IP Traceback -Traceback information is stored in the ip.id field by the “IPT” routers on the packet’s path -Probability to catch smaller attacks is better than with itrace >MULTOPS (Multi-Level Tree for Online Packet Statistics) -A local data structure on each router stores data about current flows and is analyzed to detect/respond to attacks

23. © 2002 Sécurité.Org 23 Protection (9) » At the Internet « level » >SPIE (Source Path Isolation Engine) -The router stores temporary a hash about each packet it forwards and authorized routers can query this information >Pushback -Routers send rate-limit requests for certain networks if they detect attacks (based on traffic characteristics) to their neighbors >IDIP (Intruder Detection and Isolation Protocol) -Protocols and framework used to correlate information, detect and respond to intrusions >HIP (Host Identity Payload/Protocol) -New name space (next to IP/DNS) with IKE like functionalities and public key based authentication for hosts

24. © 2002 Sécurité.Org 24 Protection (10) » At the Internet « level » >CenterTrack -Secondary network used to carry “interesting” packets detected by routers for analysis >Limitations -CPU and memory needs on routers -Fundamental changes (infrastructure, deployment, ops, etc) -IP address spoofing and traceback are the key issues >Conclusion -{in,e}gress filtering -Deployment of S-BGP, IPsec (AH), IPv6, ECN, multicast ? -« Legitimate » DoS (« Slashdot effect ») -Laws ?

25. © 2002 Sécurité.Org 25 Conclusion » Future >Research in this domain is quite active, but not a lot of publications (attack/defense) >Device capable of generating a lot of PPS are being targeted (routers) >Agents and worms become more and more « intelligent » >A new playground : Internet2 >Come up with « un peu de finesse dans ce monde de brutes » : attacks are usually emotional firebacks and not « well prepared » » And you ? >Post-mortem analysis and incident response processes >Help to get rid of (D)DoS by securing your network ;-)

26. © 2002 Sécurité.Org 26 Publications » Publications >Inferring Internet DoS Activity (Caida) >A Snapshot of Global Worm Activity (Arbor) >Shining Light on Dark Internet Address Space (Arbor) >How to 0wn the Internet in Your Spare Time (Staniford/Paxson) >Global Routing Instabilities during Code Red II and Nimda Worm Propagation (Renesys) >Trends in Denial of Service Attack Technology (CERT) >...

27. © 2002 Sécurité.Org 27 That’s all folks :-) » Latest version will be posted to : » IP Backbone Security presentation : » Q&A Image: http://www.inforamp.net/~dredge/funkycomputercrowd.html