At its core, Wireshark is a network forensic tool, and at its core, Voice over IP is a networking protocol. This may seem obvious to those within the network forensics field, but to the typical VoIP administrator, the fact that network forensics is exactly what is occurring when they run a Wireshark capture on the network may not be readily apparent.
But when you strip away the reasons why the capture is running, the fundamental forensic question that must be answered is this: What happened on my network?
Looking at it from this perspective, Wireshark VoIP and unified communications use provide essential information for VoIP admins within a UC environment.
Using Wireshark to validate VoIP encryption
All too often, vendors say that their product can perform certain functions, but in reality, their product may not perform exactly as advertised. For example, a common security technique within a UC environment is to encrypt the control channel for the Session Initiation Protocol when an IP phone requests service from a SIP server. The encryption mechanism in this case would be Transport Layer Security (TLS), and this is typically done over TCP port 5061 (which is associated with SIP). So, with a Wireshark capture running in line with the SIP server, a VoIP administrator could type in the following filter:
ssl.record.version == 0x0301 && tcp.port == 5061
This string instructs Wireshark to filter out all traffic except for TLSv1 traffic on TCP port 5061. If, after placing an allegedly secure call from an IP phone to the SIP server, VoIP administrators don't see any traffic appearing within the Wireshark screen, they should check the technical specifications to ensure that their products don't use some obscure port for TLS traffic. They should also check any accompanying documentation in the event that some other encryption mechanism is utilized for VoIP calls, as this may explain the lack of captured packets. Otherwise, the vendor should be contacted immediately for clarification.
Checking security by looking for null values in SIP headers
To say Wireshark is a useful security tool is akin to saying paper towels come in handy when cleaning. Pointing to various security utilities that Wireshark provides may seem redundant, but I would be derelict in my duties if I did not point to at least one of the lesser-known use cases for Wireshark in a UC environment. Most UC environments that utilize SIP have some type of rule in place that disallows for null values in certain SIP headers. One such rule may involve an INVITE message with a null value. So, the VoIP administrator could type in the following filter:
sip.Request-Line == "INVITE null"
This filter will display all INVITE messages with a null value, but administrators can play around with this filter and select a different field in which to look for null values, as each organization will allow for different fields to have a value of null. The vigilant administrator should always keep in mind that malformed packets, such as those with null INVITE values, can have an adverse effect on their UC environment, and special attention should be given to any they come across.
Training new VoIP IT admins to run Wireshark captures
More Wireshark VoIP and UC resources
Detecting malicious traffic on VoIP-enabled networks with Wireshark
How to get a Wireshark VoIP packet capture
Learn how to parse your VoIP traffic with Wireshark filtering
How to sniff network traffic using Wireshark
Training is an often talked about, but little understood concept within the realm of IT. Quite frequently, when the subject of training arises, many think in terms of a formal classroom setting, a conference, or worse yet, sitting through a PowerPoint presentation. As many experienced IT administrators will explain, however, IT is a field that one must simply do, and VoIP administration is no different in this respect. Once the decision is made to throw a new employee into the fire that is an operational network, the dilemma many senior administrators have to grapple with is how much responsibility to give the new guy. Too little responsibility may result in the new employee getting bored and disenchanted. Too much responsibility may result in a disaster for the network, as the new guy may not be familiar with the many nuances that are inherent to a specific network. So, what to do? Why not instruct new personnel to conduct Wireshark VoIP captures on the operational network? Let's unpack this further.
First, Wireshark is completely passive, so any worries regarding inadvertent tampering or damage to the network are rendered moot. Second, what better way to delve into network heuristics than to examine the packets entering and exiting the network? When different network events occur -- like a simple phone call -- have new personnel examine the capture after the event has taken place, and then have them follow the various User Datagram Protocol (UDP) and TCP streams. This is done by simply right-clicking a packet and selecting Follow UDP Stream. Have them play around with other events, like an intrusion, and give new personnel the opportunity to diagnose what happened. VoIP administrators may be surprised at how much can be gleaned from simply examining different network events.
VoIP and network admin capabilities must be equal
It has quickly become a necessity that the networking capabilities of a VoIP administrator be on par with those of any administrator of a traditional IP network. One could even say that the differences between a VoIP administrator and a traditional IP network administrator have essentially become less and less apparent when they're subjected to closer scrutiny. With the dwindling of the distinctions comes a set of responsibilities for those within the voice industry that have traditionally been the responsibility of others. One of these responsibilities involves understanding the Wireshark packet capture tool and how it can be of use in a VoIP and broader UC environment.