Tap vs Lightning Strike

Earlier this year my lab suffered a near lightning strike. A tree right outside the lab was struck by lightning, causing damage to multiple electronic and electrical devices outside and inside the building.

Outside, the lightning disabled an exterior lighting system and my phone lines. Inside, the lightning took a severe toll on the lab. The cable modem to the outside world was destroyed. The NIC on the lab firewall facing the cable modem was fried, along with a second NIC in the firewall. The NIC on a sensor watching a tap between the cable modem and firewall was also destroyed. So far, this is a grim story.

I have one good piece of news to report, and it involves the tap I mentioned sitting between the cable modem and firewall. The tap survived the lightning strike. More precisely, the tap continued to pass traffic even when its monitoring interface was damaged.

Had the tap been receiving traffic from the modem or firewall, it would have continued to pass it. This truly amazed me. Frequently monitoring practitioners worry that inserting a tap in their network architecture will introduce a single point of failure. In my experience, all of the components around the tap are more likely to fail. A well-engineered tap will continue to pass traffic -- perhaps even when struck by lightning!

The tap that survived my lab lightning strike was built by Net Optics. Congratulations to the Net Optics engineering and manufacturing teams for building quality hardware.

Read More

Notes on Net Optics Think Tank

Last week I attended and spoke at the latest Net Optics Think Tank. I've presented for Net Optics twice before, but this was the first event held in northern Virginia.

The first half of the event consisted of two briefings. The first discussed tap technology. This was supposed to be a basic introduction but I learned quite a bit, especially with regards to fiber optics. Specifically, I learned of some cases where customers reverse cables when plugging in their taps, thereby causing lots of tough-to-troubleshoot problems. Furthermore, as customers move from Gigabit over fiber to 10 Gigabit over fiber, they are encountering cabling issues. Gigabit is much more forgiving than 10 Gig. At 10 Gig, you apparently have to pay close attention to the specifications, such as core size.

I learned that Net Optics is considering ways to "tag" or "label" packets collected by their link aggregator taps. When discussing matrix switches, it occurred to me that those devices are a great way to implement on-demand monitoring while keeping true to the tenets of Visiblel Ops. Rather than monkeying around with a switch SPAN port, risking making a problematic change, you tell the matrix switch which port you want to monitor. The switch is never touched.

The same idea applies to bypass switches. Net Optics (and their customers) basically convinced me that it's a bad idea to ship an appliance with a bypass switch embedded as a NIC in a security appliance. It's far better (if you have the rack space) to have a separate bypass switch. This allows you to completely power down and remove the "inline" security appliance with no effect on the network. This isn't possible with an integrated bypass NIC. The second briefing covered the Net Optics iTap product line, which I covered several months ago. Dennis Carpio (pictured at left) gave that briefing. Basically Net Optics is moving this "intelligent Tap" functionality into all of their products. I told them I would like to see the tap inspect and classify the traffic it sees, namely by doing port independent protocol identification. I would also like to see the iTaps support 802.1X, IPv6, SNMPv3, and a HTTPS Web interface.

The iTap might also support filtering at the monitoring ports. This would reduce the load of a sensor on the tap. For example, you could tell the iTap not to pass ARP or non-IP traffic to the sensor. Besides continuing to add features to taps without adding cost, Net Optics is also reducing their size. They will be able to fit six taps into 1U. They're also moving to replacing fixed ports with SFPs.

During the second half of the day Net Optics shared ideas for future products. I'll keep this to myself, since this was not exactly meant for broadcast on the Internet. Basically, if you have a network traffic access requirement you're trying to meet, get in contact with me. I can put you in touch with the right people at Net Optics and they will be able to meet your demands. I am not getting any kind of referral fee -- I just trust the people at this company to do the right thing.

Expect to see more reporting on their gear as I get demo products to test.

Read More

Net Optics Think Tank Tuesday in Fairfax, VA

Don't forget to attend the free Net Optics Think Tank on Tuesday, 26 September 2006 in Fairfax, VA. It looks like I will be speaking during lunch from 1215 to 1315. Please register. I expect to see a lot of cool Net Optics gear on display, along with insights from those who make products for enterprise network instrumentation.

Read More

Net Optics Think Tank on 26 September

In about three weeks I will be speaking at the next Net Optics Think Tank on 26 September 2006 in Fairfax, VA. It looks like I will be speaking during lunch from 1215 to 1315. Please register. Speaking of Net Optics, I see they've announced a GigaBit Port Aggregator with SFP Monitor Ports and a New iBypass™ Switch with Heartbeat, Unique Utilization Display, and Remote Management. I expect those will be on display in Fairfax.

Read More

Speaking at Net Optics Think Tank on 26 September

Almost exactly one year after my last appearance, I will be speaking at the next Net Optics Think Tank on 26 September 2006 in Fairfax, VA. I haven't figured out exactly what I will be covering yet. I might talk about some material from my TCP/IP Weapons School class and how it relates to recent incidents like the Freenode event. It looks like I will be speaking during lunch from 1215 to 1315.

Read More

Cool News Taps from Net Optics

You know I am always on the prowl for new networking gear to perform network security monitoring. In fact, I may write a whole new book about the subject, pulling enterprise network instrumentation coverage from future editions of The Tao and other books and concentrating it in a single volume.

In the spirit of sharing information on new gear, I am happy to let you know about two cool new products from Net Optics. The first is the 10/100 Teeny Tap, pictured above. This is a fully-functional, dual-power, dual output traditional 10/100 Mbps tap. It's functionally equivalent to the 10/100 Ethernet Tap.

The second neat product is the iTap Gigabit Dual Port Aggregator. This is a Gigabit tap that provides two outputs where each are combinations of the two TX input streams. This tap is similar to the Gigabit Dual Port Aggregator with several major differences, which I noted last month. I ran some traffic through this tap today and I really liked seeing the traffic load on the LCD screen. I did not get a chance to try the remote management features, but I plan to soon.

I took some photos of the Teeny Tap sitting above a traditional Ethernet tap, on top of the copper iTap. (There will also be a fiber iTap.) You can see just how tiny the Teeny Tap is. You can also buy the Teeny Tap online. It ships with a smart black canvas carrying case that looks like a digital camera container. It is big enough to hold the tap and two power supplies, along with some cables. I intend to take one with me on all of my engagements.

Thank you to Net Optics for sharing these with me. Who in your organization could use a Teeny Tap? I'm sure any consultants who travel as frequently as I do with a laptop bag would love to replace their existing setup with a Teeny Tap. As for the iTap, expect to see more of these everywhere -- the statistical functions are awesome.

Read More

Net Optics Introduces iTap

This morning I found I was quoted in a press release for the new Net Optics iTap GigaBit Port Aggregator tap. This is a cool device that I expect to test soon. I participated in a Think Tank where the concept of an "intelligent tap" was first introduced. From the installation guide (.pdf):

The iTap Port Aggregator displays the link utilization level, last peak with time right on the front panel so you can see real-time utilization on both directions of the network link. The iTap Port Aggregator is accessible from remote interfaces that provide information and control from anywhere in the network.

If you're scared by the thought of a tap offering network statistics via a front panel display, SNMP, and a Web interface, you can disable all of them and deploy the tap in "dumb" mode. It would be cheaper to buy a dumb tap, though!

It makes a lot of sense to introduce this device on a port aggregator model. Port aggregators are vulnerable to dropping traffic when the total bandwidth load exceeds the capacity of the output interface. With the iTap, you can see immediate and ongoing traffic statistics that ensure you're observing and collecting what you expect.

---

On an unrelated note:I think Blogger may be using a small set of CAPTCHAs to frustrate posting "spam". I actually recognize the CAPTCHA I had to enter for this post. I've had to manually delete several proxy list spam posts over the last few days, too.

Read More

How Do You Use Taps?

How do you use taps? Specifically, do any of you use Net Optics taps? If yes, I would like to speak with you through email. I'm interested in your thoughts on any of these subjects:

• How did you justify buying these products?


• Did you encounter any installation issues?


• How are you using taps?


• What alternatives did you consider?


• Did taps help you learn more about any intrusions, or help you prevent or mitigate intrusions?

I appreciate any feedback you might have. Please email richard at taosecurity dot com. Thank you.

Read More

Speaking at Net Optics Think Tank on 21 September

I will be speaking at the next Net Optics Think Tank at the Hilton Santa Clara in Santa Clara, CA on 21 September 2005. I will discuss network forensics, with a preview of material in my next two books, Real Digital Forensics and Extrusion Detection: Security Monitoring for Internal Intrusions. I had a good time speaking at the last Think Tank, where I met several blog readers.

Read More

Net Optics Seminar on Passive Monitoring Access

I just received word that Net Optics will be hosting a free seminar titled Fundamentals of Passive Monitoring Access. It will start at 0830 on Wednesday 3 August 2005 at the Hilton Santa Clara in Santa Clara, CA. You will notice the seminar description uses terms like pervasive network awareness and defensible network, which I described when I spoke at Net Optics in May. I am scheduled to speak again at a Net Optics event in September in California. I will post details when available.

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

Notes on Net Optics Think Tank

Last week I had the good fortune to be invited to speak at a Net Optics Think Tank event. Net Optics is a California-based maker of products which help analysts access traffic for monitoring the security and performance of the network. I recently wrote about the Net Optics tap built in a PCI card form factor. I also use their gear to conduct network security monitoring, as profiled in my first book.

The meeting offered attendees three sessions: the first two were conducted by Net Optics personnel, and I presented the third. The purpose of the sessions were not to sell products, but to solicit feedback from attendees. In fact, in some cases the "products" in question didn't exist yet. Rather than implement products customers might not want, or lacking desired features, Net Optics polls its clients and prospective customers and builds the gear those customers need.

The first presentation described the Bypass Switch. This is a really interesting product which I had not paid any attention to prior to the Think Tank event. It is primarily designed to work with inline devices like so-called intrusion prevention systems. Apparently many prospective IPS customers are reluctant to deploy an IPS inline along with their routers and firewalls. Either customers have grown to trust the reliability of those products, or routers and firewalls usually support clustering and/or active failover to mitigate the risk of network down time. IPSs are apparently not that mature. Enter the bypass switch.

As the diagram below shows, traffic is first sent to the bypass switch. The bypass switch ensures that the IPS is alive by sending special heartbeat packets through it. As long as the IPS is functioning (i.e., passing heartbeats), the bypass switch sends traffic to the IPS. Should the heartbeat packets fail to traverse the IPS, the bypass switch reroutes traffic to go directly through the switch, thereby avoiding the failed IPS.

This makes sense for a single IPS that is deployed inline and that supplements a filtering router and firewall. Using a bypass switch would not make much sense if the connected device was a site's only access control mechanism. Who would want traffic to pass if their firewall died?

If power is lost to the bypass switch, it will still pass traffic. It is truly a passive device. This is a big improvement over the average inline appliance, whose loss of power or operating system would bring the entire link down.

The innovation that Net Optics continues to apply to this scenario involves support for dual or multiple devices attached to the bypass switch. In other words, add a second IPS to complement the primary system. Should number one IPS die, route traffic through number two. There are additional opportunities for creativity here, so I suggest watching Net Optics for future product releases.

The second session discussed adding Simple Network Management Protocol (SNMP) support to Net Optics devices. This would allow a tap to report statistics similar to those provided by Cisco device interfaces. While this is useful, I recommended Net Optics provide hardware dip switches to completely disable the feature. Those that want "dumb" taps should still be allowed to deploy them!

Finally, Net Optics asked me to speak on how I conduct monitoring. I delivered a presentation on defensible networks, based on the chapter of the same name in my forthcoming book Extrusion Detection. Essentially, a defensible network is one that can be monitored, controlled, minimized, and kept current. If you would like to hear me speak on this subject, I will be offering a similar presentation at Techno Security 2005 on 13 June in Myrtle Beach, SC. Incidentally, the pictures showing me speak at the Net Optics Think Tank link to larger versions.

Read More

Tap on a PCI Card

Those of you who've read my first book know I like to use taps built by Net Optics to access wired traffic. The device pictured at left is a port aggregator tap. It combines the TX side of whatever's plugged into port A with the TX side of port B into a single output on port C, using buffering if the aggregrate throughput exceeds 100 Mbps.

Today I got a chance to test the device pictured at left. It's a Net Optics PCI Port Aggregator tap. You plug this device into a 32 bit PCI slot on your monitoring station, and you effectively have the normal port aggregator tap I showed earlier sitting within your sensor. Let me show you what I mean in pictures.

This is the inside of my preferred monitoring platform, a Dell Poweredge 750. I've removed the dual Gigabit Ethernet NIC I usually order with these systems. That NIC is a PCI-X device recognized as em under FreeBSD.



In this next picture you see the Net Optics PCI tap at the top, and the dual Gigabit Ethernet NIC below it.



Here is the Net Optics PCI tap installed. It takes up almost all of the space available, but it fits nicely. You can barely see the three tap ports in this picture. The PCI tap does not appear active to the operating system. All the PCI tap needs from the PCI interface is power. There is a plug for a back-up power supply on the tap, but I did not connect it here. If power to the tap fails (i.e., the PC is off), the tap still passes traffic.



In this final picture, you see my test setup. This isn't how I would deploy it in real life. In a real deployment, say on a site perimeter, one tap interface would go to the router and the other tap interface would go to the firewall. The third tap interface connects to the sensor monitoring traffic passing between the router and firewall.

In this test deployment, I am essentially watching traffic to and from the server em0 interface by sending copies of that traffic through the tap and to the server em1 interface.

In the picture below, the tap ports are occupied by blue, yellow, and black cables. The yellow cable is connected to a switch with Internet access. The black cable next to the yellow line is connected to the live (IP addressed) interface on the server, em0. The blue cable connects the monitoring interface of the tap to the monitoring interface of the server, em1.



Do you see where I am going with this? What I can do now (for test purposes) is send and receive traffic on em0 and watch that traffic on em1. First I set up em1 to listen to what the tap sends it:

sensor# ifconfig em1 -arp up
sensor# tcpdump -n -i em1
tcpdump: WARNING: em1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1, link-type EN10MB (Ethernet), capture size 96 bytes

Now I send traffic out em0:

$ ping -c 1 www.taosecurity.com
PING www.taosecurity.com (66.93.110.10): 56 data bytes
64 bytes from 66.93.110.10: icmp_seq=0 ttl=55 time=15.240 ms

--- www.taosecurity.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 15.240/15.240/15.240/0.000 ms

Here is what em1 sees courtesy of the tap:

09:43:33.263664 IP 192.168.1.41.58947 > 216.182.1.1.53: 
 27655+ A? www.taosecurity.com. (37)
09:43:33.276900 IP 216.182.1.1.53 > 192.168.1.41.58947: 
 27655 1/2/2 A 66.93.110.10 (131)
09:43:33.277149 IP 192.168.1.41 > 66.93.110.10: icmp 64: echo request seq 0
09:43:33.296513 IP 66.93.110.10 > 192.168.1.41: icmp 64: echo reply seq 0
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

I think that is cool. What's the practical application? You could ship a monitoring appliance to a customer, with built-in tap. The customer connects her lines to the tap and the sensor listens via normal cable connection from tap monitor port to sensor monitor port. No external tap is needed. If the server fails completely, the tap will keep passing packets. I like it. If you would like to know more, email me and I will hook you up with the people I know at Net Optics.

If you'll be near Sunnyvale, CA next week, stop by for the Net Optics Think Tank on 18 May. I'll be speaking there around lunch time.

Read More

Speaking at Net Optics Think Tank Event in May

I will be presenting my thoughts on pervasive network awareness as facilitated by taps at the next Net Optics Think Tank. The event will take place on 18 May 2005 in their Sunnyvale, CA headquarters. I use Net Optics taps to gain access to traffic when performing network security monitoring.

Read More