Means for Intrusion Detection. Intrusion Detection. INFO404 - Lecture 13. Content

Transcription

1 Intrusion Detection INFO404 - Lecture nfoukia@infoscience.otago.ac.nz Content Definition Network vs. Host IDS Misuse vs. Behavior Based IDS Means for Intrusion Detection

2 Definitions (1) Intrusion: a deliberate or accidental unauthorized access to and/or activity against a communication and information system Intrusion detection is to be able to identify if and when an intrusion has occurred The goal is to minimize damage done by an intruder: catching the intruder at the first symptom of an intrusion, discovering the intrusion as soon as possible Complements existing security tools: network firewalls Extends the security capabilities: include security audit, monitoring, attack recognition, and response Intrusion includes attacks coming from outside the organization as well as misuse originating inside the organization Definitions (2) Intrusion Detection System (IDS) collects information from a variety of systems and network sources, then analyze the information for signs of intrusion and misuse. Vulnerability/Risk assessment performs rigorous examinations of systems in order to locate problems that represent security vulnerabilities Different Types of IDS: behavior-based IDS and misuse-based IDS Host-based IDS and Network-based IDS All could be combined to provide an hybrid IDS

3 Network IDS vs. Host IDS (1) Host-Based IDS (HIDS) First type of IDS to be developed and implemented Collects and analyze data that originate on a computer that hosts a service (Web server). Once this data is aggregated for a given computer, it can either be analyzed locally or sent to a separate/central analysis machine Example of HIDS Windows NT/2000 Security Event Logs [1] RDBMS audit sources: audit data server data summarization Enterprise Management systems audit data (such as Tivoli [2]) UNIX Syslog in their raw forms or in their secure forms such as Solaris' BSM host-based commercial products include RealSecure [3] Network IDS vs. Host IDS (2) Network-Based IDS (NIDS) Analyzes data packets that travel over the actual network. These packets are examined and sometimes compared with empirical data to verify their nature They have NW interface in promiscuous mode They tend to be more distributed than host-based IDS. Instead of analyzing information that originates and resides on a computer, NIDS uses techniques like "packet-sniffing" to pull data from TCP/IP or other protocol packets travelling along the network Good for detecting access attempts from outside the trusted NW unauthorized outsider access: detecting the unauthorized user before log on attempt is best accomplished with NIDS Bandwidth theft/dos: packets that initiate/carry these attacks can best be noticed with use of NIDS Barriers against NIDS include encrypted packet payloads and highspeed networks: inhibit the effectiveness of packet interception and deter packet interpretation Examples of NIDS include Shadow [4], Snort [5], Dragon [6], RealSecure

4 Misuse IDS vs. Behavior Based Detection Anomaly Detection Assumes that all intrusive activities are necessarily anomalous. This means that from a "normal activity profile" of a system, it is possible in theory to flag all system states that vary from the established profile by a statistically significant amounts as intrusion attempts High rate of false positives: Anomalous activities that are not intrusive are flagged as intrusive Misuse Detection or Signature-Based The concept: there are ways to represent attacks in the form of a pattern or a signature so that variations of the same attack can be detected Can detect many or all known attack patterns, but are of little use for unknown attack signatures: false negatives Main Means of Detecting Intrusion Log Analysis: logs are often so large that is hard for the average person to analyze and manage Traffic Sniffer: tracks the communications of intruders via the NW Integrity Verifier: detects when critical components have changed, and if it is due to malicious activity: Tripwire [7]

5 Signature Analysis (1) Specific signatures or patterns define attack attempts Descriptions or signatures of known attacks are collected, formulated and stored in a database Audit trail analysis, compares information found in the audit trails, e.g., a system's built-in audit log or event log from monitor, with the attack signatures Signature Analysis (2) Attack scenarios might be translated into sequences of events, or into patterns of data that can be sought in the audit trail generated by the OS of a computer, by router software, firewalls, switches, or applications Other patterns or sequences may be found in a stream of network traffic. When a sequence of events is found in the audit trail, or in the network traffic, that matches a sequence of audit events, or the signature of an attack, an intrusion is suspected Main drawbacks of the signature analysis need for frequent updates to keep new vulnerabilities/attacks discovered an attack has to be represented with all its possible facets in the database

6 Rule-Based Intrusion Detection Intrusion attempts can be represented by sequences of user activities that lead to compromised system states IDS characterized by their expert system properties that fire rules when audit records or system status information begin to indicate illegal activity. These predefined rules typically look for high-level state change patterns observed in the audit data compared to predefined intrusion state change scenario Audit events are sent to the expert system, and the intrusion analysis function draws conclusions using these rules and events either to detect the presence of a suspected attack or to detect inconsistent behaviour If the expert system infers that an intrusion is in process or has occurred, it will raise an alert and provide a justification for the alert and the identification of the suspected intruder The rule DB must be continually updated to accommodate new descriptions of attacks or new usage patterns Statistical IDS (1) Main approach of anomaly-based intrusion detection Assumes that intrusions can be detected by inspecting a system's audit trail data for unusual activity, and that an intruder's behaviour will be noticeably different from that of a legitimate user. Before unusual activity can be detected, IDS requires a characterization of user or system activity that is considered "normal." These characterizations, called profiles, are typically represented by sequences of events that may be found in the system's audit data. Any sequence of system events deviating from the expected profile by a statistically significant amount is flagged as an intrusion attempt User or system behaviour is measured by a number of variables sampled over time and stored in profile. There are several types of measures in a profile. These types include: Activity intensity measures; Audit record distribution measures; Categorical measures (e.g., relative frequency of logins); Ordinal measures (e.g., a number value of an amount of CPU or I/O for a specific user) At regular intervals the current profile is merged with the stored profile Anomalous behaviour is determined by comparing the current profile with the stored profile. The original model keeps averages of all these variables and detects whether thresholds are exceeded based on the standard deviation of a variable More complex models have been developed which compare profiles of long-term and short-term user activities

7 Statistical IDS (2) The profiles are regularly updated as the behaviours of users evolve Main advantage Intrusions can be detected without a priori information about the security flaws of a system Example SYN flood attack where an attacker sends many connection requests with a forged source IP address and requires the attacked system to acknowledge these requests without finally receiving a confirmation Attacker seems to behave according to the communications protocol. He can be statistically detected by the quantity of connection requests received within a certain period of time. The quantity of requests together with the configured number of allowed open connections define the threshold for this type of attack User Anomalous Behavior Identification (1) Models the normal or authorized behavior of users by the set of tasks they have to or are authorized to perform on the system Tasks represented as system's security policy Tasks represented as system's security policy are patterns for users' expected or authorized actions such as access to particular files or types of files These actions are related to the audited or logged events, e.g. security related events, which are observed and recorded by the system

8 User Anomalous Behavior Identification (2) An analyzer keeps a set of tasks or patterns that each user should or may perform. Then by comparing, either real-time or off-line, the individuals' actions found in the audit trails with their desired or authorized patterns, if they do not fit the task pattern an alarm is issued Similar to signature analysis except that the inspection expects the actions to match the pattern for proper activity and when it fails to match, it signals suspected improper activity, while in signature analysis the inspection expects the activity to not match the pattern (signature) for improper activity and when it matches an attempt of intrusion is suspected Using Snort: A simple Example (1) See how snort can be used to read packets off the wire by typing the following command: snort -v -*> Snort! <*- Version /11-20:33: :3436 -> :53 UDP TTL:64 TOS:0x0 ID:22707 Len: 36 07/11-20:33: > :3436 UDP TTL:57 TOS:0x0 ID:1177 Len: 91 07/11-20:33: :3437 -> UDP TTL:64 TOS:0x0 ID:22708 Len: 47 07/11-20:34: :53 -> :3437 UDP TTL:57 TOS:0x0 ID:1367 Len: 109 ^C Exiting... ====================================== Snort received 72 packets. Packet loss statistics are unavailable under Linux. Sorry! Breakdown by protocol: TCP: 0 (0.000%) UDP: 4 (5.556%) ICMP: 0 (0.000%) ARP: 66 (91.667%) IPv6: 0 (0.000%) IPX: 0 (0.000%) OTHER: 0 (0.000%) ======================================

9 Using Snort: A simple Example (2) Examination of the first packet gives: 07/11-20:33: :3436 -> : a b c d e- UDP TTL:64 TOS:0x0 ID: f-- -g- --h i Len: j---- a. Date/time stamp b. Source IP address c. Source port d. Destination IP address e. Destination port f. Protocol g. Time to live h. Type of service i. Packet identification j. Length of packet We can see from the transfer above that the client made a DNS request to the server: server port number = 53 Snort generates a nice table of statistics. Unfortunately, snort seems not to provide packet loss statistics under Linux but is able to do so under both FreeBSD and Solaris. (To verify with other different Linux version ) More use of Snort during the Lab 8 References and Tools Tivoli: ftp://ftp.software.ibm.com/software/tivoli/datasheets/tib USEN-00.pdf and 3. RealSecure: ibm.com/services/us/index.wss/offering/iss/a Shadow IDS: 5. Snort (cf. Lab 8) 6. Dragon: 7. Tripwire: Digitally signs important files. Compares new signatures against old signatures to detect when files change. Signing algorithms include MD4, MD5. Signatures should be kept on remote server or read-only medium: