Working with Port Security When Capturing Packets

When you get involved with packet analysis you will eventually encounter the most common issue: How will you capture packets? For example, will you use SPAN, TAP, or capture right from the server/client? Each option has its pros and cons.

Even though this is a very important question to consider an equally important consideration is what limitations you might have to work with. Things such as what types of taps, media (copper, fiber, or wireless) and network equipment configuration.

Common equipment configuration changes such as SPAN could cause an issue if the switch is already working hard of if an entire VLAN is SPAN’ed to a port causing bandwidth over subscription. Then there is the challenge when working with clients where configuration changes are subject to change management protocol. Unfortunately, in many cases I am onsite for a limited time and need to maximize time. The same argument holds true for the full-time staff since waiting for change management process delays the troubleshooting process and deters the analyst from considering this option in the future.

Another common switch configuration that I have encountered is port security. Even though every vendor has different specific port security options, I will provide a generic definition. Port security controls the input to an interface based on various criteria.The common option is to define a MAC address that is allowed to access a port.

I could cause a problem if I unknowingly connected to a client port configured with port security and used a device that allowed my MAC address to be seen as well as the client’s. If I’m lucky, I can get port security disabled or reconfigured, but in most cases, this is yet another example of something that falls within the client’s change management process.

I thought I would address the options I have when working with port security configurations. The details of my methodology and results are in the accompanying video but I will summarize for the benefit of the written piece.

Methodology overview

I will start with the obvious option, capture from the client or server. This approach is very convenient but brings many challenges along with it. One big one is that you might not have ‘admin’ or proper access. So, you can’t install a protocol analyzer. If you can install Wireshark or a similar analyzer, you need to figure out how much data the host can capture and its accuracy. Then there is the possibility that installing software on a client PC may add to the current issue.

If you have a TAP, check your documentation and see if it has a setting that will put your capture/monitor port in a ‘listen only’ mode. Every vendor has their own name for this configuration from listen only, no injection, prohit xmit, etc. Lastly, please test your Tap to ensure your configuration works. Now for some points to keep in mind. Since your computer can’t transmit packets, you will have to use WiFi or another Ethernet port if you need to access the internet or corporate network. The more important point is to understand the limitations of your capture device if you plan to use your laptop or desktop. I have seen in my lab where as little as 11 percent bandwidth can cause dropped packets.And even if you don’t drop them, the accuracy of the timestamps come into question.

This is where my Profishark comes in.it connects to my computer via USB3, so there is no additional MAC address introduced. As far as dropped packets or questionable delta times goes, I have tested the Profishark and found it will keep up at line rate and has accurate timestamps.