Analyse network traffic in Linux
Mihalis Tsoukalos teaches you how to get packet sniffing. Learn how to set up, process and inspect your network traffic using Wireshark and tshark.
Wireshark, as well as tshark which is the commandline version of Wireshark, are the best tools for analysing network traffic of almost any kind. This tutorial will show you how to use tshark, including using it with Perl and Python, cover its Flow Graph feature and traffic statistics. We’ll also present a real scenario that involves the DHCP protocol and how to solve it using Wireshark. If you don’t have Wireshark and tshark already installed, you can install both of them on Ubuntu as follows:
$ sudo apt-get install wireshark-dev wireshark-qt tshark
At the time of writing, the latest stable release of Wireshark is 2.2.0, which can be downloaded from www.wireshark.org/download.html (pictured, below, is the About window of Wireshark running on Ubuntu.)
Wireshark has a very handy feature called flow graph, which makes your life easier by visualising and commenting on the network traffic. To use this feature go to the Statistics menu and select the ‘Flow Graph’ option. See the flow graph in action (opposite, top). As you can see, it can be very handy for getting a high-level overview of your network traffic.
Wireshark can display various types of statistics about the captured data, which can help you get a sense of your data without having to look at every single network packet. This can help you understand whether you’ve captured the type of network traffic you wanted. In other words, if you want to examine the traffic from a web server but you have too much data, then you need to figure out what went wrong and start capturing again.
The bottom-right image opposite is the Statistics menu, plus a window with statistics about the IPv6 protocol. As you can see, there was not so much IPv6 traffic in the captured data.
A PYTHON MODULE FOR TSHARK
This section will briefly illustrate the use of Python 3 module pyshark from the Python 3 shell. The following command will install pyshark: $ sudo pip3 install pyshark . First, you will have to execute the Python 3 binary to enter the shell and then execute the following Python 3 code: >>> import pyshark >>> myData = pyshark. FileCapture(‘dhcpNormal.pcap’, only_ summaries=True)
>>> print(len([packet for packet in myData])) 131 >>> numberOfPackets = len([packet for packet in myData])
>>> for i in range(0, numberOfPackets): print(myData[i]) The first command imports the pyshark module and enables you to use it in your session. The second command reads an existing file with network data named ‘dhcpNormal.pcap’ and saves the output into a variable named
myData . The third command allows you to find out the number of packets in the file you read and the last part shows how to iterate over all the packets. The pyshark module can do many more things including capturing network data and applying filters — you can find more information about it at pypi.python.org/pypi/pyshark/0.1.
SOLVING A REAL NETWORK PROBLEM
This section will talk about a real-case scenario that took place on a company LAN and involves the DHCP protocol. Although the case is real, the presented network data is from another network, which was used for simulating the original scenario in order to protect the privacy of the company.
Additionally, despite the fact that the original network data was examined using Wireshark, this section will mainly use tshark in order to be able to provide the text output.
Before continuing with the solution, it’s time to learn about the network problem: some computers on a LAN couldn’t connect to the LAN, although other computers were able to without issue. As if this wasn’t strange enough, after a given time of the day, which was different each day, no computer could correctly connect to the LAN. Plus, after that time, if a working computer was rebooted, it couldn’t connect to the LAN again! The problem somehow depended on the time of the day.
It’s easy to imagine that the problem might have been related to the network configuration of the machine and that it might have involved the DHCP protocol because each machine of this particular network gets its network configuration from the DHCP server of the company. As you will see in a while, the problem was indeed DHCP-related. However, sometimes the most improbable things might happen, which means that the root of the problem wasn’t clear.
Generally speaking, the nasty problems are the ones that involve a combination of hardware malfunctions and software misc on figurations because hardware problems are usually non deterministic. Luckily enough, this particular problem only involved a software mis configuration but in quite a tricky way.
In order to continue, you will need to learn more information about the DHCP protocol. DHCP stands for Dynamic Host Configuration Protocol and provides configuration information to both wired and wireless hosts on TCP/IP networks. The DHCP is based on the BOOTP protocol, which is useful to know because it will allow you to define a proper display filter. Both DHCP and BOOTP use the UDP protocol with port numbers 67 and 68. Usually, a DHCP server provides an IP address, a Subnet mask, one or more DNS servers and a Default gateway to its host, although it is capable of giving many more configuration parameters. The initial communication happens with the help of various basic messages that, for obvious reasons, don’t require an IP address. The four messages are DHCPDISCOVER, DHCPOFFER, DHCPREQUEST and DHCPACK. The DHCPDISCOVER message is used by the DHCP client that searches for a DHCP server and is a broadcast message, which means that it’s sent to a LAN only using the MAC address of the client, because the client doesn’t yet have an IP address. When a DHCP server receives a DHCPDISCOVER message, it replies with a DHCPOFFER message. The DHCPREQUEST message is sent by a DHCP client responding to a DHCPOFFER message from a DHCP server, from a client that wants to verify a previously allocated IP address or from a client that wishes to extend the lease on a network address. Last, the DHCPACK message contains the response of the DHCP server to the DHCPREQUEST message and contains all the necessary configuration information. After a DHCP client receives and processes the DHCPACK message, it’s ready to configure its network interface and, therefore, validly connect to the network. All the gory DHCP details are at www.ietf.org/ rfc/rfc2131.txt.
Two files with network data will be used in this section: the first contains the network data from a normal and proper DHCP transaction and is called ‘dhcpNormal.pcap’ whereas the file with the DHCP traffic that simulates
the case with the problem is called ‘dhcpProblem.pcap’. Both files were captured using Wireshark — we’ll take a look at how to capture and save network data using this tool in depth in a future issue of APC. See the screenshot, above, of the four messages of a valid DHCP interaction, as well as some of the contents of the DHCPACK message using the data from dhcpNormal.pcap.
TROUBLESHOOT LIKE A NETWORK PRO
It’s now time to start examining the problematic network traffic in more detail by looking at the traffic that’s related to DHCP. So dhcpProblem.pcap contains the following network packets related to DHCP:
$ tshark -r dhcpProblem.pcap -Y ‘bootp’
1 0.000000 0.0.0.0 -> 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x7cdcacad
2 0.007067 192.168.1.254 -> 255.255.255.255 DHCP 321 DHCP Offer - Transaction ID 0x7cdcacad
3 0.008310 0.0.0.0 -> 255.255.255.255 DHCP 353 DHCP Request - Transaction ID 0x7cdcacad
4 0.015050 192.168.1.254 -> 255.255.255.255 DHCP 321 DHCP ACK - Transaction ID 0x7cdcacad
5 0.910851 10.0.10.10 -> 255.255.255.255 DHCP 348 DHCP Offer - Transaction ID 0x7cdcacad
6 0.912131 10.0.10.10 -> 255.255.255.255 DHCP 348 DHCP Offer - Transaction ID 0x7cdcacad
As you can see, there are more network packets than expected. What’s stranger is the presence of two DHCPOFFER packets, which means that you might have two DHCP servers on the network instead of just one! The IP addresses of the two DHCP servers, according to the two DHCPOFFER messages, are 192.168.1.254 and 10.0.10.10. As you already know that the IP address of the legitimate DHCP server is 10.0.10.10, the presence of a second DHCP server with an IP address of 192.168.1.254 might be the root of the problem. On the left-hand side of the -> sign of each packet is the IP address of the sender, whereas on the right-hand side is the IP address of the destination computer. As the DHCP client doesn’t have an IP address when it sends the DHCPDISCOVER and DHCPREQUEST messages, the source IP address of packets with numbers 1 and 3 is 0.0.0.0. Similarly, both DHCP servers send a broadcast message to the 255.255.255.255 address, which is received by the DHCP client.
In order to look into a specific network packet from the previous interaction, you should use tshark as follows:
$ tshark -V -r dhcpProblem. pcap -Y frame.number==1
You know that your machine is using the non-legitimate DHCP server because you’ve received a DHCPACK packet from it! So you want to look into frame number 4 because the DHCPACK message contains the information for the network configuration of a DHCP client:
$ tshark -V -r dhcpProblem. pcap -Y frame.number==4
As the previous output — which is not shown on the screen — is relatively big, you can try the following two variations of the command:
$ tshark -V -r dhcpProblem. pcap -Y frame.number==4 | grep “IP address”
Client IP address: 0.0.0.0
Your (client) IP address: 192.168.1.68
Next server IP address: 0.0.0.0
Relay agent IP address: 192.168.1.254 Or alternatively: $ tshark -V -r dhcpProblem. pcap -Y frame.number==4 | grep “DHCP Server” Option: (54) DHCP Server Identifier DHCP Server Identifier: 192.168.1.254
The previous output verifies our suspicions: the DHCP client uses another DHCP server to configure its network interface, so instead of getting an IP address that belongs to the 10.0.10.x network, it gets the 192.168.1.68 IP address, which is why it can’t communicate with the internet and the other machines on the LAN.
CASE STUDY
Back to the real situation now: after finding out that there was a second DHCP server running, the execution of some commands on a Cisco switch revealed the switch port of the physical computer and, therefore, the machine itself. The actual root of the problem was that this machine was running a virtual machine with Linux, which was running its own DHCP server! As this machine was turned off during non-working hours, the problem was occurring when the user of the machine was turning on their computer, which explains the fact that some computers were being configured from the legitimate DHCP server!
After that, an email was sent to every user, advising them to avoid running unnecessary services on their Linux machines!
Please note that, in case you want to use Wireshark instead of tshark, you can use the same Display filter in Wireshark. You will just see the same output in a different format because of the graphical interface of Wireshark. In other words, nothing that you learn for tshark is wasted when used in Wireshark and vice versa! Although it wasn’t needed in this situation, MAC addresses are truly useful when you want to track a given machine that resides on your LAN, because the IP of a device can change but its MAC address will not change so easily. In other words, use a Display filter that tracks the network traffic from and to the MAC address of the desired machine.
As you can appreciate, in order to solve a network-related problem with Wireshark, you will need a pretty good knowledge of networking, which, in this case, covers the way DHCP works, but you will also need to know how to interpret the network data correctly because the theoretical isn’t enough to reveal the actual problem.