Investigating the Impact of Real-World Factorson Internet Worm Propagation

Daniel Ray, Charles Ward, Bogdan Munteanu, Jonathan Blackwell, Xiaoyan Hong, Computer Science

University of Alabama

Jun Li,Department of Computer and Information Science

University of Oregon

2

Worms: Why Do We Care?

Internet worms have been costly and destructive• Traffic causes network degradation• Infected hosts are often unusable• Repair is labor-intensive• Code Red v.2 and Slammer are estimated to cost $2bn

and $1bn, respectively

Fast self-propagating worms• Slammer reached its peak infection rate in ~3 minutes

• Infected ≥90% vulnerable hosts in ≤10 min

• Theoretical maximal speed: ~15 seconds• 15 seconds to infect most vulnerable hosts

3

Analyzing Worms

Analytical methods• Based on mathematical epidemiological models• Easy to compute, with limitations

• Model may or may not represent that of the real-world• Some margin of error is to be expected

• Also very rigid/Inflexible Empirical model

• build components that act like real world components.• Coarse Granularity

– abstract out individual packets or even individual nodes

• Fine Granularity– Have components that simulate all elements of the network down to and

including individual packets

• Is where our research fits in

4

What Do We Study?

The impact of real-world factors on Internet worm propagation

Factors we focus on:• IP address allocation strategy• Worm scanning methods• Wireless media

Use packet-Level network simulator: GTNetS

5

Wireless Internet

Wireless networks • WLAN• Mobile ad hoc network• Multihop mesh wireless network• Vehicular networks

Possible influences• WLAN address allocation• Bandwidth • Use behavior – connectivity • Device vulnerability – e.g. Bluetooth

6

Previous Work (a few examples)

Chen, Gao, Kwiat, “Modeling The Spread of Active Worms”• give analytical model entitled Analytical Active Worm Propagation (AAWP)• do not deal specifically with connection type or network topology. • using a variant of the Code Red & NIMDA Worm, which are TCP worms

Wei, Mirkovic, Swany, “Distributed Worm Simulation with a Realistic Internet Model”• examine worms using a similar but less flexible packet level simulator• UDP worms (TCP be approximated), random and subnet scanning• network topology at AS level • adjusting ratio of live hosts in address space for each AS

Weaver, Staniford, Paxson, “Very Fast Containment of Scanning Worms”• employ a simulator to test worm retardation algorithm by starting with an

algorithm for containment of scanning worms • focus on scanning in general, rather than specific scanning types or

connection types • use a probability method to determine if an attack is likely to succeed based

on the expected amount of non-attack traffic • LAN or company workstation networks instead of internet like topology. • address space adjustable through the likelihood of successful infection.

7

Previous Work (cont’d)

GTNetS folks: Riley, Sharif, and Lee • “Large-Scale Network Simulations with GTNetS”, “Simulating Internet

Worms”• GTNetS design to model networks• GTNetS capabilities of modeling worms

• Investigated:• randomly scanning TCP worms

– TCP payload size, # of Parallel TCP Connections • randomly scanning UDP worms

– Length bandwidth, Scan rate, payload size

More work• Self-learning worm using importance scan • Self-stopping worms

• Defending hit-list worm using address space randomization

8

Previous Work: Wireless (cont’d)

Khayam, Radha, VANET 04• warm spread over ad hoc vehicular network• SIR (susceptible, Infected and removed) epidemic model • Network: a new geometric random graph• Impact: vehicle traffic density – average node degree used

Hoh, Gruteser, WSPWN06• Infection may be limited due to device diversity. • Propagate rate and infection rate. • Experiment:

• Southern New Jersey highway network• SIR model, traffic simulator PARAMICS

– 10min reach 11.6 km, 75m/s if 5% of vehicles are susceptible– Slower but still fast enough to make containment difficulty

Worms in wireless sensors (analytical models)

Not sufficient work on detailed empirical analysis

9

Why GTNetS

The simulator we chose to use to facilitate our research• Fully Functional, Fully Adaptable, Packet-Level Network Simulator

Has a worm packet class which is fully extensible Allows the simulation to handle worm characteristics

• Support TCP or UDP connections• Varying infection lengths, infection ports, scan rate (UDP) and

number of connections (TCP)• Allows for varying IP block scanning methods

Network topology support (but weak for our purpose) • Simple network structure: Star, Dumbbell, Trees• Interfaces support BRITE network simulator

• to generate internet like topologies.

10

Factors Currently Studying

Topology (IP address allocation)• Dense vs Sparse

• IPv6: The ratio of active simulated nodes in the address space can be limited in such a fashion to mimic the distribution of nodes in the early stages of IPv6.

• Internet-like topology vs other topology (deeper tree or wider tree)• Wireless LAN address allocation

11

Worm Scanning Methods

IP address block scanning:• Random Scan• Local Preference Scan• Hit-List Scan

Connection types, worms at the packet level• UDP: they are faster, more effective• TCP: TCP connections can increase the effectiveness of worm

scan over the cost of TCP overhead. Note: hit-list was the most likely to be effected positively.

12

Preliminary GTNetS Simulation

Network topology:• Internet like,

• Addresses are chosen randomly and assigned to topology randomly• IP address space population density

– Sparse (IPv4 like): 1/35 Addresses in the space are occupied– Dense (IPv6 like): 1/135 Addresses in the space are occupied

• Synthetic topology• Wide tree: backbone + local WLANs• Deep tree: more administration penetration

Worm IP block Scanning method• UDP worms

• uniform random and local preference based on examples• hit-list worm with local preference scanning

• TCP worm: hit-list worm• Port scanning are not used

13

Preliminary GTNetS Simulation (cont’d)

Network constants• Size of network• No other network traffic

• Can effect worm spread but,

• Largely a function of the topology

• Difficult to simulate real-world situation

• Individual node vulnerability

Worm constants• Scan rate/number of TCP connections• Infection Length

Each simulation was run until all vulnerable nodes were infected or until computer memory was consumed.

14

Worm Types: Uniform Random vs. Local Pref

Uniform random

Local preference

dense

dense

sparse

sparse

universally quicker on dense networks

15

Worm Types: TCP Hit-List vs. UDP Hit-List

TCP hit-list

UDP hit-list

dense

dense

sparse

sparse

TCP causes a lot of overhead but no gain in speed

Local Preference and Hit-List• Worse than uniform random

on dense graphs• Better than uniform random on

sparse graphs

16

Dense and Sparse Graphs

Dense net

Sparse net

Worms spread trend similar• Local-pref slower than hit-list• Uniform random shifted

regardless of worm type, sparse networks retard spread

Blue – Uniform Random Red – Hit-list Green - Local Pref

17

Low Bandwidth Wireless Links

Wider-tree

deeper-tree

TCP worm Uniform vs. local preference.

100% allocated space

Uniform

Local preference

deeper-tree

Wider-tree

18

Low Bandwidth Wireless Links (cont’d)

Wider-tree

deeper-tree

UDP worm Uniform vs. local preference.

100% allocated space

Uniform random

Local preference

deeper-tree

Wider-tree

19

Summary…

Impact of real-world factors on Internet worm propagation Factors discussed:

• IP address allocation strategy: dense, sparse, wider tree, deeper• Worm scanning methods: uniform random, hit-list, local preference• Wireless media: low-bandwidth in two topology

Future work: More worm scanning types, e.g.,

• Permutation scanning, topological scanning• Hit-List with other scanning methods• Emerging ones

Influence from other network traffic More topology testing, including wireless network.

Questions?

Thanks!