Making a Connection with tcpdump, Part I
As a system administrator, small command-line utilities that require little setup and can be used for troubleshooting increase in value--especially when you are called out at 2:00am for a system problem.
As an instructor, small command-line utilities that require little setup and can be used to demonstrate a critical concept increase in value--especially when it is 2:00pm on a Friday and you are trying to finish a lecture before a long weekend.
Tcpdump is such a utility. It is a command-line utility that allows the root user to capture (sniff) the contents of frames that are traveling through the network interface. The operation is non-intrusive; it does not alter the contents of the frame.
A frame is a protocol data unit (PDU) used to move data from sources to destinations on a network. A train boxcar is analogous to a frame. Boxcars are structured transportation units used to carry goods between two points. Likewise, frames are structured data units used to carry data between two points.
Figure 2. Encapsulation Illustration
Many documents reference data units as packets; everything seems to be a packet. Using the three layers from the OSI model as a reference, I label PDUs at each layer. I also try to maintain the PDU naming convention in my classroom lectures. The PDU at the datalink layer is labeled a frame, the PDU found at the network layer is labeled a packet and the PDU at the transport layer is labeled a segment.
Payloads inside the frames are encapsulated PDUs. Examples of payload protocols are IP, TCP and DNS if TCP/IP is the protocol of choice. Packet sniffers (there goes that packet reference again) simply display the data in the captured frames. By understanding PDUs and their unique structure, an administrator can decipher the contents.
Okay, teach, the introduction seems to have put the class to sleep.
Did I mention that this tool could prove useful in trying to hack a system? (Describing network hacking always has a waking effect on students.) Hopefully some insight can be gained in system hacking after you finish reading this article.
So let me get back to the reason I wrote this article: how the tcpdump utility can be used to troubleshoot a connection problem between two systems.
Figure 3. Sample Network
To produce the examples for this article, I used the computer resources shown in the sample network drawing. The network has three computers connected via a hub. Host 192.168.2.10 (Windows 2000) establishes a Telnet connection to host 192.168.2.165 (Red Hat 6.2). Host 192.168.2.100 (Red Hat 7.2) runs the tcpdump utility. The reason for listing the operating systems will be discussed in Part II of this article.
To turn tcpdump on, I issued the following command as root user on host 192.168.2.100: tcpdump. The output shown below was a continuous stream, line after line nonstop, until a CTRL-C (^C) was issued to stop the utility.
# tcpdump tcpdump: listening on eth0 05:22:27.216338 burner.ssh > prime.1035: P3797249897:3797249949(52) ack 2183278948 win 8576 (DF) [tos 0x10]
This continuous output was expected. One of the computers was running a ssh session generating network traffic. tcpdump did exactly what was asked: dump everything. The tcpdump command can be issued with numerous options that give the user the ability to tailor the output to display specific information.
The man pages for tcpdump explain the options in detail. Another source of documentation for this utility is a pocket reference guide found on the SANS security site. The SANS document provides a tcpdump usage chart (i.e., common options), as well as some PDU layouts for specific protocols. I recommend printing the two-page doc for a quick reference source when examining tcpdump outputs.
The following command line starts tcpdump and displays only those frames that contain an IP address of 192.168.2.165.
# tcpdump host 192.168.2.165 tcpdump: listening on eth0 19:16:04.817889 arp who-has tssoss tell prime 19:16:04.818025 arp reply tssoss is-at 0:a0:c9:20:5b:fe 19:16:04.818182 prime.1219 > tssoss.telnet: S2506660519:2506660519(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
The following command line will output only those frames containing a specific IP address and specified port. Option -nn disables name and port translations. The output is raw data values.
# tcpdump -nn host 192.168.2.165 and port 23 tcpdump: listening on eth0 19:20:00.804501 192.168.2.10.1221 > 192.168.2.165.23: S2565655403:2565655403(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
If the above command is repeated with -t in the option, the display will appear with no timestamps. The -e option requests layer 2 or datalink information. Destination and source MAC addresses are an example of datalink information.
# tcpdump -nne host 192.168.2.165 and port 23 tcpdump: listening on eth0 19:30:13.024247 0:5:5d:f4:9e:1f 0:a0:c9:20:5b:fe 0800 62: 192.168.2.10.1223 > 192.168.2.165.23: S2718633695:2718633695(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
So that's a lot of output. What does it mean? The display provides the PDU information contained in the captured frames. The following table can be used to translate the output from Example 2.
Field Contents | Description |
19:20:00.804501 | Description |
192.168.2.10.1221 | source IP address with port number |
192.168.2.165.23 | destination IP address with port number |
S | flag |
2565655403 | data sequence numbers |
win 16384 | window size |
More data fields than what is shown in the chart above actually appear in the output. I leave the man pages to fill in the missing details.
A solid understanding of a protocol's operation and construction is required to do complete data analysis. The need for this information may be overwhelming to some readers, which is understandable. Don't be discouraged, though. The SANS pocket guide does a good job of describing the contents of a PDU found in TCP/IP.
Part II of this article will describe how to use tcpdump to capture frames from different connection scenarios. The unique contents of the captured frames also will be discussed. Try the commands and the world of protocols will unfold.
Sean D. Conway is a former college instructor turned network system specialist for a regional telecommunications company in Canada.
email: Seconway@mts.net