Active methods for network defense

1. Active methods for network defense Vinod Yegneswaran SRI International (joint work with Prof. Paul Barford, University of Wisconsin)

2. 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

3. Observe Protect Analyze Architectural components Internet Sink (iSink): Observes unused address space Yegneswaran et al. (RAID 2004) NetSA: Analyzes data collected by Internet Sinks Yegneswaran et al. (Hotnets 2005) Nemean: Signatures to protect live networks Yegneswaran et al. (Security 2005) Kaleidoscope: Secures honeynet deployments

4. 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

5. Online Nemean implementation Star Clustering and PFSA Generalization (Userlevel) Functional Diagram Generalized automatons Shared Memory Module Aggregated, reassembled and annotated connection records Match? Forward to ALERT Database Active Sink Responder (Kernel) Inspector (Kernel) Dark IP traffic Production traffic Honeynet response No match? To network

6. 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

7. Current suite of responders NetBIOS Responder (139) SMB Responder (139/445) Active Sink / Honeyd OS Responder Honey Interface DCE/RPC Responder (135/139/445) NetBIOS-NS Responder (137) MS-SQL Responder (1433) Dameware Responder (6129) HTTP Responder (80/1080/3128/8080) Echo Responder (Beagle/Mydoom)

8. 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

9. 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

10. 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

11. 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

12. VMware pool Integrated deployment Binary Analysis Tools Production Traffic (e-to-i and i-to-e) Bot-Hunter Bro/NetSA Nemean Snort OS Honeyfarms Active Sink Honeynet Traffic (e-to-i) NAT Filter

13. Honeygames: Strategies for honeynet defense

14. 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

15. 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)

16. 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

17. 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)

18. Black segment (m) White segment (n-m) Game formulation • 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”

19. 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

20. 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

21. Black segment (m) White segment Attacker strategy (1) • 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

22. Black segment (m) White segment 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 m m

23. 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)

24. 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)

25. Analytic performance • Shuffling frequency as we vary l and m (constant l) (lαm)

26. Analytic performance • Impact of segmentation (as we vary l) (as we vary m)

27. 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

28. Shuffer performance (delays) • Shuffling policy performance • Background traffic 200, 400 mbps/s • Induced delays < 300 us; zero packet loss

29. 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

30. 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

31. 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)

32. Relevant publications

33. Nemean architecture Active-Sink packet traces Protocolsemantics ConnectionClustering DataCollector FlowAggregator ServiceNormalizer Signature Generalizer SessionClustering Tuning parameters IDS/IPSsignatures