Strengthening IDS Security

---

Despite the fact that an IDS is itself a security tool, it still needs protection against hacker attacks.

Backing up the IDS

The parallel use of two IDSs is quite often more efficient from a security point of view, but is significantly more expensive. (This is applicable only to network-level IDSs.) The advantages of such a solution are listed below.

• Controlling network traffic with two IDSs increases the probability of attack detection. Furthermore, combining two IDSs for parallel traffic processing increases the probability of detecting a vulnerability. Products from different manufacturers can use different approaches to detect the same vulnerability: It is quite possible that one will detect a vulnerability, while the other one will miss it. David Le Blanc, one of the leading developers of the Internet Scanner system, who has recently moved to Microsoft, provides the following illustrative analogy: "If you ask me if my friend is at home, I will try to call him. If he does not answer, I will call you and say that he is not at home. However, if you then go to visit him, knock on the door, and he opens it, do not call me a liar just because the plan that I suggested did not work. Perhaps I was not right, or it was necessary to use other methods, but I tried to do what I considered to be right." The same is also applicable to IDSs. For example, the differences between such systems as CyberCop Scanner and Internet Scanner lie in the fact that Network Associates' developers never add a check to their product if they are not sure that the check reliably detects a vulnerability. On the other hand, Internet Security Systems' developers add the check to their database even if it detects vulnerabilities with a certain probability of error. Later, after releasing a new version, they return to the added checks, improve them, add new mechanisms for detecting the same vulnerability, and so on. It is difficult to say for certain which approach is better: It is important to know definitively that a specific vulnerability is not present on the analyzed host, but on the other hand, if even the smallest chance of detecting a specific vulnerability exists, it would be wise to take that chance. Cisco has suggested a combined approach, implemented in its Secure Scanner, which works at the network level. This subdivides all vulnerabilities into the following two classes:

  • Potential vulnerabilities. A potential vulnerability may exist in the system, but active probing checks (described in Chapter 6) will not confirm this. Checks for potential vulnerabilities are performed via header analysis, and by "nudging." Nudging is used for services that do not return headers, but react to simple commands, such as the HEAD command used to obtain the HTTP server version. After this information is obtained, Secure Scanner enables a special mechanism, known as a rules engine, which implements a set of rules that determine whether or not the potential vulnerability really exists, thus clarifying, which potential vulnerabilities actually exist in the system, and which ones require confirmation.

  • Confirmed vulnerabilities, which have had their existence confirmed after being detected on the analyzed host by means of header analysis.

  However, this product has not been supplied to clients since June 15, 2002. (http://www.cisco.com/warp/public/cc/pd/sqsw/nesn/prodlit/1736_pp.htm).

• If one of the systems is compromised, the second one will continue to operate.

• Combining IDSs from different vendors improves the overall reliability of the whole security infrastructure, and prevents an intruder who has exploited the vulnerabilities of the first IDS from compromising the other one.

Protecting against Unauthorized Access

To prevent intruders from getting unauthorized access to an IDS host and compromising it, the system's sensors and console must be placed in a physically secure location. For example, network sensors can be mounted in racks with other network equipment (routers, switches, etc.).

After installing a network sensor, it is best to disconnect unnecessary peripherals — monitor, keyboard, floppy-disk drive, CD-ROM drive, etc. — from it. In this case, even if intruders manage to penetrate the physically secure room where the IDS resides, they will not be able to introduce unauthorized modifications into its configuration. Authorized updates of the system software and signature database will have to be performed remotely (as in, for example, RealSecure SiteProtector and Cisco IDS 4200).

IDS Users

To ensure discretionary access control to the IDS, the operating system under which the IDS operates will have to be configured as described earlier in this chapter. First, the list of users granted access to the system must be limited, so that only specific individuals can access it. This will prevent unauthorized IDSs configuration, and reduce the risk of its failure. At least the following specialists must have access to the IDS:

• The IDS administrator, or operator, responsible for the configuration and monitoring of the controlled resources

• The OS administrator, responsible for its operation, software updates and so on

In most organizations, these employees work in different departments: the Information Security (IS) and Information Technology (IT) departments, respectively. In large companies with a hierarchical management system, the administration of the IDS can be delegated to more than two specialists. Consider, for example, a situation in which an administrator performs sensor configuration, an operator is responsible for network monitoring, while a third specialist manages attack response. (Usually, this specialist belongs to the incident-response team.) System operators have no right to change the IDS' configuration; should this be required, one employee must perform the functions included in both user categories.

If the IDS takes the form of a combination of software and hardware with built-in routing functions (e.g., Cisco's Secure Integrated Software or RealSecure for Nokia), then a network administrator from telecommunications department must manage the appliance. A practice that is currently widely adopted is outsourcing, in which all security management is delegated to third-party firms. In this case, personnel from the third-party firm perform all functions related to controlling and managing the IDS and the operating system.

Access Rights to the IDS

If the IDS is controlled remotely and the reliability of communications between its components — for example, between a sensor and the console — needs improving, strict authentication mechanisms and cryptographic protection should be used. These methods are needed even if you access the IDS from internal network.

It is not a good idea to rely only on controlling access from specific addresses. First, control using dynamic address assignment (for example, DHCP) can not be guaranteed; second, address spoofing can allow an intruder to mimic an authorized user. A good way of getting around this problem is UAM (User to Address Mapping), developed and implemented by Check Point. Using Check Point's OPSEC SDK interface, it is possible to integrate UAM into an IDS. UAM is quite simple, and allows efficient user authentication in networks that use dynamic address assignment. Authentication includes the following steps:

1. When the computer starts up, it contacts the DHCP server, which assigns it an unused IP address. Simultaneously, the DHCP server contacts the UAM server and sends it information on the IP address that it has just assigned, along with the corresponding MAC address.

2. When the user logs on to the network, the user name and the host on which the user logged onto are sent to the UAM server.

3. The UAM server compares the data received at the first and the second steps and, as a result, gets accurate information about each user's address.

When providing access to various network resources, the security system operates with user names rather than with IP addresses.

Security Policy

The security policy — in particular, the policy on the intrusion detection infrastructure — must take the following aspects into account:

• The intrusion detection software's checksum (hash function)

• List of users with IDS access

• Security measures implemented to protect the IDS

• Schedule of backup operations for intrusion detection components

All IDS-related actions must be listed in appropriate documents, which taken together, comprise the organization's security policy. (This topic was covered in detail in Chapter 7.) When drawing up these documents, the following must be taken into account:

• Controlled resources (analyzed hosts)

• Most probable attacks

• Objects — protocols, addresses, ports, files, etc. — accessible from outside (for each protected resource)

• Subjects — users, applications, etc. — using the protected resources

• Who will manage the IDS, and how

• IDS rules and templates

Stealth Mode Implementation

Most IDSs can work with two network interfaces. The unprotected interface is used for traffic control, while the protected interface is used for response implementation and communication with the management console. This mode of IDS operation is known as stealth mode.

To avoid creating additional firewall rules for communication between the sensors and the console, the connection scheme in Fig. 8.4 is usually implemented. Sometimes, however, this is impossible, and in this case, additional firewall rules have to be created. To avoid introducing additional vulnerabilities into the network segment protected by the firewall, the firewall rules should be customized. There are usually two such rules (Fig. 11.14) — one for traffic transmitted from the IDS sensor to the console and one for traffic from the console to the sensor.

Fig. 11.14. Firewall configuration for IDS support

Automation

As mentioned in Chapter 8, automation is one of the important criteria that should be taken into account when selecting an IDS. As a rule, mechanisms built into the IDS provide an easy way of implementing scheduled system startups or report generation procedures. However, it is quite difficult to introduce intelligent automation functions using only GUI tools. The ideal solution for this situation is provided by the built-in scripting capabilities available both in Windows and Unix.

Below is a sample script that can be used for automating the process of security scanning of the specified hosts and generating a report after finishing the task (Listing 11.1). This example uses Internet Scanner 6.1, but such a script can be created for any other security scanner supporting command line mode [ISS9-00].

Listing 11.1. Automation of the Security Scanning Process and Report Creation (in Internet Scanner for Windows NT)

 echo off echo Scanning specified hosts and generating a report echo echo Changing to the Internet Scanner working directory c: cd c:\program files\iss\scanner6 echo Starting the scanning process from the command line echo -k - system activation key preventing echo unauthorized usage echo -p - template describing the checks to be performed echo -f - file containing the list of host to be scanned Iss_WinNT.exe -k "iss.key" -p "L3 Finance Server on Unix.Policy" -f ÄU finance.hst echo Starting the process of generating a report echo based on the collected information echo -X — generating report in HTML format echo and saving it in N:\ForSendmail\Out\My echo Reports\TechVuln\TechVulnSeverity echo techvuln.sev — generating report for technical specialists echo with sorting the detected vulnerabilities by the level of risk Iss_WinNT.exe -X techvuln.sev="N:\ForSendmail\Out\ ÄU My Reports\TechVuln\TechVulnSeverity" echo End job 

Practically all IDS operating tasks — except for analyzing the scanning results and editing the template used — can be combined with the capabilities provided by Windows NT Scheduler (AT). Scheduled starting of the batch file can easily be implemented using the AT (Windows NT) or CRON (Unix) utilities, as shown in Listing 11.2.

Listing 11.2. Using the AT Scheduler (Windows NT)

 at 16:10 /every:M,T,W,Th,F "c:\nsb-finance.bat" 

Combining Internet Scanner and RealSecure SiteProtector makes it possible to replace Listings 11.1 and 11.2 with a single window (Fig. 11.15).

Fig. 11.15. Scheduled start of Internet Scanner with a predefined template

Possible Problems

Deploying and customizing an IDS in a corporate network is both very important and very difficult. The efficiency of the whole intrusion detection infrastructure depends on the correct solution. An administrator who notices no trace of hacker activity may either feel a false sense of security or accuse the vendor of selling a substandard product. An absence of any events on the IDS console may be due to the following:

• The sensor is configured incorrectly.

• The sensor's network interface responsible for network monitoring or the interface responsible for transmission of events to the management console is malfunctioning. (The console's network interface can also fail, but this is quite rare.)

• The network cable connecting the sensor or the console to the network equipment is damaged.

• The sensor or console is connected to a malfunctioning port of the switch, concentrator, splitter, or balancer.

• The sensor has been placed in an incorrect location and, consequently, can not detect any events.

• There is no suspicious activity. (This is purely hypothetical — I have never seen such a network.)

The second, third, and fourth causes are easily detected and eliminated. It is a good idea to use network equipment from well-known firms — such as 3Com, Intel, etc. — to avoid such problems. Network adapters and ports should be backed up, in order to provide continuity of the IDS' operation, even if a network component fails.

The first and fifth problems are the most common. To solve the first problem, the IDS will need to be reconfigured and customized. These topics were covered earlier in this chapter. Therefore, let's examine how to select locations for IDS components correctly. (Typical locations were covered in Chapter 10.) Practical experience shows that there are several typical errors that are made when deploying an IDS' network components.

The first error is the most common — incorrect selection of the sensor location. This is best illustrated by an analogy to traffic. For example, upon looking out of the window one morning, you see no cars on the road and decide that it will be possible to get to the office quickly and without problems. However, upon driving one block further down the road, you run into heavy traffic, and as a result, are late in getting to the office. Arriving late was a result of not anticipating the possibility of traffic jams, looking at the wrong location, and drawing the wrong conclusion. It is possible to make the same mistake with an IDS. Problems usually arise at the physical level rather than at the logical layer. (As previously noted, there are only seven logical variations.)

The second common error relates to data filtering, which is often recommended in order to improve the performance of the components responsible for detection of attacks and vulnerabilities, or to decrease the vast amount of data displayed on the management console. However, any mechanism must be used carefully. Sometimes, a seemingly insignificant event represents a missing link in the process of identifying unauthorized activity. If this event is neglected, the IDS filters it out, thus preventing the entire pattern from being analyzed.

The third important problem is a lack of understanding of network operations. When purchasing an IDS, most users erroneously think that it will solve all their problems. This is partially true, but in order to solve all the problems, the IDS must be "taught." This entails an understanding of network internal processes and a list of signatures of attacks and vulnerabilities based on the network map. Network map creation is especially important, since the IDS will only work efficiently — and justify its cost — provided that the map is properly created and maintained.

Practical example 

A client contacted me and accused us of selling him a substandard product. The client declared that the purchased IDS could not detect attacks on his web server, which had suffered damage as a result. After investigation, it became obvious that the client — who did not want to pay for technical support — had installed the IDS independently, and incorrectly, by enabling detection of HTTP attacks and deciding that this was enough. However, the web server was using port 8080, rather than the default port 80. Naturally, this was not taken into account when configuring the sensor. As a result, the sensor controlled HTTP traffic on port 80, and did not suspect that the web server was using port 8080. Fortunately, in this case, we persuaded the client to purchase a training course and implement an event-monitoring and incident response system.

It is worth mentioning once again that IDSs tend to be seen as being at fault for all network problems (such as reduction in performance, unexpected termination connection, loss of packets, failed identification, etc.). This becomes a particularly sore point when there are conflicts between the IT and IS departments. Sometimes, network administrators simply do not want to admit their errors, and therefore try to place the blame on some device that is outside their control, and whose operation they do not understand.

To resolve all possible conflicts in a businesslike manner, it is necessary to have a sound understanding of the working principles and specific features of the chosen IDS, and to know of all possible problems and how to solve them. This will help normalize relations with the IT department in case of conflicts.

---