Part I of this article discussed tcpdump, a command-line utility that sniffs network traffic. Now let's see what it can do.

Using tcpdump we can analyze the PDUs that establish and terminate a TCP/IP connection. TCP uses a special mechanism to open and close connections. The tcpdump output below display data from different connection scenarios between host 192.168.2.10 and 192.168.2.165. The following tcpdump command and options were used to generate output:

#tcpdump -nn host 192.168.2.165 and port 23

Before examining the output, let's take a detour and get a brief overview of TCP/IP connection management. This small detour will assist those individuals who are new to protocols. To guarantee a reliable connection (startup and shutdown), TCP uses a method in which three messages are exchanged. The process is called a three-way-handshake. To startup a connection:

A similar handshake process is used to close a connection using a finish flag (FIN).

To establish a connection, the sending host creates a segment containing the IP address and port number of the host it want to connect to. The segment contains a SYN flag and the sending hosts initial sequence number. Data is segmented before it is sent. The sequence numbers allow the segments to be assembled in the correct order.

20:06:32.845356 192.168.2.10.1249 > 192.168.2.165.23:
S 3263977215:3263977215(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)

The receiving hosts responds with its own SYN flag and its initial sequence number. This segment also contains an ACK flag to acknowledge the sending host's SYN (segment 3263977215 +1). This type of acknowledgment is called expectational acknowledgment, because the receiver acknowledges the sequence number of the next segment it expects to receive.

20:06:32.845725 192.168.2.165.23 > 192.168.2.10.1249: S
48495364:48495364(0) ack 3263977216 win 32120 <mss 1460,nop,nop,sackOK> 
(DF)

The sending host acknowledges the SYN flag from the receiving host by sending another segment containing the . and ACK flags.

20:06:32.845921 192.168.2.10.1249 > 192.168.2.165.23: . ack 1 win 17520
(DF)

So far two flags, S and ., have been seen. There are five in total.

To terminate a connection, a segment containing a FIN flag is sent from host 192.168.2.165 back to the host with the open session.

20:07:32.916410 192.168.2.165.23 > 192.168.2.10.1249: F 147:147(0) ack
56 win 32120 (DF)

This may appear backwards, but trust me, it's not. Think of where the session is open--this is the point that is asking to close the connection. Host 192.168.2.10 acknowledges the FIN segment.

20:07:32.916680 192.168.2.10.1249 > 192.168.2.165.23: . ack 148 win
17374 (DF)

Then host 192.168.2.10 terminates it connection by sending a segment containing a FIN flag.

20:07:32.928907 192.168.2.10.1249 > 192.168.2.165.23: F 56:56(0) ack 148
win 17374 (DF)

Host 192.168.2.165 acknowledges the segment.

20:07:32.929121 192.168.2.165.23 > 192.168.2.10.1249: . ack 57 win 32120
(DF)

To establish a connection, host 192.168.2.10 sends a segment containing the IP address and port number of the host it want to connect to. The segment contains a SYN flag and the sending hosts initial sequence number.

05:28:00.080798 192.168.2.10.1063 > 192.168.2.165.23:
S 3034008467:3034008467(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)

Host 192.168.2.165 acknowledges the SYN from host 192.168.2.10 by sending another segment containing the R (connection reset) and ACK flags.

05:28:00.080979 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0)
ack 3034008468 win 0 

Host doesn't take no for answer and tries again.

05:28:00.579420 192.168.2.10.1063 > 192.168.2.165.23: S
3034008467:3034008467(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)

But it receives the same result from receiving host.

05:28:00.579524 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0) ack 1 win
0

A final attempt is made to establish a connection.

05:28:01.080114 192.168.2.10.1063 &glt; 192.168.2.165.23: S
3034008467:3034008467(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)

Only three strikes in this ball game. Sending host gives up.

05:28:01.080225 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0) ack 1 win
0

Compare the outputs from an Establish Telnet Connection scenario and Telnet Connection Refusal scenario. The outputs from the receiving host are different. For the Telnet Connection Refusal scenario, the Telnet service was turned off at the receiving host using the /etc/inetd.conf file. If the service is not available, no connection can be established. Note to self: simple security measures turn off services not being used.

The same opening as before is used to establish a connection.

05:40:39.838710 192.168.2.10.1064 > 192.168.2.165.23: S
3223709294:3223709294(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)

The receiving host responds with its own SYN flag and its initial sequence number. This segment also contains an ACK flag to acknowledge the sending hosts SYN (segment 3223709294 +1).

05:40:39.839045 192.168.2.165.23 > 192.168.2.10.1064: S
063202536:2063202536(0) ack 3223709295 win 32120 <mss
1460,nop,nop,sackOK> (DF)

Host 192.168.2.10 acknowledges the SYN from host 192.168.2.165 by sending another segment, which contains the . and ACK flags.

05:40:39.839295 192.168.2.10.1064 > 192.168.2.165.23: . ack 1 win 17520
(DF)

Host 192.168.2.165 responds with a segment containing a FIN flag--connection terminated. Something has told the receiving host no connection is allowed.

05:40:44.852844 192.168.2.165.23 > 192.168.2.10.1064:
F 1:1(0) ack 1 win 32120 (DF) 

Host 192.168.2.10 has a no-flag-set second acknowledgment.

05:40:44.853137 192.168.2.10.1064 > 192.168.2.165.23: . ack 2 win 17520
(DF)

Because a FIN flag segment was received, the connection must be terminated. So host 192.168.2.10 sends a FIN flag to terminate the connection.

05:40:44.855050 192.168.2.10.1064 > 192.168.2.165.23: F 1:1(0) ack 2 win
17520 (DF)

Host 192.168.2.165 responds with a segment acknowledgment.

05:40:44.855176 192.168.2.165.23 > 192.168.2.10.1064: . ack 2 win 32120
(DF)

Compare the outputs from an Establish Telnet Connection scenario and Telnet Connection Refusal (tcp wrappers) scenario. The outputs from the receiving host are different. In the Telnet Connection Refusal (tcp wrappers) scenario, tcp wrappers is enabled by adding the following line to the /etc/hosts.deny file: ALL:192.168.2.10. This means "deny all services to this host with address 192.168.2.10". A similar connection test was done using a rule in iptables firewall. The resulting output was the same.

The reader may gain some insight into how systems are at risk from the trappings of tcpdump. Before a system hack is possible, some effort is expended to engineer the hack. An examination of the data from a system can provide the hacker with some insight into where efforts might provide the greatest chance of success.

Same opening, different scenario.

05:55:21.557846 192.168.2.10.1065 > 192.168.2.165.23: S
3443876657:3443876657(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)

There's no response, so the sending host tries the same request again.

05:55:24.560891 192.168.2.10.1065 > 192.168.2.165.23: S
3443876657:3443876657(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)

With still no response on the third try, the three-strike rule comes into effect. The sending host abandons the connection attempt.

05:55:30.569584 192.168.2.10.1065 > 192.168.2.165.23: S
3443876657:3443876657(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)

In looking at tcpdump, I have limited the discussion to the TCP/IP protocol connection. There are other protocols and other areas that could be examined using tcpdump, such as performance monitoring. Measuring a PDUs response times can be used to determine network/system performance.

If you recall in the sample network description from Part I, I mentioned the operating systems for each host. The reason I did so was to draw attention to open-source protocols. TCP/IP is an open-source protocol. The PDUs standards for each protocol in the stack can be found in request for comment (RFC) documents.

The word standard in the computer industry means "we all agree to use it". Vendor implementations of RFCs, however, are not all the same. Each vendor implementation becomes a standard if you agree to use their operating system (OS). With detailed analysis, the slight differences in protocol behaviors for each vendor could be determined. Protocol analysis from tcpdump provides the knowledge to make an educated guess on what the host OS is running. So there's no sense in trying known Windows hacks if the system OS is Linux.

Sean D. Conway is a former college instructor turned network system specialist for a regional telecommunications company in Canada.