CSE 581 Internet Technology Detection Systems #1 Presented by Jason Liu

1. CSE 581 Internet TechnologyDetection Systems #1PresentedbyJason Liu

2. Agenda • “Bro: A System for Detecting Network Intruders in Real-Time” by Vern Paxson • “Designing a Web of Highly-Configurable Intrusion Detection Sensors” by Vigna, Kemmerer, and Blix • “Aggregation and Correlation of Intrusion-Detection Alerts” by Debar, and Wespi

3. Topics • Bro: • Stand-alone, real-time, passive • STAT framework • Development platform, highly configurable probes, dynamic • Probes and ACCs

4. Goals and requirements of Bro • High-speed, large volume monitoring • 100Mbps, 20GB/per day • No packet filter drops • Drops defeat the monitoring • Real-time notification • Minimize damage, prevent further break-ins • Mechanism separate from policy • Hardwired responses are cumbersome • Avoid simple mistakes • The monitor will be attacked

5. Structure of the Bro system Real-time notification Record to disk Policy Script Policy Script Interpreter Event Control Event Stream Event Engine Tcpdump filter Filtered packet stream Libpcap Packet stream Network

6. Bro: Libpcap • The packet-capture library used by tcpdump • Isolates Bro from details of the network link technology (Ethernet, FDDI, SLIP) • Operates on tcpdump save files, making off-line development and analysis easy. • Downloads packet filter into kernel • Example of tcpdump’s filtering language • Tcp port finger or tcp port ftp or tcp port telnet or port 111 (portmapper)

7. Bro: Event Engine • Reduces kernel-filtered network stream into high-level events • Performs integrity checks on packet headers • Records full packets if it analyzed the entire packet • Just header if only analyzed for SYN/FIN/RST computations • Skips recording if it didn’t process the packet

8. Bro: Event Engine – Tcp processing Set timer T Init SYN pack request conn Connection_attempt Event Engine Connection_established Connection_rejected Connection_finished

9. Bro: Policy script interpreter • Executes event handlers written in Bro language • Separates mechanism from policy • Event handlers execute Bro scripting cmds, inc generating new events, logging real-time notifications, recording data to disk, or modifying internal state for access by invoked event handlers • Adds extensibility • Adding new functionality – add new protocol analyzer to event engine and a new event handler

10. Types of attacks – Overload attacks • Overburden the monitor to the point where it fails to keep up with the data stream it must process • Drives the monitor to the point of overload • Attempts a network intrusion • Defensive strategies • Monitor was not sufficiently overwhelmed • To shed load when it becomes unduly stressed • Event engine generates a net_stats_update event every T seconds • Bro scripts have basic info to determine • Bro: use a hardware platform with sufficient processing power to keep up with hi volume of filtered traffic

11. Types of attacks – Crash attacks • To knock monitor out of action by causing it to Fault or run out of resources • Send a series of packets or just one to cause monitor to fault due to coding error • Cause the monitor to exhaust its available resources: dynamic mem or disk space • Create traffic consumes a large amount of state • Defenses against the attacks: • Careful coding and testing • The event engine maintains a “watch-dog” timer that expires every T seconds • The script runs Bro detects if it ever unduly exits • Executes tcpdump to log the attack • Do not allow a subsequent intrusion attempt to go unrecorded

12. Types of attacks – Subterfuge attacks • An attacker attempts to mislead the monitor • Attacks on integrity of the byte stream monitored for a TCP connection • Transmit the packet with an invalid TCP checksums • Launch the packets with an IP “Time to Live” (TTL) field • Attacked endpoint has a smaller MTU than the internet path from attackers host to the monitoring point. • Attacker send a packet size exceeding this MTU and with the IP “Don’t Fragment” header bit set • Examples: • Attacker sends text with an embedded NULL • Use fragmented IP datagrams to elude monitor that failed to resemble IP fragments

13. Types of attacks – Subterfuge attacks • Defenses • Observe a retransmitted packet, compare it with any data if overlap, if they disagree, sound an alarm • Monitor retains a record of previously transmitted data, both in and out of sequence

14. Conclusions • Generates 40MB of connection summaries each day, and average of 20 real-time notifications • Generally operates without any packet drops • Distribute monitoring across multiple CPUs • Extending BPF to better support monitoring • Adding lookup tables and var-length snapshots

15. The STAT Framework -- Introduction • Limitations of existing tools • Developed ad hoc forcertain domains and or environments • Difficult to configure, extend, and control remotely • Do not allow dynamically configure a running sensor • Relatively static configuration of responses • Configuration performed manually at a lower level • This paper presents a distributed components integrated by locally communication and control infra.

16. The STAT Framework • The STAT framework consists of five concepts • The STAT technique • STAT is a technique for representing high-level descriptions of computer attacks • The STATL language • Represents STAT attack scenarios. Defines domain-indep features of STAT technique • The STAT core • Represents the runtime of the STATL language. Implemented domain-indep char of STATL • The CommSTAT communication infrastructure • STAT-based sensors are connected by a comm infra that allows sensors to exchange alert msg, control directives

17. The STAT Framework (2) • The MetaSTAT control system • The CommSTAT comm infra is used by MetaSTAT to exert control over a set of sensors • It’s responsible for the following tasks • Collect and store alerts produced by managed sensors • Route alerts to STAT sensors and other MetaSTAT inst • Maint a database of avail modules and dependencies • Maint a database of current sensor config

18. Architecture of a web sensors

19. STAT Sensors • Evolution of a STAT-based sensor

20. Dependencies and Configurations • Configuration: • A set of installed and activated modules and available external components • A configuration can be valid and or meaningful. • All activated modules activation deps satisfied • All functional deps satisfied

21. Conclusions • The “web of sensors” is an open design • 3rd party IDS modules can be integrated through CommSTAT proxies • The STAT framework has been designed and implemented. • A number of IDSs built using the framework • Most of the control primitives have been defined and partial implemented • Need to add alert routing functionalities to MetaSTAT

22. Aggregation and Correlation of Intrusion-Detection Alerts • Issues • Address the following intrusion detection weaknesses: • Flooding • Prone to alert flooding • Context • Multiple related alerts • False alerts • Likely to generated false alerts (positive or negative) • Scalability • Difficult to achieve large-scale deployment

23. Relationship between probes and ACCs • Probes • Intrusion detection systems available either as commercial products or in the public domain • Aggregation and Correlation components (ACCs) • Correlate the output of several probes and give the operator a condensed view of the reported security issues • Consists two parts • A unified data model for intrusion-detection alerts • A set of rules to process the alerts

24. Relationship between probes and ACCs (2)

25. ACCs Representation

26. Definitions • Duplicates • Alerts are reported by different probes but are related to the same attack • Consequences • Alerts are related and should occur together • Situations • Aggregates similar alerts and provide the operator with a more condensed view of the security issues

27. Example of Duplicates and Consequences • Web IDS and RealSecure alerts

28. Conclusions • ACC can handle alerts generated by intrusion-detection probes • The AC algorithm can detect duplicates, as well as consequences • Plan to enhance the generic rules of the AC algorithm • To improve performance, investigate normalization of alerts as a front-end to the TEC • The framework will benefit when more probes integrated.