Profound Words from the Past and Present

I recently mentioned writings by Marcus Ranum on "deep packet inspection" and related topics. This morning while browsing the firewall-wizards list I read a profound post by MJR. Here is the most powerful part:

"Basically, what's going on is that a lot of security practitioners are in the position of being asked to make something safe that is fundamentally dangerous. So we hide behind the notion of 'risk management' - basically the illusion that 'if we try hard to cover our butts it's less dangerous than otherwise.'

What that has accomplished is to create an environment in which security has NO CHOICE but to compromise because senior execs know that if they don't get the answer they want out of one security practitioner, they can keep asking until they get the answer they want out of another...

My feeling is that during the 90's we, as an industry, dug ourselves into a hole we're not going to be able to spend or risk manage our way out of. We did that by trying to deal with the 'real world' instead of demanding excellence, good design, and wise leadership."

Wow. That statement really made me question my role in the security industry and whether my contribution has been worthwhile.

For a sign that nothing has really changed in security, check out this thread from February 1998. It followed the release of a ground-breaking paper by Tom Ptacek and Tim Newsham. This seven-year-old thread is as applicable to the IDS vs "IPS" argument as any I've seen recently.

Read More

Bejtlich Writing Like Mad During Home Stretch

I am writing like mad to meet a 1 June book delivery deadline for Addison-Wesley, so I won't be posting much or at all until I finish Extrusion Detection. I think crunching to meet deadlines is a common author predicament, after speaking with the other participants at the BSDCan book signing last week. Pictured with me, starting from my left, are Dru Lavigne, Greg Lehey, Marshall Kirk McKusick, and George Neville-Neil. Michael Lucas was not present for that photo but he appeared momentarily afterwards. Standing in the background is conference organizer extraordinaire Dan Langille. Thanks to Robert Bernier for posting the original photo.

Read More

Snort Inline?

Is anyone successfully running an inline deployment of Snort on FreeBSD? If so, please email me: richard at taosecurity dot com. This guide makes it look easy, but I've tried multiple variations (bridging, routing, etc.) with Snort 2.3.3 on FreeBSD 5.4 REL and nothing works completely. Thank you.

Update: I got it working. snort-2.3.3.tar.gz doesn't work; snort_inline-2.3.0-RC1.tar.gz does. Who knew.

Read More

Vote for Sguil at SANS ISC Poll

Thanks to Brandon Greenwood I learned that the current SANS ISC poll asks for your favorite Snort interface. Sguil is currently running third behind BASE and ACID. Visit SANS ISC and vote for Sguil!

Read More

NetBSD Binary OS Updates

I discovered a system running NetBSD 2.0 in my lab and decided to upgrade it to NetBSD 2.0.2. I read that "this is also the first binary security/critical update since NetBSD 2.0." I found a thread which gave various forms of advice on updating to NetBSD 2.0.2 from 2.0. Here is what I did.

When I started the system was running NetBSD 2.0.

bash-2.05b# uname -a
NetBSD juneau.taosecurity.com 2.0 NetBSD 2.0 (GENERIC) #0:
 Wed Dec  1 10:58:25 UTC 2004  builds@build:/big/builds/ab/netbsd-2-0-RELEASE/
 i386/200411300000Z-obj/big/builds/ab/
 netbsd-2-0-RELEASE/src/sys/arch/i386/compile/GENERIC i386

First I downloaded base.tgz, comp.tgz, kern-GENERIC.tgz, man.tgz, misc.tgz, and text.tgz into a directory I created called /usr/tmp. The FTP server directory listing shows what was available in total.

juneau# ftp ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-2.0.2/i386/binary/sets/
Trying 204.152.190.13...
Connected to ftp.netbsd.org.
...edited...
ftp> ls
229 Entering Extended Passive Mode (|||51263|)
150 Opening ASCII mode data connection for '/bin/ls'.
total 227868
-rw-r--r--  1 srcmastr  netbsd       444 Mar 30 06:10 BSDSUM
-rw-r--r--  1 srcmastr  netbsd       581 Mar 30 06:10 CKSUM
-rw-r--r--  1 srcmastr  netbsd       987 Mar 30 06:10 MD5
-rw-r--r--  1 srcmastr  netbsd       448 Mar 30 06:10 SYSVSUM
-rw-r--r--  1 srcmastr  netbsd  18047923 Mar 23 09:24 base.tgz
-rw-r--r--  1 srcmastr  netbsd  21308430 Mar 23 09:25 comp.tgz
-rw-r--r--  1 srcmastr  netbsd    168642 Mar 23 09:23 etc.tgz
-rw-r--r--  1 srcmastr  netbsd   3036879 Mar 23 09:23 games.tgz
-rw-r--r--  1 srcmastr  netbsd   3565556 Mar 23 09:20 kern-GENERIC.MP.tgz
-rw-r--r--  1 srcmastr  netbsd   3526224 Mar 23 09:20 kern-GENERIC.tgz
-rw-r--r--  1 srcmastr  netbsd   3557989 Mar 23 09:20 kern-GENERIC_DIAGNOSTIC.tgz
-rw-r--r--  1 srcmastr  netbsd   2632995 Mar 23 09:20 kern-GENERIC_LAPTOP.tgz
-rw-r--r--  1 srcmastr  netbsd    859230 Mar 23 09:20 kern-GENERIC_PS2TINY.tgz
-rw-r--r--  1 srcmastr  netbsd    822571 Mar 23 09:20 kern-GENERIC_TINY.tgz
lrwxrwxrwx  1 1237      netbsd        27 Apr  6 17:13 man.tgz -> 
 ../../../shared/ALL/man.tgz
lrwxrwxrwx  1 1237      netbsd        28 Apr  6 17:13 misc.tgz -> 
 ../../../shared/ALL/misc.tgz
-rw-r--r--  1 srcmastr  netbsd   1982544 Mar 23 09:23 text.tgz
-rw-r--r--  1 srcmastr  netbsd   5787182 Mar 23 09:24 xbase.tgz
-rw-r--r--  1 srcmastr  netbsd  10732131 Mar 23 09:24 xcomp.tgz
-rw-r--r--  1 srcmastr  netbsd     32342 Mar 23 09:24 xetc.tgz
-rw-r--r--  1 srcmastr  netbsd  32171614 Mar 23 09:25 xfont.tgz
-rw-r--r--  1 srcmastr  netbsd   8053884 Mar 23 09:25 xserver.tgz

Next I switched to a bash shell and ran the following:

juneau# ls *.tgz
base.tgz            kern-GENERIC.tgz    misc.tgz
comp.tgz            man.tgz             text.tgz
juneau# bash
bash-2.05b# for i in *.tgz; do tar -xpvzf $i -C /; done

This extracted all of the archives. When done, I rebooted the system. Upon reboot, I checked uname output.

NetBSD juneau.taosecurity.com 2.0.2 NetBSD 2.0.2 (GENERIC) #0:
 Wed Mar 23 08:53:42 UTC 2005  
 jmc@faith.netbsd.org:/home/builds/ab/netbsd-2-0-2-RELEASE/i386/
 200503220140Z-obj/home/builds/ab/netbsd-2-0-2-RELEASE/
 src/sys/arch/i386/compile/GENERIC i386

That's it -- I'm running NetBSD 2.0.2 now.

Read More

Marcus Ranum on Proxies, Deep Packet Inspection

I asked security guru Marcus Ranum if he would mind commenting on using proxies as security devices. I will publish his thoughts in my new book Extrusion Detection, but he's allowed me to print those comments here and now. I find them very interesting.

"The original idea behind proxies was to have something that interposed itself between the networks and acted as a single place to 'get it right' when it came to security. FTP-gw was the first proxy I wrote, so I dutifully started reading the RFC for FTP and gave up pretty quickly in horror. Reading the RFC, there was all kinds of kruft in there that I didn't want outsiders being able to run against my FTP server. So the first generation proxies were not simply an intermediary that did a 'sanity check' against application protocols, they deliberately limited the application protocols to a command subset that I felt was the minimum that could be done securely and still have the protocol work.

For example, while writing FTP-gw I realized that the PORT command would cause a blind connection from TCP port 20 to anyplace, over which data would be transferred. Port 20 was in the privileged range and I was able to predict an 'rshd' problem so I quietly emailed the guys at Berkeley and got them to put a check in ruserok() to forestall the attack. I also added code to make sure that the client couldn't ask the server to send data to any host other than itself, forestalling FTP PORT scanning. So I 'invented' 'FTP bounce' attacks in 1990 by preventing them with my proxy.

There are several other examples of where, in implementing proxies, I was horrified to see gaping holes in commonly-used application protocols, and was able to get them fixed before they were used against innocent victims. Since the proxies implemented the bare minimum command set to allow an application protocol to work, a lot of attacks simply failed against the proxy because it only knew how to do a subset of the protocol. When the hackers started searching for vulnerabilities to exploit in the internet applications suite, they often found holes in seldom-used commands or in poorly tested features of the RFC-compliant servers. But often, when they tried their tricks against the proxy all they'd get back was: 'command not recognized'.

The proxy gave a single, controllable, point where these fixes could be installed.

The problem with proxies is that they took time and effort and a security-conscious analyst to write them and design them. And sometimes the proxy ran up against a design flaw in an application
protocol where it couldn't really make any improvement to the protocol. The first reaction of the proxy firewall vendors was to tell their customers, 'well, protocol XYZ is so badly broken that
you just can't rely on it across an untrusted network.' This was, actually, the correct way (from a security standpoint) to solve the problem, but it didn't work.

Around the time when the Internet was becoming a new media phenomenon, a bunch of firewalls came on the market that were basically smart packet filters that did a little bit of layer-7 analysis. These 'stateful firewalls' were very attractive to end users because they didn't even TRY to 'understand' the application protocols going across them, except for the minimum amount necessary to get the data through.

For example, one popular firewall from the early 90's managed the FTP PORT transaction by looking for a packet from the client with the PORT command in it, parsing the PORT number and address out of it, and opening that port in its rulesbase. Fast? Certainly. Transparent to the end user? Totally. Secure? Hardly. But these 'stateful firewalls' sold very well because they offered the promise of high performance, low end-user impact, and enough security that an IT manager could
say they'd tried.

There are a few vendors who have continued to sell proxy firewalls throughout the early evolution of the Internet, but most of the proxy firewalls are long gone. Basically, the customers
didn't want security; they wanted convenience and the appearance of having tried. What's ironic is that a lot of the attacks that are bedeviling networks today would never have gotten through the early proxy firewalls. But, because the end user community chose convenience over security, they wound up adopting a philosophy of preferring to let things go through, then violently slamming the barn door after the horse had exited.

Proxies keep cropping up over and over, because they are fundamentally a sound idea. Every so often someone re-invents the proxy firewall - as a border spam blocker, or a 'web firewall' or an 'application firewall' or 'database gateway' - etc. And these technologies work wonderfully. Why? Because they're a single point where a security-conscious programmer can assess the threat represented by an application protocol, and can put error detection, attack detection, and validity checking in place.

The industry will continue to veer back and forth between favoring connectivity and favoring security depending on which fad is in the ascendant. But proxies are going to be with us for the long term, and have been steadfastly keeping networks secure as all the newfangled buzzword technologies ('stateful packet inspection,' 'intrusion prevention,' 'deep packet inspection') come - and go."

This is a report he wrote for a client, but he's sharing it with the world. If you're looking for some cynical digital security artwork to grace your cubicle, check out Marcus' media outlet.

Read More

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.

Read More