Haha! TCP leaks operating system information...

[[414423]]

Hello everyone, I am Xuanyuan.

A few days ago, I asked a question in the reader group:

At this point, everyone finally stopped posting nonsense (this group of people don't have to go to work, they just slack off every day) and started discussing the issue.

Some said that it can be viewed through User-Agent, and I just gave a dog head.

Then he realized something was wrong and changed his words, saying that you can check it through the Server field of the HTTP response. For example, if you see something like this, it must be Windows.

 HTTP/1.1 200 OK
 Content-Type: text/html
 Last -Modified: Fri, 23 Aug 2019 01:02:08 GMT
 Accept-Ranges: bytes
 ETag: "e65855634e59d51:0"  
 Server: Microsoft-IIS/8.0
 X-Powered- By : ASP.NET
 Date : Fri, 23 Jul 2021 06:02:38 GMT
 Content-Length: 1375

Others say that you can judge by the URL path. If it is case-sensitive, it is Linux, and if it is not sensitive, it is Windows.

So I raised the difficulty further. What if there is no Web service and only a TCP Server?

At this time, someone else said: You can ping this IP to check the TTL value in the ICMP message. If it is xxx, it is the xx system, and if it is yyy, it is the yy system... (However, it is not very accurate in some cases)

Starting from TCP retransmission

Today I want to discuss another method with you. The idea of ​​this method comes from the article that was deleted a few days ago. It is about the problem that Geek Time cannot be accessed under the Japanese network environment. When I captured the packet, I saw the following picture:

Did you see the server trying to resend the message? At that time, I thought of a question:

How many times will the server retransmit?

As we all know, TCP is a connection-oriented, reliable, byte stream-based transport layer communication protocol.

Among them, an important manifestation of reliability is its timeout retransmission mechanism.

There is a confirmation mechanism in TCP communication. I send you data, and you have to tell me whether you have received it, so that both parties can continue to communicate. This confirmation mechanism is implemented through sequence number SEQ and confirmation number ACK.

Simply put, when the sender sends a message to the receiver and the receiver does not respond within the specified time, the sender will consider it necessary to resend.

How many times can a message be retransmitted? The RFC document about TCP does not clearly stipulate this, but only gives some references to the total timeout period, which leads to some differences in the implementation of this mechanism in different operating systems. So I further thought of another question:

Will the number of retransmissions be different for different operating systems, so that the operating system can be judged by this point?

Then I looked through TCP/IP Detailed Explanation Volume 1, trying to find the answer. Sure enough, this magical book never let me down:

What does this paragraph say? The RFC standard recommends two parameters, R1 and R2, to control the number of retransmissions. In Linux, these two parameters can be viewed as follows:

 cat /proc/sys/net/ipv4/tcp_retries1
 cat /proc/sys/net/ipv4/tcp_retries2

The default value of tcp_retries1 is 3, and the default value of tcp_retries2 is 15.

But it should be noted that the maximum number of retransmissions is not 3 or 15. Linux has an algorithm inside. These two values ​​are very important parameters in the algorithm, not the number of retransmissions itself. The specific number of retransmissions is also related to RTO. Friends who are interested in the specific algorithm can read this article: Let's talk about the number of retransmissions (http://perthcharles.github.io/2015/09/07/wiki-tcp-retries/)

In general, the number of retransmissions on Linux is not a fixed value, but a dynamic value calculated by different connections based on tcp_retries2 and RTO, and is not fixed.

On Windows, there is also a variable to control the number of retransmissions, which can be set in the registry:

 Key value path:
 HKLM\System\CurrentControlSet\Services\Tcpip\Parameters 
 
 Key value name:
 TcpMaxDataRetransmissions 
 
 Default value: 5

I have a copy of the Windows XP source code, and this information is also confirmed in the part of the driver tcpip.sys that implements the protocol stack:

Reading a key value from the registry

No default value was read

However, based on the current information, since the number of retransmissions in Linux is not fixed, it is not possible to use this number of retransmissions to determine the operating system.

TCP SYN+ACK retransmission

Just when I wanted to give up, I read the passage in TCP/IP Detailed Explanation Volume 1 again and found another piece of information: TCP retransmission is different in the connection establishment phase and data transmission phase!

The retransmission limit mentioned above is for the situation where a TCP connection has been established and a timeout retransmission occurs during data transmission.

In the process of establishing a TCP connection, that is, the three-way handshake, a timeout retransmission occurs, and the number of times it is limited is stipulated by another set of agreements.

Linux:

In Linux, there are two additional parameters to limit the number of retransmissions during the connection establishment phase:

 cat /proc/sys/net/ipv4/tcp_syn_retries 
 
 cat /proc/sys/net/ipv4/tcp_synack_retries

tcp_syn_retries limits the maximum number of SYN retransmissions when initiating a TCP connection as a client. The default value is 6 in Linux 3.10 and 5 in Linux 2.6.

tcp_synack_retries limits the maximum number of times a SYN+ACK is retransmitted after receiving a SYN as a server. The default value is 5

Focus on tcp_synack_retries, which refers to the number of times the server will resend the TCP three-way handshake when the server responds to the second handshake packet but the client has not sent the third handshake packet.

We know that under normal circumstances, the TCP three-way handshake looks like this:

But if the client does not send the third packet to the server, the server will resend its second handshake packet, and the situation will become as follows:

Therefore, this tcp_synack_retries actually specifies the number of times the server will retransmit SYN+ACK in the above situation.

To further verify, I wrote a piece of code in Python to manually send TCP packets. The packet sending library used was scapy, which I wrote an article to introduce before: Prison-oriented programming, rely on it!.

In the following code, I only send a SYN packet to the specified port of the target IP:

 def tcp_syn_test(ip, port): 
 
 # First handshake, send SYN packet
 # Request port and initial sequence number are randomly generated
 # Use sr1 instead of send, because sr1 will receive the returned content
    ans = sr1(IP(dst=ip) / TCP(dport=port, sport=RandShort(), seq=RandInt(), flags= 'S' ), verbose= False )

Use the above code to send it to a Linux server and capture the packet to see:

In actual verification, the server did retransmit the SYN+ACK message 5 times.

One server couldn't explain the problem, so I looked for a few more, and the result was 5 times in each case.

Let's take a look at the definition of this number in the Linux source code:

Next, let’s look at the situation on Windows.

Windows

As mentioned earlier, there is a parameter called TcpMaxDataRetransmissions in the registry directory HKLM\System\CurrentControlSet\Services\Tcpip\Parameters that can be used to control the number of data retransmissions, but that is limited to the number of retransmissions during the data transmission phase.

According to the introduction on MSDN, in addition to this parameter, there is another parameter used to limit the number of SYN+ACK retransmissions above, which is TcpMaxConnectResponseRetransmissions.

And interestingly, unlike the default value on Linux, the default value on Windows is 2.

This is interesting, and this is what distinguishes Windows from Linux.

I quickly ran nginx on XP in the virtual machine and tested it:

Sure enough, it happened twice. Then I changed to Windows Server 2008, and it happened twice again.

To further verify, I set this value to 4 through the registry:

Let’s try again:

The number of retransmissions has indeed become 4 times.

Next, verify this information in the Windows XP source code:

Sure enough, the same conclusion was reached both from the experiment and from the source code:

On Linux, SYN+ACK is retransmitted 5 times by default.

On Windows, SYN+ACK is retransmitted twice by default.

Summarize

If an IP has started a TCP-based service, whether it is an HTTP service or not, you can determine whether the other party is a Linux operating system or a Windows operating system by sending a SYN packet to it and observing its response.

Of course, this method has considerable limitations.

First of all, this article only introduces some default situations, but the number of TCP retransmissions can be changed. If the network administrator changes this value, the judgment result will be inaccurate.

Secondly, for some network servers that have anti-DDoS function enabled, tests have found that they will not retransmit SYN+ACK packets at all. For example, I got this result when I used Baidu's IP test.

Finally, other operating systems, such as Unix and MAC OSX, were not tested. Why?

Therefore, the method introduced in this article can only be used as an auxiliary means and is for reference only. It is also very meaningful for everyone to learn some knowledge about TCP retransmission by the way.

Well, that’s all for today’s sharing. Writing is not easy. Please give me a triple like after reading it.

This article is reprinted from the WeChat public account "Programming Technology Universe", which can be followed through the following QR code. To reprint this article, please contact the Programming Technology Universe public account.