Interviewer: How to close a TCP connection without killing the process?

Hello everyone, I am Xiaolin.

A reader was asked this question during an interview.

"How to close a TCP connection without killing the process?"

I have also mentioned this in my previous article: "What happens when a connection in the establish state receives a SYN message?"

Let me explain the key points here.

text

When closing a TCP connection, the first thing people do is to “kill the process”.

Yes, this is the most brutal way. Killing the client process and the server process will have different impacts:

• If the client kills the process, a FIN message will be sent to disconnect all TCP connections established between the client process and the server. This method only affects the connections established by the client process, and other clients or processes will not be affected.
• Killing the process on the server side will have a greater impact. At this time, all TCP connections will be closed and the server will no longer be able to provide access services.

Therefore, closing the process is not an option. The best way is to close a specific TCP connection.

Some of you may ask, isn't it enough to forge a RST message with the same four-tuple?

This is a good idea, but don't forget the problem of the sequence number. Will the sequence number of your forged RST message be accepted by the other party?

If the sequence number of the RST message cannot fall within the other party's sliding window, the RST message will be discarded by the other party and the connection will not be closed.

Therefore, to forge a RST message that can close a TCP connection, the two conditions of "the four-tuple is the same" and "the sequence number falls exactly within the other party's sliding window" must be met at the same time.

It is difficult to directly forge an expected sequence number, because if a TCP connection is transmitting data, the sliding window is changing all the time, so it is difficult to forge a RST message with a sequence number that happens to fall within the other party's sliding window.

There is a way. We can forge a SYN message with the same four-tuple to get a "legal" sequence number!

Because if the server in the establish state receives a SYN message with the same four-tuple, it will reply with a Challenge ACK. The "confirmation number" in this ACK message is exactly the sequence number that the server wants to receive next time. To put it simply, this step can be used to obtain the sequence number that the server expects to receive next time.

Then use this confirmation number as the sequence number of the RST message and send it to the server. At this time, the server will think that the sequence number in the RST message is legal, so it will release the connection!

There is a tool called killcx on Linux, which is implemented based on the above method. It will actively send a SYN packet to obtain the SEQ/ACK number, and then use the SEQ/ACK number to forge two RST packets and send them to the client and server respectively. In this way, the TCP connections of both parties will be released. In this way, both active and inactive TCP connections can be killed.

The usage is also very simple, just specify the client's IP and port number.

./killcx

The working principle of the killcx tool is as follows

It forges the client to send a SYN message. After receiving it, the server will reply with an ACK message (Challenge ACK) carrying the correct "sequence number and confirmation number". Then, it can use the information in this ACK message to forge two RST messages:

• Use the confirmation number in Challenge ACK to forge a RST message and send it to the server. After receiving the RST message, the server will release the connection.
• Use the sequence number in Challenge ACK to forge a RST message and send it to the client. The client will release the connection after receiving the RST.

It is in this way that a TCP connection is successfully closed!

Here is a packet capture of using the killcx tool to close the connection. Please take a closer look at the changes in the sequence number and confirmation number.

Therefore, in the future, if a SYN packet appears inexplicably during packet capture, it is possible that the other party will launch a RST attack on you and directly disconnect your TCP connection!

How about it, very clever!