According to Richard Bejtlich and to my past experiences I also prefer Network TAPS to R/SPAN technology. When someone ask to me why I prefer TAPS I start a long discussion with examples and sensations. I never though to 5 schematic points to resume all the security and non security issues in aid of TAPS. For this reason I think his words are really clear and concise.
I’m (Richard) using the following points when discussing the situation.1) Taps free SPAN ports for tactical, on-demand monitoring, especially intra-switch monitoring. Many switches have only two ports capable of SPAN, and some offer only one. If you commit a SPAN port for permanent monitoring duties, and you need to reassign it for some sort of troubleshooting on a VLAN or other aspect of the traffic, you have to deny traffic to your sensor while the SPAN port is doing other work. Keep your SPAN ports free so you can do intra-switch monitoring when you need it.2) Taps provide strategic, persistent monitoring. Installing a tap means you commit to a permanent method of access to network traffic. Once the tap is installed you don’t need to worry about how you are going to access network traffic again. Taps should really be part of any network deployment, especially at key points in the network.3) Selected taps do not permit injected traffic onto the monitored link. Depending on the tap you deploy, you will find that it will not be physically capable of transmitting traffic from the sensor to the monitored link. This is not true of SPAN ports. Yes, you can configure SPAN ports to not transmit traffic, and that is the norm. However, from my consulting days I can remember one location where I was told to deploy a sensor on a box with one NIC. Yes, one NIC. That meant the same NIC used for remote SSH access also connected to a switch SPAN port. Yes, I felt dirty.4) What taps see is not influenced by configuration (as is the case with SPAN ports); i.e., what you see is really what is passing on the link. This is key, yet underestimated. If you own the sensor connected to a SPAN port, but not the switch, you are at the mercy of the switch owner. If the switch owner mistakenly or intentionally configures the SPAN port to not show all the traffic it should, you may or may not discover the misconfiguration. I have seen this happen countless times. With a network tap, there’s no hiding the traffic passing on the monitored link. Many shops have been surprised by what is traversing a link when the finally take a direct look at the traffic.5) Taps do not place traffic on a switch data plane, like a SPAN port does. This point is debatable. Depending on switch architecture, SPAN ports may or may not affect the switch’s ability to pass traffic. By that I mean a SPAN port may not receive all traffic when the switch is loaded, because forwarding may take precedence over SPANning.
Making a Network Tap is also really cheap and very easy. Network Tpas have not the hardware capability to send signal on the cable so what you need to build a tap is to extract the RD cables from you network following this patter:
At the end of the day, if you wanna put on your home network two taps (one for security monitoring and one for statistical monitoring) what you see is something like this one.
Anyway, I don’t wanna write about how to build a tap, for this you can find a great guide right here,today I have learned how to support my “taps thesis” using only 5 observations.Â
Can anyone recommend the well-priced IT automation utility for a small IT service company like mine? Does anyone use Kaseya.com or GFI.com? How do they compare to these guys I found recently: N-able N-central remote control
? What is your best take in cost vs performance among those three? I need a good advice please… Thanks in advance!