View a video about Wireshark on Lynda.com 1. What are the five commonly accessed

Question

View a video about Wireshark on Lynda.com

1. What are the five commonly accessed menu choices?

2. Open the file “A TCP-Example.pcapng” as in the video, and follow the instructions given to edit this file. In Wireshark Preferences, which box does the author suggest unchecking (or keeping unchecking)? Why?

3. Continuation of 2): Which box does the author suggest checking (or keeping checked)? Why?

4. Under which menu choice is the Time Display Format?

5. How would you determine the manufacturer of a NIC?

6. Which View option shouldn’t be activated? Why?

7. Where is the Summary option and what information does it give you?

8. How do you set up a capture filter to capture DNS packets?

9. Under what circumstances should you consider not using a capture filter? Why?

10. What is the Expression Builder used for?

11. How do you choose only the acknowledgement flag set in TCP?

12. Try Challenge: Filtering Data that is Displayed. Take a screenshot of your trial.

13. Watch Solution: Filtering Data that is Displayed. Repeat her steps to learn how to use the filters.

Explanation / Answer

Wireshark, a network analysis tool formerly known as Ethereal, captures packets in real time and display them in human-readable format. Wireshark includes filters, color-coding and other features that let you dig deep into network traffic and inspect individual packets.
Getting Wireshark
You can download Wireshark for Windows or Mac OS X from its official website. If you’re using Linux or another UNIX-like system, you’ll probably find Wireshark in its package repositories. For example, if you’re using Ubuntu, you’ll find Wireshark in the Ubuntu Software Center.
Just a quick warning: Many organizations don’t allow Wireshark and similar tools on their networks. Don’t use this tool at work unless you have permission.
Capturing Packets
After downloading and installing Wireshark, you can launch it and click the name of an interface under Interface List to start capturing packets on that interface. For example, if you want to capture traffic on the wireless network, click your wireless interface. You can configure advanced features by clicking Capture Options, but this isn’t necessary for now.
As soon as you click the interface’s name, you’ll see the packets start to appear in real time. Wireshark captures each packet sent to or from your system. If you’re capturing on a wireless interface and have promiscuous mode enabled in your capture options, you’ll also see other the other packets on the network.
Click the stop capture button near the top left corner of the window when you want to stop capturing traffic.
Color Coding
You’ll probably see packets highlighted in green, blue, and black. Wireshark uses colors to help you identify the types of traffic at a glance. By default, green is TCP traffic, dark blue is DNS traffic, light blue is UDP traffic, and black identifies TCP packets with problems — for example, they could have been delivered out-of-order.
Sample Captures
If there’s nothing interesting on your own network to inspect, Wireshark’s wiki has you covered. The wiki contains a page of sample capture files that you can load and inspect.
Opening a capture file is easy; just click Open on the main screen and browse for a file. You can also save your own captures in Wireshark and open them later.
Filtering Packets
If you’re trying to inspect something specific, such as the traffic a program sends when phoning home, it helps to close down all other applications using the network so you can narrow down the traffic. Still, you’ll likely have a large amount of packets to sift through. That’s where Wireshark’s filters come in.
The most basic way to apply a filter is by typing it into the filter box at the top of the window and clicking Apply (or pressing Enter). For example, type “dns” and you’ll see only DNS packets. When you start typing, Wireshark will help you autocomplete your filter.

Domain Name System (DNS)

DNS is the system used to resolve store information about domain names including IP addresses, mail servers, and other information.

History

DNS was invented in 1982-1983 by Paul Mockapteris and Jon Postel.

Protocol dependencies

TCP/UDP: Typically, DNS uses TCP or UDP as its transport protocol. The well known TCP/UDP port for DNS traffic is 53.
Example traffic

XXX - Add example traffic here (as plain text or Wireshark screenshot).

Wireshark

The DNS dissector is fully functional. Also add info of additional Wireshark features where appropriate, like special statistics of this protocol.

Preference Settings

The DNS dissector has one preference: "Reassemble DNS messages spanning multiple TCP segments". As you might have guessed, this takes a DNS request or reply that has been split across multiple TCP segments and reassembles it back into one message. TCP_Reassembly has to be enabled for this feature to work.

Example capture file

The SampleCaptures has many DNS capture files.

Display Filter

A complete list of DNS display filter fields can be found in the display filter reference

Show only the DNS based traffic:
dns
Capture Filter

You cannot directly filter DNS protocols while capturing if they are going to or from arbitrary ports. However, DNS traffic normally goes to or from port 53, and traffic to and from that port is normally DNS traffic, so you can filter on that port number.

Capture only traffic to and from port 53:
port 53
On many systems, you can say "port domain" rather than "port 53".

DNS servers that allow recursive queries from external networks can be used to perform denial of service (DDoS) attacks. You can look for external recursive queries with a filter such as

udp port 53 and (udp[10] & 1 == 1) and src net not <net1> and src net not <net2>
where <net1> and <net2> are network specifiers, such as 10.0.0.0/8.

While packets are captured, each packet is timestamped. These timestamps will be saved to the capture file, so they will be available for later analysis.
The timestamp presentation format and the precision in the packet list can be chosen using the View menu, see Figure 3.5, “The “View” Menu”.
The available presentation formats are:
Date and Time of Day: 1970-01-01 01:02:03.123456 The absolute date and time of the day when the packet was captured.
Time of Day: 01:02:03.123456 The absolute time of the day when the packet was captured.
Seconds Since Beginning of Capture: 123.123456 The time relative to the start of the capture file or the first “Time Reference” before this packet (see Section 6.12.1, “Packet time referencing”).
Seconds Since Previous Captured Packet: 1.123456 The time relative to the previous captured packet.
Seconds Since Previous Displayed Packet: 1.123456 The time relative to the previous displayed packet.
Seconds Since Epoch (1970-01-01): 1234567890.123456 The time relative to epoch (midnight UTC of January 1, 1970).
The available precisions (aka. the number of displayed decimal places) are:

Automatic The timestamp precision of the loaded capture file format will be used (the default).
Seconds, Deciseconds, Centiseconds, Milliseconds, Microseconds or Nanoseconds The timestamp precision will be forced to the given setting. If the actually available precision is smaller, zeros will be appended. If the precision is larger, the remaining decimal places will be cut off.

The Three-Way Handshake
TCP utilizes a number of flags, or 1-bit boolean fields, in its header to control the state of a connection. The three we're most interested in here are:

SYN - (Synchronize) Initiates a connection
FIN - (Final) Cleanly terminates a connection
ACK - Acknowledges received data

Sequence and Acknowledgment Numbers
The client on either side of a TCP session maintains a 32-bit sequence number it uses to keep track of how much data it has sent. This sequence number is included on each transmitted packet, and acknowledged by the opposite host as an acknowledgement number to inform the sending host that the transmitted data was received successfully.
The display of relative sequence numbers can optionally be disabled by navigating to Edit > Preferences... and un-checking Relative sequence numbers and window scaling under TCP protocol preferences. However, be aware that the remainder of this article will reference relative sequence and acknowledgement numbers only.

To better understand how sequence and acknowledgement numbers are used throughout the duration of a TCP session, we can utilize Wireshark's built-in flow graphing ability. Navigate to Statistics > Flow Graph..., select TCP flow and click OK. Wireshark automatically builds a graphical summary of the TCP flow.

When a host initiates a TCP session, its initial sequence number is effectively random; it may be any value between 0 and 4,294,967,295, inclusive. However, protocol analyzers like Wireshark will typically display relative sequence and acknowledgement numbers in place of the actual values. These numbers are relative to the initial sequence number of that stream. This is handy, as it is much easier to keep track of relatively small, predictable numbers rather than the actual numbers sent on the wire.
Each row represents a single TCP packet. The left column indicates the direction of the packet, TCP ports, segment length, and the flag(s) set. The column at right lists the relative sequence and acknowledgement numbers in decimal. Selecting a row in this column also highlights the corresponding packet in the main window.

We can use this flow graph to better understand how sequence and acknowledgement numbers work.

Packet #1

Each side of a TCP session starts out with a (relative) sequence number of zero. Likewise, the acknowledgement number is also zero, as there is not yet a complementary side of the conversation to acknowledge.

(Note: The version of Wireshark used for this demonstration, 1.2.7, shows the acknowledgement number as an apparently random number. This believed to be a software bug; the initial acknowledgement number of a session should always be zero, as you can see from inspecting the hex dump of the packet.)

Packet #2

The server responds to the client with a sequence number of zero, as this is its first packet in this TCP session, and a relative acknowledgement number of 1. The acknowledgement number is set to 1 to indicate the receipt of the client's SYN flag in packet #1.

Notice that the acknowledgement number has been increased by 1 although no payload data has yet been sent by the client. This is because the presence of the SYN or FIN flag in a received packet triggers an increase of 1 in the sequence. (This does not interfere with the accounting of payload data, because packets with the SYN or FIN flag set do not carry a payload.)

Packet #3

Like in packet #2, the client responds to the server's sequence number of zero with an acknowledgement number of 1. The client includes its own sequence number of 1 (incremented from zero because of the SYN).

At this point, the sequence number for both hosts is 1. This initial increment of 1 on both hosts' sequence numbers occurs during the establishment of all TCP sessions.

Packet #4

This is the first packet in the stream which carries an actual payload (specifically, the client's HTTP request). The sequence number is left at 1, since no data has been transmitted since the last packet in this stream. The acknowledgement number is also left at 1, since no data has been received from the server, either.

Note that this packet's payload is 725 bytes in length.

Packet #5

This packet is sent by the server solely to acknowledge the data sent by the client in packet #4 while upper layers process the HTTP request. Notice that the acknowledgement number has increased by 725 (the length of the payload in packet #4) to 726; e.g., "I have received 726 bytes so far." The server's sequence number remains at 1.

Packet #6

This packet marks the beginning of the server's HTTP response. Its sequence number is still 1, since none of its packets prior to this one have carried a payload. This packet carries a payload of 1448 bytes.

Packet #7

The sequence number of the client has been increased to 726 because of the last packet it sent. Having received 1448 bytes of data from the server, the client increases its acknowledgement number from 1 to 1449.

For the majority of the capture, we will see this cycle repeat. The client's sequence number will remain steady at 726, because it has no data to transmit beyond the initial 725 byte request. The server's sequence number, in contrast, continues to grow as it sends more segments of the HTTP response.

Tear-down
Packet #38

After acknowledging the last segment of data from the server, the client processes the HTTP response as a whole and decides no further communication is needed. Packet #38 is sent by the client with the FIN flag set. Its acknowledgement number remains the same as in the prior packet (#37).

Packet #39

The server acknowledges the client's desire to terminate the connection by increasing the acknowledgement number by one (similar to what was done in packet #2 to acknowledge the SYN flag) and setting the FIN flag as well.

Packet #40

The client sends its final sequence number of 727, and acknowledges the server's FIN packet by incrementing the acknowledgement number by 1 to 22952.

- Let's take a look at the Wireshark interface with a little more detail. Specifically, let's take a look at the menu choices and five commonly accessed menu choices. File, Edit, View, Capture and Statistics. With File, File is where we commonly go to obtain a file and maybe open recent files. I'm going to simply go to File and Open and I'm going to get a TCP example. Now that we have something to look at, let's take a look at Edit.

Edit allows us to do common editing tasks such as Find Packet, Find Next and also add a Packet Comment. At the end of Edit, we can see where we can modify the preferences. I'm going to select that and it will take a second to load. Up at the top of your Preferences, you will see that the Profile says Default. You can make additional Profiles but for now we're just going to stay with the default. We'll start up at the top and just briefly look at the user interface.

And the user interface is how you want Wireshark to be displayed to you. Most commonly viewed is where you see the three Panes.

Capture filter is not a display filter

Capture filters (like tcp port 80) are not to be confused with display filters (like tcp.port == 80). The former are much more limited and are used to reduce the size of a raw packet capture. The latter are used to hide some packets from the packet list.

Capture filters are set before starting a packet capture and cannot be modified during the capture. Display filters on the other hand do not have this limitation and you can change them on the fly.

Wireshark uses the libpcap filter language for capture filters. A brief overview of the syntax follows. Complete documentation can be found in the pcap-filter man page.

You enter the capture filter into the “Filter” field of the Wireshark “Capture Options” dialog box, as shown in Figure 4.3, “The “Capture Options” dialog box”.

A capture filter takes the form of a series of primitive expressions connected by conjunctions (and/or) and optionally preceded by not:

[not] primitive [and|or [not] primitive ...]
An example is shown in Example 4.1, “A capture filter for telnet that captures traffic to and from a particular host”.

Example 4.1. A capture filter for telnet that captures traffic to and from a particular host
A capture filter for telnet that captures traffic to and from a particular host

tcp port 23 and host 10.0.0.5

This example captures telnet traffic to and from the host 10.0.0.5, and shows how to use two primitives and the and conjunction. Another example is shown in Example 4.2, “Capturing all telnet traffic not from 10.0.0.5”, and shows how to capture all telnet traffic except that from 10.0.0.5.

Example 4.2. Capturing all telnet traffic not from 10.0.0.5
Capturing all telnet traffic not from 10.0.0.5

tcp port 23 and not src host 10.0.0.5

A primitive is simply one of the following: [src|dst] host <host>
This primitive allows you to filter on a host IP address or name. You can optionally precede the primitive with the keyword src|dst to specify that you are only interested in source or destination addresses. If these are not present, packets where the specified address appears as either the source or the destination address will be selected.
ether [src|dst] host <ehost>
This primitive allows you to filter on Ethernet host addresses. You can optionally include the keyword src|dst between the keywords ether and host to specify that you are only interested in source or destination addresses. If these are not present, packets where the specified address appears in either the source or destination address will be selected.
gateway host <host>
This primitive allows you to filter on packets that used host as a gateway. That is, where the Ethernet source or destination was host but neither the source nor destination IP address was host.
[src|dst] net <net> [{mask <mask>}|{len <len>}]
This primitive allows you to filter on network numbers. You can optionally precede this primitive with the keyword src|dst to specify that you are only interested in a source or destination network. If neither of these are present, packets will be selected that have the specified network in either the source or destination address. In addition, you can specify either the netmask or the CIDR prefix for the network if they are different from your own.
[tcp|udp] [src|dst] port <port>
This primitive allows you to filter on TCP and UDP port numbers. You can optionally precede this primitive with the keywords src|dst and tcp|udp which allow you to specify that you are only interested in source or destination ports and TCP or UDP packets respectively. The keywords tcp|udp must appear before src|dst.

If these are not specified, packets will be selected for both the TCP and UDP protocols and when the specified address appears in either the source or destination port field.

less|greater <length>
This primitive allows you to filter on packets whose length was less than or equal to the specified length, or greater than or equal to the specified length, respectively.
ip|ether proto <protocol>
This primitive allows you to filter on the specified protocol at either the Ethernet layer or the IP layer.
ether|ip broadcast|multicast
This primitive allows you to filter on either Ethernet or IP broadcasts or multicasts.
<expr> relop <expr>

4.13.1. Automatic Remote Traffic Filtering

If Wireshark is running remotely (using e.g. SSH, an exported X11 window, a terminal server, …), the remote content has to be transported over the network, adding a lot of (usually unimportant) packets to the actually interesting traffic.

To avoid this, Wireshark tries to figure out if it’s remotely connected (by looking at some specific environment variables) and automatically creates a capture filter that matches aspects of the connection.

The following environment variables are analyzed:

SSH_CONNECTION (ssh)
<remote IP> <remote port> <local IP> <local port>
SSH_CLIENT (ssh)
<remote IP> <remote port> <local port>
REMOTEHOST (tcsh, others?)
<remote name>
DISPLAY (x11)
[remote name]:<display num>
SESSIONNAME (terminal server)
<remote name>
On Windows it asks the operating system if it’s running in a Remote Desktop Services environment.

4.13.2. Stop the running capture

A running capture session will be stopped in one of the following ways:

Using the Stop button from the “Capture Info” dialog box.
[Note]   Note
The “Capture Info” dialog box might be hidden if the “Hide capture info dialog” option is used.

Using the Capture Stop menu item.
Using the Stop toolbar button.
Pressing Ctrl+E.
The capture will be automatically stopped if one of the Stop Conditions is met, e.g. the maximum amount of data was captured.
4.13.3. Restart a running capture

A running capture session can be restarted with the same capture options as the last time, this will remove all packets previously captured. This can be useful, if some uninteresting packets are captured and there’s no need to keep them.

Restart is a convenience function and equivalent to a capture stop following by an immediate capture start. A restart can be triggered in one of the following ways:

Using the Capture Restart menu item.
Using the Restart toolbar button.

Related Questions

Navigate

• Browse (All)
• Browse V
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.