INTRODUCING THE WIRESHARK NETWORK ANALYZER

1.1. Work description

When diagnosing network problems and studying the behavior of network applications, traffic analysis data is an invaluable source of information. Applications that allow you to work with traffic are called network analyzers or sniffers (from English to sniff - sniff out). Traffic analyzers allow you to intercept all packets passing through the network card and present them in a "raw" (as a sequence of bits and bytes) or already decoded into parameters and flags. One of the most common network analyzers is Wireshark (a very old name for Ethereal). This work is devoted to acquaintance with this application and the study of traffic analysis techniques.

Wireshark is distributed under the free license GNU GPL 2 [1]. The official site of the project is https://wireshark.org/. One of the features of the application is the constantly growing base of the packet decoder. The application automatically recognizes the packet format for hundreds of protocols from data link to application layer. With the right hardware, Wireshark can be used to analyze traffic from Wi-Fi, Bluetooth, GSM, LTE, USB, etc.

Another advantage of Wireshark is that it is open source and has implementations for Windows, MacOS, Ubuntu, and many Unix-like systems.

The program is updated very often. And with the release of new versions, some elements of the interface may change, but, as a rule, there are no fundamental changes. You can install Wireshark by downloading the distribution kit from the official website. During installation, you must allow the installation of the WinPCap library (libpcap on Linix), which implements packet capture directly.

Close all unnecessary tabs in the browsers you use and try not to run unnecessary applications that generate network traffic while you work. This is necessary in order to simplify the search for the necessary packages. As you work, don't forget to save the captured traffic: you may need it again when creating a report.

This work, with minor modifications, can be performed in the Linux operating system.

System requirements:

computer with Windows 7 or 10 OS;

connection to the Internet (Ethernet or Wi-Fi with DHCP address assignment);

Wireshark version not lower than 2.6.0 (with WinPCap package installed), it is recommended to use the English interface (because it is less subject to changes);

Web browser Mozilla Firefox version 70 or higher;

up-to-date GeoLite databases from MaxMind for ASN, countries and cities;

VMWare Workstation version 15 or later with an Ubuntu Server image of version 18.04 LTS or later (requires tcpdump, links, traceroute, openssh packages and network connection in bridge mode);

WinSCP version 5.15 or higher.

1.2. Introduction to the program interface

When you start working with the program, you must select the network interface on which the packets will be captured. This can be done either on the start screen of the application, or in the window for selecting network interfaces. To do this, select Capture Options in the menu, then in the window that opens, mark the necessary network adapters (using the Ctrl key you can select several interfaces at the same time) and click the Start button. If the necessary network interfaces are not in the list, close the program and run it again with administrator rights.

The main working window of Wireshark is divided into 3 areas, as shown in figure 0.1. You will be taken to this window as soon as you start capturing traffic. The area marked with number 1 displays the captured network packets. In area number 2 is the packet decoder. In it, the contents of the package selected in the first area are categorized depending on the level of the OSI model. The bottom area, labeled 3, displays a byte-by-byte representation of the same packet. Area number 4 contains buttons for controlling packet capture.

Figure 0.1. Wireshark working window

When traffic capture is running, area number 1 automatically scrolls down (to where new packets appear). Autoscroll is enabled/disabled using the button marked in Figure 0.2

Figure 0.2. Button to enable/disable auto scrolling of the packet capture area

Note that packet capture cannot be paused. It can only be stopped. But the next time you run packet capture, all previous data will be cleared. To avoid data loss, captured packets can be saved to a file and then loaded from there (these operations are available from the "File" menu). The file in which the captured packets are written is called a traffic dump.

The default set of columns in the list of captured packets may be inconvenient for some analysis tasks. It can be changed. To do this, you need to call the settings window using the menu item "Edit Preferences". In the window that opens, select the Appearance Columns section, in which you can remove unnecessary columns (- button) or add new ones (+ button). When adding a column, you must specify its name and select the information displayed in it. Figure 0.3 shows an example of creating a column to display the source port (for a transport protocol).

Figure 0.3. Example of adding a column to the list of captured packets

In order to adjust the width of a column, you can use its context menu in the main application window and select the Resize To Contents item there.

3.2.1. Start Wireshark. List the interfaces available for capturing traffic. Using the techniques learned in No. Mistake! Reference source not found., determine which interface is used to send packets to the default gateway. Start capturing traffic for this interface (in future work, also use this interface).

3.2.2. Keep capturing traffic for a minute, then stop it. View captured packets. List which protocols they apply to. For protocols that were not considered in the theoretical part of the course, find information about their purpose on your own.

3.2.3. Choose one of the captured packets. In the packet decoder, sequentially expand information about all nested protocols. Capture the result in a screenshot. What do you think, what application and why has formed this package?

3.2.4. In the list of captured packets, add columns containing the source port and destination port. Change the display format of the time in the "Time" column from seconds elapsed since the capture began to absolute time with millisecond precision. To do this, select the menu items "View Time Display Format Date and Time of Day" and "View Time Display Format Milliseconds". Adjust the width of all columns so that there are no large empty spaces between them and at the same time the content is not cut off (except for the "Info" column). Capture the result in a screenshot.

3.2.5. Save the received traffic using the "File" menu. What is the extension and size of the resulting file?

1.3. Packet filtering

Very rarely all packages are needed for analysis. Most often, only a part of them is of interest. In order to leave only essential information, a filtering mechanism is designed. There are two types of filters in Wireshark:

capture filters;

display filters.

As the name implies, in the first case, the filter limits the packets that will be placed in the application's memory, i.e. part of the traffic is lost. In the second case, restrictions apply only to the list of displayed packets in the main window, while all captured packets remain in memory. Thus, the display filter can be changed many times without data loss. For example, on the same dump, you can first display all ARP packets, and then only ICMP. On the contrary, if the capture filter was configured only for ARP packets, then all other packets were not captured and it is impossible to recover them. The display filter is more convenient to use, but storing all the packages requires a large amount of RAM. For example, if you need to analyze a packet stream at gigabit speeds, then when recording all the traffic, the RAM of a regular PC can be used up in just a few seconds or minutes. In this case, you need to use a capture filter, limiting yourself to only some specific packets, instead of all in a row.

Filters are a logical expression consisting of the package parameters, their values, and the AND, OR, and NOT logical operators. Unfortunately, the syntax for capture and display filters is quite different. This is because in the first case the filter is sent to WinPcap, and in the second case to the built-in Wireshark packet decoder.

The capture filter is more primitive (less set of parameters) than the display filter, but this is due to the requirements for its performance. It uses "and", "or" and "not" as logical operators (as in Python). Parentheses are used to group logical operators. Parameter values are written immediately after the parameter separated by a space without a comparison sign. Subparameters are also written after the parameter with a space. For example, "ip proto 0x11 and (port 53 or port 67)" corresponds to the rule "capture only UDP traffic using ports 53 and 67" or, in other words, "capture only DNS and DHCP packets". More details about the filter syntax can be found on the WinPacp project website [2].

To create a new filter, select the Capture Capture Filters item in the menu, then click the + button in the window that opens, and then enter the filter name (arbitrary) and the filtering criterion in the line that appears. An example of creating a capture filter is shown in Figure 0.4.

Figure 0.4. Create a capture filter

You can apply the created filter before you start capturing traffic. A drop-down list for selecting a filter is available both on the start screen (above the list of interfaces) and on the screen in the network interface selection window, which is called by the Capture Options menu item (here the filter selection is below the list of interfaces, Fig. 0.5).

Figure 0.5. Selecting a capture filter

The display filter has a syntax similar to the C programming language: "&&", "||" are used as logical operators and "!", comparison operators are used "==", "!=", "<", ">", etc., subparameters are written through "." after the parameter. The previous criteria for sampling DNS and DHCP packets for the display filter corresponds to: "udp.port==53 || udp.port==67". And thanks to the rich dictionary of the packet decoder, you can immediately write the filter in the form dns || dhcp".

The display filter is entered in a special line immediately above the list of captured packets. It can be used during or after packet capture.

To simplify the procedure for writing display filters, you can automatically construct a filter on any field in the packet decoder. To do this, you need to find the package of interest in the list and select it. Then, when its contents are displayed in the packet decoder, call the context menu for the field of interest and select the item "Apply as Filter Selected" or "Apply as Filter ... and Selected" (if you need to refine the already set selection). Figure 0.6 shows an example of how you create a filter for an ICMP echo reply. As a result, the expression "icmp.type == 0" will appear in the filter field.

Figure 0.6. Creating a Display Filter for ICMP Echo Replies

The system has a lot of built-in display filters, but if you lack them (for example, when working with your own or very rare protocols), then in the filter conditions you can directly access the byte values by their number. To do this, you need to use a record of the form: frame[X:Y]==Z, where X is the offset relative to the beginning of the data (counting from 0), Y is the amount from the specified offset, and Z is the desired value in hexadecimal form. Instead of "frame", which corresponds to the count from the channel part of the Ethernet frame, you can use the names of higher protocols. In this case, the offset will be relative to the beginning of the given protocol header in the packet.

For example, the entry "frame[23:1]==01" will match the ICMP protocol, since 23 bytes from the beginning of an Ethernet frame can contain a "Protocol" field, but only if an IPv4 protocol is nested in it. If the IPv6 protocol is inside the frame, then this byte will contain a fragment of the source IP address. And if the protocol is CDP, then the result will be even more unpredictable. Thus, the "frame[23:1]==01" filter will indeed allow you to get all ICMP messages, but apart from them, pseudo-random information will also be included in the selection. Therefore, it is desirable to refine the logical expression by adding only IPv4 selection: "frame[23:1]==01 && frame[12:2]==0800" or using offsets from the IPv4 header: "ip[9:1]==01" . Here offset 9 from the start of the IPv4 header corresponds to offset 23 from the Ethernet header since the Ethernet DIX header is 14 bytes long.

3.3.1. Start capturing traffic in Wireshark and navigate in your web browser to any site of your choice. Stop capturing packets. Use the packet decoder to create a filter to display only DNS packets. Capture the result in a screenshot.

3.3.2. Clear the filter and select again any DNS packet from the list of captured ones. Using a packet decoder, find the field containing the port number "53" (corresponding to the DNS protocol) in the UDP header and use the value of this field as a new filter. Capture the result in a screenshot.

3.3.3. What is the difference between the filtering results in paragraphs 3.3.1 and 3.3.2? What needs to be corrected in the filter from paragraph 3.3.2 in order to select all DNS packets without using the dns keyword?

3.3.4. Which hosts are DNS packets addressed to? Find these IP addresses in the output of the "ipconfig /all" utility and note them in the screenshot.

3.3.5. Create a capture filter that will only allow ARP and DNS packets through (don't forget that client DNS is determined not only by port 53, but also by UDP transport). Start capturing traffic and continue capturing until the two types of packets you are looking for are captured (this should not take more than a few minutes). Using the techniques from work No. Mistake! Reference source not found. you can provoke the appearance of these packages. Capture the result in a screenshot and note down the filter you used.

3.3.6. Compose a mapping filter to fetch ARP requests by accessing bytes by their offset relative to the beginning of the Ethernet frame. You can find out the required offset (packet ARP type) from the RFC documents, or by examining the sample packet (when you select the parameter of interest in the packet decoder, the corresponding bytes in the "raw" representation are highlighted in color). Write down the resulting filter.

3.3.7. Start capturing traffic using a capture filter that allows only DHCP packets to pass through (refer to the theoretical material for information about the ports used and the transport protocol). Record the resulting filter

3.3.8. At the command prompt, as an administrator, run the "ipconfig /release" and "ipconfig /renew" commands, which cause the OS to first discard the dynamic address and then request it again. Stop capturing traffic. Capture the result in a screenshot. What types of DHCP packets did you capture? What is the role of each of these types?

3.3.9. In the packet decoder, examine the DHCPOFFER packet. What network settings are offered to the client in it?

1.4. Analysis of service protocols

3.4.1. Launch Wireshark and start capturing traffic. Run the command prompt as an administrator and clear the workplace ARP table with the "arp -d *" command. Ping first the default gateway (can be determined using the ipconfig utility) and then the yandex.ru host. Finish capturing traffic. To hide unwanted traffic, set the filter to show only ARP, DNS, and ICMP packets. Capture the result in a screenshot.

3.4.2. How many ARP packets and what type were captured? What hosts were the senders and receivers of these packets (identify by MAC addresses which hosts they are)? What did these packets have to do with pinging? What value in the EtherType field of the Ethernet header indicates the presence of the ARP protocol in the attachment?

3.4.3. How many DNS packets and what type were captured? What hosts were the senders and receivers of these packets at the link and network layers? What did these packets have to do with pinging?

3.4.4. Among the captured ICMP packets are several requests and several responses. Select any ping from the list of captured packets. Take a screenshot of the contents of the decoder for the IP and ICMP headers of the selected packet. When a package is selected, the symbol appears to the left of its number in the general list. Find the package marked with a double arrow "". This is a response package. Take a screenshot of the contents of the packet decoder for its IP and ICMP headers. On the two screenshots you receive, check the boxes that indicate that these packages are related.

3.4.5. Create a filter that will display only the ICMP packets that were used to ping the yandex.ru host. Write down this filter. Write down the IP and MAC addresses of the recipients and senders of the packets for the echo request. Which nodes do these addresses belong to? Why is the same packet at the network and link levels addressed to different nodes?

3.4.6. Ping the yandex.ru host with a 1400-byte packet with traffic capture. What is the data field filled with and how long does it have in requests and responses? Ping the google.com host with a 1400-byte packet with packet capture. What is the data field filled with and how long does it have in requests and responses? Note that in the second case, Wireshark marks the echo request with no response found!, even though the response exists and is recognized by the ping utility. This is because these applications check a different set of fields when looking for a paired package.

#Additionally

Almost all operating systems for their implementation of ping allow you to set the length of the packet. However, they interpret this parameter differently. So, for example, Windows understands the length of the packet as the length of the ICMP data field of the packet (for MTU 1500 without fragmentation, it can vary from 0 to 1472). And Cisco IOS raises the total length of the IP packet under the packet length (for MTU 1500 without fragmentation, it can vary from 28 to 1500).

3.4.7. Ping the yandex.ru host with a 3000-byte packet with traffic capture. If you use the "icmp" display filter, then some of the IP packets containing echo request fragments will disappear from the display. Why is this happening? Use the filter using the "ip.addr==..." condition to see all the pieces of the ping we are interested in. For any of the echo requests, find all three of its fragments. Write down the values of the "Identification", "MF", "Fragment offset" fields of the IP header for these packets. Explain how the values of these fields allow you to restore the sequence of fragments and determine their number.

3.4.8. Ping the yandex.ru host with the "-r 9" switch with traffic capture. Find which part of the network packet contains the route information you received? Explain why 9 is the maximum possible value for the "-r" option.

3.4.9. Create a traffic capture filter that only allows ICMP and DNS packets to pass (write it down). Start capturing traffic with the created filter, and then trace the yandex.ru host. Stop capturing packets when the trace is complete. Record the capture result in a screenshot.

3.4.10. What types of ICMP messages were captured? Which nodes send what types of messages? Why do different nodes send a message with type 11 in response to a request to the same node?

3.4.11. Filter the packets leaving only pings (select the packet type field in the decoder and use it as a filter). Why does the list still show type 11 ICMP messages despite filtering by type 8? How can the filter be improved to leave only the original queries?

3.4.12. There are DNS packets in the list of captured packets. What is their role in the tracing process? What type of DNS record do they use?

1.5. Accessing the website

3.5.1. Start capturing traffic in Wireshark and open the site

http://linuxatemyram.ru (never use the https scheme). When the site is fully open, stop capturing traffic. Use the "ipconfig /displaydns" command to determine which IP address was used to query the content of this site and use that as the value for the "ip.addr" parameter of the display filter. Capture the result in a screenshot.

3.5.2. In the list of captured packets, look for the one whose text in the "Info" column starts with "GET/HTTP...". Call the context menu for this packet and select Follow TCP Stream. This will display the data transmitted in all packets belonging to the same stream. Data transferred by the client is highlighted in red, and server data is highlighted in blue. If the server response starts with HTTP/1.1 304 , then this indicates that the page was loaded not from the server, but from the local cache (perhaps you were not able to record the traffic the first time or visited this site before). In this case, go back and repeat step 3.5.1, refreshing the page in the browser using the Ctrl+F5 key combination (forced cache refresh). Capture the contents of the TCP stream in a screenshot.

3.5.3. What value did the display filter take when you selected all the messages from the same thread? Examine the first three packages in the thread: what flags do they have set? Determine in which packages (now for the entire thread) the "MSS" and "Windows Scale" options are changed and what value they take. Given the information about the multiplier, determine the size of the window and whether it changes during the flow. Note that the window size, window multiplier and "MSS" change independently for the server side and the client side.

3.5.4. For all other packets, determine: window sizes: received by server and client.

3.5.5. Write down all the headers used in the HTTP request and response. On your own, find and enter into the report information about which of these headings is for what.

3.5.6. Clear display filters and make sure packet capture is stopped. Use the menu item "File Export Objects HTTP", which calls the built-in decoder for the application protocol. What files are on the list? What is their role in the formation of the studied page? Find an image in png format among the files and save it on your computer (select the file and use the "Save As ..." button). Open the saved image. Capture the result in a screenshot.

1.6. Viewing TLS traffic

Most modern websites use an encrypted connection to transfer data. In most cases, encryption is provided by the TLS protocol (which has replaced the less secure SSL). TLS works between the transport and application protocol (in the case of web traffic, between TCP and HTTP). The presence of TLS is indicated by the "https" scheme in the URL. In this case, it is impossible to see the HTTP protocol data directly in the traffic analyzer, just as it was done in paragraph 1.5.

To view data encapsulated in TLS, the parser needs to provide session encryption keys. In turn, encryption is carried out by the browser, so the encryption keys are in it.

3.6.1. If the FireFox browser was already running, then close all its windows. Then start the operating system console, in which run the commands:

"set SSLKEYLOGFILE=%HOMEDRIVE%%HOMEPATH%\keys.log" (sets the environment variable for the current command line session) followed by "%ProgramFiles%\Mozilla Firefox\firefox.exe"" (launches the browser). Note that both commands must be run from the same command line, as the set command only affects the current session. Open any site with the https scheme in a browser and check that the keys.log file has appeared in the user's home directory. Open this file and write to the report the first line contained in it.

3.6.2. Launch traffic capture and open the page https://max.zolotyh.su/lab03 in FireFox. In the form that opens, enter your nickname as a username and any random combination of characters as a password, then click the login button. Stop capturing traffic. Similarly to paragraph 3.5.1, filter the traffic sending data to the site by its IP address, and then display the contents of the TCP stream. Capture the result in a screenshot. Can you understand what information was being sent in the stream?

3.6.3. Open the Wireshark settings window (menu "Edit Preferences ..."), then in the left part of the window select the "Protocols" item and the "TLS" sub-item. On the tab that opens, in the "(Pre)-Master-Secret log filename" field, specify the full path to the key file created in step 3.6.1, and close the window by pressing the "OK" button. Remove the TCP stream filter and return the IP address filter. Please note that HTTP and other headers that were previously hidden appeared in the list of captured packets, headers nested in the TLS header appeared in the packet decoder, and a Decrypted TLS tab appeared at the bottom of the packet byte-by-byte display, allowing you to view the decrypted content without using the field decoder. Capture the list of captured packets in a screenshot.

3.6.4. In the list of captured packets, look for the one whose text in the "Info" column begins with "POST /lab03 ...". Call the context menu for this package and select Follow TLS Stream. Capture the result in a screenshot. Find and note in this snapshot the username and password that you sent to the server and intercepted by the network analyzer.

3.6.5. Start capturing traffic and open the page https://yandex.ru in FireFox. In the search form that opens, enter any combination of Latin characters (to avoid problems with the choice of encoding, do not use Cyrillic when further analyzing headings) and click the "Find" button. Stop capturing traffic. Similarly to paragraph 3.5.2, restore the TLS stream for sending the search request. Note that the stream is not human readable. This is because it is binary-encoded using the HTTP2 protocol (note that encoding and encryption are separate processes). This is indicated by the magic sequence PRI * HTTP/2.0 at the beginning of the stream. For older browsers, it is treated as an unknown "PRI" method. Capture the result in a screenshot.

3.6.6. The HTTP2 protocol contains headers similar to HTTP1.1, but now they can only be seen in readable form in the packet decoder. Use "http2" as the display filter. Press the keyboard shortcut Ctrl+F. In the search bar that opens under the filter, select the search type "String", the search area "Packet details" and enter the combination of Latin characters used in the previous paragraph into the search bar. Keep searching until you find a package containing both the text you are looking for in the package decoder and the HTTP2 "POST" method (in the "Info" column of the package list). Examine the headers of the found packet in the decoder. Which of the headlines have you already seen in 3.5.5? List them and capture some of them (of your choice) in a screenshot.

3.6.7. Write a display filter that will only display HTTP2 headers containing the POST (data submission) and GET (page request) methods. Write down this filter. In the "Info" column, you'll see a lot of relative URLs: check out this entire list. Can you guess from the information they contain about the role of at least some of them in the display of the search page? If so, write down examples of such URLs with comments.

3.6.8. Wireshark has a large number of tools that allow you to extract statistics from captured traffic. Very often, statistics are even more important than analyzing individual packets. Let's use one of the same tools. To do this, apply the display filter "http2 || http", and then call statistics on traffic senders and recipients using the menu "Statistics Endpoints". In the window that opens, go to the "IPv4" tab, check the "Limit to display filter" box and sort the list in descending order by the number of bytes sent and received by each node. Capture the resulting rating in a screenshot. Most of these nodes also participated in the issuance of the search page. These are the servers from which pictures, tips, user trackers and other resources were loaded.

3.6.9. Open the DNS packet analyzer in the captured traffic: "Statistics Resolved Addresses". Find the hostnames from the ranking obtained in the previous step. Record these names and their corresponding IP addresses in the report in tabular form.