Active methods for network defense Vinod Yegneswaran SRI International (joint work with Prof. Paul...
-
Upload
corey-obrien -
Category
Documents
-
view
213 -
download
0
Transcript of Active methods for network defense Vinod Yegneswaran SRI International (joint work with Prof. Paul...
Active methods for network defense
Vinod YegneswaranSRI International
(joint work with Prof. Paul Barford, University of Wisconsin)
Overall scope
Two Objectives Measurement based classification of fundamental attack patterns Timely Identification of emerging threats
Active components: state of the art Honeynets and Honeyfarms (iSink, Honeyd, VMware, Potemkin) NIDS signature generation (Nemean, Autograph, Polygraph etc.) Challenges: Accuracy, Scalability and Vulnerability
Research Thrusts How do we integrate active components into real-time network defenses? How do we build scalable detection systems? How do we develop situational awareness to enhance alert accuracy? How do we build resilient honeynet deployments?
Active mapping techniques, Data pollution attempts
Architectural components
Observe
Protect
Analyze
Internet Sink (iSink): Observes unused address spaceYegneswaran et al. (RAID 2004)
NetSA: Analyzes data collected by Internet SinksYegneswaran et al. (Hotnets 2005)
Nemean: Signatures to protect live networksYegneswaran et al. (Security 2005)
Kaleidoscope: Secures honeynet deployments
Nemean components
Automated semantics-aware NIDS signature generation
Original implementation was offline, userlevel Tested on HTTP and NetBIOS Low false alarms, high detection rate
Current focus: scalable, real-time Nemean instance Online implementation of an IPS Integration with live Active-Sink
Online Nemean implementation
Functional
Diagram
Active SinkResponder
(Kernel)
SharedMemoryModule
Star Clustering and PFSA Generalization
(Userlevel)
Dark IP traffic
Aggregated, reassembled and annotated connection records
Generalized automatons
Production traffic
No match? To network
Match? Forward to ALERT Database
Inspector(Kernel)
Honeynet response
Nemean components (1)
Active Sink responderReceives packets destined to dark IPResponds to packets
EnhancementsSupport for tracking connection state
TCP and app-level reassemblyPeriodic transfer of reassembled
connections to shared memoryExpires connection state using timers
Current suite of respondersA
ctiv
e S
ink
/ H
oney
dO
S R
espo
nder
Hon
ey I
nter
face
NetBIOS Responder(139)
SMB Responder(139/445)
DCE/RPC Responder(135/139/445)
Echo Responder(Beagle/Mydoom)
Dameware Responder(6129)
NetBIOS-NS Responder(137)
HTTP Responder(80/1080/3128/8080)
MS-SQL Responder(1433)
Nemean components (2)
Shared memory driver Handles flow of data between user level clustering
module and the kernel modules Fixed size memory allocation for data structures
Star clustering Incremental clustering algorithm Clusters related connections
PFSA generalizer Sk-strings + domain specific enhancements
Suffix abstraction (repetition), subsequence creation (wildcards)
Pushes generalized automatons to shared memory
Nemean components (3)
Traffic inspector Pulls new automatons from shared memory Monitors production (live) network Reassembles connections Compares FSAs with connection records Forwards matching connections to Alert DB
Minimal UI Apache web server with PHP/HTML front end Displays currently active automatons Displays matched connection count summaries Displays cluster information along with the generalized PFSA
Performance implications
Connection-maintenance overhead Potential vulnerability to resource attacks under high traffic volumes Current solution: periodic connection timeouts
Message-passing overhead Can be optimized by decreasing the communication frequency Current implementation filters (identical) duplicate connections
Automaton matching Current implementation performs sequential matching
Scalability needs to be better studied Research: Parallel signature matching, Hardware-based Inspectors Trade-off: state vs signature/detection quality
Active methods in Cyber-TA
How do we integrate iSink and Nemean into Cyber-TA?Bot-Hunter projectPrivacy-preserved sharing and mining of
iSink dataGenerating consensus signaturesGenerating privacy-preserving signatures
Integrated deployment
NAT Filter
Active Sink
Nemean
Bot-Hunter
OS Honeyfarms
VMware pool
SnortBro/NetSA
Binary Analysis Tools
HoneynetTraffic(e-to-i)
ProductionTraffic
(e-to-i and i-to-e)
Honeygames overview
Large number of monitoring/honeynet installations Dshield, CAIDA, Michigan, U Wisc, LBL, Georgia Tech, JHU, Honeynet alliance projects Passive monitors / low interaction / full interaction honeypots
Honeynet fingerprinting is a significant problem Worm/botnet seeding... Fingerprinting passive monitors: Bethencount et al., Shinoda et
al. [Usenix Security '05] Fast and evasive worms: Rajab et al., RAID '06
Vital for Cyber-TA
Goals and assumptions
Our goal: dissuade fine-grained honeynet mapping by Black Hats
Assumptions: Collaborative adversaries Stateful honeynet model – bases responses on
history of past interactions Honeynet addresses can be distinguished by
sending a finite number of probes to monitored addresses
System resources limited by finite memory (global lie budget)
Our approach (1)
Game-theoretic abstraction 2 player game between attacker and defender
Attacker objective: Identify contiguous segment of monitored
addresses with minimal number of probes Attacker knows the length of monitored segment
(m) Defender objectives:
Prevent the honeynet from being mapped by shuffling the location of monitored segment
Delay shuffling, i.e., extend duration of game as much as possible
Our approach (2)
System implementation Kaleidoscope: An address shuffling middle-box Implemented on top of Click network processor
Questions What is the right granularity for mapping address
blocks? What are appropriate shuffling policies? How do you trade-off frequency of shuffling with
resiliency to mapping? How well can Kaleidoscope scale? (resiliency to
traffic load and attacks)
Game formulation
White segment (n-m)
Black segment (m) Circular address space of size
(n) Simplifies analysis of address
boundary cases Single contiguous segment of
monitored addresses, i.e., “black” nodes Attacker knows the length of the
segment (m) All other addresses are “white”
Game formulation (2)
Attacker queries and receives answer based on the color of node White nodes must answer white Black nodes might answer black or “lie” and answer white Lies may be used flexibly until the global limit is reached
Zero-sum game Let v denote the expected number of queries until Attacker
finds the honeynet. Common objective function: payoff for A is -v and payoff for D
is v The objective of Defender is to maximize v
Defender strategy (Delay Delay)
Naïve Defender strategy Delay-Delay (DD) - Lie as long as quota of lie
allows
First Time (T) Time when attacker learns his first black node Against any Attacker strategy, DD maximizes T
Capitulation Time (L) Time when Defender exhausts his lie budget
Against DD, T = L
Attacker strategy (1)
Black segment (m)
White segment
Assume attacker has found one black node. Then he can zoom in using a binary search
Log(m) steps to identify the boundaries of the honeynet
Attacker strategy (2)
Round-Robin strategy Finding the first black
node: Pick any cell j to start. Query j, consecutively “l”
times If reply is b=1 (i.e.,
black) break; Set j = j + m, repeat
v(RR,DD) >= (k+1) l/2 + log m on average
Black segment (m)
White segment
m
m
Optimal strategy (Defender)
Delay-Delay is essentially optimal against any attackerAgainst RR, DD performs as well as any DPerforms well against any A
v(A, DD) > k l /4 +Ω log(m) l=lie quota; m = length of monitor; k = n / m
(proof by Jin-Yi Cai)
Optimal strategy (Attacker)
RR is uniquely-optimal against any D v(RR, D) < k l /2 + 1 + 1.5 log2m + 2*(l-1) l=lie quota; m = length of monitor; k = n / m
Multiple monitoring segments Optimal strategy is a one-sided binary search (OSBS) Simultaneous upper and lower bound: v(OSBS, D) = θ(k l + b
log m)
(proof by Jin-Yi Cai)
Shuffling strategies
Four different shuffling policies Restricted Swap Shuffling
Map each black segment to another equally sized segment
Discrete Random Map Shuffling Divide address into equally sized, non-overlapping
segments Per Source Shuffling
Maintain address map per source Source Group Shuffling
Maintain address map per “source-group” or service Connection pools and address maps
Shuffer performance (delays)
Shuffling policy performanceBackground traffic 200, 400 mbps/s Induced delays < 300 us; zero packet loss
Resiliency to attacks
Attacks: Scanning attacks; SYN-floods [300-2400 connection requests per sec] Background traffic load 200mb/s Delays < 400 us
Scanning attacks SYN floods
Deployment issues
NAT devicesSimilar in principle, but local network
changes constantlyWe assume most local machines are
clients. i.e., need not be statically routedCo-exist with DHCP?Integration with routers
Periodic link-state updatesNew OSPF message type
Thanks!
Chris Alfeld (University of Wisconsin)Prof. Paul Barford (University of Wisconsin)Prof. Jin-Yi Cai (University of Wisconsin)Prof. Jonathon Giffin (Georgia Tech)Ramanathan Palaniappan (Amazon Inc.)Dave Plonka (University of Wisconsin)
Relevant publications
Situational Awareness On the Design and Use of Internet Sinks for Network Abuse Monitoring (RAID 2004)
Using Honeynets for Internet Situational Awareness (ACM Hotnets 2005)
An Architecture for Generating Semantics-aware Signatures (Usenix Security 2005)
Characteristics of Internet Background Radiation (ACM IMC 2004)
Distributed Network Intrusion Detection
Global Intrusion Detection in DOMINO Overlay System (NDSS 2004)
Internet Intrusions: Global Characteristics and Prevalence (ACM Sigmetrics 2003)
Fusion and Filtering in Distributed Intrusion Detection Systems (Allerton 2004)