Lab: Getting started with Wireshark

Wireshark a network traffic analyzer. It is widely regarded as the de facto tool for capturing and examining network traffic.

In this lab, you'll install Wireshark on your own system and become familiar with a few of its key features: capturing traffic, exploring packets, and extracting data from captures.
There will be a few points in this tutorial where you can demonstrate your progress, which you can include in your homework submission to receive credit.

Installing Wireshark

To install Wireshark:

1. Download Wireshark via this link and install it on your system.
2. Install Wireshark using the installer you downloaded. You may be prompted to install some additional components (eg. WinPcap on Windows or BPF tools on MacOS); you should install these as well.
3. Next, open wireshark! You should be greeted with a window like this:

What's next? There are two ways to use wireshark: it can perform live captures, where it reads and displays network traffic observed on your system in real-time, or it can view or save capture files (also called .pcap files), which are files that store captured traffic for later analysis. In this lab, we will briefly work with both.

Starting a live capture

Now that you have Wireshark running, it's time to use it to capture traffic!

Packet captures are performed by attaching to one of your system's network interfaces (eg. your Wifi card, Ethernet port, etc.). To start a capture:

1. Select Capture > Options from the menus at the top. This will present a list of interfaces
2. Select the network interface you use to connect to the internet. If you connect using Wifi, the interface is most likely labeled "Wi-Fi", "Wireless Network connection", or "Local Area Connection".

Not sure which interface to pick?

• If you're not sure which interface is correct, watch the tiny traffic graphs that appear next to each interface: the one you use to connect to the internet should have the most activity.
• If the graphs don't give any clues, you can just start at the top of the list and try every interface except "Loopback". If you've picked the right one, you should see some traffic within a couple of seconds.

What you're seeing are all the packets entering or leaving your network interface in real-time. If you have some applications running that are using a lot of network traffic (eg. watching a video), you may see a lot of packets!

Just watching the packets in real-time can be useful: you can observe exactly how your system is interacting with the network as you do things. However, what we see here is a ton of information–this can be overwhelming, and we don't need to understand everything here. In the next section, we'll look at how to narrow this down and examine some packets.

Warning: While you have a live capture running, Wireshark stores all network traffic it captures in your memory or on disk. If you're doing something bandwidth intensive (eg. streaming a movie, Zoom call, etc.) and need to leave the capture running, this could use a lot of resources!

If you need to stop working on this tutorial, you can stop your capture by selecting Capture > Stop from the menu. This will stop Wireshark from saving packets while you're not working.

It's also possible to confiure Wireshark to skip saving certain types of packets to save resources: this is called a capture filter, which is beyond the scope of this tutorial. You can read more about Capture Filters here.

Filtering traffic

To help us sort through all of the packets, Wireshark has support for filtering traffic based on certain criteria. This can be useful to focus your analysis for certain types of packets.

To demonstrate filters, we'll send some traffic and then look for it in Wireshark's output. To do this:

1. Start a live capture as described in the previous section (or leave it running if you already had it open)

2. Open a terminal on your host machine and run one of the following:

• (On MacOS/Linux): ping -c 3 1.1.1.1
• (On Windows, from Command Prompt/Powershell): ping 1.1.1.1

This will send some ping packets (like in the figure below)–these are really simple messages used to test if a host is online. In this case, we are sending three packets to the address 1.1.1.1 (which happens to be Cloudflare's public DNS server).

When you type the command, you might see some pink packets fly past your Wireshark output. To find them, let's add a filter:

2. In the "Display filter" box just above the packet list, enter the filter icmp. This tells Wireshark to show only packets for the ICMP protocol, which is the protocol used by ping packets. Your Wireshark window should now look like this:

You should now see six packets (like the figure) in the list: there should be 3 packets sent from your IP address to 1.1.1.1, and a response for each one.

You've now had practice with the most basic Wireshark filters. You can do a lot with filters–this is only the beginning. Here are some more examples of filters you might find useful:

• http: Show all HTTP traffic
• icmp || dns: Show all ICMP and DNS packets
• tcp.port == 80, udp.port == 1234: Show traffic on a certain port number
• ip.len > 1000: Show all IP packets > 1000 bytes in size
• http.request.method == "GET": Show all HTTP GET requests

To read more about Wireshark filters, see here.

Exploring packets

The main packet list shows the most important information about each packet, but we can also look further to see what each byte of the packet means. Wireshark contains hundreds of packet dissectors, which are programs that know how to decode various network protocols and display the information for you.

For example, Wireshark knows these packets use the ICMP protocol because it has a built-in dissector to recognize these packets.

To explore further:

1. Click on one of the ICMP packets from the previous step
2. Look in Wireshark's lower-left pane. This shows decoded view for the packet, which is what Wireshark's dissectors found when analyzing the packet. The decoded view has a tree-like structure: each part of the tree pertains to a different packet header, roughly corresponding to the different protocol layers we've been leaning about in lecture (eg. link-layer, IP, …).
   To practice this, expand some of the headers and look at the different fields. As you click on them, you should see some data highlighted in the pane to the right–these are the actual bytes in the packet that match this field!

For example, each ICMP packet has an identifier field, so that it's possible to uniquely differentiate between two ping packets. Here's what it looks like in decoded and bytes view:

Decoding HTTP traffic

Now that we've seen the basics, let's explore some of Wireshark's more powerful features for decoding more complex traffic. To do this:

1. If you already have a live capture running from the previous step, stop it by selecting Capture > Stop from the menu
2. Download this capture file and open it in Wireshark with File > Open. (You may get a prompt asking if you want to save your previous capture. If so, you can continue without saving–you will not need this data.)

This file contains a saved capture of a request to an insecure website (you might even find it familiar…) via HTTP. If you scroll through the file, you should see some traffic that represents fetching a web page in a browser.

Recall from the Flag project that a web page contains many elements and resources: browsers fetch an initial web page and then need to issue additional requests for other assets on the page (eg. images, fonts, etc.). Most of the packets here result from loading a single web page! In particular, if you scroll through the capture, you will see:

• Some DNS queries for the main site (juice.cs1660.net), as well as various other domains referenced in URLs. (To see this, filter with dns)
• Lots of HTTP traffic on port 80, for the main web page and various other assets on the page (Filter with http or tcp.port == 80)
• More web traffic using HTTP and HTTPS (on port 443) for external resources used by the web page (eg. fonts, libraries). The HTTPS traffic is encrypted, so instead of seeing the request in the clear, we see the setup process for a TLS connection.

Wireshark can tell us more about the web page and the HTTP request process. To see this:

1. Scroll down to packet 619 (based on the number in the leftmost column in the packet view). This packet should be a GET request for the URL /assets/public/images/products/fruit_press.jpg
2. Click on this packet and expand the HTTP header in the decoded view. You should be able to see all of the HTTP headers and cookies sent with the packet, which should look like this:

Think back to how you once viewed this same information in your browser's Developer Tools–now you're seeing the actual bytes as they're sent over the network!

3. Under the HTTP headers are some lines that look like links. These are added by Wireshark as it analyzes all of the requests and responses in the capture. For example, Wireshark can figure out if the server responded to this request, and where the response is located in the capture. To see this, click on the link "Response in frame…" to jump to the response, which should look like this:

Some things to note about this message:

• The note from wireshark "4 reassembled TCP segments": means that the HTTP response was actually sent to the browser in 4 TCP packets. TCP's job is to reassemble these packets into the response that the browser sees: Wireshark can read the TCP information on the packet and reassemble the response, just as your browser does!
• Take a look at the data in the response: Wireshark is looking at the content and recognizes this is a JPG file, which matches what we would expect based on the URL (.../images/products/fruit_press.jpg)

Exporting HTTP objects

In addition to showing us HTTP requests and responses, Wireshark can also export the page elements for us to view! To do this:

1. With the Juice Shop capture file open (from the previous section), go to File > Export Objects… > HTTP. You should see a window that looks like this:

This is a view of all the HTTP data that was returned in HTTP responses and would have been loaded by the browser. Since all the data was sent in the clear via HTTP, we can view all of this content!

2. Click on one of the images. You should see Wireshark jump to the packets where the image appeared in the capture.

3. Click Save to save the image to your computer.
   If you get an error saying the filesystem is read-only, make sure you are saving to a path in your user folder–for some reason, Wireshark might select an unwritable system path by default.

Congrats, you successfully extracted data from a packet capture, just like a network eavesdropper might be able to do!

What to submit: a final challenge

Now that you've learned some basic skills for exploring capture files, packets and filters, demonstrate your skills by doing the following:

1. In your homework submission, include one of the images you extracted from the capture file, per the Exporting HTTP objects section.
2. Somewhere in the capture file, there is an unencrypted POST request where a user logs in. Find this request and include the user's credentials (email and password) in your submission. To do this, remember what you learned about filters to search for this request, then look at the request content to find the credentials.

There is no particular format for your submission, so long as you include these items.

We hope you found this initial tutorial on Wireshark useful. For more guides and demos, we recommend checking out Wireshark's documentation, which has a lot of guides and tutorial videos to learn more!