1 / 27

> 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

Download Presentation

> Nicolas FISCHBACH IP Engineering Manager - COLT Telecom AG

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

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

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

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

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

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

More Related