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.
Figure 1. Frame Illustration
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)

Example 1The 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)

Example 2If 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)

Example 3So 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 ContentsDescription19:20:00.804501Description192.168.2.10.1221source IP address with port number192.168.2.165.23destination IP address with port numberSflag2565655403data sequence numberswin 16384window sizeMore 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