Capturing packets Business Computing Environments & Networks

A packet sniffer, sometimes referred to as a network monitor or network analyzer, can be used legitimately by a network or system administrator to monitor and troubleshoot network traffic.

Using the information captured by the packet sniffer an administrator can identify erroneous packets and use the data to pinpoint bottlenecks and help maintain efficient network data transmission.

In its simple form a packet sniffer simply captures all the packets of data that pass-through a given network interface. Typically, the packet sniffer would only capture packets that were intended for the machine in question. However, if placed into promiscuous mode, the packet sniffer is also capable of capturing all packets traversing the network regardless of destination. [1]

In this lab, we used a program called “Wireshark” to capture packets. Our goal was to achieve three things. Firstly, we understood the functionality of Wireshark, and analysed simple protocols. Next, we found specific packet sequences, we observed a TCP connection, a DNS request/response, and learnt how we can follow an HTTP stream using Wireshark. Finally, we set up a network by making one computer as an FTP client, and the other one as an FTP server to view an FTP transfer over this network.

RELEVANT TERMINOLOGY:

PACKET: A piece of a message transmitted over a packet switching network. See under packet switching. One of the key features of a packet is that it contains the destination address in addition to the data. In IP networks, packets are often called datagrams. (Webopedia)

HOST: A network host is a computer or other device connected to a computer network. A network host may offer information resources, services, and applications to users or other nodes on the network. A network host is a network node that is assigned a network layer host address. (Wikipedia)

TCP: TCP is one of the main protocols in TCP/IP networks. Whereas the IP protocol deals only with packets, TCP enables two hosts to establish a connection and exchange streams of data. TCP guarantees delivery of data and also guarantees that packets will be delivered in the same order in which they were sent. (Webopedia)

IP: IP specifies the format of packets, also called datagrams, and the addressing scheme. Most networks combine IP with a higher-level protocol called Transmission Control Protocol (TCP), which establishes a virtual connection between a destination and a source. (Webopedia)

FTP: File Transfer Protocol (FTP) is the commonly used protocol for exchanging files over the Internet. FTP uses the Internet’s TCP/IP protocols to enable data transfer. FTP uses a client-server architecture, often secured with SSL/TLS. FTP promotes sharing of files via remote computers with reliable and efficient data transfer. (Webopedia)
DNS: An Internet service that translates domain names into IP addresses. Because domain names are alphabetic, they’re easier to remember. The Internet however, is really based on IP addresses. Every time you use a domain name, therefore, a DNS service must translate the name into the corresponding IP address. For example, the domain name www.example.com might translate to 198.105.232.4. (Webopedia)

DHCP: Dynamic Host Configuration Protocol (DHCP) is a protocol for assigning dynamic IP addresses to devices on a network. With dynamic addressing, a device can have a different IP address every time it connects to the network. In some systems, the device’s IP address can even change while it is still connected. DHCP also supports a mix of static and dynamic IP addresses. (Webopedia)

ETHERNET: A local-area network (LAN) architecture developed by Xerox Corporation in cooperation with DEC and Intel in 1976. Ethernet uses a bus or star topology and supports data transfer rates of 10 mbps. The Ethernet specification served as the basis for the IEEE 802.3 standard, which specifies the physical and lower software layers. Ethernet uses the CSMA/CD access method to handle simultaneous demands. It is one of the most widely implemented LAN standards.

IMPLEMENTATION:
We downloaded Wireshark from www.wireshark.org as per the given instructions. Installing Wireshark took few minutes, after which WinPCap was installed. The implementation section is divided into three parts.
Part 1: Analyzing Simple Protocols

After the installation of Wireshark was completed, we opened Wireshark and found our local interface listed. We pressed “Start” to begin capturing packets, and clicked on the square red button (Stop button) to stop the capturing of packets.

We found TCP packets by observing the “Protocol” column of the packet list pane. When we selected that packet, we could observe the details of that packet in the packet details pane.

Fig 1: Ethernet II Frame Layout of the TCP packet

Figure 3a includes 20 bytes that are processed in the hardware and will not be seen in the packet details pane. These are the preamble (7 bytes), the Start of Frame (1 byte), the Frame Check Sequence (FCS, 4 bytes), and the final Flag (8 bytes). [2]

The Ethernet II frame layout, the IP header layout, the TCP header layout can be seen in the following picture. [3]

So, when we compare the screenshot with the above picture (fig. 3a), we see that the only field missing is the “Data” field. And that is because, our connection wasn’t an Ethernet connection. We used “NIU Wireless” from Barsema Hall at NIU. Since it is a wireless connection and doesn’t use Ethernet, we weren’t able to find the “Data” field in our packet.

We then observed the rest of the sections of the packet.

Fig. 2: IP Header Layout

Comparing fig. 2 with fig. 3b we find that the header layout in our screenshot in fig. 2 is the same as the expected layout (fig. 3b).

Finally, we observed the TCP header layout of the packet.

Fig. 4: TCP header layout

Comparing fig. 3c with fig. 4 shows that we got the expected results in the packet under observation.

Part 2: Finding Specific Packet Sequences

Step 1: Observing a TCP Connection

We started the packet capture process as before, opened a web browser, and visited www.niu.edu. We waited for it to finish loading before we stopped the packet capture.

We wanted to observe the first three TCP packets in the packet list pane. We found them easily due to their green background colour.

Fig. 5: Observing a TCP connection

The three packets were listed as [SYN], [SYN, ACK] and [ACK]. This three-packet exchange establishes a connection between two computers. Port 80 is the destination port for the [SYN] packet. This shows the web request. The other two are sequence/acknowledgement and acknowledgement packets.

Step 2: Observing a DNS Request/Response

We began the capture session again and opened the command prompt. We hit the “ipconfig/release” command to release our IP address.

Fig. 6: Releasing a DHCP IP Address Lease

Our computer was IPv6 configured, so we hit the “ipconfig/release6” command to release the configured IPv6 address.

Fig. 7: Releasing configured IPv6 address by “ipconfig/release6”

After releasing the IP address, we hit the “ipconfig/renew” command at the command prompt. We waited for few seconds until the renewal process was completed before stopping the packet capture process.

Fig. 8: Renewing a DHCP IP Address Lease

In order to sort the entries in the order of protocol, we clicked on the column “Protocol” in the packet list pane. We easily found the DHCP packets by doing so.

Fig. 9: DHCP packets in the packet list pane

Totally, there were 5 DHCP packets. We learnt that the first of these packets is from our computer to the DHCP server telling it to release the lease on our IP address. The next 4 packets renew that lease. We noted that the source address on the “DHCP Discover” and “DHCP Request” packets is 0.0.0.0. This indicates that our computer does not actually use its new IP address until the interchange has completed. Also, the destination address in each of the 4 packets is a broadcast address. [4]

It should be obvious to you why the first two packets are broadcasted, but what about the last two? Can you explain this?

The DHCP Discover request is sent by the device to the DHCP server. The DHCP server responds to this by holding an IP address that can be used by the device, and then sending the DHCP Offer packet to the device in the form of an offer.

The client (device) then replies to this by a DHCP Request packet which shows that it is ready to accept this offer. Then the server acknowledges this by sending the DHCP ACK packet which is a confirmation that it can use this specific IP address. It also specifies the time that the device can use this IP address.

Step 3: Following an HTTP Stream

In this step, we observed the request/response interchanges that are involved in loading a website. We started the packet capture session as before after opening Microsoft Edge as per the instructions given. We visited www.niu.edu again and waited for the page to load completely before we stopped the capture session. The next step was to find the packet with comments in the “Info” column saying “GET / HTTP/1.1” and selecting it.

Fig. 10: Following an HTTP stream

Right clicking this packet, then clicking on “Follow TCP stream” opened a new window which contained the details of the http exchange.

Fig. 11: Raw TCP stream data

We could see the request and acknowledgements from our workstation in red, and the responses in blue.
After we clicked the “Close” button at the bottom to return to the main window, we saw that only the TCP and HTTP packets were retained. This was due to the creation of a filter based on our action of following the TCP stream. Then we exported this file by selecting File > Export > Objects > HTTP.

Fig. 12: Exporting TCP Stream (HTTP)

On viewing the file in a web browser, the file seemed to lack a few things such as image, CSS, or flash files when compared to the original website. The following image is a comparison between the original website our file.

Fig. 13: niu.edu comparison

Part 3: Viewing an FTP Transfer

In this section, we used FileZilla to download both the server and client version of the program. We setup the FileZilla server on one computer and the FileZilla client was setup on the other one. This was done to observe the file transfer between an FTP client and an FTP server.

Step 1: Setting up the FTP Server

The FileZilla server was downloaded and installed from http://filezilla-project.org on one of the computers. As per the instructions, 127.0.0.1 was put as the server name. We created a user (“johndoe”) and assigned home directory to that user. Then we setup “secret” as the password. We then created a folder on desktop, copied an image into the folder, and added it into the server under “shared folders”.

An important thing to remember here was to turn off the firewall to prevent any problems pertaining to setting up of the server.

The following is a screenshot after the server was setup and logged in.

Fig. 14: FileZilla server after the setup

Next, the FileZilla client was downloaded and installed on the other computer.

Step 2: Monitoring the FTP Login Exchange

We opened Wireshark (on the client) and began the packet capture process. After that, we opened the program and entered the IP address of the server. (It was 10.166.80.56 in our case.) Then we entered the username and password as mentioned earlier. After capturing the packets, the packet capture session was stopped by Wireshark. We could see the changes in FileZilla server which are shown in the following screenshot.

Fig. 15: FileZilla server during the FTP transfer

The window of the FileZilla client is shown in the following screenshot.

Fig. 16: FileZilla client during the FTP transfer

On careful observation, we can notice the image file that we copied in the “shared folder” of the FileZilla server being displayed here.

In order to observe the FTP packets in the Protocol column, we clicked on “Protocol” so that it sorts by protocol. When we see that all packets are FTP packets, we can notice that the username and password are clearly visible in the “Info” column. Following are the screenshots which show this.

Fig. 17a: FTP login sequence in Wireshark

Fig. 17b: FTP login sequence in Wireshark

Fig. 17c: Password clearly visible during the packet capture process

If you have never seen a password revealed in a packet sniffer, it can be a real eye opener. Although we know that FTP servers are inherently not secure, this demonstration should make you think about the security of other types of logins. Try this: if you have a domain controller on your network, try logging on to it from a workstation and sniffing the packets as you do so. Are you able to find the password? (Hopefully not.) Now set up a database server for which the security setting is controlled by the operating system and do the same thing. If the security is not configured correctly, not only will you be able to find the login information (user name and password), but data will be passed in the clear also.

LAB QUESTIONS:

Packet sniffing can be a controversial subject. Discuss any issues related to ethics that might arise when an organization monitors the electronic activity of its employees.

A. There can be multiple issues that may arise if an organization monitors the electronic activity of its employees. For example, if an employee is given a task to complete within 40 hours, he may do that in 30 hours and may want to relax during the rest 10 hours. If the organization finds about this, would it be a problem for him? Other instances could be the exchange of personal messages among employees. How would the organization react if they were to find that some of its employees were backbiting their manager? Or an employee may face problem if he/she were to access shopping websites during his office hours.

You looked at packets captured during a web page request. What might this be useful for?

A. If an organization runs into a problem with their website, this method can be used to troubleshoot the website/webpage. The packets captured during the webpage request can be used to debug the communication between a client and server. It can help in keeping away the intruders, and thus contributing to improve the security of the website.

Most computers are connected together with switches (rather than hubs). How does this affect the packet capturing process?

A. Switched networks are more secure than those networks connected with hubs. If a hacker uses packet sniffing tools in order to eavesdrop the network, it would be easier for him to eavesdrop a network connected with hubs than a switched network.

Discuss how sniffing packets from wireless networks might differ from wired networks. Use the Internet to search for wireless packet sniffers. Where might someone go to sniff wireless packets and possibly obtain some “juicy” information?

A. Packet sniffing in wireless network is easier than a wired network. In a wired network, the packet sniffing software is difficult to install for the hacker. This is because the installation happens pertaining to one or more hosts inside the subnets under target. The hacker must operate the sniffing tool adequately pertaining to the target’s computer. He would also need to run the sniffing tool on those hosts identical to the subnet of the target’s computer so that he can start sniffing packets in a wired system. That is why it is difficult to install a sniffer software in a wired system. Whereas, sniffing packets in a wireless system is much easier. The hacker can crack protocols like WPA and WEP in a wireless system.

CONCLUSION:

We used packet sniffing in this lab to achieve three main objectives:

We understood the functionality of Wireshark in capturing packets over a network. We learnt that the details of a packet can be obtained in Wireshark by selecting a specific packet. The details like Ethernet frame header, the IP header, the UDP header and the data payload are displayed in the “Packet Details” pane. Also, the hexadecimal and ASCII equivalent of each packet is shown in the “Packet Bytes” pane at the bottom.

In the second part, we observed a TCP connection and the three packets (i.e. [SYN], [SYN, ACK] and [ACK]) involved in establishing connection between two computers. We also observed a DNS request/response by releasing and renewing a DHCP IP Address Lease. Finally, we observed the difference between a webpage’s TCP stream and its original version.

Lastly, we observed an FTP transfer between an FTP client and FTP server. We did this by setting up an FTP server on one computer and an FTP client on the other. We learnt that packet sniffing can be risky as it may cause the password to become visible over the network since there is no encryption.

REFERENCES:

HYPERLINK “https://www.lifewire.com/introduction-to-packet-sniffing-2486803” “Introduction to Packet Sniffing”
“Protocol Analysis: Capturing Packets” (Instruction manual for this lab.)
Picture taken from “Protocol Analysis: Capturing Packets”. (Instruction manual for this lab.)
“Protocol Analysis: Capturing Packets” (Instruction manual for this lab.)