Host-Level Intrusion Detection Systems

These intrusion detection systems run on the protected host and control various security events. Most often, these systems operate with the operating system log files (for example, the Intrusion Alert system), application log files (RealSecure Server Sensor) or DBMS log files. Thus, all these systems depend on the contents of the log files. Consequently, if the log-file data is incomplete (or, even worse , modified by the intruder), these systems will be unable to detect an attack. Some less common systems (such as EMERALD) are modeled on detecting anomalous behavior, comparing the current user session (issued commands and other parameters) statistically to the standard profile of normal behavior. For detecting deviations from normal behavior, such systems utilize sophisticated algorithms. Besides this model, there are other intrusion detection systems that operate over network traffic sent or received from a specific host (for example, RealSecure Server Sensor).

Recently, systems built into the OS kernel have become common. Since such systems can control all system calls, they provide you with the ability to detect and lock all unauthorized activities quickly. The list of such systems includes Cisco Host IDS Sensor and StormWatch, developed by Okena.

There are several categories of host-level intrusion detection systems, which function at different levels of the information system.

Operating System Level

These tools are based on the monitoring of the operating system's log files, filled in the course of a user session or as the result of other activities carried out on the controlled host (for example, Swatch). Generally, these intrusion detection systems use the following criteria for detecting unauthorized activities:

User's working hours (logon time)
Number, types and names of the created files
Number, types and names of accessed files
Types of logon and logoff events
Running applications
Security policy changes (events such as the creation of a new user or user group , password changes and so on)

Events registered in the log file are compared to the signature database using special algorithms, which may vary depending on the intrusion detection system. The system classifies suspicious events and sends administrative alerts when these events occur. As a rule, the intrusion detection systems under consideration run on the server. Note that it does not usually make sense to run these systems at workstations because of the high demand they place on resources.

Sometimes, intrusion detection systems of this class control user activities in real-time mode (for example, HostSentry system from Psionic). However, this mechanism is rarely implemented. These systems usually analyze only OS log files. Quite recently, solutions have appeared that are not based on log-file analysis alone.

Some operating systems (for example, FreeBSD or Linux) are supplied with their source code. Thus, developers of intrusion detection systems can modify the OS kernel in order to add to the capabilities for detecting unauthorized activities. Examples of such additions are OpenWall and LIDS. These systems are built into the Linux kernel and enhance the default security mechanisms of this OS. The LIDS system, for example, can detect an instance of a protocol-analyzer installation or a change in the rules of the built-in firewall system, and react appropriately by blocking these activities.

Application and DBMS Level

{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

There are two ways to implement systems of this class. In the first case, they analyze the records in the log file of a specific application or DBMS and are very similar to the OS-level intrusion detection systems. The main advantages of this approach are simplicity of implementation and that support is provided by any application program or DBMS that can register events in the log file. An example of this type of system is the RealSecure Server Sensor. However, this simplicity also conceals the main drawback associated with such an approach. In order to make the system work efficiently , you will have to spend a lot of time and effort customizing it for a specific application. Also, almost any application has a unique log-file format. The second method of implementing these systems is integrating them into a specific application or DBMS. In this case, the IDS becomes less universal, but more functional as a result of the close integration with the controlled software. An example of such a system is WebStalker Pro, developed by Trusted Information Systems (TIS) and then bought by Network Associates. Unfortunately, this system is no longer available. However, some of its elements are built into the CyberCop Monitor system.

Network Level

Besides performing an analysis of log files or system activities, intrusion detection systems of this class can operate with network traffic. In this case, the intrusion detection system does not analyze all network packets but, instead, considers only those that are directed to or from the controlled host. Because of this, the network interfaces of the controlled hosts can function in mixed mode as well as in normal mode. Since these systems control all incoming and outgoing network connections, they can act as personal firewalls. Examples of such systems include RealSecure Desktop Protector from ISS and PortSentry from Psionic.

Working Mechanism

The working mechanism of intrusion detection systems that implement the principle of information logging is quite simple - when a new record is written to the log file, an alert is sent to the intrusion detection system, which analyzes this information in relation to the attack-signature database (Fig. 6.19). Methods of network-traffic analysis will be covered in detail later in this chapter in the discussion of network-level intrusion detection systems.

click to expand
Fig. 6.19. Components of the host-level intrusion detection system

Advantages of the Host-Level Intrusion Detection Systems

Naturally, each intrusion detection system has specific advantages and drawbacks.

Confirming an Attack

Since intrusion detection systems based on log-file analysis operate only with events that have actually taken place, systems of this class can determine with a high level of precision whether an the attack really took place. In this respect, host-level intrusion detection systems ideally complement network-level intrusion detection systems, the strong points of which will be covered later. Such a combination provides preventive alerts based on the network component and the detection of an attack's success based on the system component.

Control over Specific Host Activity

These systems control user activity, file access, changes to file-access privileges, attempts to install new programs and attempts to access privileged services. For example, they can trace all user logons and logoffs. Using network-level systems, it is very difficult (or simply impossible ) to implement this level of event details. System-level intrusion detection tools can also control the administrator's activities, which normally are not controlled by anyone . Operating systems register any event, when user accounts are created, deleted or modified. Intrusion detection tools of this class can immediately detect specific events when they take place.

Furthermore, host-level intrusion detection systems can control changes introduced to the key system or executable files. Any attempts to overwrite these files or install Trojan horse programs can be detected and blocked in a timely manner. Note that network-level intrusion detection systems sometimes miss this type of activity.

Detecting Attacks Missed by Other Tools

Systems of this class are capable of detecting attacks that can not be detected by network-level tools (for example, attacks originating from the attacked host). Additionally, some systems (for example, RealSecure Server Sensor) can detect network attacks directed at a controlled host that were missed for some reason by a network-level intrusion detection system.

Working on Dial-up Networks and Networks with Channel Encryption

Since these intrusion detection tools are installed on different hosts in the organization network, they can solve some of the problems that arise when operating network-level intrusion detection systems in dial-up networks or networks with channel encryption.

Dial-up connections permit the management of a globally distributed network in relatively small network segments. As a result, it might sometimes be difficult to determine the best place to install the system for detecting attacks in network traffic. Sometimes special ports (mirror ports, managed ports, and span ports) located at the switches can be helpful. However, this is not always the case. The detection of attacks at the system level allows more efficient work in the dial-up networks, since it enables you to place the intrusion detection systems only on those hosts where they are really necessary.

Encryption also creates a problem for network-level intrusion detection systems, since they may remain "blind" and miss some encrypted attacks. Host-level intrusion detection systems are not subject to this limitation, since the traffic at the OS level is already decrypted.

Detecting and Reacting in a Mode Close to Real-Time

Although intrusion detection at the system level does not allow for true real-time reactions , it can function in a mode very close to real time, provided that the system has been properly configured. In contrast to legacy systems that check the status and contents of the log files once in a specified time interval, most contemporary applications get an interrupt from the OS immediately after the new record is added to the log file. This new record can be processed immediately. Thus, the time delay between the identification of an attack and the system's reaction can be decreased significantly. The only remaining delay is the interval between the moment when the OS logs the new event that when the intrusion detection system identifies the attack. However, in most cases intruders, can be detected and stopped before they can cause any significant damage.

Low Prices

Despite the fact that network-level intrusion detection systems analyze the traffic of the whole network, quite often they are too expensive, in some cases exceeding $10,000 in price. On the other hand, host-level intrusion detection systems usually cost only a few hundred dollars per agent and can be purchased as needed.