detecting intra-enterprise scanning worms based on address resolution

Carleton University School of Computer Science

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


Dsheild Report –- December 6, 2005

Top Attacker: 216.81.35.172 Most Attacked Port: 445


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?


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


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


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


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


Enterprise Network


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


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


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


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


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


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


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


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


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


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


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'


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


Questions?

[email protected]

detecting intra-enterprise scanning worms based on address resolution

Documents