These intrusion detection systems run on the protected host and control various security events. Most often, these systems
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.
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
Number, types and names of accessed files
Types of logon and
Security policy changes (events such as the creation of a new user or user
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
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
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
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.
Fig. 6.19. Components of the host-level intrusion detection system
Naturally, each intrusion detection system has specific advantages and drawbacks.
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
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
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
Systems of this class are capable of detecting attacks that can not be detected by network-level tools (for example, attacks originating from the
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
Although intrusion detection at the system level does not allow for true real-time
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