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
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 onslaught? 2 Communication Network Services
OU Environment • Open, heterogeneous network • No firewall • 13,000 nodes • 650 switches • Wireless network • Separate IP address space for ResNet and Admin networks 3 Communication Network Services
Network Diagram 4 Communication Network Services
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 5 Communication Network Services
Related Work • Quarantine (Zou et al.) – Block infected hosts from the network for short periods of time – Can mask the problem 6 Communication Network Services
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 7 Communication Network Services
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 8 Communication Network Services
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 9 Communication Network Services
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 10 Communication Network Services
Implementation 11 Communication Network Services
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 12 Communication Network Services
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 13 Communication Network Services
Automated Detection Schemes • Nachi • Blaster • Netsky • Glider • MyDoom • Spam-bot • Naldem • Sdbot • Sasser • SQL Slammer • Blubster 14 Communication Network Services
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 15 Communication Network Services
Administrative Input 16 Communication Network Services
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) 17 Communication Network Services
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 18 Communication Network Services
Results (cont.) Blaster/Nachi Port Blocks by Day (September 2003) 200 180 160 140 120 Port Blocks ResNet 100 Admin 80 60 40 20 0 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 19 Communication Network Services
Results (cont.) Port Blocks By Reason 2500 2000 Number of Port Blocks 1500 1000 500 0 spam-bot nachi blubster sasser sdbot netsky glider bagle sql-slammer mydoom other/manual 20 Communication Network Services
Issues • Notifying users • Transient users • Malicious denial of service attacks • False positives • Intervention records • Timing • New detection schemes created manually 21 Communication Network Services
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 of port block system is ongoing 22 Communication Network Services
Recommend
More recommend
