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