1 / 23

Using Honeynets for Internet Situational Awareness

Using Honeynets for Internet Situational Awareness. Vinod Yegneswaran, Paul Barford Vern Paxson University of Wisconsin, Madison ICSI, LBNL Hotnets 2005. Motivation. Currrent tasks for security analysts Abuse monitoring Audit and forensic analysis NIDS/Firewall/ACL configuration

lorene
Download Presentation

Using Honeynets for Internet Situational Awareness

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Using Honeynets for Internet Situational Awareness Vinod Yegneswaran, Paul Barford Vern Paxson University of Wisconsin, Madison ICSI, LBNL Hotnets 2005

  2. Motivation • Currrent tasks for security analysts • Abuse monitoring • Audit and forensic analysis • NIDS/Firewall/ACL configuration • Vulnerability testing • Policy maintenance • Liaison activities • Network management • End host management

  3. NIDS: State of the art • Pinpoint descriptions of low-level activities • Source A launched CVE-XXX against Dest B • Large volume of alerts • Too many false alarms • Vulnerable to flooding attacks / IP spoofing • Continual manual update of signatures • Lack of “longitudinal” baseline • Lack of breadth for root-cause inference

  4. Our vision • Network “Situational Awareness” (NetSA) • “Degree of consistency between one’s perception of their situation and reality” -- US Navy • “an accurate set of information about one’s environment scaled to specific level of interest” -- NCOIC • Elevate quality and timeliness of alerts

  5. Our approach • Developing NetSA “building blocks” toward • Automated incident discovery • Robust classification • Real-time event notification • Forensic analysis capabilities • Honeynet situational awareness • Rich source of information of large-scale malicious activity • Accurate attribution of events such as botnets, worms and misconfiguration

  6. System structure • Tunnel filter: one source -> one dest • Volume vs diversity • Active responders • NetBIOS/SMB, DCE/RPC, MS-SQL, HTTP, Dameware, MyDoom • Bro Radiation-analy • Condensed protocol-aware summaries • Six-hour batches stored in MySQL backend • Adaptation • Auto-update of “previously-unseen” activities • Situational-analy • Organized reports highlighting most “unusual” and significant events

  7. Radiation-analy summarization • Leverage Bro’s protocol knowledge and attack semantics • Distill activity into high-level abstractions • Quickly validate against past history to check for previous instances • Types of summaries • Connection profiles • Source Profiles • Infer connection-profile associations • Session Profiles • Hard to summarize due to high degree of variability

  8. Radiation-analy vs MD5 signatures

  9. NetSA report example • Four components • New and interesting events • High beta events • Very high beta events • Top 10 profiles • For profile (p), interval (i): • Beta (p, i) = Num_sources(p, i) / Avg (num_sources(p)) across all intervals

  10. NetSA report example • New and interesting events No. Sources; Port tag 1 445-tcp CREATE_FILE: ``samr''; CREATE_FILE: ``webhost.exe''; CREATE_FILE: ``atsvc'‘ • High beta events Beta dest_port No.sources(avg) tag 12.6 1025-tcp 494 (39.2) [exploit] (RPC request (2904 bytes)) 11.5 135-tcp 416 (36.3) [exploit] (RPC request (1448 bytes))

  11. NetSA report example • Very high beta events (beta > 10) TAG: 1025/tcp/[exploit] (RPC request (2904 bytes)) Hour 0..5 srcs: 97, 93, 79, 74, 68, 94, src-overlaps: 0, 8, 13, 10, 8, 10, /8s: 25, 26, 19, 21, 16, 19, dsts: 103, 97, 80, 71, 76, 96, dst-overlaps: 0, 14, 12, 8, 8, 8, • Top 10 profiles Port No. Sources Tag 135-tcp 591 RPC bind: afa8bd80-7d8a-11c9-bef4-08002b10298 len=72; RPC request (24 bytes) 1025-tcp 494 [exploit] (RPC request (2904 bytes)) 135-tcp 416 [exploit] (RPC request (1448 bytes)) …

  12. Analysis dataset • Collected from 6 months of operation on 1,280 address LBL honeynet • Operational for over a year now… • Highlights from situational-analy summaries • 4 instances of misconfiguration (3 P2P, 1 NAT box) • 11 suspected botnet sweeps • Number of sources per incident 30 – 26,000 • MS-SQL, DCE/RPC, Several NetBIOS/SMB exploits • Slammer re-emergence (350 sources) • Historical worm data (5) • CR I, CR – reemergence, CR II, Nimda, Witty • 5,500 – 155,000 sources

  13. Situational awareness in-depth • Toolkit for large-scale forensic analysis of anomalous events • 9 offline statistical analyses (Worms/Botnets/Misconfig); • Source arrivals • Temporal source counts, arrival window, source interarrivals • Destination / source network coverage • Dest net footprint, first-dest pref, source-net dispersion • Per-source macro-analysis • Scanning profile, target scope, lifetime • Based on hypothesized behavior

  14. SA in-depth large scale events

  15. Temporal Source Counts Edonkey misconfig Codered I Wkssvc botnet

  16. First Destination-IP preference • Considers ordering and preference Nimda Wkssvc botnet

  17. Per-source scanning profile(100 random sources) Phase plot of dest IP Source ID vs dest IP MS-SQL botnet incident

  18. Inferring target scope • How broadly was a given event scoped? • Was our network specifically targeted? • Assumption: sources are not just sequentially scanning the honeynet • IDEA 1: Estimate global packet rate from change of IPID • Often cannot look at all packet pairs due to honeynet size (multiple wrap-arounds) • IDEA 2: Look at IPID spacing between retransmitted SYNs from passive traces • For UDP look at packets arriving less than 3 secs apart • Target scope = Honeynet size * (global rate / local rate)

  19. Inferring target scope: Example Wkssvc (1280 addresses) multiplier ~ 10^4 13 M addresses Witty UW (8K addresses) multiplier ~ 5* 10^5  4 B addresses

  20. Summary • Objective: Internet situational awareness • Accurate timely summaries of honeynet data • Bro NetSA (radiation-analy / situation-analy) • MySQL backend • Situational in-depth statistical analyses • Provide different yet valuable perspectives on individual events • Toward real time classification of events • Future work • Refinement and extension of in-depth SA analyses • Distributed NetSA

  21. Other arrival characteristics • Arrival window • Expectation: botnets should see sharp spike in arrivals • Often not true – botnets don’t have to push commands, instead zombies could poll and pull • phatbot zombies wake up every 1000 seconds to check for new commands • Source interarrivals • Bots poll independently, implies their arrivals will appear to be poisson with exponential interarrivals • Worm interarrival rate should increase during the initial stages of the outbreak

  22. Other arrival characteristics

  23. Honeynet footprint Nimda Wkssvc botnet

More Related