The alternative. TAP stands for Test Access Port. Network Taps are devices that allows to examine network traffic without causing any data stream interference. They work at OSI level 1, therefore they do not make any fowarding or routing decisions.
Obviously, Network Taps are more expensive than making your own receive-only cables, but they have more advantages. For example, they are more robust and professional, they usually have buffers to avoid data losses, they can monitor fiber optic communications, etc.
There are several companies that develop these products. Net Optics, Inc. [4], Shomiti Systems [5], Network Critical [6], Finisar [7], Intrusion Inc. [8], Datacom Systems Inc. [9] and Comcraft [10] are some of them.
It is interesting to note that all Tap manufacturers claim their copper Taps are fail-safe (no disruption to the link on powerloss). This is only partly true, because there is a 5-10 ms switchover time (a 0-1 packet loss possibility). In most environments this can be acceptable, but in a high availability network it can cause major issues such as causing the router and switches to renegotiate their links (VLAN, Spanning tree, etc). 4x4 Taps seems to be the only ones that offer `zero' packet loss in the event of power-failure. Securicore [11] is one of the companies that distributes those Taps, from Network Critical.
Net Optics [4] offers PCI Network Taps for full-duplex monitoring access for 10/100 Mbps networks with a single NIC.
The diagram 11 describes two ways to represent the Tap connection scheme.
A Tap captures network traffic in both directions and sends it to a monitoring device, such an IDS or a statistics traffic generator. As you can observe in figure 11, there is one data line by each traffic direction. Therefore, if we apply this scheme to UTP cables, which are usually used in Ethernet networks, we can easily deduce the following diagrams in figure 12.
To build a Tap like that is trivial. In fact, there are already instructions that explain how, with a straight through cable [12]. This solution requires two network interfaces to analyze traffic (each one receives one direction). Keep in mind that the signal power of one network segment is not prepared to be shared by more than two network interfaces (source and destination). Therefore, this design can lead to signal (and data) losses.
More solutions for analyze traffic with Taps are discussed later on section 4.3 `Implementation Examples'.
Adaptive Taps are designed to make signal conversions, in addition to capturing traffic. For example, there are Taps that convert signals from GigaBit-TX to Gibabit-SX, or from Gigabit-LX to Gigabit-SX.
The idea of Regeneration Taps, from Net Optics [4], is to generate multiple streams of network traffic from a single access point. They act like several Taps combined in only one device, saving costs and space.
Regeneration Taps can be used in cases where it is necessary to analyze traffic in more than one way and with different machines. For example, both intrusion detection and protocol analysis may be used. Figure 13 represents this concept.
Another way to implement a Regeneration Tap is using two or more Taps and sort them of daisy chain. 4x4 Critical Tap in figure 14 combines four individual Taps in one rackmountable case, and can be used in this manner. Although this can be done with both fiber and copper Taps, fiber Taps need more care with signal loss and must be ordered with the appropriate split ratio to preserve the live stream integrity.
As we saw in figure 11, each traffic direction is a signal to analyze. Therefore, to monitor the traffic two network interfaces are needed. The advantage of the Aggregation Taps, among other features, is that they aggregate both signals into one, allowing the analysis with only one network interface. The Aggregation Tap by Network Critical [11] can, exceptionally, inject RESET TCP packets to kill hostile communications. This feature makes it especially useful in environments with NIDs with active response capabilities, or with NIPS (Network Intrusion Prevention Systems).
Taps and span ports are used to monitor network traffic, but there are important differences between both technologies [14]:
On the other hand, a span port on a switch does not see all the traffic. Corrupt network packets, packets below minimum size, and layer 1 and 2 errors are usually dropped by the switch.
By contrast, the software architecture of low-end switches introduces delay by copying the spanned packets. Worse yet, in many cases the data is being aggregated through a gigabit port, introducing a delay as the signal is converted from electrical to optical.
Furthermore, access to switch traffic is limited by the span port capacity. If the traffic passing through the span port is too great, the port will drop packets, thus some data loss will be experienced. For example, to see full-duplex traffic on each 100 Mbps link, a span port would need 200 Mbps of capacity.
In contrast, span ports are apt to consume switch resources, degrading its overall performance.
Figure 15 represents one way of analyzing traffic, using a sensor with two network interfaces, one for each traffic direction. In addition, some kind of software is required to aggregate the data from both physical interfaces into one logical interface. You can use for example the Sun Trunking software [13], or the Linux network bonding driver. The last option requires you to compile the driver as a module first, and then to combine the physical network interfaces into a logical one (bond0). For example, if we wish to bond the physical interfaces eth1 and eth2 to logical interface bond0 with IP address 192.168.0.254/24:
[root@tap root]# modprobe bonding
[root@tap root]# ip addr add 192.168.0.254/24 brd + dev bond0
[root@tap root]# ifconfig eth1 promisc -arp up
[root@tap root]# ifconfig eth2 promisc -arp up
[root@tap root]# ifconfig bond0 promisc -arp up
[root@tap root]# ifenslave bond0 eth1
master has no hw address assigned; getting one from slave!
The interface eth1 is up, shutting it down it to enslave it.
[root@tap root]# ifenslave bond0 eth2
The interface eth2 is up, shutting it down it to enslave it.
[root@tap root]# ifconfig
bond0 Link encap:Ethernet HWaddr XX:XX:XX:78:7F:C5
inet addr:192.168.0.254 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING NOARP PROMISC MASTER MULTICAST MTU:1500 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:888 (888.0 b) TX bytes:0 (0.0 b)
eth0 Link encap:Ethernet HWaddr XX:XX:XX:77:02:13
inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:151 errors:0 dropped:0 overruns:0 frame:0
TX packets:113 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:69180 (67.5 Kb) TX bytes:17418 (17.0 Kb)
Interrupt:11 Base address:0x3400
eth1 Link encap:Ethernet HWaddr XX:XX:XX:78:7F:C5
inet addr:192.168.0.254 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING NOARP PROMISC SLAVE MULTICAST MTU:1500 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:444 (444.0 b) TX bytes:0 (0.0 b)
Interrupt:9 Base address:0xd800
eth2 Link encap:Ethernet HWaddr XX:XX:XX:78:7F:C5
inet addr:192.168.0.254 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING NOARP PROMISC SLAVE MULTICAST MTU:1500 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:444 (444.0 b) TX bytes:0 (0.0 b)
Interrupt:11 Base address:0xd400
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:18863 errors:0 dropped:0 overruns:0 frame:0
TX packets:18863 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1287600 (1.2 Mb) TX bytes:1287600 (1.2 Mb)
Needless to say that ARP support is disabled since it is not needed by a receive-only device. As bond0 is a logical interface, it can be used by tcpdump. The eth0 interface can be used to remote control the sniffer, or to send alerts to a central console. More information on bonding can be found in Documentation/networking/bonding.txt file from the linux source code tree.
On the other hand, if we have a switch with span ports, we can try the implementation of figure 16, from Jeff Nathan [15]. This implementation analyzes network traffic using a 100 Mbps or 1000 Mbps span port.
When monitoring high speed traffic (Gigabit fiber and higher) it becomes necessary to use multiple IDS systems and load balance between them. Figure 17 represents how to implement this type of configuration [16]. Netoptics also offers a detailed installation guide [17] for one of their Gigabit Fiber Taps.
