9.3 Host-Based versus Network-Based IDSs

9.3 Host-Based versus Network-Based IDSs

In most cases, an IDS is actually a combination of products. A sensor is the part that actually sniffs traffic on a LAN segment. Sensors will typically send their data to a central IDS database device. Thus, a single database is able to monitor a number of sensors. On the IDS database server or as part of a separate host, the IDS may also include a console management station. The ratio of database/console management to sensors typically runs in the range of 10:1, or even as high as 20:1. This means that for anything less than a dozen IDS sensor segments, a single IDS database/management station will suffice.

9.3.1 Host-Based IDS

The first major choice that affects IDS effectiveness is the decision to use host-based or network-based IDSs. As the name implies, a host-based IDS is a system that resides on a network host. Generally, host-based systems only detect attacks directed at that particular host. The advantage of this system is that we can have fairly high confidence in knowing about every detectable attack on that host. Because the volume of traffic to the host is normally a subset of the volume of traffic on the network, we have effectively created a distributed IDS that is more likely to detect attacks due to the lower volume of traffic.

Despite this, the disadvantages of host-based IDSs are many. The first is that the host-based IDS depends on the OS of the host. In heterogeneous network environments, this may mean that several different host-based IDSs are required to cover all the hosts. Depending on how many host-based IDSs are chosen for deployment, host-based IDSs may also present a substantially higher administrative cost. This is especially true when host-based IDSs are placed on all user workstations in a network. Finally, there is the issue of managing the distributed IDS itself. Does the host-based IDS support central logging, or must each host be periodically and individually examined to detect intrusions in a timely manner? In response to these disadvantages, host-based IDSs are typically deployed only on particularly sensitive hosts such as network servers.

9.3.2 Network-Based IDS

Network-based IDSs are devices that operate on a single network segment. Operating in promiscuous mode, these devices record all the traffic they can on any given network segment. This has the advantage that a single network-based IDS can detect attacks for a great many hosts from a single spot. One or two network-based IDSs are also much easier to manage than dozens or hundreds of host-based IDSs.

Similar to the host-based IDS, however, there are a number of negatives associated with network-based IDSs alone. The first is that most networks are switched. For a network-based IDS to operate correctly, it must have access to all network traffic. Many switches, in response to this need, are configurable with port forwarding (also known as port mirroring). Port forwarding is the ability to forward traffic between other ports to a single monitoring port. Not all switches, especially the less-expensive ones, support this feature. Furthermore, even if switches do support port forwarding, they do not always support the ability to monitor both transmit and receive packets from ports.

To explain the problems of port mirroring associated with transmit and receive packets, let us simplify the problem. In Exhibit 1, we have two hosts and a port connecting to a router. We also have a fourth port reserved for mirrored traffic.

Exhibit 1: Using an IDS with Switch Port Mirroring

We decide to mirror the traffic sent to the router. How we can do that depends on the type of switch we are using and its port forwarding capabilities. If the switch is only able to forward received traffic (from the point of the view of the switch), then we are only ever going to see traffic that is sent from the router, and not traffic that the router is receiving from other hosts. Ideally, we would like the port to mirror both transmit and receive traffic — a function found on some but not all switches. This can be overcome by forwarding all received traffic for the VLAN or LAN, but here again, the switch must support the ability to mirror for multiple ports or on a per-VLAN basis.

Even if the switch does support this feature, there is a problem of capacity for both the network-based IDS and the switch itself. Consider the average 100-Mbps switch. Assuming that any five devices are communicating with another five devices, there is the potential for 250 Mbps of traffic being switched. We are using 250 Mbps instead of 500 Mbps, to account for the burst characteristics of packet data and the fact that it is rare to actually find hosts that will transmit information at the full 100 Mbps. Even so, if we have a single network-based IDS using port forwarding from a single 100-Mbps port of the switch, we see that the IDS is only privy to a bit less of the 100 Mbps once layer 2 headers are taken into account. More than half of the data will be unanalyzed.

One way to circumvent the problems that switches introduce into the process of intrusion detection is to avoid them entirely. This does not mean pulling the hubs out of the closet and dusting them off. A device known as a test access point (TAP) can be used to split off the signals from a standard UTP or fiber cable. TAPs have been used for some time — since switches were placed into common service. Originally, they were used to allow network monitoring devices such as protocol analyzers to examine what was happening on a particular network segment. Because an IDS is little more than a glorified network sniffer, the application of TAPs to the IDS arena followed shortly thereafter.

By echoing the transmit pairs in a UTP cable, the TAP would allow a single device to monitor the physical media through the use of two interface cards, as illustrated in Exhibit 2. The primary advantage of TAPs over advanced port mirroring of high-speed switches is that they do not affect the performance of the switch in any way. For all intents and purposes, they are invisible to the network. This lack of visibility also increases their security potential because the IDS itself is likewise removed from the active network traffic. Typically, a TAP is placed between a router and the switch and is able to monitor all traffic forwarded to the router. TAPs can also be placed in other strategic points on the network, such as inline between a server and a switch. To ease the deployment of multiple TAPs in a network, manufacturers offer multi-TAP units that can be rack mounted and support multiple TAPs.

Exhibit 2: Using an IDS with a TAP

While TAPs ease integration with switches, they are not ideal for all installations. As the TAP illustration above indicates, a single TAP will create two output ports, one for each TX (transmit) signal on the physical media. This is a problem because a normal network interface card will assume that there is a single TX signal and the other pair will be reserved for RX (receive) signaling. This then requires the IDS station to have at least two network interfaces for both TX signals from the TAP. As will be discussed later, some IDS devices will operate in a reactive mode, resetting or otherwise blocking suspicious connections on behalf of network hosts. To be able to perform this option, the IDS needs to know enough to associate traffic in a connection with the information it records between the two interfaces. Not all IDSs have this functionality.

As with any technical problem, there is a solution. Along with a TAP, the simplest solution is to create an IDS-specific switch. The two TX ports on the TAP are fed into two ports on the IDS switch. Port mirroring is then configured on the switch itself and all traffic is directed to the port with the IDS sensor attached. As will be discussed in the IDS design section, this arrangement of TAPs, sensors, and a dedicated IDS switch can create IDSs that are quite large and scalable.

Increasing the speeds for network-based IDSs can only increase the problems that network-based IDSs have. Vendors might claim that their products accurately detect attacks at gigabit speeds, but careful attention should be paid to the marketing literature and independent testing should be consulted. More often than not, gigabit detection speeds are only possible in laboratory environments. Real-world detection may be significantly lower at around 300 Mbps or so. The reasons for this wide discrepancy include both overly zealous marketing and the way in which these capacity tests are performed. In the lab, there may be a limited number of connections being monitored on a limited number of ports with maximum-sized packets. This softball testing will allow any product to run close to its maximum theoretical capacity.

It should not be surprising that IDSs in the real world have such a difficult time keeping up with ever-increasing network speeds. Consider that each packet must be captured and then analyzed from attack databases that can include hundreds if not over a thousand attack signatures. Even a firewall would have difficulty operating at high speeds if it was responsible for such a rule set. The actual performance of an IDS is based on a number of factors in the work environment, including the number of active sessions, the size of the packets, and whether the packets are valid to begin with. An IDS examining valid packets has far less work to do than one trying to detect out-of-sequence fragments from five million active connections. In practice, then, gigabit IDS will detect significantly less than the reported 1000 Mbps of data. What that value is will be determined by the conditions of the local network.

To compensate for degraded detection capabilities at higher network speeds, there are several options. All of them in some way relate to distributing the load of the high-speed connections to multiple IDS sensors. For installations that require them, application- or network-based load balancers can be used to split traffic onto multiple lower-speed links and allow an IDS sensor on each link to monitor what traffic it can. If this is done, it is far preferable to split traffic on a per-destination or per-session basis rather than in a round-robin scheme that is sometimes employed to accomplish network bandwidth-based load balancing. It is important that the load balancer keep associated packets together so that the IDS will have the ability to detect related packets that are part of a single attack.

The second option, which may be more difficult to manage but costs much less, is to distribute the network-based IDS sensors closer to the hosts instead of on the backbone where the higher-speed links are typically employed. While it is becoming more common for even modest networks to employ gigabit Ethernet links, many network segments operate at slower speeds. By placing IDS sensors in areas of the network that are forced to operate a slower speeds for other reasons, you can create fairly complete IDSs without the expense of application load balancers or a hardware-based gigabit IDS.