In the previous article I used a “construction industry” metaphor to try and define a firewall and its purpose. Once a building has been constructed with firewalls appropriately located, it is then time to install a monitoring system. This system would have its smoke detectors, video cameras, motion sensors etc. In the building industry scenario each component is designed to perform tasks, in intrusion detection, however, the components are general-purpose components and may vary in terms of the processing of data that they collect. There are event correlation mechanisms and attack signature databases in the heart of each IDS. These components are also used to distinguish IDSes from network monitors. The event correlation mechanisms are either arranged as a filter that works by matching packet contents with known attack patterns, or operate in a somewhat more sophisticated “intelligent” manner, detecting network-level abnormalities and abuse. This is nearly always a utility or sensor that operates in promiscuous mode. This mode name implies that the network card “listens” to all packets being sent (this is important) in so-called collision domain. Why nearly always? This means that this group of packets does not include audit file processing systems that are associated with their work, that reside e.g. on servers. When deploying either distributed IDS devices or centralized IDS sensors, attention should be paid to follow the same guidelines as those used by experts who are responsible for installing sensors in various parts of a building – i.e. being guided by common sense and a well-thought out and balanced security policy. The latter will decide what to monitor and where.
Prior to attempting to consider a suitable location for distributed IDS engines, the first decision that must be made is how to configure the computer to accommodate the IDS application. In the first place, the workstation one wishes to install an IDS on, should be as hidden as possible, to make it difficult for a potential intruder to trace. The trick is that one should configure the system so that it will not respond to any incoming packets. In addition, one should further protect the system by adding a firewall to the computer it is located on. An IDS can operate properly provided that it resides in a collision domain, which means that all devices within such a domain should have the same address, called broadcast and must not be isolated by switches (certain switches have a separate monitoring part). Figures 1 and 2 illustrate correct and incorrect IDS installations respectively. In Fig. 1, the IDS functions properly, since it is within the same domain as the firewall, in Fig.2, instead, the IDS and the firewall are located in different collision domains. IDS implementation will surely fail if a proper location for it is not provided for, within an IT system. This is particularly important where large private networks are concerned, especially if they are composed of many subnets that, in turn, may be segmented by switches. It may well be that for monitoring large networks, dozens (or hundreds) of extra workstations are required for the sole purpose of collecting information on specific points over the system. An extra problem may also be associated with the fact that someone will have to monitor the functioning of such systems, which means that the network administrator will have to dedicate many hours a day just walking from one workstation to another.
Fig. 1 An IDS properly located on a network
Fig. 2 No such IDS location over a network
In order to avoid this, designers started to develop systems with arrayed sensors. Such sensors can be installed throughout a private network on servers or client workstations to collect and redirect information to a selected central location where the information is processed in accordance with pre-established rules. There is, however, a catch. A potential intruder who either manages to get inside a private network, or who will attack from inside, may deduct, on seeing a large number of “checking” packets directed toward a single address, that this network hosts an IDS. It may also detect the IDS’ location and freeze its activity for the duration of the incident, exploiting, for example, a DoS attack. It is therefore considerably important to provide security-critical points with a traditional solution i.e. to tie a separate undetectable workstation having a local IDS into the network.
As its name implies, an IDS excels at detecting break in events, so it is complimentary to firewalls to possibly reconfigure the firewall rules.
Fig. 3 An IDS – firewall interaction
In the introductory part of this article I mentioned that, on one hand, IDSes and their sensors operate in promiscuous mode and on the other hand, the IDS must be invisible. How can one get around this problem, if the market offers tools to detect sniffers i.e. workstations operating promiscuously? This is not a threat for a hidden IDS, since this is undetectable. Sniffer detection programs use similar “statistical” techniques i.e. they send appropriately prepared packets and analyze responses. This looks somewhat like scanning a workstation. If a station does not respond, its presence cannot be revealed. It should also be noted, that sniffer detection mechanisms are unreliable and it therefore becomes merely probable that a station captures all packets within a local network. The examples above clearly indicate that an effective IDS configuration and application will rely upon the network administrator’s experience and initiative. Under certain circumstances an IDS is a less expensive solution, and may replace a firewall, particularly in the light of the previous notes. It is not always necessary to have a separate computer running a utility, but a single monitoring station using either an array of sensors deployed over various locations within the system, or a station monitoring server audit log contents. Such an IDS approach allows monitoring or other logging of all user activity including attempts to gain access to the assets.
Under these circumstances, it is possible to replace a firewall with an IDS. This is because, frequently, in addition to appropriately reestablished procedures of security policy and joint operation with an owner of a private network, the system is addressed toward enforcing proper user attitudes within a private network, and its function is also as an administrative control over insider users.
An example of an IDS layout.
All IDS sensors redirect packets toward a station called an IDS. In fact, the IDS-1 doubles the activities of the basic station. Such a solution has been conversely adopted to ensure that even if the “official” IDS is detected and disabled, another IDS could detect and repel an attack, either originating from outside a private network or from an internal intrusion. This would disable the possibility of exporting sensitive data outside the network.
Fig. 4 An IDS inside a network
Fig. 5 detecting an intruder by changing signal level in the transmission medium
According to recent statistics, most cases of breaking into networks are associated with private networks, where penetrated IT assets are located. This is mainly because companies need to trust their employees and willingly open their network for internal use believing that productive employees need to be trusted and the system is absolutely secure against potential internal threats. The end result is that often, actions towards the creation of an adequate security policy to cover the company’s internal IT assets and also to establish consistent access rules, are neglected. Dishonest employees often believe in their impunity. Therefore, one would have to consider and use additional legal and administrative activities. For example, one must inform employees about the fact that each of their IT system-related activities will be monitored and they may suffer the consequences if caught breaching these conditions. Moreover, clear rules are required to establish who, why and when may have access but using sufficiently flexible rules to avoid re-establishing security policy rules for migrating employees. A good approach would be to define workgroups, followed by creation of profiles containing information about the assets to be freely accessed by a specific group and consequently, by each member. Any departure from a profile may trigger an alert being sent to the administrator and activate appropriate explanatory administrative proceedings to verify if any breach has occurred.
When selecting an IDS and its working location another aspect must be considered. Not all IDS operate in real time. This apparently trivial fact becomes essential, however, if an IDS is inter-operating with a firewall (by reconfiguring its rules) and cannot operate in real time, then its use is pointless. Therefore, an additional element must be considered when planning an IDS-based IT system: the response time of a monitoring device. I would not like to suggest any ready-to-use solutions – for which IDSes must operate in real time and which must not, since no one solution exists and the security policy needs to be decided upon.
Monitoring the behavior of devices across a network is the ultimate element of a network security policy, and is not necessarily associated with a typical IDS. Accessing a network from an unknown workstation can often be a signal that either an employee from another company branch has logged on, or an intruder has managed to get inside a private network. Also irregularities in the function of network devices (or worse, network segments) might represent an intrusion attempt or a successful intrusion.
- Chris Hare, Karanjit Sijan, Internet Firewalls and Network Security, New Riders Publishing, Indianapolis 1996.
- Micki Krause, Harold F. Tipton, Handbook of Information Security Management, CRC Press LLC, 1997.
- Matthew Strebe, Charles Perkins, Firewalls sciany ogniowe (in Polish), Mikom, Warszawa 2000.
- Merike Kaeo, Tworzenie bezpiecznych sieci (in Polish), Mikom, Warszawa 2000.
- Edward Amoroso, Wykrywanie Intruzow (in Polish), Read Me, Warszawa 1999.