In this article by Charit Mishra, the author of Mastering Wireshark, we will help the reader understand the following topics:

• Checking for different analysis flags in Wireshark
• Understanding UDP traffic
• Practice questions

(For more resources related to this topic, see here.)

How to check for different analysis flags in Wireshark

The analysis of the flags present in the TCP packets is quite simple. While using Wireshark, there is an individual section that is available in the details pane for every TCP packet. Let's take a TCP packet and see how the flags are presented in the details pane, and then we will try to create a display filter corresponding to the same. Refer to the following screenshot:

Now we will see what each pointer mentions:

• 1: The SYN packet sent from the client to the server to initiate the three-way handshake can be seen in the list pane.
• 2: Flags related to the same packet is set and the hex equivalent of 000000000010 is 0 x 002.
• 3: For the corresponding TCP packet, the SYN flag bit is set to 1. The same can be seen in the details pane. The rest of them are still 0.

Now if you wish to create a display filter to see only the SYN packets you have in the trace file, then apply the filter shown in the following screenshot. As a result, you will see only the SYN packets present in your trace file, as illustrated in the following screenshot:

Let's try to create one more filter to view the SYN, ACK packets only in the list pane. Perform the following steps to create the same:

1. Open your trace file.
2. Choose any TCP SYN, ACK packet.
3. Note the corresponding SYN, ACK hex equivalent value for the flags set.
4. Create your filter using the hex equivalent you have. Your filter must look something like the following screenshot.

User Datagram Protocol

As defined in RFC 768, User Datagram Protocol (UDP) is a connectionless protocol, which is great to transmit real-time data between the hosts and often termed as an unreliable form of communication, reason being UDP doesn't care about the delivery of packets and any lost packets are not been recovered, because the sender is never informed about the dropped or discarded packets lost during the transmission. But still many protocols such as DHCP, DNS, TFTP, SIP, and so on, rely on this only. The protocols that use UDP as a transport mechanism have to rely upon other techniques to ensure data delivery and error-checking capabilities. They are inbuilt with such features, which can provide some level of reliability during the transmission. A point not to forget is that UDP provides faster transmission of the packets and it is not concerned about the initiation of the connection or graceful termination as seen in the TCP. That's why UDP is also referred to as a transaction-oriented protocol not a message-oriented protocol like TCP.

UDP header

The size of a usual UDP header is 8 bytes; the data that is added with the header can be theoretically 65535 (practically 65507) bytes long. UDP header is quite small if compared to TCP header. It has just four common fields that are Source Port, Destination Port, Packet Length, and Checksum, as follows:

• Source Port: The port number used by the sending side to receive any replies if needed. Probably most of the time in TCP and UDP, the port number chosen to be the part of the socket is ephemeral. And on the other side of the communication, the port number comes in the category of well-known port numbers.
• Destination Port: This field of the header identifies the port number used by the server or the receiving side and all the data will be transmitted to this port. This port number is assigned to a particular service by IANA and definitely it is permanently assigned to the same service specifically. For example, port 53 is for DNS and cannot be assigned to any other service (it is not advisable).
• Packet Length: This field specifies the length of the packet starting from the header to the end of the data; the minimum length you will observe will be 8 bytes every time that is the length of the UDP header.
• Checksum: As discussed earlier, checksum is performed over the data that is the packet of the packet to ensure data integrity, that is, what is sent from the sender side is the same as what the receiver got. To verify this, there are a couple of checksum algorithms which come to the rescue. Sometimes, while working with UDP mostly you will see the checksum value is 0 in the packet we received, which means that the checksum is not required to be validated.

How it works

To understand the way UDP works, let's go ahead and analyze some of the protocols that use UDP as a delivery protocol. First, I would like to discuss DHCP and then we will see DNS traffic as well.

For the analysis purpose, I have a default gateway configured at 192.168.1.1 and a client at 192.168.1.106. Using the client, I will try to generate DHCP and DNS traffic, which will be captured Wireshark and then I will try to dissect the each protocol's communication process as well as the different components utilized during the whole session.

DHCP

The most common and important protocol, which assigns IP addresses to devices and enables them to be network compatible is Dynamic Host Configuration Protocol (DHCP). Now, from the client, I will try to release the IP address that the client already holds, which will generate a DHCP packet and the same will be captured by the sniffer placed. Look at the following screenshot:

In the list pane, we can see a DHCP release packet, which was generated implicitly by the client in order to release the current IP address (I used the dhclient –v –r command on the Linux terminal to release the IP address. But be careful while using this command; it may disconnect your machine from the network, hence making it incompatible for network communication). The client from IP 192.168.1.106 to the server at 192.168.1.1 initiated the request. The port numbers used by the client and the server in case of DHCP is permanent. That won't be changed in your case too, until it is manually configured. The DHCP server port number is 67 and DHCP client port number is 68 by default. The same you can see in the preceding screenshot (highlighted as 3). The fourth field I have highlighted is the packet length field, which specifies the length of the packet starting from the first byte until the end of data in the packet. But out of the 308 bytes, 8 bytes is the UDP header length and the rest of the 300 bytes would be the application data appended. Interestingly, if a machine is power cycled, it will request the DHCP server to allocate an IP that, as a result, will generate a couple of packets relating to the DHCP request, release, offer, and various others that will also be using UDP as a transport mechanism.

I filtered the packets listed to show only the DHCP packets using the filter udp.port==67. As a result, only the DHCP packets will be listed in the list pane.

TFTP

Trivial File Transfer Protocol is light-weighted version of FTP, which is used for transferring between hosts. Unlike the FTP protocol, TFTP does not ask the users for any sought of credentials. TFTP uses UDP as a transport mechanism. Most commonly, TFTP is used in the LAN environments and when dealing with manageable devices like switches and routers. Network administrators do use TFTP servers to back up configuration files and to update the firmware running in those devices. And TFTP is also used by security professionals to transfer files from their system to yours in order to escalate the privileges (gaining more rights on a compromised system).

I have a TFTP server running at 192.168.1.106 and a client at 192.168.1.104. There is a text file abc.txt that I've created on the server and the client will try to download the same. And our sniffer in place will capture the traffic generated.

The traffic generated due to the transaction that happened between the two hosts is successfully captured and the packets corresponding to it is shown in the following screenshot:

Now, let's see what each pointer mentions:

• 1: The transfer of the packet initiated as soon as the client requested for the file abc.txt. The request frame can be seen in the list pane.
• 2: As discussed, TFTP uses UDP for the transport mechanism. Relating details for the request is shown in the details pane that states that request was initiated from an ephemeral port number from the client destined to port 69 on the server (69 is a well-known port to the TFTP protocol).
• 3: And the request was specific to the file abc.txt that is also shown in the details pane in the TFTP protocol section.

You must be wondering about the acknowledgement packets that are shared between the two hosts. As we studied, UDP is an unreliable form of communication, so why are we seeing some sort of ACK's in UDP. The reason is that the TFTP server I am using has some kind of reliability feature inbuilt into it. Even on the client side over the standard console, after initiating the request, I received quite interactive messages from the server like "the file of size 3 bytes has been transferred successfully" and various other details were listed along with the message. An interesting thing to know here is that the port 69 was involved only in the first packet, and the rest of the packets are sent and received by the acknowledging feature the server is embedded with. So, the statement that, some protocols using UDP as transport protocol has an inbuilt feature for ensuring delivery is true which we witnessed it now.

Unusual UDP traffic

Suppose if the resource we are looking for is not available on the server, then how the traffic will look like. Refer to the following screenshot:

As seen in the preceding screenshot, the client requested for an invalid resource that the server wasn't able to locate and hence returned with an error code and a summary message File not found. The same message was shown over the standard console to the client.

Sometimes, it is also possible that the server daemon is not running and the client requests for a certain resource. In such cases, the client would receive ICMP destination unreachable with error code 3. Refer to the following screenshot for the same:

Now we will see what each pointer mentions:

• 1: Server returned with an ICMP destination unreachable message when the TFTP server daemon on not functional
• 2: Client received and type code error 3
• 3: The details regarding the request is mentioned in the reply under the UDP protocol section, which states that the request was sent to port 69 that is currently nonfunctional.
• 4: The requested resource is shown under the TFTP protocol section.

Unusual DNS requests are also seen very often when a client initiates a request to look for name servers associated with an address. It would look similar to the following screenshot:

Now, we will see what each pointer mentions:

• 1: As seen in the list pane, the client at 192.168.1.106 initiated a request to look for address 8.0.0.0 and received a response in the frame number 2
• 2: The request was sent to the default gateway that holds the DNS cache
• 3: The gateway responded with a No such name error

There can be multiple scenarios where you will be seeing unusual traffic related to UDP. The most important one you can look for is the TFTP traffic, which might be generated because of a TFTP client in your network. It may be a malicious traffic that you would like to take a note of.

Practice questions

1. Distinguish at least five differences between TCP and UDP protocols.
2. Capture the three-way handshake and tear down packets using your own FTP server.
3. Explain the purpose of window scaling and checksum offloading and tell their corresponding significance in terms of TCP communications?
4. In what way a TCP-based communication can recover from packets loss or unexpected termination? Imitate any scenarios that can generate such traffic.
5. Create a display filter to show only TCP, FIN, and ACK packet sent to your machine from your default gateway in the list pane.
6. What is the difference between the absolute and relative numbering system used by Wireshark in order to keep track of the packets.
7. What is the purpose of the options field at the end of the TCP header? What kind of arguments does it contain?
8. There is one more way through which you can create filters for viewing packet with specific flags set. Without providing the HEX equivalent, figure out what it is and how you can filter packets set with PSH flag using the same technique.
9. Find out why the length of the data can be practically 65507 bytes while working with UDP?
10. What kind of packets you will see in the list pane if the server daemon for TFTP is not running?
11. Try performing zone transfer on your locally configured DNS and capture the traffic for analyses. What interesting facts did you noticed about the packets? Explain in brief.

Summary

TCP is a reliable form of communication that uses the processes like three-way handshake and tear down, ensuring to make the connection reliable and interactive. A lot of traffic is generated because of these packets taking part in the creation of the session between the two hosts.

The TCP header is 20 bytes long that consists of various fields like source and destination port, SEQ and ACK numbers, offset, window size, flag bits, checksum, and options. The presence of various flags and header fields let the sender and receiver make sure about the delivery as well as the integrity of the data being sent.

SEQ and ACK numbers are used by the TCP-based communications to keep track of how much data is being sent across between the hosts taking part.

Several popular protocols like HTTP, FTP use TCP for transport mechanism, and in case of packet loss, the retransmission of the lost frames take place to ensure successful delivery.

UDP is a connectionless protocol that is a nonreliable means of communication over IP; the lost and discarded packets are never recovered. UDP does provide us with faster transmission and easier creation of sessions. UDP header is 8 bytes long, which has very few fields like source and destination port, packet length, and checksum. At the end, the Application data is appended.

UDP is being utilized by many protocols today, one of the most important implementation of UDP you will see while streaming live videos from the Internet.

Common protocols such as DHCP, TFTP, DNS, RTP, SIP, and so on use UDP for transport mechanism and not to mention these services are some of the major services, which we deal with in our everyday life. For making the connection reliable, some of these protocols support their own version of acknowledging features that comes inbuilt into them.

Resources for Article:

Further resources on this subject:

• Wireshark: Working with Packet Streams [article]
• Capturing Wireshark Packets [article]
• Wireshark [article]