Вы находитесь на странице: 1из 69


What is Wireshark?

Wireshark is a network packet/protocol analyzer.

A network packet analyzer will capture network packets (as they travel on the wire) and
try to display that packet data in a human readable form by utilising methods such as
colour coding and grouping/filtering similar or related IP traffic.

Application such as Wireshark are most commonly used for:

1. Troubleshooting problems on the network
2. Analyzing the performance of a network to discover bottlenecks
3. Analyzing the operations of applications.

Wireshark is one of the best and most popular open source packet analyzers available today for
UNIX and Windows.
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

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

WinPcap open source library for packet capture

Operating System Windows & Unix/Linux

Network Card Drivers Ethernet/WiFi Card

Ethernet Card
Who uses Wireshark?

Network administrators use it to troubleshoot network problems

Network security engineers use it to examine security problems

Developers use it to debug protocol implementations

Students/Pupils use it to learn about network protocol internals

Why Monitor and Analyze Network Traffic?
From the network administrators viewpoint, Wireshark can be use to
Troubleshoot problems on the network
Analyse the performance of network sections to identify bottlenecks
Perform network intrusion detection (retrospective)
Log network traffic for forensic evidence
Analyse the operation of network applications
Trace the source of a DoS attack
Detect spyware
Detect compromised hosts possibly a botnet member

From the network intruders viewpoint, Wireshark can be use to

Capture clear-text usernames and passwords
And those which are trivially encrypted
Passively map a network
Passively fingerprint the OS of network hosts
Capture other confidential information
Packet Capture Hubs/Repeaters
In order to capture the required network traffic, it is necessary to consider the relevant network
hardware and architecture.

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.


PC running
Router Wireshark to
Sniff IP Traffic


Client Client Client Client Client

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.




Client Client Client Client Client

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.


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

Client Client Client Client Client

Packet Capture - Summary
When designing a network architecture, we need to consider the following:

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
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
Wireshark Capture Filters Cont
Wireshark Capture Filters...

As previously stated, by default, Wireshark attempts to capture all traffic presented to a host

There are two potential issues with this default behaviour:

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:

Host names and IP addresses

MAC addresses
TCP / UDP port number
Protocols (eg arp, ip, ipx, tcp, udp, etc)

These can be combined using logical operators. E.g.:

host panasonic.co.uk and port 80
dst host panasonic.co.uk and (port 80 or port 443)
Wireshark Capture Filters Cont
There are several ways to access the Capture Filter screen.

Once you have opened the Wireshark application, you can click on Capture > Options (from the
top menu), which will display the following screen:

This box must be ticked to allow you to

capture all IP traffic received by your
network interface card (and not just the
traffic destined for your PC)

Enter you Capture Filter string here

If you intend to capture over a long period

of time, Wireshark can create a collection
of small (easier to process) files based on
your preferences such as max file size,
number of packets or duration of time.
Wireshark Display Filters
Wireshark Display Filters...

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.


The screens that follow will show basic Display Filters and how to configure and apply them within
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

Examples of some simple display filter strings:

sip This will instruct Wireshark to only display SIP packets
rtp This will instruct Wireshark to only display RTP packets
bootp This will instruct Wireshark to only display Bootstrap protocols such as DHCP
http contains GET This will apply a filter that will only show packets which are of type HTTP that contains a GET request
not tcp.port == 80 - This will apply a filter that will show all traffic except HTTP
ip.src == - This will apply a filter that will show all traffic from a specific IP address
ip.dst == - This will apply a filter that will show all traffic to a specific IP address
ip.src == and ip.dst == - This will apply a filter that will show all traffic to and from specific IP addresses
Exposing VoIP Problems Using Wireshark
VoIP (Voice over IP) is a Protocol that is optimized for transmission of voice over an IP
infrastructure such as an internal Local Area Network (LAN) or an external Wide Area Network
(WAN) such as the Internet (This is also referred to as IP telephony)

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.


Phone Phone


External Switch
Router Router


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.


Phone Phone


Router Router

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.


Phone Phone


Router Router

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.


Phone Phone


Router Router

Here you see B A Here you see A B
jitter, but not A - B jitter, but not B - A Phone
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.


Phone Phone


Switch Router
Src=C Src=A
Dst=D Dst=B Switch
The address can also A
Change within the cloud!
Wireshark Supported Protocols
This presentation has been developed with Wireshark Version 1.6.3 (SVN Rev 39702 from /trunk-1.6)

By default, Wireshark can recognise

1170 different protocols (you can
also manually add new protocols if
Starting a Trace
To start a packet capture, simply click on the Capture menu option and click Start next the
interface you wish to capture from.
Wireshark Windows Panes
Main Menu

The Packet List

Pane (Summary
of all

The Packet
Details Pane
view of packet

The Packet Bytes

Pane (Showing
Raw data in Hex)
Setting capture filters
As previously mentioned Wireshark uses two types of filters,
capture and display.

Capture filters describe what data is pulled off the wire.

Display filters allow you to show or hide data thats already
been captured.

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.

To make matters worse, some VoIP protocols dont run on

predictable ports. RTP runs on random UDP ports. SIP
normally runs on 5060/UDP, but if you have a two line phone,
it can also run on 5061. H.323 runs on many different ports.

A capture filter of udp is generally good enough for SIP

because theres usually not much background UDP traffic.
Filtering by hosts is also good, but you have to make sure that
you know which hosts are involved in the conversation.
The Packet List Pane
The packet list pane shows a great amount of detail about the packets that Wireshark can decode.

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


Router Router

The ToS (Type of Service)

octet* within the IPV4
header is used to allow
tagging or classification of
the IP Payload. This is
where the values used by
Layer2 and Layer 3 QoS
e.g. ToS and Differenciated
services (DSCP/Diff Serv)
are stored.
Add a column for DSCP


Tagged 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 is tagged EF but the return traffic isnt. You would then start your
troubleshooting at

The coloring method is much more efficient than digging into each packet and looking through the IP
header for the QoS tag.

View -> Coloring Rules

Are you running a proprietary PBX?
As shown in a previous screen, Wireshark knew the signaling traffic was SIP because it was using UDP
port 5060 (the standard port for the SIP protocol).

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.

Edit -> Preferences, Protocols -> RTP

Packet Details Pane
The Packet Details pane allows you to see whats inside the packet in a human readable format.

Each of the encapsulation layers are expandable/collapsible to allow the user to look at the data
contained within it.

Each of the layers correspond directly to the OSI 7 Layer model.

The example above shows the layer 5 (session layer) expanded to show SIP header associated with a
call Initialization or Invite.
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)),

H.323 (Signalling protocol designed to provide audio-visual communication),

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:

To indicate to the remote end that a call is coming,

Establish the codec to be used for voice, video (or other form of peer to peer communication) ,
Establish the addresses of the endpoints,
Get out of the way (Step back from the communication once the connection has been established),
Tear down the connection once the communication process is complete.
Signaling Protocol Summary Info
It is possible to generate statistical information about certain protocols such SIP to
summarize/categorise the type of traffic within any given trace.

This example shows a health SIP call with no 4xx, 5xx or 6xx errors.

Telephony -> SIP ->Create Stat

Note: You can also apply a filter at the Create Stat window, to isolate a
Specific call or communication session:
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])

A Codec (G.711u/A law, G.729, G.726, etc)

Most codecs use 20ms voice samples = 50pps
Even with compression, you have a fairly consistent packet rate, only the size changes.
Three factors that affect voice quality
Latency should be less than 100ms (one way)

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 should be less than 30ms

Delta - is simply the difference in time between the current packet and the previous packet in the

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,

Path delay



Hi, how are you? Hello? Oops, sorry, go ahead

Fine, I oh hello, go ahead
Packet Loss the than 0.1%


Some RTP Packets being

dropped in transit

Conversation would sound like

Hi Pa *POP* How *POP*e you?

Hi Bo How you?
Jitter Less than 30ms

Better late than never? No.

You can use Wireshark to analyze the Jitter value

through the following menu option:
Telephony -> RTP -> Stream Analysis
Exposing VOIP problems
VOIP suffers from three common problems

1. When a number is dialed, the phone idles & no ringing is heard,

2. Only one party hears any audio,
3. Missing parts of a conversation due to packet loss.
No Ringing

Its important to utilise a combination of the tools

available to correctly diagnose an issue.

We can begin a detailed analysis by selecting VoIP

Calls under the Telephony menu and then select the
Flow option to see all communication related to
particular call.

The Graph Analysis screen example shows a Busy

Here from the service provider but the cause is not
apparent unless you look at the Packet List pane
(above) to get a more holistic view. Then you can see
that the Registration is failing with what appears to be
an invalid password (401 Unauthorized)

So the next step in this scenario would be to check the

Username, Password and Authentication ID is correctly
entered into the client device.
One sided Audio
Using advanced analysis tools
As explained within the previous screen, we can use the Graph Analysis screen to see a visual
representation Flow Graph of VoIP communications. To get to this screen you need to select the
following: Telephony->VOIP calls

Click on the call you wish to analyze and then the Flow button.

From this screen, if we inspect the

communications in this example we
can see that the RTP travels from the
iphone to the remotephone
(depicted by the direction of the arrow,
however if there is not return RTP we can
deduce that there must have been one
way audio and the direct would be from
the remotephone to the iphone.
Partially audible conversation
Partially audible conversation can be caused by out of order or lost packets.
The easiest way to verify the cause is to utilize the Stream Analysis function within Wireshark.
This can be access from the Main Menu -> Telephony -> RTP -> Stream Analysis.

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.

This feature is accessible from Telephony->VOIP calls

Next select the call you would like to replay and click the Player button.

On the next screen, select the Decode button.

Audio replay
After ticking the RTP stream you would like to listen to, you will now be able to replay the
conversation through you PC speakers.
Audio Export
If you wish to export the Audio, you can utilize the Save payload button with thin the Stream
Analysis screen.

Once clicked, you will be presented with you save options.

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.
Install under Windows
Install under Debian/ Ubuntu
To install under Linux, just enter the following command into the su prompt:

# apt-get install wireshark

What Wireshark Cannot Do.
It cannot be used to automatically build a topology (map) of the Network,

It cannot be used to generate IP Traffic Its a Passive tool,

It will only show detailed information about protocols it understands,

It can only capture data as well as the OS\Interface\Interface driver supports.

Here are a few thing to consider with regards to VoIP call analysis and Wireshark:

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.
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)