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: Strategies for honeynet defense

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)

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

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)

Nemean architecture

SignatureGeneralizer

FlowAggregator

ServiceNormalizer

DataCollector

ConnectionClustering

SessionClustering

Protocolsemantics

Active-Sink packettraces

IDS/IPSsignatures

Tuningparameters