Using Network Taps

Using Network Taps

As we saw earlier, in cases where monitoring is needed for a set of links widely distributed over different switches, configurations can get quite complicated where RSPAN, VACLs, and trunking are involved. There are also cases when features such as RSPAN are simply unavailable because they are not supported by hardware—for example, with 2900 series switches.

The other option for adding IDS systems to such environments is to use networks taps. A network tap is a device that is inserted into the monitored link. This device usually has at least four ports— two for connecting a network cable of a monitored link and two output ports where the traffic is copied. When used on a full-duplex connection, the tap splits copied traffic into two—one monitoring port outputs traffic flowing in one direction and the second port tackles traffic flowing in the opposite direction (see Figure 9.8). One of the nice features of the tap compared to SPAN ports is that taps monitor all traffic, including incorrect or control frames, which are usually not copied to SPAN ports on switches. Some network taps allow traffic flow in one direction while others allow dual–direction traffic. Why would a network tap permit this, you ask? Because your IDS sensor may allow for something called TCP Resets where the IDS sensor can send an IP reset packet to break the connection of a suspected attacker. Without the ability to send traffic back through the TAP, this capability would be lost.

Figure 9.8: Network Tap Connections

There also exist multiport taps, which allow monitoring of a number of connections by the same device. Taps are different from small hubs—they are designed so that in case of a power failure they do not block traffic on a monitored line (they "fail open"), as a hub would. Some larger tap products may have internal load balancers to prevent packet loss—for example, it is possible to have a Gigabit Ethernet tap which outputs captured traffic into several monitor ports, where a set of IDS sensors is connected.

Taps do, however, pose some challenges from an implementation point of view. Most important is the fact that tap output is two data streams and IDS usually has only one monitoring interface. This means that tap outputs have to be connected to an aggregation device of some sort, where traffic is assembled. This device can be a hub or a switch, although hubs are not recommended—when both flows of a single full-duplex connection are plugged into the same hub, this will most likely result in a heavy collision rate, meaning an IDS will not be able to see much. Thus, it is more appropriate to use a switch. This switch can have many taps connected. The output port, connected to the IDS is usually a local SPAN port, configured to monitor all tap connections, as shown in Figure 9.9.

Figure 9.9: Aggregating Tap Traffic on a Switch

Multiport taps often come with an internal aggregation device, which outputs collected traffic into a designated "analysis" port.

The pros and cons of SPAN ports and network taps are shown in Tables 9.1 and 9.2.

As a result, taps are often used on core links—inter-switch trunks, server farms, and so on. SPAN ports are commonly used in smaller networks, on the leaf nodes, and when planning IDS installation and testing, because they allow for easy drafting of IDS' place in the network infrastructure. Of course, with the Catalyst IDSM module, the situation is completely different than with external sensors, there is no need to use taps because IDSM is already connected to the switch backplane.

Two of the leading vendors of network taps are Finisair (www.finisair.com) and Netoptics (www.netoptics.com).