1 / 15

Toward Self-directed Intrusion Detection

Toward Self-directed Intrusion Detection. June, 2005. Paul Barford Assistant Professor Computer Science University of Wisconsin. Motivation - the good. Network security analysts have many tasks Abuse monitoring Audit and forensic analysis Firewall/ACL configuration Vulnerability testing

costillo
Télécharger la présentation

Toward Self-directed Intrusion Detection

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. Toward Self-directed Intrusion Detection June, 2005 Paul Barford Assistant Professor Computer Science University of Wisconsin

  2. Motivation - the good • Network security analysts have many tasks • Abuse monitoring • Audit and forensic analysis • Firewall/ACL configuration • Vulnerability testing • Policy • Liaison • Network management • End host management wail.cs.wisc.edu

  3. Motivation - the bad • Adversaries are smart • Vulnerabilities and threats are significant • Worms • Slammer, Blaster, Sasser, Witty, MyDoom, etc. • Persistent and growing background radiation (Pang et al. ‘04) • Scans • Billions per day Internet-wide and growing (Yegneswaran et al. ‘03) • Viruses • No longer clearly defined (eg. Agobot) • DDos • Bot-nets consisting of hundreds of thousands of drones wail.cs.wisc.edu

  4. Motivation - the ugly (sort of) • Network intrusion detection systems (NIDS) • Static signatures - hard to tune and maintain • Lots of alarms • Scalability problems • Firewalls and intrusion prevention systems • Limited capability • Bulletin boards and commercial services • May not be timely enough • Traffic monitors (eg. FlowScan, AutoFocus) • A step in the right direction wail.cs.wisc.edu

  5. Objective • Network situational awareness based on self-directed network intrusion detection • “The degree of consistency between one’s perception of their situation and reality” • “An accurate set of information about one’s environment scaled to a specific level of interest” • Expand notions of traditional abuse monitoring and forensic analysis • Adapts to malicious traffic • Front-end for firewalls/IPS wail.cs.wisc.edu

  6. Mechanisms • Data sharing between networks • Eg. DOMINO (Yegneswaran et al., NDSS ‘04) • Monitoring unused address space • Eg. iSink (Yegneswaran et al., RAID ‘04) • Eg. BroSA (Yegneswaran et al. ‘05) • Automatic generation of resilient signatures • Eg. Nemean (Yegneswaran et al., USENIX Security ‘05) wail.cs.wisc.edu

  7. DOMINO architecture • Hierarchical overlay network • Descending order of security and trust • Data sharing • XML-based schema • Summary exchange protocol extends IDMEF • Push or pulling periodically • Data/alert fusion and filtering • Subject of on-going research (eg, Barford et al. Allerton, ‘04) wail.cs.wisc.edu

  8. Unused address monitoring • Packets are (nearly) all malicious • There have been some very weird misconfigurations • Enables active responses • Key for understanding details • Widely available • We monitor four class B’s and one class A • Useful in large and small • Easier to share this data wail.cs.wisc.edu

  9. iSink architecture • Passive component: Argus • libpcap-based monitoring tool • Active component: based on Click modular router • Library of stateless responders to collect details of intrusions • NAT filter: to manage (redundant) traffic • Source/destination filtering wail.cs.wisc.edu

  10. Activities on ports (port 135) • Distribution of exploits varies with network • 170 byte requests on Class A • Blaster, RPC-X1 all 3 networks • Welchia LBL • Empty connections • UW Networks wail.cs.wisc.edu

  11. Real-time honeynet reports • Bro plug-in for situational summary generation • Periodic reports • New events • High variance events • Low variance events • Top profiles • Adaptive • NetSA in depth • Identify large events quickly • On-going wail.cs.wisc.edu

  12. Semantics-aware signatures • Objective:automated generation of resilient NIDS signatures • Signatures must be both specific and general • Challenge: generate signatures for attack vectors that have never been seen • Multi-step and polymorphic attacks • Approach: create a transformation algorithm to synthesize semantics-aware signatures from iSink data • Session and application protocol semantic awareness (Sommer & Paxson, ‘03) wail.cs.wisc.edu

  13. Nemean architecture • Data abstraction • Transport normalizer • Aggregation • Service normalizer • Clustering • Group sessions/connections using similarity metric • Signature generation • Machine learning to build finite state automata wail.cs.wisc.edu

  14. Signature example (Welchia) • Multistage attack (3 steps) • GET /  200 OK • SEARCH /  411 Length Required • SEARCH /AAAA… Start Get / 200 Search / 411 Search / 411 Get / 200 Search /AAAAA[more] 400 Search /AAAAA[more] 400 Search /AAAAA[more] 400 wail.cs.wisc.edu

  15. Summary • Malicious activity in the Internet is a huge problem and is likely to persist for a long time • Current network security analysis tools are largely inadequate • We advocate network situational awareness through self-directed intrusion detection • Distributed data sharing • Unused address space monitoring • Automated semantics-aware signature generation wail.cs.wisc.edu

More Related