Wireshark EXAMPLE
Wireshark EXAMPLE
Wireshark EXAMPLE
ELEMENT 11 :
INTRODUCTION INTO
WIRESHARK
WHAT IS WIRESHARK?
Wireshark
What is Wireshark?
Wireshark is one of the best and most popular open source packet analyzers available today for
UNIX and Windows.
Wireshark
Wireshark utilises Pcap to capture the IP data from the network.
pcap (packet capture) consists of an application programming interface (API) for capturing network
traffic. Unix-like systems implement pcap in the libpcap library; Windows uses a port of libpcap known as
WinPcap.
Monitoring software may use libpcap and/or WinPcap to capture packets travelling over a network and,
in newer versions, to transmit packets on a network at the link layer, as well as to get a list of network
interfaces for possible use with libpcap or WinPcap.
The pcap API is written in C, so other languages such as Java, .NET languages, and scripting languages
generally use a wrapper; no such wrappers are provided by libpcap or WinPcap itself. C++ programs may
link directly to the C API or use an object-oriented wrapper. Wikipedia
Wireshark (and WinPcap)
Wireshark Application for Sniffing Packets
Ethernet Card
WHO USES WIRESHARK AND WHY?
Wireshark
Who uses Wireshark?
In a hub-based network, each host is placed in a large collision domain and can see the traffic
addressed to all hosts in that domain, therefore it is relatively easy to sniff in a hub based network.
However, networks with large collision domains are now uncommon due to the performance impact
of such a configuration and, as a result, switches have largely replaced hubs.
External
Network
PC running
Router Wireshark to
Sniff IP Traffic
Hub
Collision Domain
Packet Capture and Switches
In a switch-based network, each host is in its own collision domain and so can only see the traffic
addressed to itself.
This makes it much more difficult to sniff in a switched based network.
Since the price of switches has fallen in recent years, most networks now employ switches although
Hubs may still be present at the periphery of older networks.
External
Network
Router
Switch
Collision Domains
Packet Capture and Switches - Port Mirroring
In a managed switch, one port (the mirror port) can be configured to mirror all traffic travelling to and
from another port.
This allows the switch administrator to monitor traffic:
For any individual client
For the uplink connection
Some managed switches also have a port span feature, which allows the traffic from a number of
different ports (for example 1-5) to be directed to a single monitoring port (for example 6).
Though the use of this feature may cause throughput restrictions.
External
Network
Router PC running
Wireshark to
Port 6 on the Managed Managed Sniff IP Traffic
Switch is configured to Switch
mirror all traffic on Port 1 Port 6
Port 1
1. How we will facilitate legitimate sniffing of the network by the network administrator
2. How we minimise the risk of the network being sniffed by unauthorised persons
HOW CAN WE FILTER THE TRAFFIC?
Wireshark Capture and Display Filters
Wireshark has 2 primary types of Filtering:
Capture Filters - these are used to filter during sniffing* This allows the user to omit
unwanted IP Traffic from being captured in real-time, thus reducing the trace file size and
also the amount of effort required to isolate problematic/suspicious activity. The default
setting within Wireshark is off. Although you are able to create Profiles with whichever
default settings you wish to apply.
Display Filters allow the user to isolate particular packets or protocol types for display during
network packet analysis (although this is typically used for retrospective analysis, a display
filter can also function in real time). The default setting within Wireshark is off. Although you
are able to create Profiles with whichever default settings you wish to apply.
The primary difference between the above filters is that the Capture Filters are used to
control which IP packets are stored by informing Wireshark of the interesting traffic or
protocols that you would like to investigate/analyze. Display Filters allow you to further filter
the captured traffic and investigate/isolate particular communication flows and/or
protocols.
HOW CAN WE FILTER THE TRAFFIC?
CAPTURE FILTERS
Wireshark Capture Filters Cont
Wireshark Capture Filters...
As previously stated, by default, Wireshark attempts to capture all traffic presented to a host
interface.
1. On a busy network, the Operating System (OS) of the capturing host may not be able to keep
up with the traffic rate, resulting in lost packets.
2. On a busy network, even if the OS can keep up, the resulting data file maybe very large and
therefore slow to manipulate and analyse.
Wireshark Capture Filters Cont
Wireshark can capture using filters based on the following:
Once you have opened the Wireshark application, you can click on Capture > Options (from the
top menu), which will display the following screen:
Display filters are generally much more sophisticated than the capture filters.
Display filters can filter by the attributes of a very wide range of protocols.
These protocols can be at a number of different layers of the TCP/IP model (network stack) e.g. ip,
tcp, http, arp.
The full range of protocols which display filters can use is available in the on-line documentation.
http://www.wireshark.org/docs/dfref/
The screens that follow will show basic Display Filters and how to configure and apply them within
wireshark.
Wireshark Display Filters Cont
Once you have opened the Wireshark application, you have to first select a particular network
interface on your machine. In most of the cases the machine is connected to only one network
interface but in case there are multiple, then select the interface on which you want to monitor
the traffic.
From the top menu, click on Capture > Interfaces, which will display the following screen:
After selecting the interface you would like to capture data from (by ticking the adjacent box and
selecting Start), the trace will begin and you should see a screen similar to the one below:
Wireshark Display Filters Cont
The Display filter is simply entered into the filter field and then press return twice or click on Apply
Just like all other IP traffic, VoIP is affected by Latency, Jitter and Packet Loss.
Unlike your PC (which in most cases is very tolerant to fluctuation in these areas) , any disruption in
Voice transmission is immediately detectable by the user as poor sound quality, echo and breaks in
Audio and If there is high enough network congestion, this can even lead to failed calls.
Wireshark can be used to troubleshooting a VoIP network by allowing real-time and retrospective
analysis of the VoIP protocols. Wireshark can even recreated to calls to allow you to listen to the
quality of the conversation and confirm the users experience.
Just a simple network
This is a fairly simple VoIP network. Over the next couple of screens, we will use this example to
highlight many of the challenges in network analysis of VoIP traffic.
PBX PBX
Phone Phone
Switch
External Switch
Network
Switch
Router Router
Switch
Phone
Signalling Example 1
The signaling traffic takes a different path from the RTP traffic
Perhaps the most critical thing to understand about VoIP is that the signaling traffic and the voice
traffic are separate. The telephone signals its PBX to set up a call, which might set off more signaling
traffic. Eventually the phone stops signaling, and starts speaking real time protocol (RTP).
The path of the signaling can depend on how the PBXs are configured to handle the traffic.
PBX PBX
Phone Phone
Switch
External
Switch
Network
Switch
Router Router
Switch
Voice
Phone
Signaling
Signalling Example 2
In this case the phone talks RTP to the PBX, who talks RTP to the other PBX, who talks RTP to the phone.
This is three separate conversations that have been bridged together. Nothing is inherently wrong about
this configuration, you will see if often. However, consider what would happen if you took your packet
trace on one of the parts of the network that sees the traffic twice.
Seeing traffic twice isnt necessarily a bad thing unless it causes you to misinterpret your observations.
PBX PBX
Phone Phone
Switch
External
Switch
Network
Switch
Router Router
Switch
Voice
Phone
Signaling
Same conversation, different perspectives
When analyzing VoIP you are not only interested in the contents of the packets, but the time at
which they are received. These packets contain parts of a real time voice conversation.
One particular problem happens when you are looking at the same conversation from two different
vantage points. You will not see any jitter on one side of the conversation because the packet has not
traversed enough elements to experience jitter.
PBX PBX
Phone Phone
A C
Switch
External
Switch
Network
Switch
Router Router
Switch
Here you see B A Here you see A B
jitter, but not A - B jitter, but not B - A Phone
B
NAT changes the address
To further complicate the issue, you might have NAT involved. NAT changes the source or the
destination address of the packet in order to alter routing, or to hide devices behind a gateway.
NAT often causes problems with VoIP network because of this change in address, especially when
transiting the Internet.
You must understand how the addresses are being changed, and adjust your capture filters
accordingly depending on which side of the NAT gateway youre on.
PBX PBX
Phone Phone
D
Switch
B C
External
Switch
Network
Switch Router
Router
Src=C Src=A
Dst=D Dst=B Switch
The address can also A
Change within the cloud!
Phone
UNDERSTANDING WIRESHARK
Wireshark Supported Protocols
This presentation has been developed with Wireshark Version 1.6.3 (SVN Rev 39702 from /trunk-1.6)
The Packet
Details Pane
(Showing
explode-able
view of packet
contents)
Capturing too much data means that youll have a lot of stuff
to sift through as you troubleshoot. However, data that you
dont capture cant be analyzed.
You will find information about the protocol under the protocol heading. Some protocols have sub
protocols, such as the Session Description Packet within SIP, and those are displayed here (see the
green box)
The info column usually has some more details about whats going on in the particular packet. Look at
the red box, you can see that an invitation is made, and we can confirm that the call was setup
normally with the presence of the ACK following the 200 OK with session description. This is a normal
SIP call setup scenario.
Quality of Service for VoIP networks
Phone Phone
Switch
External
Switch
Network
Switch
Router Router
Signaling
Tagged RTP
Untagged
RTP
Use color to show QoS problems
In the illustration above, a coloring rule has been applied to make any packet set for expedited
forwarding have a red foreground and a white background. From View, coloring rules, you can add a
color filter. By default the new filter will go at the bottom, so you want to push it up above the UDP
rule of black on blue.
Once the coloring rule is in place, untagged voice traffic shows up easily.
Here, traffic from 192.168.1.156 is tagged EF but the return traffic isnt. You would then start your
troubleshooting at 192.168.1.1.
The coloring method is much more efficient than digging into each packet and looking through the IP
header for the QoS tag.
Because RTP doesnt have a defined port, Wireshark uses the signaling details to figure out which
port is being used for RTP, and then decodes the packets accordingly.
In some occasions, Wireshark can get it wrong and not match the RTP with the correct signaling
traffic. In this instance, the RDP packets may appear as just UDP packets (or some other form of UDP
protocol depending on which port is in use).
To correct this problem, the simplest way is to right click the incorrectly interoperated RTP packet
and select decode as and select RTP. Alternatively you can tell Wireshark to look more closely at
UDP packets to determine if they are RTP by checking the Try to decode RTP outside of
conversations box.
Each of the encapsulation layers are expandable/collapsible to allow the user to look at the data
contained within it.
The example above shows the layer 5 (session layer) expanded to show SIP header associated with a
call Initialization or Invite.
THE SIGNALING TRAFFIC
Signaling protocols
Below are several well known Signaling Protocols:
SIP (Session Initiation Protocol widely used protocol for controlling communication sessions such
as voice and video calls over Internet Protocol (IP)),
MGCP (Media Gateway Control Protocol Used for the control of Voice over IP (VoIP) calls by
external call-control elements known as media gateway),
SS7 (Signalling System 7 This is a set of telephony signalling protocols which are used to set up
most of the world's public switched telephone network)
GSM (Global System for Mobile Communication this is a standard set developed by the European
Telecommunications Standards Institute (ETSI) to describe technologies for second generation (2G)
digital cellular networks.)
SCCP (Cisco Skinny - Proprietary Cisco protocol for Terminal Control for use with VoIP)
The role of signaling
The primary role for any signaling protocol is:
This example shows a health SIP call with no 4xx, 5xx or 6xx errors.
Note: You can also apply a filter at the Create Stat window, to isolate a
Specific call or communication session:
ANALYZE THE RTP TRAFFIC
The properties of RTP
RTP simulates the real time voice normally carried over a wire:
4KHz voice bandwidth = 8KHz sampling rate (Nyquist[1])
8 bits/sample * 8KHz = 64,000bps (DS0[2])
Delay and Latency - Delay and latency are similar terms that refer to the amount of time it takes a
bit to be transmitted from source to destination.
One way to view latency is how long a system holds on to a packet. That system may be a single
device like a router, or a complete communication system including routers and links.
Jitter
Jitter should be less than 30ms
Delta - is simply the difference in time between the current packet and the previous packet in the
stream.
Jitter - Jitter is delay that varies over time (basically the mean average of the Delta).
Packet loss
Packet Loss should be less that 0.1%
Latency <= 100ms (one way)
Jitter buffer,
Transcoding
delay
Path delay
External
Network
Serialization
delay
External
Network
Click on the call you wish to analyze and then the Flow button.
Here we can quickly see a summary of the key factors that affect voice quality and Wireshark will
even put a X in the Pb? (Problem) field to indicate that there was a quality issue with a particular
RTP stream.
If we apply previously discussed guidelines (Jitter should be less than 30ms and Packet Loss should
be less that 0.1%) we can clearly see that the problem relates to Packet Loss because the Jitter value
for the selected RTP stream is within tolerance (even though the was a spike in the call highlighted
by the high value Max Delta).
Partially audible conversation cont...
If you click the Analyze button on the RTP Streams screen, you can then get more detailed information
on a particular stream.
The screen above shows a detailed view of the same RTP stream analyzed within the previous screen.
We can see from the multiple Wrong sequence nr. indicators and the 116 sequence errors (shown at
the bottom of the screen) that this RTP stream is not only suffering from Packet loss (19.43%) but also
has a substantial number of packet receiveds out of order.
As explained previously within this presentation, out of order packets (once the buffers are full), will be
dropped. This will then add to the poor audio quality experienced during this call.
Audio replay
If the voice utilized the G.711 audio codec, Wireshark can also listen/playback to the content of the
voice call.
Next select the call you would like to replay and click the Player button.
If you select .au for the format setting and click OK,
the voice call will be saved to your hard drive
You can be play the file with an audio program that support
the .au format such as Windows Media Player, RealPlayer and Apple Quicktime Player.
INSTALLING WIRESHARK
Install under Windows
Download
Install
Install under Debian/ Ubuntu
To install under Linux, just enter the following command into the su prompt:
If the signaling or the voice is using a compression codec (such as G.729), you wont be able to
replay the audio.
If the signaling or the voice is encrypted, you wont be able to decode it.
OTHER NETWORK ANALYSIS TOOLS
Some Other Network Analysers
NMAP cli and gui
Network Associates Sniffer popular commercial product
TCP Dump basic command line utility (UNIX)
Microsoft Network Monitor supported only for Windows OSs
WinDump a Windows version of TCP Dump
Snort An intrusion detection system
DSniff aimed at specifically sniffing passwords
Ettercap as DSniff but with more functionality
End Of Element 11 Introduction into Wireshark
Next Element :
Element 12 Quality Of Service (QoS) and Cost of Service (CoS)