Nutter helps a reader with port monitoring
As more and more of our network infrastructure gets older and/or fails, we are going to a switched configuration instead of the hubs that were initially used to set up the network. We have used mostly Cisco switches at this point but are open to other vendor’s offerings. In a previous column you talked about how to monitor certain ports using an inline hub or Ethernet tap. Is there another option without having to unplug and plug connections to put this type of monitoring in place?
Via the Internet
When going to a switched network, one thing you will want to look at closely is going to a “managed” vs. an unmanaged switch. The managed version will cost you more per port in most cases but gives you additional functionality that is well worth the difference. One of the things you get is the ability to “mirror,” or span, a port. What this means is you can send a copy of the data coming into and out of a specific port on a switch to a designated port on the same or different switch.
This gives you the ability to shift what you’re monitoring on the fly without having to move any cabling. Depending on the level of sophistication of a switch, the commands to do this may be named differently but should accomplish the same thing. For example, on a Cisco 6500 series Catalyst switch, you will use the monitor command. On a less-complex Cisco switch, the command syntax will be Set Span, followed by the port information and how you are watching the traffic (in only, out only or both). Other vendors will probably have a different command syntax to use.
One option with Cisco switches is that you can mirror a port on one switch and have the data copied to a port on a switch elsewhere on the network. Depending on how much monitoring/sniffing you have to do at the same time, you can have different span/mirror sessions running – each watching a different port and going to a different destination port. If you’re doing a lot, you’ll want to make sure you have sufficient bandwidth on the network backbone so as to not impact users and business-critical needs. I have dealt with port mirroring on Cisco switches a lot lately and noticed one thing that was very interesting – the destination port on a mirror/span configuration doesn’t get an IP address from the DHCP server on the network and because of that seems to be a little more protected unless you were able to launch an attack at a specific port on the switch.
If you end up having different vendors’ switches on your network, your port mirroring/spanning will probably be limited to being done only on the same switch. Talk to the vendors you’re looking at to see if this feature is available/supported between different vendors they’ve tested with. It would be ideal to have all one vendor’s switch solution on the network to make this easier. Once you get used to setting up port mirroring, think about writing up a little cheat sheet on how to do it – that should save you time the next time you have to do it. Also think about dedicating at least one port per switch to mirroring to help keep things consistent on the network between switches.
