> Nicolas FISCHBACH IP Engineering Manager - COLT Telecom AG

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

Agenda • Denial of Service and Worms • Attacks • Architectures • Distributed attacks and agents • Local and remote network based attacks • Detection and protection • Locally • Internet • Conclusion

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

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

Attacks : architecture (1) • 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 Victim Bad guy Compromised host Third parties

Attacks : architecture (2) • 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. Victim Bad guy Amplifiers Owned host

Attacks : architecture (3) • Distributed attack • Usually only one target : large packets (bandwidth), small packets (host resources) Victim (s) Master agent Bad guy Slave agents (zombies, bots) Owned host Third parties

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

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.

Attacks : the data link layer • 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 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

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)

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 ?

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 ?

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

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

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

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.

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

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

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

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

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

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 ?

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 ;-)

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) • ...

That’s all folks :-) • Latest version will be posted to : • IP Backbone Security presentation : • Q&A < http://www.securite.org/presentations/ddos/ > < http://www.securite.org/presentations/secip/ > Image: http://www.inforamp.net/~dredge/funkycomputercrowd.html

> Nicolas FISCHBACH IP Engineering Manager - COLT Telecom AG