Specifying the Rules for Classical IDSs | Protect Your Information with Intrusion Detection (Power)

As previously mentioned, network-level IDSs only operate with network traffic. When creating the rules for systems of this class, it is possible to use both internal and external information. Internal sources include the complete contents of the network packet, i.e.:

Source and destination addresses
Source and destination ports
Packet length
Connection state
Data field
Header flags (TCP protocol)

External sources use information, which is external in relation to network packets. A more detailed description of these information sources can be found in Chapter 4.

There are several ways to customize the templates of attacks to be detected. By making all signatures available — or nearly all, if there are some which it is certain will never be needed — and monitoring from the console, it is possible to determine which signatures are detected in the network, which events are important and which are not. After repeating this procedure within different segments of the network, it will be possible to create customized templates for sensors located at different points in the network. However, in practice, this approach ignores the possibility of missing some events when studying network traffic.

The second method comprises several steps:

A list of protocols, ports and addresses within the network segment should be created, based on the network map. (This is why the creation of a network map is so important.) If the IDS has to protect the network segment that is connected to public networks (such as the Internet), and the network is protected by a firewall, then the list used by the firewall can be used for the IDS. It is not advisable, however, to rely on that list completely; an additional check will be useful in any case.
A list of operating systems and software used within the protected network should be drawn up, again based on the network map. This list must include all installed updates (including service packs, hotfixes, and patches). Without this, the IDS will attempt to look for attacks that can not cause any damage. A typical example is the WinNuke attack, or Windows Out of Band, which can cause the failure of a host running Windows NT or Windows 95. However, this attack only presents a threat to hosts without the OOB-FIX installed on Microsoft Service Pack 2 or 3; in all other cases it is absolutely harmless. If this update is installed on hosts within the protected network segment, and the list that has been drawn up does not mention it, the IDS will waste resources searching for the appropriate signature within network traffic. If such attacks are numerous, the system performance may drop dramatically.
The collected information should be placed into a table, which later will be made into the rules for the IDS.
The IDS database must include only those signatures that correspond to the created table and to the list of signatures detected by the IDS.
If necessary, you can create custom signatures that are temporarily lacking in the database.
If necessary, each signature's properties (priority, threshold values) can be changed, and various types of responses can be enabled.

When customizing attack signatures, you should make sure that both the signatures and the rules that use them are based on a numeric representation of the sender's and the recipient's addresses, rather than on symbolic ones. Otherwise, if the DNS or WINS server is configured incorrectly or caused to fail by an intruder, the IDS will identify the attack source or target incorrectly. In this case, although a numeric representation of addresses is not user-friendly, it is more reliable and able to overcome most potential problems. An ideal approach is to use a symbolic representation when configuring the system — which also simplifies the configuration procedure — and then to translate this into numeric form. This principle is implemented in Check Point Firewall-1, which provides the ability to create so-called network objects and assign them intuitive, user-friendly names. For example, it is easier to memorize a name such as Oracle_Finance_2Floor than 192.168.1.1. The RealSecure Network Sensor is based on the same principle (Fig. 11.7).

click to expand
Fig. 11.7. Implementation of mapping numeric and symbolic names

The RealSecure SiteProtector system provides the broadest possibilities, allowing different methods of specifying network objects' names, from IP address and custom, user-defined names to NetBIOS and DNS names (Fig. 11.8).

click to expand
Fig. 11.8. Mapping NetBIOS host names

All of the rules and signatures available to the IDS should not be enabled in alert mode, as this might have a negative impact on performance, as might the number of user-defined filters. Because of this, a preliminary stage — — identifying all the protocols and operating systems in use in the protected segment — is necessary. In addition, a large number of rules complicates the IDS operation, and increases the probability of configuration errors.

From this point of view, the NetProwler system employs one of the most interesting mechanisms. This mechanism, intended to simplify the process of IDS configuration, carries out a preliminary scan of the hosts within the protected segment, in order to identify the operating systems running on those hosts (Fig. 11.9). After this, the IDS automatically initiates detection of those attacks that might be potentially dangerous for those operating systems. This approach is somewhat risky, however, because if the operating systems are incorrectly identified, the IDS will enable the wrong rules, and consequently, will detect the wrong attacks. Some potentially dangerous attacks may also be missed. Unfortunately, it is impossible to change the list of operating systems detected by the built-in scanner if some operating systems are identified incorrectly. If the developers eliminate this shortcoming, the mechanism may prove to be indispensable.

click to expand
Fig. 11.9. Implementation of the preliminary scanning mechanism

The same principles that apply to network-level systems apply to host-level IDSs, with the exception of the information needed to determine the rules. Host-level systems operate with concepts such as "user," "application," etc. The rules should be documented after being determined, in order to be able to restore the operating settings as soon as possible when necessary.

The management console may need to be customized in the same way as the sensors. For example, custom filters may be required to prevent the console from displaying all events related to ARP activities. (There may be thousands of such events per day.) These filters differ from the sensor's filters in that they do not prevent the system from registering specific events but rather, simply do not display such events on the console. These filters are only applicable to the console on which they are created, providing flexible management capabilities that enable control over the IDS in a large distributed network.