New Net Optics Product Evaluations

I recently acquired several more specialized taps from Net Optics. I thought you might like to hear a few words about them. I plan to feature these and a few other devices in my new book Extrusion Detection, but why wait until then? I specifically requested evaluation units to meet monitoring and network access problems my clients brought to me. Perhaps you will find one or more of these products answer a monitoring question you've also been pondering. Keep in mind that I show Ethernet versions here, but a variety of optical products are offered. Also, I mention these products as they might be deployed at the perimeter, between a border router and firewall. They can certainly be used elsewhere, but for consistency here I stay with that deployment scenario.

The first product I tried was the 10/100 Active Response Dual Port Aggregator Tap. The purpose of this device is to provide full duplex access to a network link to two sensor platforms. The two outputs on the left of the tap accept lines from your border router and firewall. The two outputs on the right of the tap each contain the aggregated traffic of the two transmit (TX) lines, one from the firewall and one from the router.

Here are examples of traffic captured by two sensors. One uses interface sf0 to listen for traffic, and the other uses sf1. I run the captures from each through Tcpdump to show what each interface saw.

bourque# tcpdump -n -r dual_port_agg.sf0.lpc
reading from file dual_port_agg.sf0.lpc, link-type EN10MB (Ethernet)
11:01:16.965312 IP 192.168.2.94 > 192.168.2.7: icmp 64: echo request seq 0
11:01:16.965490 IP 192.168.2.7 > 192.168.2.94: icmp 64: echo reply seq 0
11:01:17.971660 IP 192.168.2.94 > 192.168.2.7: icmp 64: echo request seq 1
11:01:17.971796 IP 192.168.2.7 > 192.168.2.94: icmp 64: echo reply seq 1

bourque# tcpdump -n -r dual_port_agg.sf1.lpc
reading from file dual_port_agg.sf1.lpc, link-type EN10MB (Ethernet)
11:01:16.965361 IP 192.168.2.94 > 192.168.2.7: icmp 64: echo request seq 0
11:01:16.965537 IP 192.168.2.7 > 192.168.2.94: icmp 64: echo reply seq 0
11:01:17.971732 IP 192.168.2.94 > 192.168.2.7: icmp 64: echo request seq 1
11:01:17.971843 IP 192.168.2.7 > 192.168.2.94: icmp 64: echo reply seq 1

Notice you see traffic in both directions, and each copy is exactly the same.

Dual port aggregator taps allow you to deploy two monitoring systems, as shown in the diagram below.

The only drawback to a device like this appears if your aggregated traffic load exceeds 100 Mbps for a sustained period. In other words, a full duplex link can send 100 Mbps in one direction and 100 Mbps in the other. If the sum of the two TX lines seldom or never exceeds 100 Mbps, an aggregator tap is the perfect way to consolide the two TX lines into a single output interface. When the Dual Port Aggregator Tap is used, you have two complete copies of the aggregated TX lines available.

If you find yourself in a situation where you routinely exceed 100 Mbps aggregate, then you should consider this next solution. The 10/100 Regeneration Tap takes the TX lines from, say, your router and firewall, and sends those lines out multiple interfaces. The device pictured at left is a 2X1 model, meaning you get two copies of each TX line. (It's sort of like having two traditional taps in series.) You could plug the router line into the port at the very far right and the firewall line into the port right next to it. The interfaces on the left go to your pair of monitoring platforms. Your sensor needs to know how to bond the two TX lines together to see them as a single stream. (I use the commands here on FreeBSD.)

To understand how this device works, consider the following captures. Here interfaces sf0 and sf1 sit on one sensor, while sf2 and sf3 are located on the second sensor. Interfaces sf0 and sf2 see "Network A", and sf1 and sf3 connect to "Network B" on the tap. Here is what each interface sees, as captured and then reviewed using Tcpdump.

bourque# tcpdump -n -r 2x1_regen_tap_pre-bond.sf0.lpc
reading from file 2x1_regen_tap_pre-bond.sf0.lpc, link-type EN10MB (Ethernet)
11:14:53.818127 IP 192.168.2.94 > 192.168.2.7: icmp 64: echo request seq 0
11:14:54.827103 IP 192.168.2.94 > 192.168.2.7: icmp 64: echo request seq 1

bourque# tcpdump -n -r 2x1_regen_tap_pre-bond.sf1.lpc
reading from file 2x1_regen_tap_pre-bond.sf1.lpc, link-type EN10MB (Ethernet)
11:14:53.818293 IP 192.168.2.7 > 192.168.2.94: icmp 64: echo reply seq 0
11:14:54.827238 IP 192.168.2.7 > 192.168.2.94: icmp 64: echo reply seq 1

bourque# tcpdump -n -r 2x1_regen_tap_pre-bond.sf2.lpc
reading from file 2x1_regen_tap_pre-bond.sf2.lpc, link-type EN10MB (Ethernet)
11:14:53.818082 IP 192.168.2.94 > 192.168.2.7: icmp 64: echo request seq 0
11:14:54.827041 IP 192.168.2.94 > 192.168.2.7: icmp 64: echo request seq 1

bourque# tcpdump -n -r 2x1_regen_tap_pre-bond.sf3.lpc
reading from file 2x1_regen_tap_pre-bond.sf3.lpc, link-type EN10MB (Ethernet)
11:14:53.818248 IP 192.168.2.7 > 192.168.2.94: icmp 64: echo reply seq 0
11:14:54.827186 IP 192.168.2.7 > 192.168.2.94: icmp 64: echo reply seq 1

This is good, but we would prefer to have interfaces sf0 and sf1 bonded on the first sensor to show a single stream. We also want sf2 and sf3 bonded on the second sensor for the same reason. Once bonded, the traffic looks like this on virtual interfaces ngeth0 and ngeth1.

bourque# tcpdump -n -r 2x1_regen_tap_post-bond.ngeth0.lpc
reading from file 2x1_regen_tap_post-bond.ngeth0.lpc, link-type EN10MB (Ethernet)
11:25:01.763213 IP 192.168.2.94 > 192.168.2.7: icmp 64: echo request seq 0
11:25:01.763345 IP 192.168.2.7 > 192.168.2.94: icmp 64: echo reply seq 0
11:25:02.767909 IP 192.168.2.94 > 192.168.2.7: icmp 64: echo request seq 1
11:25:02.767918 IP 192.168.2.7 > 192.168.2.94: icmp 64: echo reply seq 1

bourque# tcpdump -n -r 2x1_regen_tap_post-bond.ngeth1.lpc
reading from file 2x1_regen_tap_post-bond.ngeth1.lpc, link-type EN10MB (Ethernet)
11:25:01.763202 IP 192.168.2.94 > 192.168.2.7: icmp 64: echo request seq 0
11:25:01.763336 IP 192.168.2.7 > 192.168.2.94: icmp 64: echo reply seq 0
11:25:02.767873 IP 192.168.2.94 > 192.168.2.7: icmp 64: echo request seq 1
11:25:02.767893 IP 192.168.2.7 > 192.168.2.94: icmp 64: echo reply seq 1

This 2X1 device isn't the only option. There are also 4X1 and 8X1 versions available, if you need to send traffic to more than two sensors.

So far we've seen two taps which provide more than one copy of network traffic traversing a link. Is there a way to use a tap with a SPAN port?

Yes there is -- the Span Regeneration Tap is the answer. This product looks exactly the same as the previous device. However, the two interfaces on the far right of the box don't connect to your router and firewall. Instead, they connect to SPAN ports from your enterprise class switches. Whatever is connected to the port at the far right is duplicated on the ports labelled "B" on the left side of the tap. Whatever is connected to the port second furthest from the right is duplicated on the "A" ports on the left side of the tap.

This is a regeneration tap, meaning it is designed to take copies of observed traffic and send them to more than one sensor. In the following traces, interfaces sf0 and sf1 are again on one sensor, and sf2 and sf3 are on a second sensor.

bourque# tcpdump -n -r span_tap_sf0.lpc
reading from file span_tap_sf0.lpc, link-type EN10MB (Ethernet)
11:47:55.784352 IP 192.168.2.10.56047 > 192.168.2.7.53: 50548+ A? www.taosecurity.com. (37)
11:47:55.785463 IP 192.168.2.7.53 > 192.168.2.10.56047: 50548* 1/1/1 A 66.93.110.10 (90)
11:47:55.797978 IP 192.168.2.10.56047 > 192.168.2.7.53: 50548+ A? www.taosecurity.com. (37)
11:47:55.805704 IP 192.168.2.7.53 > 192.168.2.10.56047: 50548* 1/1/1 A 66.93.110.10 (90)

bourque# tcpdump -n -r span_tap_sf1.lpc
reading from file span_tap_sf1.lpc, link-type EN10MB (Ethernet)
11:50:33.465715 IP 192.168.2.10.58009 > 192.168.2.7.53: 56871+ A? www.sguil.net. (31)
11:50:33.587480 IP 192.168.2.7.53 > 192.168.2.10.58009: 56871 3/5/4
CNAME wfb.zoneedit.com., A 207.234.129.65, A 216.98.141.250 (248)
11:50:33.590831 IP 192.168.2.10.58009 > 192.168.2.7.53: 56871+ A? www.sguil.net. (31)
11:50:33.687485 IP 192.168.2.7.53 > 192.168.2.10.58009: 56871 3/5/4
CNAME wfb.zoneedit.com., A 207.234.129.65, A 216.98.141.250 (248)

bourque# tcpdump -n -r span_tap_sf2.lpc
reading from file span_tap_sf2.lpc, link-type EN10MB (Ethernet)
11:47:55.784265 IP 192.168.2.10.56047 > 192.168.2.7.53: 50548+ A? www.taosecurity.com. (37)
11:47:55.785390 IP 192.168.2.7.53 > 192.168.2.10.56047: 50548* 1/1/1 A 66.93.110.10 (90)
11:47:55.797888 IP 192.168.2.10.56047 > 192.168.2.7.53: 50548+ A? www.taosecurity.com. (37)
11:47:55.805617 IP 192.168.2.7.53 > 192.168.2.10.56047: 50548* 1/1/1 A 66.93.110.10 (90)

bourque# tcpdump -n -r span_tap_sf3.lpc
reading from file span_tap_sf3.lpc, link-type EN10MB (Ethernet)
11:50:33.465631 IP 192.168.2.10.58009 > 192.168.2.7.53: 56871+ A? www.sguil.net. (31)
11:50:33.587403 IP 192.168.2.7.53 > 192.168.2.10.58009: 56871 3/5/4
CNAME wfb.zoneedit.com., A 207.234.129.65, A 216.98.141.250 (248)
11:50:33.590747 IP 192.168.2.10.58009 > 192.168.2.7.53: 56871+ A? www.sguil.net. (31)
11:50:33.687403 IP 192.168.2.7.53 > 192.168.2.10.58009: 56871 3/5/4
CNAME wfb.zoneedit.com., A 207.234.129.65, A 216.98.141.250 (248)

So what are we looking at? It appears sf0 and sf2 (on different sensors) see the same SPAN port output, which here shows a DNS request and reply for www.taosecurity.com. Interfaces sf1 and sf3 (again on different sensors) see SPAN port output from a different switch, where a DNS request and reply for www.sguil.net has been recorded.

There is an important difference between these four traces for interfaces sf0 - sf3 and the four traces shown for sf0 - sf3 for the 2X1 Regeneration Tap. The 2X1 Regeneration Tap showed only half-duplex traffic, meaning packets sent in one direction only. We used bonding to bring interfaces sf0 and sf1 together, and sf2 and sf3 together, to display a single full duplex stream on the sensor.

Here, we are already looking at full duplex output on each interface, sf0 - sf3. Remember that we are getting our packets from two separate SPAN ports in this case. The tap is not directly inline -- two enterprise switches are collecting traffic and sending it to the tap. There is no need to bond interfaces here because we are already looking at full duplex streams as provided by the switch SPAN ports.

However, we could bond interfaces sf0 and sf1 together on one sensor, and sf2 and sf3 on the other sensor, if we wanted to present a single virtual interface to the sniffing software on each platform. If we do that, we can now see the output from two SPAN ports combined into a single virtual interface. It would look something like this.

11:55:06.032533 IP 192.168.2.10.56047 > 192.168.2.7.53: 50548+ A? www.taosecurity.com. (37)
11:55:06.036645 IP 192.168.2.10.58009 > 192.168.2.7.53: 56871+ A? www.sguil.net. (31)
11:55:06.037014 IP 192.168.2.7.53 > 192.168.2.10.56047: 50548* 1/1/1 A 66.93.110.10 (90)
11:55:06.041972 IP 192.168.2.7.53 > 192.168.2.10.58009: 56871 3/5/4
CNAME wfb.zoneedit.com., A 207.234.129.65, A 216.98.141.250 (248)
11:55:06.045319 IP 192.168.2.10.56047 > 192.168.2.7.53: 50548+ A? www.taosecurity.com. (37)
11:55:06.062005 IP 192.168.2.7.53 > 192.168.2.10.56047: 50548* 1/1/1 A 66.93.110.10 (90)
11:55:06.065079 IP 192.168.2.10.58009 > 192.168.2.7.53: 56871+ A? www.sguil.net. (31)
11:55:06.072073 IP 192.168.2.7.53 > 192.168.2.10.58009: 56871 3/5/4
CNAME wfb.zoneedit.com., A 207.234.129.65, A 216.98.141.250 (248)
11:55:06.075315 IP 192.168.2.10.56047 > 192.168.2.7.53: 50548+ A? www.taosecurity.com. (37)
11:55:06.081956 IP 192.168.2.7.53 > 192.168.2.10.56047: 50548* 1/1/1 A 66.93.110.10 (90)
11:55:06.085050 IP 192.168.2.10.58009 > 192.168.2.7.53: 56871+ A? www.sguil.net. (31)
11:55:06.101978 IP 192.168.2.7.53 > 192.168.2.10.58009: 56871 3/5/4
CNAME wfb.zoneedit.com., A 207.234.129.65, A 216.98.141.250 (248)

So how might you use this device in real life? You may have an enterprise switch mirroring traffic to a SPAN port. You would like multiple sensors to watch that SPAN port. Rather than send the traffic from the SPAN port into a cheap hub, you send the SPAN output to a 2X1 (or 4X1 or 8X1) SPAN Regeneration tap. Everything stays at full duplex for highest performance. Also, consider the consequences of sending tapped traffic to a hub; if traffic enters the hub at the same time, the packets collide but no retransmission occurs. The tap is passive so those collided packets are lost forever. Taps and hubs never mix.

You may have noticed that the last two products looked physically identical. However, they are not electrically identical. In other words, on the SPAN Regeneration Tap, the two ports on the far right cannot pass traffic through themselves, as is the case with the 2X1 Regeneration Tap.

Keep an eye out for additional monitoring product reviews. I have a couple Matrix Switches on the way.

Comments

Anonymous said…
I just talked to our NetOptics rep last night about the SPAN Regeneration Taps. We have instances where more than one device needs to see the same traffic. As we all know, spanning to a hub is a huge "no-no" so these new taps are a great fit. Now we can use a single SPAN to the tap and pass the data to our IDS, WebSense, and network management tools. We were also running into problems where our switches couldn't accomidate all the SPANning we wanted to do and these new taps will allow us to be more efficient.

It's good stuff :)

Bammkkkk
Anonymous said…
Hi Richard,

Can you post something similiar for fiber interfaces?

Thanks,
Shahid
Sorry, I have no fiber equipment here to test.
Anonymous said…
no worries.. regardless it is coool stuuff. thanks for sharing.

Shahid

Looking forward to RDF and Extrusion Detection from you.

Popular posts from this blog

Zeek in Action Videos

New Book! The Best of TaoSecurity Blog, Volume 4

MITRE ATT&CK Tactics Are Not Tactics