In today’s exercise, we will be using Wireshark to capture and analyze network traffic. Wireshark is a free to use tool that is available for Windows, Linux and MacOS. You can download it for free here.
Part 1: Capuring Local ICMP traffic
To capture ICMP traffic, we are required to have 2 devices on the network and send a ping from one device to another. The ping preferably needs to be sent from the device running WireShark to any other device in the network. To go a step further however, a ping can be sent from any other device in the network to the device running Wireshark.
I tried this first by using a virtual machine running Kali and tried to ping the host, but since the was set-up as a bridged connection to the host, Wireshark was not picking up the request. Upon some research, I found out that I may have been capturing the packets sent on the wrong network. After quite a bit of digging and searching, I was unable to capture this traffic. If any of you have any suggestions on how I can do this successfully, it will be much appreciated.
I therefore set up a second scenario where I pinged my android device using my windows host device to capture the ICMP packets while pinging the device. This was successful. I found that each ping is comprised of a request and reply. The request is sent from the source and a reply is sent from the destination. Each ping is sized at 32 bytes at the network layer but the headers from the network and data link layers adds headers to the data making each request and reply to total at 74 bytes at the physical layer. The network layer adds the source and destination IPs to the data while the data link layer adds the source and destination MAC addresses to the data.
This traffic was easy to filter using the protocol type which was given as ICMP. To filter traffic, input the protocol you are looking for in the filter bar. This is the green bar in the screenshot below. The MAC addresses are obtained using an Address Resolution Protocol (ARP) scan. This protocol sends out a broadcast message on the network requesting for the MAC address for an IP address. The result of this scan is the MAC address of the destination IP address.
In cases where the IP address being pinged is not assigned in the network, no data is captured. An ARP scan is performed by the device to find out if the devices in the network know which MAC address has claimed the unreachable IP address. This ARP scan yields no results since the IP has not been assigned in the network. We will learn more about the Address Resolution Protocol (ARP) in a future blog.
Part 2: Capture and Analyze Remote ICMP traffic
In the previous exercise we sent a ping withing our Local Area Network. In this part we will be pinging a remote address like google.com, yahoo.com, cisco.com or any other website of your liking.
The IP addresses for the domains changed, for example: google.com (172.217.170.196), yahoo.com (87.248.100.215), cisco.com (23.39.120.122). Notice how the capture does not mention the domain/host name for the webiste, but just the IP address. This is because of the Domain Name System (DNS) service which will discuss in a future blog. The MAC address for these remote hosts however did not change. This MAC address is that of my network’s router. I found this out by pinging the router and comparing the MAC address of the router and that in the packet capture for the remote hosts.
This happens because the destination is outside the Local Area Network and thus the device has to use the Gateway address to reach this destination. The IPs within our LANs are class C internal addresses which are only internally routable. The router has both a globally routable and internally routable address. The destination server replies to the request addressing it to the global IP address of your router. The router then forwards this to you internally. To learn more about this process, look up routing and routing tables.
MAC address of the router. When getting a reply, the remote host only knows of the router and not the specific device that sent the request within the router’s network. The router then forwards the reply to the device that requested for this information using its internal routing tables.
