The connection between tclient.net and telnet.com is now closed.

The Abrupt Method

The second termination method is an abrupt halting of the connection. This is done with one host sending the other a RESET. This signals the desire to abruptly terminate the connection.tclient.net.39904 > telnet.com.23: R 28:28(0) ack 1 win 8760 (DF)

This output shows tclient.com as it aborts the connection to telnet.com. It sends a RESET to telnet.net to signal the intent to terminate immediately. There should be no further

communication between the two hosts using the negotiated session after the abort.

Data Transfer

Now that you know how TCP establishes and terminates a connection, it is time to take a look at what happens in between. Normally, the whole reason for establishing a session is so data can be exchanged between two hosts. The following data excerpt might be transferred

between tclient.net and telnet.com after the three-way handshake and before the termination: tclient.net.39904 > telnet.com.23: P 1:28(27) ack 1 win 8760 (DF)

telnet.com.23 > tclient.net.39904: P 1:14(13) ack 1 win 1024 telnet.com.23 > tclient.net.39904: P 14:23(9) ack 28 win 1024

The first line shows tclient.net sending 27 bytes of data (a relative range of 1 to 28 bytes as seen in the parentheses) to telnet.com. This is the first time the new P flag has appeared; it represents PUSH. Because telnet is an interactive application that demands the fastest response time available, the PUSH flag signals to the receiver of the data, in this case telnet.com, to push the data immediately to the telnet application upon receipt of data in the incoming buffer. This line also acknowledges that the next relative sequence number expected by tclient.com from telnet.com is byte 1.

The second line shows telnet.com sending 13 bytes of data to tclient.com and acknowledging receipt of 1 byte of data from tclient.com. It has yet to acknowledge receipt of the 27 new

bytes just sent by tclient.net. The final line shows telnet.com sending an additional 9 bytes to client.com. See how the relative bytes begin at 14 (14:23) bytes after the 13 (1:14)

preceding bytes sent from telnet.com to tclient.net.

This exchange also acknowledges receipt of 27 bytes of data from tclient.net to telnet.com. You see ack 28 because this is known as an expectational acknowledgement: Byte 28 is the

next anticipated byte to be received. All traffic exchanges between the two hosts will have the ACK flag set after the three-way handshake has been completed. This is sometimes used as an

indication of an established session.

What's the Bottom Line?

What if you need to analyze some traffic for malicious intent? Is it really necessary for you to absorb all the detailed theory about TCP to do any kind of analysis of TCP traffic of normal or anomalous behavior? The bottom line is that you can do elementary analysis without flipping bits. Here are some of the more general behaviors that you might examine:

●Was the three-way handshake completed between two hosts? If it was, this means that the server listens at the port at which the client requested and the server accepted the connection. This is fine if the expected behavior is that the server listens at the requested port. However, what if the server port is not one that you expect to listen? This might indicate some service, known to the system administrator and not to you, is running. It might also mean, however, that someone maliciously installed some backdoor application on the server without your knowledge.

●Was data transmitted? In TCPdump output, after the TCP sequence numbers, you find the number of data bytes in parentheses that were sent. If you see data transmitted, that means that the two hosts are speaking to each other. When you are doing some kind of retrospective analysis of unexpected activity between two hosts, looking at the