next up previous
Next: Conclusion Up: Receive-only UTP cables and Previous: Receive-only cables

Subsections


Network Taps

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.

Schemes

The diagram 11 describes two ways to represent the Tap connection scheme.

Figure 11: TAP connection scheme
Image tap_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.

Figure 12: Ethernet TAP connection diagrams
Image eth_tap_scheme

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

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.

Regeneration Taps

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.

Figure 13: Regeneration Tap
Image reg_tap

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.

Figure 14: Regeneration Tap using individual Taps
Image daisytap

Aggregation Taps

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 versus Span (mirror) Ports

Taps and span ports are used to monitor network traffic, but there are important differences between both technologies [14]:

  1. Traffic integrity. The device connected to the Tap receives the same traffic as if it were also in-line, including all errors. See figure 15 for more details. Neither splitting nor regeneration introduce delay, or change the content or structure of information packets.

    Figure 15: Passive network monitoring
    Image tap_inline

    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.

  2. Delay. Taps pass full-duplex data at wire speed without affecting the actual traffic.

    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.

  3. Resources. Since Newtork Taps are passive devices, they can be left permanently in-line without affecting traffic.

    In contrast, span ports are apt to consume switch resources, degrading its overall performance.


Implementation Examples

There are many ways to implement network traffic analysis with Taps. The following are just a few of the methods available.

Sensor with two network interfaces

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.

Using a switch span-port

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.

Figure 16: Network Tap and switch with span port
Image tap_span

Load balancing. Multiple IDS

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.

Figure 17: High speed traffic analysis
Image tap_lb


next up previous
Next: Conclusion Up: Receive-only UTP cables and Previous: Receive-only cables
Diego González Gómez
diego at (nospam) dgonzalez net
2005-05-22