Implementation of an Automated Virus Response System October 26, - - PowerPoint PPT Presentation

Communication Network Services

Implementation of an Automated Virus Response System

October 26, 2004 Todd Acheson, David Alexander, Terry Kelleher, Brandon Saunders {acheson|alexandd|kelleher|saundeb1}@ohio.edu www.cns.ohio.edu

Communication Network Services 2

Introduction

• Onslaught in late summer of 2003 of

worms like Blaster and Nachi exploited the RPC DCOM vulnerability in MS Windows

• Could Ohio University (OU) handle the
• nslaught?

Communication Network Services 3

OU Environment

• Open, heterogeneous network
• No firewall
• 13,000 nodes
• 650 switches
• Wireless network
• Separate IP address space for ResNet

and Admin networks

Communication Network Services 4

Network Diagram

Communication Network Services 5

OU Environment (cont.)

• Mixture of OU-owned and user-owned

desktop machines (4,500 OU-owned machines in the dorms)

• Potential explosive rate of infection at the

start of fall quarter when thousands of machines arrive and connect to the network

• Less than a month to develop and deploy

a solution

Communication Network Services 6

Related Work

• Quarantine (Zou et al.)

– Block infected hosts from the network for short periods of time – Can mask the problem

Communication Network Services 7

Related Work (cont.)

• Throttling (Williamson)

– Limit rate of anomalous traffic coming out of a host – Requires changes to host network stack – Can mask the problem

Communication Network Services 8

Related Work (cont.)

• Gatekeeper (UConn and U of Florida)

– Restrict a host’s network access until it has been cleaned – Can’t track ongoing state of host – Requires network infrastructure changes

Communication Network Services 9

Related Work (contd.)

• Hybrid Gatekeeper/Intrusion-Prevention

– Cisco Security Agent – Agent gatekeeper installed on host – Agent can be compromised – Requires installation and management of host software – Vendor dependent

Communication Network Services 10

Automated Virus Response System

• Developed tool based on quarantine method

– Leveraged existing work at CNS (Network Metadata Infrastructure) – Didn’t require network or host changes – Rapid deployment – Self-correcting – Does not mask the problem – Forces user education and problem correction

• Detect infected machines and automatically

block them from the network

Communication Network Services 11

Implementation

Communication Network Services 12

Network Metadata Infrastructure (NMI)

• Abstract framework for collecting and

storing network metadata

• Used to locate a device on the network in

near real-time

• Maps IP address to switch port and

location

Communication Network Services 13

Detection Methods

• Signature-based

– Examine Argus data for signatures of Virus/Worms (Blaster, Nachi, SQL Slammer, etc.)

• Behavior-based

– Look for anomalous behavior (eg. Spam-bot)

• Heuristics limit false positives

– Number of neighbors – White-list – Grey-list/Intervention – Static IP addresses vs. DHCP addresses

Communication Network Services 14

Automated Detection Schemes

• Nachi
• Blaster
• Netsky
• Glider
• MyDoom
• Spam-bot
• Naldem
• Sdbot
• Sasser
• SQL Slammer
• Blubster

Communication Network Services 15

Port Block System

• Once detected, NMI is used to find the switch

port where a host connects to the network

• The system uses SNMP to automatically disable

the switch port or wireless connection

• Results are stored in a database
• Administrative interface to the database is used

by support staff to enable ports upon user assertion

Communication Network Services 16

Administrative Input

Communication Network Services 17

Results

• Port block statistics

– 5,145 total port blocks as from 9/03 to 10/04 – Average time to disable port = 51 sec. – Average time to enable port = 32 sec. – Peak blocks/month = 1,062 (9/03) – Peak blocks/day = 381 (3/8/04) – Peak blocks/hour = 57 (2/25/04)

Communication Network Services 18

Results (cont.)

• Extensibility

– Blubster (September 2004) – Rogue DHCP server detection (Future)

• Unblock by assertion

– Self-correcting – Quick

• User education
• Good neighbor

– Infected hosts removed from global Internet rather than masking the problem on the local network

Communication Network Services 19

Results (cont.)

Blaster/Nachi Port Blocks by Day (September 2003)

20 40 60 80 100 120 140 160 180 200 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Day Port Blocks ResNet Admin

Communication Network Services 20

Results (cont.)

Port Blocks By Reason

500 1000 1500 2000 2500 spam-bot nachi blubster sasser sdbot netsky glider bagle sql-slammer mydoom

• ther/manual

Number of Port Blocks

Communication Network Services 21

Issues

• Notifying users
• Transient users
• Malicious denial of service attacks
• False positives
• Intervention records
• Timing
• New detection schemes created manually

Communication Network Services 22

Conclusions

• Tool was initially developed to prevent a

disaster and not prove a concept

• The tool met the goal of weathering the

Nachi/Blaster outbreak in September 2003 without network disruption

• The tool has continued to evolve to handle

new classes of problems

• Work to empirically analyze effectiveness
• f port block system is ongoing