Active Monitoring Systems - Cyber
Download
Report
Transcript Active Monitoring Systems - Cyber
Active methods for network
defense
Vinod Yegneswaran
SRI International
(joint work with Prof. Paul Barford,
University of Wisconsin)
Overall scope
Two Objectives
Active components: state of the art
Measurement based classification of fundamental attack patterns
Timely Identification of emerging threats
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
Internet Sink (iSink): Observes unused address space
Yegneswaran et al. (RAID 2004)
Analyze
NetSA: Analyzes data collected by Internet Sinks
Yegneswaran et al. (Hotnets 2005)
Protect
Nemean: Signatures to protect live networks
Yegneswaran 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
Star Clustering and
PFSA Generalization
(Userlevel)
Functional
Diagram
Generalized
automatons
Aggregated,
reassembled and
annotated
connection records
Dark IP traffic
Shared
Memory
Module
Active Sink
Responder
(Kernel)
Match?
Forward
to ALERT
Database
Inspector
(Kernel)
Production traffic
Honeynet response
No match? To
network
Nemean components (1)
Active Sink responder
Receives packets destined to dark IP
Responds to packets
Enhancements
Support for tracking connection state
TCP and app-level reassembly
Periodic transfer of reassembled
connections to shared memory
Expires connection state using timers
Current suite of responders
Honey Interface
Active Sink / Honeyd
OS Responder
NetBIOS Responder
(139)
NetBIOS-NS Responder
(137)
MS-SQL Responder
(1433)
Dameware Responder
(6129)
HTTP Responder
(80/1080/3128/8080)
Echo Responder
(Beagle/Mydoom)
SMB Responder
(139/445)
DCE/RPC Responder
(135/139/445)
Nemean components (2)
Shared memory driver
Star clustering
Handles flow of data between user level clustering
module and the kernel modules
Fixed size memory allocation for data structures
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
Message-passing overhead
Potential vulnerability to resource attacks under high traffic volumes
Current solution: periodic connection timeouts
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 project
Privacy-preserved sharing and mining of
iSink data
Generating consensus signatures
Generating privacy-preserving signatures
Integrated deployment
Production
Traffic
(e-to-i and i-to-e)
Bot-Hunter
Bro/NetSA
Nemean
Active Sink
Honeynet
Traffic
(e-to-i)
Binary Analysis
Tools
Snort
OS Honeyfarms
NAT Filter
VMware pool
Honeygames: Strategies for
honeynet defense
Honeygames overview
Large number of monitoring/honeynet installations
Honeynet fingerprinting is a significant problem
Dshield, CAIDA, Michigan, U Wisc, LBL,
Georgia Tech, JHU, Honeynet alliance projects
Passive monitors / low interaction / full interaction honeypots
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
Attacker objective:
2 player game between attacker and defender
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
Black segment (m)
Circular address space of size
(n)
Single contiguous segment of
monitored addresses, i.e.,
“black” nodes
White segment (n-m)
Simplifies analysis of address
boundary cases
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
First Time (T)
Time when attacker learns his first black node
Against any Attacker strategy, DD maximizes T
Capitulation Time (L)
Delay-Delay (DD) - Lie as long as quota of lie
allows
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
Black segment (m)
Finding the first black
node:
m
m
White segment
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
Optimal strategy (Defender)
Delay-Delay is essentially optimal
against any attacker
Against RR, DD performs as well as any D
Performs 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)
Analytic performance
Shuffling frequency as we vary l and m
(constant l)
(l α m)
Analytic performance
Impact of segmentation
(as we vary l)
(as we vary m)
Shuffling strategies
Four different shuffling policies
Restricted Swap Shuffling
Discrete Random Map Shuffling
Maintain address map per source
Source Group Shuffling
Divide address into equally sized, non-overlapping
segments
Per Source Shuffling
Map each black segment to another equally sized
segment
Maintain address map per “source-group” or service
Connection pools and address maps
Shuffer performance (delays)
Shuffling policy performance
Background 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 devices
Similar in principle, but local network
changes constantly
We assume most local machines are
clients. i.e., need not be statically routed
Co-exist with DHCP?
Integration with routers
Periodic link-state updates
New 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)
Nemean architecture
Active-Sink
packet
traces
Data
Collector
Flow
Aggregator
Protocol
semantics
Connection
Clustering
Service
Normalizer
Tuning
parameters
Signature
Generalizer
Session
Clustering
IDS/IPS
signatures