An introduction
to WireShark
Volume Number: 27
Issue Number: 03
Column Tag: Networking
An introduction
to WireShark
The graphic-interface
protocol analyzer
by Mihalis Tsoukalos
Introduction
In June 2006, Gerald Combs, the creator of the Ethereal package, renamed it to WireShark as he changed his job and could not use the old name anymore. Nowadays, most people use WireShark and Ethereal is just history! This article will present you WireShark, which is a very popular, and capable open source network protocol analyzer.
You may ask what makes WireShark different apart from the fact that is free? Why not use tcpdump? The main advantage of WireShark is that it is a graphical application. Figure 1 shows WireShark running on a Mac.
Figure 1: WireShark running for the first time
Running WireShark and basic Usage
The WireShark version that is going to be used in this article is from the MacPorts Project and has the following characteristics:
mtsouk$ wireshark -v
wireshark 1.4.1
Copyright 1998-2010 Gerald Combs <gerald@wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled with GTK+ 2.22.0, (64-bit) with GLib 2.26.0, with libpcap 1.1.1, with
libz 1.2.5, without POSIX capabilities, without libpcre, without SMI, with
c-ares 1.7.3, without Lua, without Python, without GnuTLS, without Gcrypt, with
MIT Kerberos, without GeoIP, without PortAudio, without AirPcap.
Running on Darwin 10.5.0 (Mac OS 10.6.5), with libpcap version 1.1.1, with libz
1.2.5.
Built using gcc 4.2.1 (Apple Inc. build 5664).
To install this version of Wireshark, install the latest MacPorts from http://www.macports.org and then issue the commands:
sudo port selfupdate
sudo port install wireshark
The Wireshark download, compile and install sequence will take some time (a few hours, depending on your machine).
A more simple option is to download a precompiled binary from http://www.wireshark.org/download.html. Either the MacPorts or precompiled version will work just fine for following along in this article.
WireShark requires X11 (a.k.a. XWindows) in order to run, but you are lucky as Mac OS X comes with XWindows.
If you run WireShark as a normal user, you will not be able to use any network interfaces for capturing network traffic due to UNIX permission reasons. I find it more convenient to run WireShark as root (sudo wireshark) when capturing data and as a normal user when analyzing network data. When running WireShark as root, it displays the warning message shown in Figure 2.
Figure 2: WireShark's warning when running as root
After running WireShark as root, you will be able to see the list of the available network interfaces. In my case, the Network Interface List is shown in Figure 3. Please note that not all the displayed interfaces are in use.
Figure 3: The available network interfaces (Interface List)
You can compare Figure 3 to Figure 1 and see that in Figure 1 WireShark displays no network interfaces. If you try to start capturing network traffic without first selecting a network interface you will get an error message similar to what Figure 4 shows.
Figure 4: Trying to capture network data without a network interface
The easiest way to start capturing network packages is by clicking your preferred interface as shown in Figure 3. Then WireShark will be populated with data similar to Figure 5. If you know nothing about TCP, IP or UDP you may find the output difficult to read or understand. The next article in this WireShark series will go into more detail on that, and it will not be that difficult.
In order to stop the capturing process you must select Capture and then Stop from the menu of WireShark. Alternatively, you can press the fourth icon from the left, the one with the white x with the red background. This button can only be pressed while you are capturing network data.
Figure 5: WireShark is running!
Using the described method to start capturing you cannot change any of the default WireShark Capture Options. You can see the Capture Options by selecting Capture and then Options from the menu. You can see the available options in Figure 6.
There you can select the Interface (en0), see your IP address (192.168.1.10), apply any Capture Filter (in this case there is no Capture Filter), put your network card in promiscuous mode, and save your capture data in one or multiple files (in this case the capture data is not being automatically saved). You can save your data afterwards but when capturing lots of data, it is considered a good practice to first save and then examine the captured network traffic. When you put your network card in promiscuous mode, you allow the network device to catch and read every network packet that arrives to it even if the receiver is another device on the network. Network packets still go to their initial receiver.
You can also choose to stop packet capturing after a given number of network packets or a given amount of time or a given size of data (in bytes).
Figure 6: WireShark Capture Options
WireShark Filters
The network data that WireShark may display can be too much for a human to watch and understand; especially on busy networks. Usually, when using WireShark we want to examine a given problem or situation or even watch for unusual network activity. This means that it would be nice if the network traffic can be filtered at capture time, avoiding the creation of huge capture files. WireShark offers this capability, and this article section will show you how to achieve it.
First, back in Capture Options you write your filter in the Capture Filter field. In this case, I wanted to capture traffic from and to the 208.67.222.222 IP address which is an openDNS server. A practical reason to do so is that you heard that this particular DNS server is either down or has been deleted and you want to know if anyone from your network is still using it.
Figure 7: Capturing the traffic of the 208.67.222.222 IP address
After a while some data was displayed as you can see in Figure 8.
Figure 8: The captured packets
Generally, Display Filters are considered more useful and versatile than Capture Filters because most of the times you do not know in advance what you will capture or want to examine. Nevertheless, applying filters at capture time can save you time and disk space and that is the main reason for using them.
WireShark has a way of telling you if a Display Filter is syntactically correct or not. When the background turns to light green, then the filter is syntactically correct. When the syntax is erroneous, the background becomes pink. You can see both cases in Figure 7. The result of an inaccurate (yet syntactically correct) filter at capture time is no captured data so you may recognize it the hard way.
Figure 9: Syntactically right (up) and wrong (down) display filters
What you can also notice in Figure 9 is that WireShark is smart enough to understand invalid IP addresses such as 192.168.257.10. The presented Display Filter displays only traffic that originates or goes to the 192.168.1.10 IP address.
The good thing about both types of Filters in WireShark is that you can save them in order to have them at your disposal and not have to type them again which sometimes can be very tricky.
The main difference between the two types of filters is that Capture Filters are activated before the capturing phase and Display Filters can be applied either during or after capturing. Display Filters can also be applied after reading a previously saved capture file.
If you would like to learn more about Display Filters—and you should!—you must wait for a forthcoming article in the WireShark series that is devoted to explaining Display Filters in more detail.
Network traffic
Before going into more detail about WireShark, I will talk a little about network traffic in Ethernet networks that use the TCP/IP protocols. When we say TCP/IP we not only mean the TCP and IP protocols but many others including ARP, BOOTP, UDP, ICMP, FTP, etc.
Information is transferred using packets. Each packet has a header and a body. The header contains information needed by the protocol whereas the body contains data. Many packets come and go all the time in an Ethernet network.
Some protocols are reliable whereas some other protocols are not reliable which means that they do not guarantee packet delivery–this is not always a problem but the application must deal with it if needed.
WireShark, amongst other things, captures the packets, analyzes and displays them in a human readable format. Using WireShark, you can then follow a TCP/IP "conversation" between two computers, see the data of the packets, etc. Also, WireShark understands the different TCP/IP protocols.
Capturing Network Traffic
As you can easily see by the number of available protocols, there are many things going on, especially on busy networks. Before you start capturing, it is better to have a given issue in mind that you want to solve or examine. This is the first step for successful analysis of network traffic.
Save, Open, Export, Merge and Print
WireShark allows you to read and analyze already captured network data from a large amount of file formats including tcpdump, libpcap, Sun's snoop, HP's nettl, K12 text file, etc.. This practically means that you can read almost every kind of captured network data with WireShark while new file formats are frequently added. It is more likely that WireShark cannot read a file due to invalid packet types than WireShark's inability to read it!
Similarly, WireShark allows to save your network capture data in a variety of formats. You can see the available formats in Figure 10.
Tip: you can even use WireShark to convert a file from a given format to another.
Figure 10: Supported formats for saving a file
WireShark also allows you to merge a pre-captured file with an existing file as you can see in Figure 11.
Figure 11: Merge with Capture File window
As you can see in Figure 11, you can merge using one of the following options:
Prepend packets to existing file: add the packets of the selected file before the existing packets.
Merge packets chronologically: merge the packets of the selected file with the existing packets in chronological order.
Append packets to existing file: add the packets of the selected file after the existing packets.
You can even export an existing file as a text file, using the File -> Export menu option that can be seen in Figure 12. This option is mainly for manually processing network data or using it as input to another software.
Figure 12: The Export option
There is also an option to print your packets. I have never used this option in real life work but it may be useful to print packets and their contents for educational purposes.
Analyzing DNS traffic
DNS queries are very common in TCP/IP networks. A DNS query creates little traffic and therefore is an appropriate example for learning purposes.
I ran the following command:
$ host -t ns mactech.com
mactech.com name server ns9.zoneedit.com.
mactech.com name server ns13.zoneedit.com.
Figure 13 shows the two packets that were generated in order to send the query and get the answer.
Figure 13: A DNS query
The two network packets were as follows:
No. Time Source Destination Protocol Info
206 1.529812 192.168.1.10 195.170.0.1 DNS Standard query NS mactech.com
Frame 206: 71 bytes on wire (568 bits), 71 bytes captured (568 bits)
Ethernet II, Src: Apple_f1:c9:e8 (60:fb:42:f1:c9:e8), Dst: Arcadyan_8c:eb:27 (00:1d:19:8c:eb:27)
Internet Protocol, Src: 192.168.1.10 (192.168.1.10), Dst: 195.170.0.1 (195.170.0.1)
User Datagram Protocol, Src Port: 58460 (58460), Dst Port: domain (53)
Source port: 58460 (58460)
Destination port: domain (53)
Length: 37
Checksum: 0x8594 [validation disabled]
Domain Name System (query)
[Response In: 218]
Transaction ID: 0x26ed
Flags: 0x0100 (Standard query)
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
mactech.com: type NS, class IN
Name: mactech.com
Type: NS (Authoritative name server)
Class: IN (0x0001)
No. Time Source Destination Protocol Info
218 1.575271 195.170.0.1 192.168.1.10 DNS Standard query response NS ns9.zoneedit.com NS ns13.zoneedit.com
Frame 218: 117 bytes on wire (936 bits), 117 bytes captured (936 bits)
Ethernet II, Src: Arcadyan_8c:eb:27 (00:1d:19:8c:eb:27), Dst: Apple_f1:c9:e8 (60:fb:42:f1:c9:e8)
Internet Protocol, Src: 195.170.0.1 (195.170.0.1), Dst: 192.168.1.10 (192.168.1.10)
User Datagram Protocol, Src Port: domain (53), Dst Port: 58460 (58460)
Source port: domain (53)
Destination port: 58460 (58460)
Length: 83
Checksum: 0x2cce [validation disabled]
Domain Name System (response)
[Request In: 206]
[Time: 0.045459000 seconds]
Transaction ID: 0x26ed
Flags: 0x8180 (Standard query response, No error)
Questions: 1
Answer RRs: 2
Authority RRs: 0
Additional RRs: 0
Queries
mactech.com: type NS, class IN
Name: mactech.com
Type: NS (Authoritative name server)
Class: IN (0x0001)
Answers
mactech.com: type NS, class IN, ns ns9.zoneedit.com
Name: mactech.com
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 51 seconds
Data length: 15
Name server: ns9.zoneedit.com
mactech.com: type NS, class IN, ns ns13.zoneedit.com
Name: mactech.com
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 51 seconds
Data length: 7
Name server: ns13.zoneedit.com
As you can see in Figure 13, a Display Filter (arp || dns) is used to minimize the displayed data. The full DNS query required two network packets (Frame 206 and Frame 218). The UDP (User Datagram Protocol) protocol was used and the desired information was sent back without any errors (The Flags information). You can tell from the time difference (0.045459) between the DNS query (1.529812) and the DNS answer (1.575271) that our DNS services work fine because the response time is pretty quick. The DNS server asked has the 195.170.0.1 IP address. The same DNS server answered the DNS query as its IP is the source of the second packet. The Answer RRs: 2 line informs us that there were two answers for our DNS query. You also see that the port used by the DNS server is port 53 as expected. For the first packet, it is the destination port and for the second packet, it is the source port.
In the forthcoming article about WireShark Display Filters, we will continue to use DNS as an example, which will help you learn in more detail how to deal with DNS problems.
Analyzing ARP traffic
ARP is used for retaining the MAC address of a device that resides on the same subnet as the device that makes the ARP query. Please note that devices residing on the same subnet find each other using their MAC addresses and not their IP addresses. ARP is a simple protocol that is mainly composed of an ARP request and an ARP reply. ARP packets do not have an IP address in either their IP or TCP packet headers and therefore their traffic is not routable (cannot go from a subnet to another subnet like Internet traffic).
For the purposes of this example, I turned on my network printer (an HP OfficeJet 8500 with the static IP 192.168.1.25) in order to get some ARP traffic on my network. As you can see in the following packets, the printer made a Broadcast request in order to learn the MAC address of my iMac (static IP: 192.168.1.10).
No. Time Source Destination Protocol Info
376 127.086611 HewlettP_6f:8d:a7 Broadcast ARP Who has 192.168.1.10? Tell 192.168.1.25
Frame 376: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Arrival Time: Jan 11, 2011 11:28:53.776323000 EET
Epoch Time: 1294738133.776323000 seconds
[Time delta from previous captured frame: 0.000822000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 127.086611000 seconds]
Frame Number: 376
Frame Length: 60 bytes (480 bits)
Capture Length: 60 bytes (480 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:arp]
[Coloring Rule Name: ARP]
[Coloring Rule String: arp]
Ethernet II, Src: HewlettP_6f:8d:a7 (00:26:55:6f:8d:a7), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
Source: HewlettP_6f:8d:a7 (00:26:55:6f:8d:a7)
Address: HewlettP_6f:8d:a7 (00:26:55:6f:8d:a7)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: ARP (0x0806)
Trailer: 000000000000000000000000000000000000
Address Resolution Protocol (request)
Hardware type: Ethernet (0x0001)
Protocol type: IP (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: request (0x0001)
[Is gratuitous: False]
Sender MAC address: HewlettP_6f:8d:a7 (00:26:55:6f:8d:a7)
Sender IP address: 192.168.1.25 (192.168.1.25)
Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
Target IP address: 192.168.1.10 (192.168.1.10)
No. Time Source Destination Protocol Info
377 127.086624 Apple_f1:c9:e8 HewlettP_6f:8d:a7 ARP 192.168.1.10 is at 60:fb:42:f1:c9:e8
Frame 377: 42 bytes on wire (336 bits), 42 bytes captured (336 bits)
Arrival Time: Jan 11, 2011 11:28:53.776336000 EET
Epoch Time: 1294738133.776336000 seconds
[Time delta from previous captured frame: 0.000013000 seconds]
[Time delta from previous displayed frame: 0.000013000 seconds]
[Time since reference or first frame: 127.086624000 seconds]
Frame Number: 377
Frame Length: 42 bytes (336 bits)
Capture Length: 42 bytes (336 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:arp]
[Coloring Rule Name: ARP]
[Coloring Rule String: arp]
Ethernet II, Src: Apple_f1:c9:e8 (60:fb:42:f1:c9:e8), Dst: HewlettP_6f:8d:a7 (00:26:55:6f:8d:a7)
Destination: HewlettP_6f:8d:a7 (00:26:55:6f:8d:a7)
Address: HewlettP_6f:8d:a7 (00:26:55:6f:8d:a7)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: Apple_f1:c9:e8 (60:fb:42:f1:c9:e8)
Address: Apple_f1:c9:e8 (60:fb:42:f1:c9:e8)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: ARP (0x0806)
Address Resolution Protocol (reply)
Hardware type: Ethernet (0x0001)
Protocol type: IP (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: reply (0x0002)
[Is gratuitous: False]
Sender MAC address: Apple_f1:c9:e8 (60:fb:42:f1:c9:e8)
Sender IP address: 192.168.1.10 (192.168.1.10)
Target MAC address: HewlettP_6f:8d:a7 (00:26:55:6f:8d:a7)
Target IP address: 192.168.1.25 (192.168.1.25)
The first packet sends a broadcast asking for the MAC address of the device with the IP of 192.168.1.10 and is sent by the HP printer. You can see that the "Target MAC Address" is set to all zeros as it is unknown. The return packet has both the "Sender MAC Address" and the "Target MAC Address" fields set. The Opcode 0x0001 is an ARP request and the Opcode 0x0002 is an ARP reply.
Summary
This is the first article in a series of articles about WireShark. The next article in this series is going to teach you how to examine the traffic created by the most important Nmap scans.
Acknowledgements: I would like to thank Dimitris Tsoukalos for proofreading the article.
Web links and Bibliography
WireShark site: http://www.wireshark.org/
Internetworking with TCP/IP, Volume I, Douglas E. Comer, 1991, Prentice Hall
Mihalis Tsoukalos lives in Greece with his wife Eugenia and enjoys digital photography and writing articles. He is the author of the Programming Dashboard Widgets eBook. You can reach him at tsoukalos@sch.gr.
