detecting intra-enterprise scanning worms based on address resolution
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
Carleton University School of Computer Science
Detecting Intra-enterprise Scanning Worms based on Address Resolution
David Whyte, Paul van Oorschot, Evangelos Kranakis
Carleton University School of Computer Science
Outline
â—Ź Internet Environmentâ—Ź Scanning Worm Propagation Characteristicsâ—Ź Address Resolution (ARP) Approachâ—Ź Resultsâ—Ź Limitationsâ—Ź Conclusions
Carleton University School of Computer Science
Dsheild Report –- December 6, 2005
Top Attacker: 216.81.35.172 Most Attacked Port: 445
Carleton University School of Computer Science
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?
Carleton University School of Computer Science
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
Carleton University School of Computer Science
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
Carleton University School of Computer Science
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
Carleton University School of Computer Science
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
Carleton University School of Computer Science
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
Carleton University School of Computer Science
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!!
Carleton University School of Computer Science
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
Carleton University School of Computer Science
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
Carleton University School of Computer Science
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
Carleton University School of Computer Science
ARP Statistics (Training Period)
Servers
AddressARP Chain
SizeMean
StandardDev.
Max
Requests
192.168.1.11 21 1.579 1.036 8
192.168.1.12 17 1.203 0.610 9
192.168.1.13 16 1.176 0.428 4
W orkstations
AddressARP Chain
Size MeanStandard
Dev.
Max
Requests192.168.1.16 10 1.243 0.467 4
192.168.1.24 8 1.171 0.423 4
192.168.1.33 6 1.235 0.449 3
Carleton University School of Computer Science
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
Carleton University School of Computer Science
Testing Results (Alerts) 2-week Period
AlertsThreshold (r) Server Workstation Total
1 scan 37 62 99
3 scans 5 0 5
5 scans 2 0 2
6 scans 1 0 1
Anomalous Connection ActivityServer Workstation Total
Outside ARP Chain 181 36 217
Dark Space 0 0 0
Carleton University School of Computer Science
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
Carleton University School of Computer Science
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
Carleton University School of Computer Science
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'
Carleton University School of Computer Science
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