Intrusion Detection As the name implies, the goal of intrusion detection is to be able to identify if and when an intrusion has occurred. Because we must minimize damage done by an intruder and are also interested in catching the intruder, we place a premium on discovering the intrusion as soon as possible -- within seconds, that is. IntrusionÂÂÂÂÂdetection is the logical complement to network firewalls, extending the security management capabilities of system administrators to include security audit, monitoring, attack recognition, and response. Intrusion includes attacks coming from outside the organization as well as misuse originating inside the organization. Intrusion Detection systems collect information from a variety of system and network sources, then analyze the information for signs of intrusion and misuse. Vulnerability assessment performs rigorous examinations of systems in order to locate problems that represent security vulnerabilities. Integrity Verifiers Integrity protection systems detect when critical components have changed, and assume that the changes must have been due to malicious activity such as when backdoors have been added to system files. Some well known integrity verifiers are: 1. COPS is a collection of programs that each attempt to tackle a different problem area of UNIX security such as: file, directory, and device permissions/modes; poor passwords; content, format, and security of password and group files; the programs and files run in /etc/rc* and cron tab files; existence of root-SUID files, their writeability, and whether or not they are shell scripts; a CRC check against important binaries or key files to report any changes therein; writability of users home directories and startup files (.profile, .cshrc, etc.); anonymous ftp setup; unrestricted tftp, decode alias in sendmail, SUID uudecode problems, hidden shells inside inetd.conf, rexd running in inetd.conf; miscellaneous root checks -- current directory in the search path, a "+" in /etc/host.equiv, unrestricted NFS mounts, ensuring root is in /etc/ftpusers, etc.; dates of CERT advisories vs. key files; and the Kuang expert system. This takes a set of rules and tries to determine if your system can be compromised. Open source code: www.fish.com/cops/ 2. Tripwire will checksum your system files, and later detect if an intruder has made any modifications. Compares new signatures against old signatures to detect when files change. Signing algorithms include MD4, MD5, Snefru, and Haval. Signatures should be kept on remote server or read-only medium. Tripwire is resource-intensive, but the alternative (re-installing your system from scratch) is quite costly. You may get Tripwire from www.tripwiresecurity.com/. 3. Tiger is a set of scripts that scan a UNIX system looking for security problems. Regularly checks programs and scripts to see if root access could be granted. Typical check is for suid programs. Tiger is available at ftp://net.tamu.edu/pub/security/TAMU/ Log Files Extensive system logs must be generated recording all system activity as these logs will contain evidence of an intrusion that can be discovered at least after the fact. Here are the most common of these logs. Be aware that in different Unix variants the location of these files varies. 1. utmp wtmp files are located either in /etc, /var/log or /var/run. The utmp file logs data regarding currently logged in users. The wtmp file records all logins, logouts, shutdown and reboots. For more details, man utmp and also see standard include file <utmp.h>. 2. The directory /var/log/ records logs from a variety of services. On systems that must be secure, the standard logs and directories such as /etc and /var/log are not good enough. One must employ additional logging tools. E.g., who is connecting to services on your system? There are many programs under the heading of IP loggers available. It is important that the log files are not stored on the system that generates the logs. Attackers have been able to edit these. They have also deliberately caused harmless activity that generated so much logging that the disks become full before attempting malicious actions. Analysis of Log Files But, these logs are often so large that is hard for the average person to analyze and manage. There are programs that can be searched under the phrase "log file analysis" that examine the logs systematically and alert you to suspicious activity. Sniffers Traffic sniffers are a double edged sword. They can be used to track the communications of intruders in wonderful detail, but they can also be used to sniff passwords and other sensitive information. You should be very careful in your use of these powerful programs. The machines running these programs should as hardened as possible. Intrusion Detection Systems Intrusion detection systems (IDSs) have become a major area of research and product development. They are predicated on the assumption that an intruder can be detected through an examination of various parameters such as network traffic, CPU utilization, I/O utilization, user location, and various file activities. IDSs designed to protect networks typically monitor network activity, while IDSs designed for single hosts typically monitor operating system activity. System monitors or daemons convert observed parameters into chronologically sorted records of system activities. Called "audit trails," these records are analyzed by IDSs for unusual or suspect behavior. IDS approaches include Signature analysis Specific signatures or patterns characterize attack attempts. Semantic descriptions or signatures of known attacks are collected or formulated and stored in a database. One type of signature analysis, audit trail analysis, compares information found in the audit trails, e.g., a system's builtÂÂÂÂÂin audit log or event log, with the attack signatures. Attack scenarios might be translated into sequences of audit events, or into patterns of data that can be sought in the audit trail generated by the operating system 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 attempt of an intrusion is suspected. The main drawback of the signature analysis technique -- like all misuseÂÂÂÂÂbased approaches -- is the need for frequent updates to keep up with the stream of new vulnerabilities/attacks discovered, this situation is aggravated by the requirement to represent all possible facets of the attacks as signatures in a signature database. Rule-Based Intrusion Detection Rule-based intrusion detection (RBID)assumes that intrusion attempts can be characterized by sequences of user activities that lead to compromised system states. RBID systems are 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 penetration state change scenarios. Audit events are translated into facts carrying their semantic signification in the expert system, and the intrusion analysis function draws conclusions using these rules and facts either to detect the presence of a suspected attack or to detect inconsistent behavior. This method increases the abstraction level of the audit data by attaching semantics to it. If an RBID expert system infers that a penetration is in process or has occurred, it will alert the computer system security officers and provide them with both a justification for the alert and the user identification of the suspected intruder. Note that the rule base must be continually updated to accommodate new descriptions of attacks or new usage patterns. There are two major approaches to rule-based intrusion detection: 1. State-based. In this approach, the rule base is codified using the terminology found in the audit trails. Intrusion attempts are defined as sequences of system state- as defined by audit trail information- leading from an initial, limited access state to a final compromised state. 2. Model-based. In this approach, known intrusion attempts are modeled as sequences of user behavior; these behaviors may then be modeled, for example, as events in an audit trail. The IDS determines how an identified user behavior may manifest itself in an audit trail. Model based systems can process more data, because the technology allows you to narrow the focus of the data selectively, allow more intuitive explanations of intrusion attempts, and can predict the intruder's next action. RuleÂÂÂÂÂbased description languages form natural tools for modeling the knowledge that experts have collected about attacks. This approach allows a systematic browsing of the audit trail in search of evidence of attempts to exploit known vulnerabilities. They are also used for verifying the proper application of the security policy of an organization. The main limitations of this approach are 1) the difficulty of extracting knowledge about attacks and 2) the processing speed. StateÂÂÂÂÂtransition analysis This technique describes an attack with a set of goals and transitions, but represents them as stateÂÂÂÂÂtransition diagrams. States in the attack pattern, corresponding to system states, have Boolean assertions associated with them that must be satisfied to transition to that state. This approach is conceptually identical to modelÂÂÂÂÂbased reasoning. Statistical-Based Intrusion Detection The most widely used approach of anomalyÂÂÂÂÂbased intrusion detection is statistical. User or system behavior is measured by a number of variables sampled over time and stored in a 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). The current behavior of each user is maintained in a profile. At regular intervals the current profile is merged with the stored profile. Anomalous behavior 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. The profiles are regularly updated as the behaviors of users evolve. SBID assumes that intrusions can be detected by inspecting a system's audit trail data for unusual activity, and that an intruder's behavior will be noticeably different from that of a legitimate user. Before unusual activity can be detected, SBID systems require 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. The main advantage of SBID systems is that intrusions can be detected without a priori information about the security flaws of a system. SBID systems typically employ statistical anomaly and rule-based misuse models. System profiles, user profiles, or both may be used to define expected behavior. User profiles, if used, are specific to each user and are dynamically maintained. As a user's behavior changes over time, so too will his user profile. No such profiles are used in RBID systems. As is the case with RBID systems, known intrusion scenarios can be codified into the rule base of SBID systems. Detection of specific denialÂÂÂÂÂofÂÂÂÂÂservice attacks that make use of weaknesses in the Internet protocol suite can be subsumed under the statistical approach. One example is the 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. Though the attacker seems to behave according to the communications protocol, the attack can only be 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. Neural networks Neural networks are algorithms that learn about the relationship between inputÂÂÂÂÂoutput vectors and ''generalize'' them to obtain new inputÂÂÂÂÂoutput vectors in a reasonable way. The main use of neural networks for intrusion detection is to learn the behavior of actors in the system (e.g., users, daemons). The advantage of using neural networks over statistics resides in having a simple way to express nonlinear relationships between variables, and in learning/retraining the neural network automatically. Neural networks are still a computationally intensive technique, and are not widely used in the intrusion detection community. User anomalous behavior identification This technique models the normal or authorized behavior of users by the set of tasks they have to or are authorized to perform on the system. These tasks and facets of the system's security policy are then represented as 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. The 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 and they do not fit the task pattern an alarm is issued. This method is 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 at intrusion is suspected. The Linux Intrusion Detection System LIDS (http://www.lids.org/) an intrusion detection/defense system in Linux kernel. It modifies the Linux kernel sources which enhances the kernel's security. When it is in effect, chosen files access, all system/network administration operations, any capability use, raw device, mem, and I/O access can be made impossible even for root.
