Pacific Northwest National Laboratory
Lab Module 3 –
Network Protocol Analysis
with Wireshark
NATO ASI on Energy Infrastructure Security
October 2015
1
Lab Module 3 – Network Protocol Analysis with Wireshark
Introduction
The Wireshark software is the most popular and well-known network protocol analyzer. It enables deep inspection of network traffic in over 1,000 protocols and is the de-facto standard across many industries and academia. Wireshark development thrives thanks to the contributions of networking experts across the globe. It is the continuation of a project that started in 1998.1
This module will introduce you to Wireshark and its use. For some, this may be a repeat – bear with us. We will:
• set up Wireshark to listen to some network traffic from a few different sources (which will include a custom plugin that allows direct parsing of serial traffic),
• load sample captures of interesting or relevant protocols and examine them, and • examine both un-encrypted and encrypted traffic side by side.
Basic Functions
The starting screen of Wireshark is shown in Figure 1.
Figure 1: Wireshark Starting Screen
1
2
We are interested only in two sections: the Capture window on the top left and the Files window in the center. The other windows are there for both on- and offline help.
Before a capture of network traffic can be started, Wireshark must be set to listen to the right networking interface. Click on “Interface List” to show what is available to Wireshark on this machine. You should see something like what is shown here in Figure 2.
Figure 2: Capture Interfaces
In this case, Figure 2 shows only one active interface. While more interfaces may be shown on your screen, select the Local Area Connection as shown.
Now click “Options” to bring up the Capture Options screen shown in Figure 3.
Figure 3: Capture Options
Here, you can set up the Wireshark capture configuration in detail. You can choose more than one
interface to listen to, apply capture filters, specify capture output files and how they are recorded, and you have some options regarding name resolution and display. For now, leave everything as it is and then click “Start” to begin capturing traffic.
3
Wireshark now should be displaying live traffic on the selected Ethernet interface. After you have let the traffic collect for a few seconds, click the red stop button at the top menu. You should see something similar to Figure 4 below.
Figure 4: Captured Traffic
The top half shows a chronological list of traffic packets on the network. This list can be resorted in many configurable ways. It might be useful to list the packets by source or destination address, or perhaps by protocol. The list displayed on the machine in front of you will probably include a few different protocols – TCP/IP, UDP, QUIC, STP, and some others. Packet length and brief information is also given.
The smaller center part of the window in Figure 4 provides more detailed information about each of the packets as they are selected. The different components of each packet are displayed in a hierarchical, expandable list. While the number of top-level components displayed may vary from packet to packet, the first one is always the packet wrapper frame containing information about the packet itself (metadata). This data is comprised of detailed time, packet travel duration, frame and capture lengths, and protocol(s) contained in the packet.
The second top-level component will likely be the Ethernet II wrapper. It provides information on source and destination and which protocol is used within the Ethernet II-wrapped package. The third top-level component is probably another wrapper – this time for the Internet Protocol Version 4. This metadata includes package length, flags, checksum, source and destination, and protocol used within the Internet Protocol Version 4-wrapped package.
4
After that, you may see a bigger variety of protocols in the top-level components – perhaps UDP, TCP, HTTP, etc.
The very bottom of the window shown in Figure 4 gives us the actual package contents in plain text or code (both hexadecimal and ASCII). This is a very powerful tool in protocol inspection and
troubleshooting, microscopic packet analysis, and even debugging of network code.
Next, we will inspect traffic on a wired connection to a Raspberry Pi microcomputer. If you have not already done so, connect the network cable between this machine and the Raspberry Pi for your station and ensure it is not currently powered up. Click the left-most button at the top of the Wireshark window to select a new capture interface. From the available options, choose the wired connection corresponding to the Raspberry Pi.
Now connect the micro-USB connector to the Raspberry Pi to power it up. Select “Start” to begin capturing; stop the capture only after you have seen a few packets go by.
Inspect the traffic. If you caught the Raspberry Pi during boot-up – as you should have – then you are now seeing much of the same type of traffic we saw on the local LAN or WiFi internet. You will also see some DHCP discovery requests and SSDP packages. A likely screen is shown in Figure 5.
Next, we will use a custom plugin for Wireshark that allows us to inspect serial traffic directly.
5
Next, we will take a look at how Wireshark handles encrypted versus un-encrypted traffic. We have already seen what unencrypted traffic looks like – every single frame examined thus far has been unencrypted. We have been able to read it.
We will open a sample capture file of encrypted SSL traffic and examine it without a key and then with a key. Some background on the protocol: Secure Socket Layer (SSL) provides secure communication between two hosts. It provides integrity, authentication and confidentiality. It is used most commonly in web browsers, but can be used with any protocol that uses TCP as the transport layer. SSL uses a variety of ports; some more well-known ones include 443 (http), 636 (ldap), 989-990 (ftp), and others.2
Select “File” in the top level menu of Wireshark, then “Open.” Navigate to the \SSL sub-directory and open the file “rsasnakeoil2.cap.” Wireshark should be displaying 58 TCP packets that don’t seem to contain anything useful. We see source and destination IP’s and ports (take note of these!) and also some connection-establish requests, pushes, and acknowledges. Figure 6 shows what your screen may look like:
Figure 6: Encrypted SSL traffic
2
6
Select “Edit” in the top level menu of Wireshark, then “Preferences.” On the left side of the new window, expand “Protocols” and navigate down to SSL and select it. Click on “Edit” next to “RSA keys list” (see Figure 7).
Figure 7: SSL Preferences On yet another new window, click on “New.” Enter the following:
IP address: 127.0.0.1 (The same address as in the captured TCP packets!) (Just a local loopback) Port: 443 (Same port as in the captured TCP packets)
Protocol: http
Key File: Click on the button “Wireshark,” then navigate to the \SSL subfolder and open “rsasnakeoil2.key”
Password: leave blank
Click “OK,” then “Apply,” then “OK.” Select “OK” one more time. The Wireshark display has changed a bit now that we have applied the right private key. The number of packets in the list is still 58. However, now only 25 of them show up as TCP. Eleven packets are SSLv2/v3 communications; the packets we earlier saw having ACK, SYN, and connection requests. This is the continued communication between the two SSL hosts that ensures the encrypted communication.
Finally, there are 22 HTTP packets. Those are the now-decrypted contents that SSL delivered. We see some standard web traffic – GET’s for pictures, icons, text, etc. Figure 8 below shows what your display may look like.
This concludes our brief look at encrypted traffic.
Next, we will open up a few prepared sample captures to look at some common protocols.
HTTP: Open the file “Http.cap” in the Pcaps folder. Your display should look similar to Figure 9. There
are some DNS packets (for ads!), a lot of TCP ACK and SEQ packages, and then the HTTP packets themselves with their contents – some text or html, pictures, and icons. The bottom of Figure 9 shows the contents of an HTTP package responsible for retrieving an online ad.
7
8
Figure 9: HTTP Sample Capture
WPA: Open the file “wpa-induction.cap” in the \Pcaps directory. This sample capture is a very lengthy
induction process for WPA (Wi-Fi Protected Access). When first opened, you should see something similar to what is shown in Figure 10. There are a lot of beacon frames, some unrecognized frames, and generally nothing usable. Let’s apply the WPA key.
Select “Edit->Preferences->Protocols->IEEE 802.11.” Click “Edit” at “Decryption Keys,” then select “New.” Change the key type to “wpa-pwd” and enter “Induction” for the key. Click “OK,” “Apply,” “OK”, “OK.”
We still see a large number of beacon frames, but now we do get to see some useful content as well. Starting at around packet 100, there are some Apple Talk packets, some DHCP and ICMPv6 packets. Contents of those packets are now visible thanks to decrypting them.
9
Figure 10: Encrypted WPA-Induction
Next we will examine a variety of other, often less common protocols – DNP3, IEC61850, and others. These protocols are however, prevalent in modern energy and utility infrastructure; industries which have generated a lot of attention in cybersecurity news in recent years.
DNP3: Open the file “dnp3_read.pcap.” This sample capture is the read request of a DNP3 session. This
is shown in Figure 11. In the top half, you see many TCP packets that serve mostly for connection requests, acknowledges and so on. There is one DNP 3.0 packet, however. The bottom half of Figure 11 shows the contents of that packet. The majority shown are wrapper frames. The actual DNP3 contents are at the very bottom. We can see a read request for a specific data object (object 60, variable 02, hex 0x3c02).
10
Figure 11: DNP3 Read Request
IEC-61850: Open the file “IEC61850.cap” in the \Pcap directory. This sample capture is of an IEC-61850
session, specifically GOOSE (Generic Object-Oriented Substation Events). The protocol is used in energy transmission and delivery infrastructure, some energy generation technology, and in oil and gas (limited). It is a self-describing, XML based protocol first defined in the IEC standard 61850. Figure 12 shows the capture file open in Wireshark. Notice that there are some Telnet and TCP packets, but they are irrelevant to this discussion. The only two GOOSE packets are from two different Schweitzer Engineering
Laboratories relays. The contents of one of the GOOSE packets is shown in the bottom half of Figure 12. The packet identifies the specific device 61850 data block, device ID (SEL_351_1), and which dataset to transmit. This is followed by the dataset itself, which follows the protocol language. IEC-61850 traffic can be challenging to debug due to differing MAC addresses, broadcast MAC’s, and difficulties in addressing and/or requesting the right data blocks. Some vendors do not support all data blocks. Using Wireshark to inspect the packets at a low level can help tremendously in the troubleshooting process and allows a much faster homing-in on the problem.
11
