Making a Connection with tcpdump, Part II

Part I of this article discussed tcpdump,
a command-line utility that sniffs network traffic. Now let's see
what it can do.Scenario 1: Established Telnet
ConnectionUsing 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:

• The requesting Host sends a synchronization flag
  (SYN) in a TCP segment to create a connection.
• The receiving Host 192.168.2.165 receives the SYN
  flag and returns an acknowledgment flag (ACK).
• The requesting Host 192.168.2.10 receives the SYN
  flag and returns it's own ACK flag.

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.

• S: SYN (Synchronize sequence numbers - Connection
  establishment)
• F: FIN (Ending of sending by sender - Connection
  termination)
• R: RST (Reset connection)
• P: PSH (Push data)
• .: (No flag is set)

Scenario 2: Closed Telnet ConnectionTo 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)

Scenario 3: Telnet Connection Refused (no
service offered at the host)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.Scenario 3: Telnet Connection Refused (tcp
wrappers security used at host)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.Scenario 4: No Telnet Connection (host removed
from the network)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.

email: Seconway@mts.net