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:
Now I send traffic out em0:
Here is what em1 sees courtesy of the tap:
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.
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.
Comments
One questions: Do the taps pass traffic even when unconfigured and/or when the power is out to the computer? The external taps continue to pass traffic even when powered down, which to me is an important feature.
I hate it when that happens
I meant to say:
Reread the article and found the line about passing traffic that I missed on the first run through it.