Some sample scenarios of how you can use tcpdump for various Telnet connections.
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.
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.
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.
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.
Part I of this article discussed tcpdump, a command-line utility that sniffs network traffic. Now let's see what it can do.
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
Figure 2. Encapsulation Illustration
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 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.
# tcpdumpThis 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.
tcpdump: listening on eth0
05:22:27.216338 burner.ssh > prime.1035:
P3797249897:3797249949(52) ack 2183278948 win 8576 (DF) [tos 0x10]
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 1
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.
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.
| 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 |
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 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:
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.
#tcpdump -nn host 192.168.2.165 and port 23Before 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.
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: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.
S 3263977215:3263977215(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
20:06:32.845725 192.168.2.165.23 > 192.168.2.10.1249: SThe sending host acknowledges the SYN flag from the receiving host by sending another segment containing the . and ACK flags.
48495364:48495364(0) ack 3263977216 win 32120 <mss 1460,nop,nop,sackOK>
(DF)
20:06:32.845921 192.168.2.10.1249 > 192.168.2.165.23: . ack 1 win 17520So far two flags, S and ., have been seen. There are five in total.
(DF)
- 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)
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) ackThis 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.
56 win 32120 (DF)
20:07:32.916680 192.168.2.10.1249 > 192.168.2.165.23: . ack 148 winThen host 192.168.2.10 terminates it connection by sending a segment containing a FIN flag.
17374 (DF)
20:07:32.928907 192.168.2.10.1249 > 192.168.2.165.23: F 56:56(0) ack 148Host 192.168.2.165 acknowledges the segment.
win 17374 (DF)
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.
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.
05:28:00.080798 192.168.2.10.1063 > 192.168.2.165.23: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.
S 3034008467:3034008467(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
05:28:00.080979 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0)Host doesn't take no for answer and tries again.
ack 3034008468 win 0
05:28:00.579420 192.168.2.10.1063 > 192.168.2.165.23: SBut it receives the same result from receiving host.
3034008467:3034008467(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
05:28:00.579524 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0) ack 1 winA final attempt is made to establish a connection.
0
05:28:01.080114 192.168.2.10.1063 &glt; 192.168.2.165.23: SOnly three strikes in this ball game. Sending host gives up.
3034008467:3034008467(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
05:28:01.080225 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0) ack 1 winCompare 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.
0
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: SThe 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).
3223709294:3223709294(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
05:40:39.839045 192.168.2.165.23 > 192.168.2.10.1064: SHost 192.168.2.10 acknowledges the SYN from host 192.168.2.165 by sending another segment, which contains the . and ACK flags.
063202536:2063202536(0) ack 3223709295 win 32120 <mss
1460,nop,nop,sackOK> (DF)
05:40:39.839295 192.168.2.10.1064 > 192.168.2.165.23: . ack 1 win 17520Host 192.168.2.165 responds with a segment containing a FIN flag--connection terminated. Something has told the receiving host no connection is allowed.
(DF)
05:40:44.852844 192.168.2.165.23 > 192.168.2.10.1064:Host 192.168.2.10 has a no-flag-set second acknowledgment.
F 1:1(0) ack 1 win 32120 (DF)
05:40:44.853137 192.168.2.10.1064 > 192.168.2.165.23: . ack 2 win 17520Because 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.
(DF)
05:40:44.855050 192.168.2.10.1064 > 192.168.2.165.23: F 1:1(0) ack 2 winHost 192.168.2.165 responds with a segment acknowledgment.
17520 (DF)
05:40:44.855176 192.168.2.165.23 > 192.168.2.10.1064: . ack 2 win 32120Compare 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.
(DF)
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.
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.
05:55:21.557846 192.168.2.10.1065 > 192.168.2.165.23: SThere's no response, so the sending host tries the same request again.
3443876657:3443876657(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
05:55:24.560891 192.168.2.10.1065 > 192.168.2.165.23: SWith still no response on the third try, the three-strike rule comes into effect. The sending host abandons the connection attempt.
3443876657:3443876657(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
05:55:30.569584 192.168.2.10.1065 > 192.168.2.165.23: SIn 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.
3443876657:3443876657(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
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.
No comments:
Post a Comment