1 / 22

Detecting Intra-enterprise Scanning Worms based on Address Resolution

Detecting Intra-enterprise Scanning Worms based on Address Resolution David Whyte , Paul van Oorschot, Evangelos Kranakis. Outline. Internet Environment Scanning Worm Propagation Characteristics Address Resolution (ARP) Approach Results Limitations Conclusions.

oren-livingston
Télécharger la présentation

Detecting Intra-enterprise Scanning Worms based on Address Resolution

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. Detecting Intra-enterprise Scanning Worms based on Address Resolution • David Whyte, Paul van Oorschot, Evangelos Kranakis

  2. Outline • Internet Environment • Scanning Worm Propagation Characteristics • Address Resolution (ARP) Approach • Results • Limitations • Conclusions

  3. Dsheild Report –- December 6, 2005 Top Attacker: 216.81.35.172 Most Attacked Port: 445

  4. Worm Outbreaks • Sapphire/Slammer worm – Jan 25, 2003 • Fastest spreading worm yet • 90% compromised in first 10 minutes • August 2003 the “Month of Worms” • SoBig.F: #1 “mass mailing” virus of all time • Blaster/LovSan/Welchia/Nachi • Witty worm – March 2004 • Buffer overflow in a suite of security products • Use of a hit-list?

  5. Countermeasure Challenges • Propagation speed renders human-based defensive strategies non-effective • Security patches – frequent, large and sometimes broken • Slammer fix SQL Server 2000 SP2: three parts 26MB to 506MB • sql2kdeskfullsp2.exe 390 MB

  6. Countermeasure Challenges • Active response (i.e. containment and suppression) • risky (self imposed DoS) • The IDS that cried “Worm!!”… • (Snort) alert UDP any any -> any 1434 (msg:"SQL Slammer Worm"; rev:1; content:"|726e51686f 756e746869636b43684765|";) • (Dragon) NAME=SMB:DCOM-OVERFLOW SIGNATURE=T D A B 2 0 135 SMB:DCOM-OVERFLOW /5c/00/43/00/24/00/5c/00*/00*/00*/00*/00*/00*/00*/00*/00*/00*/00*/00*/00*/00*/00 , /01/10/08/00/cc/c c/cc/cc

  7. Solution/Problem • Automated countermeasures are required for worm containment and suppression • Worm propagation detection methods need to: • Detect propagation quickly • Detect propagation accurately • Detect propagation of varying rates • Detect zero-day worms

  8. Scanning Worm Characteristics • Scanning worms can employ a variety of strategies to infect systems • Topological scanning • Slow scanning • Fast scanning • Topological scanning • Use of local information to find victims • Potential to be very fast

  9. Enterprise Network

  10. ARP-based Scanning Worm Detection Approach • Focus on protecting the internal network • Network 'hard crunchy' exterior 'soft gooey' middle • Limit damage within network cell • Behavioral '“”signature' • Based on anomalous behavior • ARP request is a 'scan' • Premise: measurable changes in amount/pattern ARP activity • 3-factor anomaly score

  11. 3-Factor Anomaly Score • Peer-list: previous connection activity • ARP activity: 'expected' amount of ARP activity vs. observed ARP activity (mean + sd) • Internal network dark space: ARP requests to non-existent systems • Factor weighting is configurable • When aggregate score from three factors exceeds threshold in specified time window: ALERT!!

  12. Set-up and Training Period • Divide network into cells (broadcast domains) • Training period • Gather ARP broadcast requests • Construct peer-list • Calculate expected ARP activity for each system • Identify internal network address darkspace

  13. Software Developed • Prototype uses Perl modules and libpcap • High-level design • Packet Processing Engine (PPE) • Extract features from ARP broadcast traffic • ARP Correlation Engine (ACE) • Create individual system ARP statistics • Create peer-list • Observe ARP request activity to generate 3-factor anomaly score • Generate alerts

  14. Testing Environment • Two-week training period • Two-week test run • Lab/production network • One quarter Class C network • DNS/mail/web • Small user population • Linux OS • Closed network

  15. ARP Statistics (Training Period)

  16. Alert Thresholds • Common threshold • Function-specific threshold • Server/workstation • Threshold as well as anomaly factor weighting is configurable • Prototype can give default threshold based on training period • (r=3): 3 scans within a 3 minute window

  17. Testing Results (Alerts) 2-week Period

  18. False Positive Analysis • Increasing scan threshold reduces false positives (our network r = 3 only 5 false positives in a two week period) • Function-specific vs. common threshold approach reduced false positive rate • All false positives were caused by a“ 'burst' in server activity

  19. Worm Simulation Results • Not practical to infect network • Nmap scanning • Sequential scanning • Random scanning • Detected all scan activity scenarios within 3 scans • Internal network darkspace a factor

  20. Limitations • Test network size • Simulation vs. actual infection • Exclusive observation of broadcast traffic may lead to underestimation of dark space • DHCP • P2 P, highly distributed network: 'your mileage may vary'

  21. Conclusions • An approach to protect the internal network (topological worms) • Analysis provides evidence that the approach has merit • Full prototype developed • Anomaly-based • ability to detect emerging worms

  22. Questions? • dlwhyte@scs.carleton.ca

More Related