哈哈！TCP泄露了操作系統(tǒng)信息···

作者：軒轅之風(fēng)O 2021-07-30 16:17:50

網(wǎng)絡(luò) 網(wǎng)絡(luò)管理

眾所周知，TCP是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。其中，可靠性的一個重要體現(xiàn)就是它的超時重傳機制。

[[414423]]

大家好，我是軒轅。

前幾天，我在讀者群里提了一個問題：

這一下，大家總算停止了灌水(這群人都不用上班的，天天劃水摸魚)，開始討論起這個問題來。

有的說通過User-Agent可以看，我直接給了一個狗頭。

然后發(fā)現(xiàn)不對勁，改口說可以通過HTTP響應(yīng)的Server字段看，比如看到像這種的，那肯定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

還有的說可以通過URL路徑來判斷，如果大小寫敏感就是Linux，不敏感就是Windows。

于是我進一步提高了難度，如果連Web服務(wù)也沒有，只有一個TCP Server呢?

這時又有人說：可以通過ping這個IP，查看ICMP報文中的TTL值，如果是xxx就是xx系統(tǒng)，如果是yyy就是yy系統(tǒng)···(不過有些情況下也不是太準確)

從TCP重傳說起

今天想跟大家探討的是另外一種方法，這個方法的思路來源于前幾天被刪掉的那篇文章。就是日本網(wǎng)絡(luò)環(huán)境下訪問不了極客時間的問題，當時抓包看到的情況是這個圖的樣子：

看到了服務(wù)器后面在不斷的嘗試重發(fā)了嗎?當時我就想到了一個問題：

服務(wù)器到底會重傳好多次呢?

眾所周知，TCP是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。

其中，可靠性的一個重要體現(xiàn)就是它的超時重傳機制。

TCP的通信中有一個確認機制，我發(fā)給你了數(shù)據(jù)，你得告訴我你收到?jīng)]，這樣雙方才能繼續(xù)通信下去，這個確認機制是通過序列號SEQ和確認號ACK來實現(xiàn)的。

簡單來說，當發(fā)送方給接收方發(fā)送了一個報文，而接收方在規(guī)定的時間里沒有給出應(yīng)答，那發(fā)送方將認為有必要重發(fā)。

那具體最多重發(fā)多少次呢?關(guān)于這一點，RFC中關(guān)于TCP的文檔并未明確規(guī)定出來，只是給了一些在總超時時間上的參考，這就導(dǎo)致不同的操作系統(tǒng)在實現(xiàn)這一機制的時候可能會有一些差異。于是我進一步想到了另一個問題：

會不會不同操作系統(tǒng)重傳次數(shù)不一樣，這樣就能通過這一點來判斷操作系統(tǒng)了呢?

然后我翻看了《TCP/IP詳解·卷1》，試圖在里面尋找答案，果然，這本神書從來沒有讓我失望過：

這一段說了個什么事情呢?大意是說RFC標準中建議有兩個參數(shù)R1和R2來控制重傳的次數(shù)，Linux中，這倆參數(shù)可以這樣看：

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

tcp_retries1默認值是3，tcp_retries2默認值是15。

但需要特別注意的是，并不是最多重傳3次或者15次，Linux內(nèi)部有一套算法，這兩個值是算法中非常重要的參數(shù)，而不是重傳次數(shù)本身。具體的重傳次數(shù)還與RTO有關(guān)系，具體的算法有興趣的朋友可以看看這篇文章：聊一聊重傳次數(shù)(http://perthcharles.github.io/2015/09/07/wiki-tcp-retries/)

總體來說，在Linux上重傳的次數(shù)不是一個固定值，而是不同的連接根據(jù)tcp_retries2和RTO計算出來的一個動態(tài)值，不固定。

而在Windows上，也有一個變量來控制重傳次數(shù)，可以在注冊表中設(shè)定它：

鍵值路徑： 
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters 
 
鍵值名： 
TcpMaxDataRetransmissions 
 
默認值：5

我手里有一份Windows XP的源碼，在實現(xiàn)協(xié)議棧的驅(qū)動tcpip.sys的部分中，也印證了這個信息：

從注冊表中讀取鍵值

沒有讀到的默認值

不過就目前的信息來看，由于Linux的重傳次數(shù)是不固定的，還沒法用這個重傳次數(shù)來判斷操作系統(tǒng)。

TCP之SYN+ACK的重傳

就在我想要放棄的時候，我再一次品讀《TCP/IP詳解·卷1》中的那段話，發(fā)現(xiàn)另一個信息：TCP的重傳在建立連接階段和數(shù)據(jù)傳輸階段是不一樣的!

上面說到的重傳次數(shù)限制，是針對的是TCP連接已經(jīng)建立完成，在數(shù)據(jù)傳輸過程中發(fā)生超時重傳后的重傳次數(shù)情況描述。

而在TCP建立連接的過程中，也就是三次握手的過程中，發(fā)生超時重傳，它的次數(shù)限定是有另外一套約定的。

Linux：

在Linux中，另外還有兩個參數(shù)來限定建立連接階段的重傳次數(shù)：

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

tcp_syn_retries限定作為客戶端的時候發(fā)起TCP連接，最多重傳SYN的次數(shù)，Linux3.10中默認是6，Linux2.6中是5。

tcp_synack_retries限定作為服務(wù)端的時候收到SYN后，最多重傳SYN+ACK的次數(shù)，默認是5

重點來關(guān)注這個tcp_synack_retries，它指的就是TCP的三次握手中，服務(wù)端回復(fù)了第二次握手包，但客戶端一直沒發(fā)來第三次握手包時，服務(wù)端會重發(fā)的次數(shù)。

我們知道正常情況下，TCP的三次握手是這個樣子的：

但如果客戶端不給服務(wù)端發(fā)起第三個包，那服務(wù)端就會重發(fā)它的第二次握手包，情況就會變成下面這樣：

所以，這個tcp_synack_retries實際上規(guī)定的就是上面這種情況下，服務(wù)端會重傳SYN+ACK的次數(shù)。

為了進一步驗證，我使用Python寫了一段代碼，用來手動發(fā)送TCP報文，里面使用的發(fā)包庫是scapy，這個我之前寫過一篇文章介紹它：面向監(jiān)獄編程，就靠它了!。

下面的這段代碼，我向目標IP的指定端口只發(fā)送了一個SYN包，：

def tcp_syn_test(ip, port): 
 
    # 第一次握手，發(fā)送SYN包 
    # 請求端口和初始序列號隨機生成 
    # 使用sr1發(fā)送而不用send發(fā)送，因為sr1會接收返回的內(nèi)容 
    ans = sr1(IP(dst=ip) / TCP(dport=port, sport=RandShort(), seq=RandInt(), flags='S'), verbose=False)

用上面這段代碼，向一臺Linux的服務(wù)器發(fā)送，抓包來看一下：

實際驗證，服務(wù)器確實重傳了5次SYN+ACK報文。

一臺服務(wù)器說明不了問題，我又多找了幾個，結(jié)果都是5次。

再來看一下Linux的源碼中關(guān)于這個次數(shù)的定義：

接下來看一下Windows上的情況。

Windows

前面說過，在注冊表HKLM\System\CurrentControlSet\Services\Tcpip\Parameters目錄下有一個叫TcpMaxDataRetransmissions的參數(shù)可以用來控制數(shù)據(jù)重傳次數(shù)，不過那是限定的數(shù)據(jù)傳輸階段的重傳次數(shù)。

根據(jù)MSDN上的介紹，除了這個參數(shù)，還有另一個參數(shù)用來限制上面SYN+ACK重傳的次數(shù)，它就是TcpMaxConnectResponseRetransmissions。