1 / 40

DEFCON 10 August 2002

Anatomy of Denial of Service Mitigation Testing. DEFCON 10 August 2002. Agenda. Why Test? Methodology Challenges and Lessons Learned Findings. Denial of Service Mitigation Testing. WHY?. Desire to Protect Infrastructure Data Business Continuity Evaluate Emerging Technologies

jett
Download Presentation

DEFCON 10 August 2002

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. Anatomy of Denial of Service Mitigation Testing DEFCON 10August 2002

  2. Agenda • Why Test? • Methodology • Challenges and Lessons Learned • Findings

  3. Denial of Service Mitigation Testing

  4. WHY? • Desire to Protect • Infrastructure • Data • Business Continuity • Evaluate Emerging Technologies • Problem is just getting worse • Many nasty DOS and DDOS tools in the wild

  5. 2001 Survey Results Results of the 2001 Information Security Magazine Industry Survey shows increase in Denial of Service attacks experienced by the survey participants. Source: Information Security Magazine, 2001 Industry Survey, October 2001, pg 34-47.

  6. 2001 Survey Results • System unavailability is 4th highest INFOSEC concern Source: Information Security Magazine, 2001 Industry Survey, October 2001, pg 34-47.

  7. 2001 Survey Results • Security and Availability of Websites 2nd most important project listed Source: Information Security Magazine, 2001 Industry Survey, October 2001, pg 34-47.

  8. What We Were Looking For • Infrastructure Protection • Minimum Gigabit Solutions (GigE and Fiber) • OC48 and OC192 capability desired • Customer Protection • Gigabit MM Fiber • GigE • 10/100 Ethernet • Eventually OC48 and OC192

  9. Products Tested Passive “tapped” Solutions • Arbor Networks • Reactive Networks • Mazu Networks • Asta Networks In-line Solutions • Captus Networks • Mazu Networks • Basis of selection due to September 2001 Information Security Magazine Article, Denying Denial-of-Service.

  10. Methodology

  11. Today’s DOS Prevention • Reverse Path Filtering (deny invalid IPs) • Allow only good traffic into your network (ingress filtering) • Allow only good traffic out of your network (egress filtering) • Stop directed broadcast traffic (to avoid being an amplifier)

  12. Methodology • Imitate a customer hosting center • Run real tests across the infrastructure • Test both network functionality and the management interfaces • Find solutions that will work upstream instead of downstream

  13. Test Environment Architecture

  14. Passive “Tapped” Testing • No network side IP address • Data mirroring • Not a single point of failure on the network • Products recommend ACLs for the routers • Automatic • Semi-Automatic • Report only

  15. Reactive Network SolutionsFloodGuard

  16. MAZU NetworksTrafficMaster

  17. Asta NetworksVantage

  18. Arbor NetworksPeakFlow

  19. In-Line Testing • Boxes placed in the data stream • Quicker response to attacks based on implemented rules • Interfaces visible on the network

  20. Mazu Networks (inline)

  21. Captus Networks

  22. Types of Tests • Baseline traffic generation to emulate a web hosting center • ldgen with replayed traffic • Attack Traffic (DOS and DDOS) • TCP SYN • TCP ACK • UDP, ICMP, TCP floods • Fragmented Packets • IGMP flood • Spoofed and un-spoofed

  23. Lesson Learned

  24. Network • Baseline Traffic must be stateful (TCP 3-way handshake must be complete)

  25. Routes • Bad Routes will kill your network and make you unemployed • Thank God we were in the lab • Be sure to isolate your management network from the attack network ON EVERY BOX

  26. Attack Network • Different tools on different systems • Linux 6.2 and Linux 7.2 • Open BSD • Solaris • Mix of 10/100 and Gig Interfaces needed to push the traffic levels

  27. Tools Utilized • DOS/DDOS Tools • Vendor provided • Arbor TrafGen • Open source • stream • litestorm • rc8.o • f__kscript • slice3

  28. Victim Network • Monitoring Tools • Lebrea • Snort • Manual Checks • Simple Pings • CPU usage monitoring

  29. Flow Sampling • Netflow/Cflowd from Cisco and Juniper • Sampling rates must match in both the router and the DDOS mitigation device • Juniper had more consistent flow characteristics and reported faster • Flow sampling has many value adds • Traffic characterization • Customer billing • And DOS/DDOS detection

  30. SNMP Communications • SNMP is used to monitor the status of the routers and providing alerts when an attack is underway. • Connectivity is necessary for proper operation. • SNMP community stream required for proper communications (NOT PUBLIC)

  31. FINDINGS

  32. What Vendors Did Well! • Monitor baseline traffic • Detect changes in traffic patterns away from baseline • Alerting and Alarming when thresholds or statistics were exceeded

  33. What wasn’t so Good • Protection of the management interfaces • Implementing warning banners and account lockouts • Port lockdown on the management interfaces

  34. Solutions

  35. Large Enterprise • Passive Solutions best • Mix of flow collectors and packet collectors that can visualize your entire network • Centralize the management consoles into a security operations center of NOC • Products: • Arbor • Asta • Reactive

  36. Smaller Enterprise • In-Line Solutions worth considering • Combination firewall/DOS solutions • Combination IDS/DOS solutions • Captus • Mazu • Recourse (not tested)

  37. Resources • www.sans.org/ddos_roadmap.htm • www.sans.org/dosstep/index.htm • www.nipc.gov • staff.washington.edu/dittrich/misc/ddos • www.cert.org

  38. Conclusions • Technology still evolving • Integrated products likely the future (DOS combined with IDS or Firewall) • Positive strides toward solutions

  39. Questions ?

  40. Greg Miles, Ph.D., CISSP • CIO – Security Horizon Inc. • Information Technology – 15 Years • Information Security – 11 Years • e-mail: gmiles@securityhorizon.com • Web: www.securityhorizon.com

More Related