intrusion-detection systems

Guaranteeing the Safety of a Network
Beyond Using a Firewall

by Dario Forte
<dario.forte@computer.org>

Dario Forte is an Italian system administrator. He is CCSE and CCSA CheckPoint Certified and is a USENIX-SAGE-CSI individual member. In Italy he moderated the independent forum of Windows NT Security and CheckPoint Firewall-1.



The increase in the number of links with the Internet has generated a proportional increase in the number of attacks brought against them. Implementing systems capable of detecting these attacks (possibly without false alarms, which in some cases is an impossible dream), and also giving the system administrator the opportunity to intervene immediately, is a specific area of networking research: intrusion detection. This article discusses how and why intrusion-detection systems (IDSs) should be used to record and report possible violations of information systems linked to the Internet.

IDSs can be considered an extension of network analyzers. Network analyzers are devices that monitor and analyze the network traffic in realtime, for the purpose of identifying any arbitrary violations of general policy established by the network manager. The differences among them concern the methods used for analyzing and reporting, and the type of traffic that can be identified. The task of an IDS is to record and report any violations of information systems (even in the form of attempts). They are not permanent devices. In other words, they do not constitute a replacement for a firewall, a proxy, or similar devices. IDSs are installed in addition to firewalls and carry out a check at an internal level, on the customer side of the network.

Generally speaking, IDSs are grouped into two families: the first performs mainly auditing functions, carrying out continuous calls to the hosts linked to the system. The second works independently, observing the traffic on the networks directly (and passively), carrying out "usual" packet filtering. Some commercial products combine the two methods.

Many IDSs feature automatic network-attack recognition and response-system type. The IDSs are installed and made to "run" throughout the network or on parts of it where there is a need to preserve critical information.

Monitoring of data traffic generally takes place on the TCP/IP stream passing through Ethernet-based infrastructures. (Some manufacturers are working on supports for different layouts.) Thus, the IDS combines the functions of a simple network analyzer with that of recognizing attacks. This is generally achieved by means of a signature check, rather like programs that detect viruses. The system contains a database of attacks, which functions as a basis of comparison with the traffic analyzed. When an attack is recognized, the IDS can stop the stream of data immediately, thereby preventing the attack from causing damage to the network.

An IDS that does its job properly must also enable recording of the date, source, target, and type of the attack, and of the activity undertaken. As for the source of the attack, the IDS must implement antispoofing functions. This turns out to be very important, primarily for preventing some DOS (denial-of-service) attacks.

The basic principle of operation of IDSs is prompt intervention. In practice, once the attempt to intrude has been discovered, the system must warn the person in charge of corporate security, who must be able to implement the necessary countermeasures, even from a remote location. It is possible for the system itself to give a warning of the incoming attack, for example by means of an SMS message (texts on GSM) or a warning sent to a pager for the security administrator.

As to required computing capacity (ascertainable in terms of the slowdown it causes in the performance of the whole network), an IDS must be able to facilitate maximum scanning speed and therefore present minimum requirements in terms of latency. Although this is guaranteed by most manufacturers, discussions among administrators on this issue are focused mainly on this aspect.

From the point of view of development philosophy, the most widespread analysis model used by the IDSs currently being circulated is called CIDF (Common Intrusion Detection Framework). This model consists of splitting up the IDS into a series of components, called boxes, which range from the management of suspicious occurrences, to the countermeasures adopted, to safe storage of the logs generated. These boxes, which are generally preceded by a letter indicating their function, are of fundamental importance also for legal purposes; regulations concerning computer crimes may require the log files as proof of illegal access.

Why Get an IDS?

While most attacks come from outside, badly administered and controlled internal resources can be a source of large-scale problems. That is the main reason why, at times, installing a firewall is not sufficient to limit the damages. In addition, a firewall can crash or, worse still, it might have been improperly configured. In that case, it is important to have a rearguard product able to interact with the perimeter of the system.

Computing Demands and Band Requirements

It must be possible to control the central unit and management from dedicated machines. For this purpose, for example, RealSecure Engine requires a minimum 200MHz Pentium, 32MB of RAM, at least 199MB of disk space for the log files and databases, 10MB for the software, and an Ethernet NIC operating in promiscuous mode. A remote management console, on the other hand, requires, for an IDS working on Intel systems, a 200MHz Pentium, 32MB of RAM, and 100 MB of disk space for each scanning engine it manages.

Arguments about the Effectiveness of IDSs

To what extent can an IDS influence the performance of a network? How effective can it really be? Management wonders most about such issues. Two well-known American security experts, Thomas T. Pracek and Timothy N. Newsham, have recently triggered a discussion about the true effectiveness of IDSs. According to these two experts, these types of device have many "weak points." However, most of these Achilles' heels reside in the analysis models.

In considering IDSs based on the signature-analysis method, also known as misuse detection, Pracek and Newsham have raised the objection that often the policies implemented are too stiff and are linked to mere signature matching; that is, in practice they are based excessively on passive monitoring. Errors made during configuration can lead to a burst of false alarms, particularly when specific services are used. To this end, the two experts, who state that they are more in favor of the active-proxy monitoring type of setup, feel that maximum granularity of the IDSs based on this method is required. As they have pointed out, highlighting the possible leaks in the analysis and operational model of an IDS does not label these devices as irreparably unsafe -- not at all. Instead, it points to a series of improvements to make to products in order to make these systems as safe as possible.

Conclusions

The analysts feel that the current status of IDS technology can be compared to that of firewalls a few years ago. Some of them compare IDSs with the first virus-detection programs, with all the problems they used to have. Perhaps, they stress, the solutions available on the market are still "immature." It should be considered, however, that products such as those surveyed in the sidebar will have something authoritative to say within a short time, or might even become reference points. Apart from anything else, I feel that the optimization process of these systems will be accelerated to an extent that is directly proportional to the commitment the international academic community will put into studying the problems involved.

A Survey of the Best-known IDS Products

CyberCop

CyberCop, originally produced by Network General, is an IDS recently released by Network Associates <www.nai.com>, an organization that is constantly at work acquiring technologies in the field of security. After their acquisition of Network General's product, Nai made some changes to CyberCop. (It must be remembered that the auditing/scanning software now called CyberCop Scanner -- also known as Ballista -- is different from the totally software-based product we are discussing here.)

Installing CyberCop does not require the network to be reconfigured or plug-ins to be added. Like other IDSs, CyberCop builds a layer of additional software which works by monitoring the ports and services enabled by the firewall.

The first version of CyberCop, announced in 1997, consists of two elements, the management server and the sensors. The latter are positioned at strategic points on the network and communicate any suspicious events to the management server. These events are classed according to a set of 170 different attacks.

If an attempt is made to access the network, the product, currently called CyberCop Server, informs the security administrator in real time, providing a detailed report of the event. The designers feel that within a few minutes CyberCop can give the input the security manager needs to take the necessary steps to resolve the problem. Management of the configuration of CyberCop, as well as the receiving and transmitting of the intrusion detection reports, can take place from a remote location using an encrypted link, which is activated only after recognition of the parties.

Of course, all the traffic monitored is stored in log files which can be consulted at any time by the security manager, both in order to trace the attacks and in order to take subsequent legal action. Configuration and positioning of the sensors are simplified by a preconfigured installation set, which makes operation easier and enables leaks to be limited.

Bro

Bro is a realtime IDS devised and developed by Vern Paxson and other experts at the Network Research Group of the Lawrence Berkeley National Laboratory. The source code of Bro is freely available, and the principle on which it is based is decidedly in an academic mold. With its spartan interface, indicating that greater attention has been paid to substance than to appearance, Bro bases its operational capacity on its scanning speed, realtime notification of violations, and a clear separation between the engine, the policy implemented, and the extensibility options.

Bro is partitioned into two components: the "event engine," which translates the traffic intercepted at kernel level into high-level events, and the "policy script interpreter," which defines the policy implemented, always by means of specific instructions written in a proprietary language. In this way, administrators can use the granularity of this IDS to adapt the system to their own requirements. The services monitored on a priority basis by Bro are Finger, FTP, and Telnet. In addition, the Portmapper function of this solution makes it possible to check the activity of the single ports as well.

So far we could say that there is nothing new. All network analyzers (or net sniffers, if you prefer), and therefore all IDSs (which can be considered extensions of them) are normally equipped with these features. The designers of Bro, however, state that during the analysis period they studied in depth the typology of both standard attacks and those that can be brought to bear on the screen in the narrowest sense, and that they were able to identify and describe attacks not referred to in the literature. Again, during the prebuilding phase the designers acquired substantial experience with systems based on offline analysis of tcpdump attempts. All this has given rise to a melting pot of reference information for subsequent implementation of the modules of this IDS.

One of the main objectives of Bro is to ensure traffic speed. In order to do this, Bro monitors DMZ links. These are usually FDDI, so that the monitor must be able to inspect the traffic, which is very bulky in itself, at speeds in excess of 100 Mbps.

Bro's separation of the engine from the rest of the modules, including the script policy interpreter, is essential to streamline the monitoring operations as much as possible (which means no degradation of network performance) and to distinguish the data on the basis of the services to which they belong. All this has been implemented in order to give Bro maximum flexibility. (Flexibility is more or less the reason why the manufacturers of virus-detection programs are revolutionizing the way they are developed. Attacks are becoming increasingly numerous and diversified, and they depend more than ever before on flaws in individual operating systems and their layouts, so they are increasingly well-targeted and unforeseeable. In this context, modularity and extensibility are strategic and can only be achieved if the architecture used is as open as possible.)

More information about Bro may be found at <http://nrg.ee.lbl.gov/nrg/papers.html>.

ISS RealSecure

ISS RealSecure for Windows NT by Internet Security Systems <www.iss.net> is one of the best known and best-selling IDSs on the market. (Indeed, ISS and CheckPoint have joined in partnership to bundle Firewall-1 and RealSecure together.) The basic operating principle is common to the other IDSs: The traffic passing through is monitored, and the activities are compared with the pattern with which it is outfitted. In the event that they match up, an alert is activated and possible automatic countermeasures are implemented.

Suspicious activities, documented with information concerning the chronology of the attack, its source, and destination -- plus other data to be selected -- can be managed extremely dynamically. Monitoring of the traffic consists above all of packet filtering. It is possible to configure RealSecure to check traffic in all its meanings: TCP, UDP, ICMP, source and destination ports, etc. It is also possible to check the traffic on the basis of the services used because the pattern of the attacks follows this schematic distribution.

The designers of ISS used this philosophy: Starting from the assumption that most attacks come from inside, the administrator needs a product able to check all the traffic (not only the traffic permitted by the perimeter security system). In addition, a check of the activity permitted by the firewall is also indispensable, since even an authorized user can "penetrate" a system.

The security policy set up by RealSecure therefore has the objective of checking and identifying beforehand:

• who can access the system and who cannot
• which protocols and/or services are permitted
• which new hosts are added to the network and what rights they have to "dialogue" with the rest of the infrastructure.

Starting from these assumptions, a series of features in Real Secure are aimed at making the work of the administrator as easy as possible and the system as flexible as possible.

NID

NID 2.x is an intrusion-detection suite available freely on the Web <http://ciac.llnl.gov/ctsc/nid/> for various operating systems, including LINUX, but its use is limited, for the moment, to government organizations.

NID works in a manner similar to Bro. It can monitor speeds and layouts, including FDDI and, of course, all IP traffic. NID has these features:

• The software is installed on a dedicated machine.
• A security domain is formed from the management console. In turn, this includes a series of hosts at the discretion of the operator.
• NID starts to audit the network traffic using three fundamental methods.
• Attack-signature recognition
• Vulnerability risk model, i.e., general safety parameters to be observed
• Anomaly detection, i.e., recognition of abnormal behavior inside the network and immediate notification of the system administrator

In NID, too, the analysis model and its operational expression are of the mainly "passive" type; traffic is audited and a consequent comparison with the attack pattern at disposal is made. If a match is found, an alarm is sent to the security administrator.

The software permits sessions of specific UNIX tasks, such as cron, to be run.