1 / 20

CONTEXT-BASED INTRUSION DETECTION USING SNORT, NESSUS AND BUGTRAQ DATABASES

CONTEXT-BASED INTRUSION DETECTION USING SNORT, NESSUS AND BUGTRAQ DATABASES. Presented by Frédéric Massicotte Communications Research Centre Canada Department of Systems and Computer Engineering, Carleton University Privacy, Security and Trust October 2005. Motivations.

hazel
Download Presentation

CONTEXT-BASED INTRUSION DETECTION USING SNORT, NESSUS AND BUGTRAQ DATABASES

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. CONTEXT-BASEDINTRUSION DETECTION USING SNORT, NESSUS AND BUGTRAQ DATABASES Presented by Frédéric Massicotte Communications Research Centre Canada Department of Systems and Computer Engineering, Carleton University Privacy, Security and Trust October 2005

  2. Motivations • Current IDS Problems • Some IDS do not provide a declarative rule specification language • Difficult to verify, compare and update attack scenarios • Many IDS only rely on one packet or on one TCP stream to identify intrusions • More complex attacks need to be programmed (two specification systems) • False negatives and false positives • Intrusion signatures do not include a precise network context • Increases the number of false positives (session state not enough) • IDS functionality needed • The IDS signature language should • be a declarative rule specification language • be independent of the monitoring engine • enable multi-packet rules • specify network-context gathering other than alarms and session states • be used on well-defined models (Packet Model and Network Model) • The IDS monitoring engine should • be multi-packet • maintain a network-context knowledge base

  3. Our Contributions • A multi-packet monitoring engine • A declarative rule specification language that uses the Object Constraint Language • A formal packet model and a formal network model • A library of passive information gathering rules to acquire the network context • Missing : • A library of intrusion detection rules with network context • Prove that these rules could be used to reduce the number of false positives • Study the correlation potential and accuracy of freely available security databases

  4. Rule Specification packet alarm ? OCL Network Model Packet Stream Model

  5. Network Model

  6. Network Model

  7. IDS Rules with Network Context p1.data.match(”/ˆ STAT\s+[ˆ \n]*\x3f/smi”) Packet characteristics p1.tcp.destinationPort = 21 and Session::sessionOpen(p1.ip.sourceAddress, p1.ip.destinationAddress, p1.tcp.sourePort, p1.tcp.destinationPort) and Session state (IPStack::hasDaemonOnPort( p1.ip.destinationAddress, p1.tcp.destinationPort, Port.TCP, ”IIS”, ”5.0”) or IPStack::hasDaemonOnPort( p1.ip.destinationAddress, p1.tcp.destinationPort, Port.TCP, ”IIS”, ”5.1”)) Proper network context

  8. IDS Rules with Network Context Snort (IDS) Nessus (VDS) Bugtraq (VDB) IDS Rules IDS Rules with Network Context Network Context p1.data.match(”/ˆ STAT\s+[ˆ \n]*\x3f/smi”) p1.tcp.destinationPort = 21 and Session::sessionOpen(p1.ip.sourceAddress, p1.ip.destinationAddress, p1.tcp.sourePort, p1.tcp.destinationPort) Context Packet inv: Packet.allInstances()->forAll(p1 | p1.data.match(”Microsoft IIS 5.0”) and p1.tcp.destinationPort = 80 and ... Context Packet inv: Packet.allInstances()->forAll(p1 | p1.data.match(”Microsoft IIS 5.0”) and p1.tcp.destinationPort = 80 and ... (IPStack::hasDaemonOnPort(p1.ip.destinationAddress, p1.tcp.destinationPort, Port.TCP, ”IIS”, ”5.0”) or IPStack::hasDaemonOnPort(p1.ip.destinationAddress, p1.tcp.destinationPort, Port.TCP, ”IIS”, ”5.1”))

  9. Snort References

  10. Group 1: Direct and Indirect Snort (IDS) Nessus (VDS) Bugtraq (VDB)

  11. Group 2: Incomplete but Inferable Snort (IDS) Nessus (VDS) Bugtraq (VDB)

  12. Group 2: Incomplete but Inferable Snort (IDS) Nessus (VDS) Bugtraq (VDB)

  13. Group 3: Incomplete and Non-Inferable Snort (IDS) Nessus (VDS) Bugtraq (VDB)

  14. Group 4: No Reference Snort (IDS) Nessus (VDS) Bugtraq (VDB)

  15. Group 1: Direct and Indirect

  16. Results of Relationship Analysis • Only 16% of the Snort rules have references to Bugtraq and Nessus. • Only 11.4% have the same set of Bugtraq references whether we use the Snort to Bugtraq references or the Snort to Nessus to Bugtraq references. • 29% of the Group 1 Snort rules present discrepancies, depending on whether we use the direct or indirect relationship to Bugtraq. • 6% of Group 1 seem to refer to different Bugtraq vulnerabilities.

  17. Results • Built a library of small IDS rules with network context using group 1 Snort rules • Tested 20 attack programs against 12 systems • Reduced the number of false positives, compared to Snort • Proved that network context is important to reduce false positives

  18. 2.4.18-14 Linux 2..4.19-4GB Attacker 1 Attacker 2 OS X Test Cases Sun 4.x Attack Attack Attack Attack Snort PNMT Oracle vs vs Results Results

  19. Conclusion • The relationships between Snort IDS signatures, Nessus and Bugtraq still need to be improved • Correlation systems using events for these systems only use a small proportion of relationship potential • For the small number of Snort rules that provide accurate relationships, network context is important to reduce false positives. • Future Work on IDS Rules • Test more context-based intrusion detection rules • Continue the development of a virtual exploit testing network • Test rules to identify more complex attacks such as DDOS and Network Discovery Techniques

  20. Questions

More Related