270 likes | 416 Vues
This paper discusses the implementation of a Distributed Intrusion Detection System (DIDS) over a medium-scale open network, focusing on service availability and proactive security measures. Key objectives include learning network traffic patterns, detecting compromised hosts, identifying misconfigurations, and acting against security threats. The study emphasizes the importance of integrating various data sources and provides detailed insights into deployment strategies, sensor placement, and handling the high volume of information generated. The use of open-source tools and databases enhances the system's efficiency and adaptability.
E N D
Distributed IDS • The implementation of a Distributed Intrusion Detection System over a medium scale open network where the focus is availability of services. • Darian Jenik - Network Management Queensland University of Technology
What we hope to achieve: • Learn about the nature of traffic flowing on the network. • Catch attempts to compromise host security. • Detect compromised hosts on the network. • Discover holes and incorrect configurations on existing services. • Take a proactive rather than reactive approach to dealing with security issues.
What IDS is not: • IDS in NOT security – • For security you need: • Good security policy that is both documented and adhered to. • Good security practice by system administrators. • Hardened perimeter firewalls and “DMZ” firewalls. • IDS is not a “product”. • IDS is not a “sensor”.
What Information can it provide: Denials, scans, vulnerable services, etc…. Other input sources (Tripwire, syslog, firewall…) Cross referencing allows individual events that seem innocent to take up more meaning in context.
Where do we put the sensor: Traditionally – gateway(s) Port Mirroring ? (50+ datacabinets) Preferably everywhere This would normally cost $$$$$ but open source makes this possible
The scale of the problem • Approximately 10000 hosts 100 web servers 300 “servers” of other type • Students • System Administrators • IAS
Outside 1 Outside 2 Servers GW GW Inside 1 10meg -> 1 Gig GW Inside 2 User hosts The scale of the problem - simplified
Outside 1 Outside 2 Inside 1 10meg -> 1 Gig Inside 2 The scale of the problem contd….. Bad!! Servers Bad!! GW GW GW User hosts
Outside 1 Outside 2 Inside 1 10meg -> 1 Gig Inside 2 The scale of the problem contd….. Servers GW GW GW Worse!! Worse!! User hosts
Outside 1 Outside 2 Inside 1 10meg -> 1 Gig Inside 2 The scale of the problem contd….. Servers GW GW GW User hosts
Outside 1 Outside 2 Inside 1 10meg -> 1 Gig Inside 2 The scale of the problem contd….. Servers GW GW GW User hosts
Dealing with the volume of information • Manually examine each incident (initially). • Classify and build up a database of false positives. • Use the power of the SQL database to look for patterns and “repeats”
IDS should perform the following tasks • Detect known violations to host integrity by passively watching network traffic. • Respond to attempted violations by blocking external IP addresses. • Respond to probes from outside by blocking external IP addresses. • Find and report usage inconsistencies that indicate account/quota theft. • Detect violations by monitoring information (web pages etc….) • Help log and establish traffic/host usage patterns for future reference and comparison
Respond to attempted violations by blocking external IP addresses. • Make sure the IDS is able to respond and send commands to firewalls and/or hosts. • IDS sends RST packets to both ends of the connection. • IDS is able to insert rules into border firewall.
Respond to probes from outside by blocking external IP addresses. • Attempts to open ports on servers that are not enabled. • Make “flypaper” IP addresses that have never been used for anything that serve to pickup slow probes.
Supporting information sources that can be fed into the database. • Central syslog collecting and analysis. • Tripwire • “Nmap” database • Performance and Usage analysis.
Open Source • Just about any platform(Including windows) • Many plugins and external modules. • Frequent rules updates.
Snort Plugins • Databases • mySQL • Oracle • Postgresql • unixODBC • Spade (Statistical Packet Anomaly Detection engine) • FlexResp (Session response/closing) • XML output • TCP streams (stream single-byte reassembly)
Snort Add-ons • Acid(Analysis Console for Intrusion Detection) - PHP • Guardian – IPCHAINS rules modifier.(Girr – remover) • SnortSnarf - HTML • Snortlog – syslog • “Ruleset retreive” – automatic rules updater. • Snorticus – central multi-sensor manager – shell • LogSnorter – Syslog > snort SQL database information adder. • + a few win32 bits and pieces.
Snort + Acid = ? • Acid is a Cert project. • Pretty simple PHP to mySQL • Quite customizable. • Simple GUI for casual browsing.
Securityfocus • Whitehats • CVE
URLS • www.snort.org • http://www.cert.org/kb/acid/ • www.whitehats.com(Intrusion signatures data) • www.securityfocus.com(Intrusion signatures data) • http://cve.mitre.org/(Intrusion signatures data) • http://www.psionic.com/(logcheck + hostsentry)