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

大家好，我是軒轅。

前幾天，我在讀者群里提了一個(gè)問(wèn)題：

這一下，大家總算停止了灌水（這群人都不用上班的，天天劃水摸魚(yú)），開(kāi)始討論起這個(gè)問(wèn)題來(lái)。

有的說(shuō)通過(guò)User-Agent可以看，我直接給了一個(gè)狗頭。

然后發(fā)現(xiàn)不對(duì)勁，改口說(shuō)可以通過(guò)HTTP響應(yīng)的Server字段看，比如看到像這種的，那肯定Windows無(wú)疑了。

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

還有的說(shuō)可以通過(guò)URL路徑來(lái)判斷，如果大小寫(xiě)敏感就是Linux，不敏感就是Windows。

于是我進(jìn)一步提高了難度，如果連Web服務(wù)也沒(méi)有，只有一個(gè)TCP Server呢？

這時(shí)又有人說(shuō)：可以通過(guò)ping這個(gè)IP，查看ICMP報(bào)文中的TTL值，如果是xxx就是xx系統(tǒng)，如果是yyy就是yy系統(tǒng)···（不過(guò)有些情況下也不是太準(zhǔn)確）

從TCP重傳說(shuō)起

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

看到了服務(wù)器后面在不斷的嘗試重發(fā)了嗎？當(dāng)時(shí)我就想到了一個(gè)問(wèn)題：

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

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

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

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

簡(jiǎn)單來(lái)說(shuō)，當(dāng)發(fā)送方給接收方發(fā)送了一個(gè)報(bào)文，而接收方在規(guī)定的時(shí)間里沒(méi)有給出應(yīng)答，那發(fā)送方將認(rèn)為有必要重發(fā)。

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

會(huì)不會(huì)不同操作系統(tǒng)重傳次數(shù)不一樣，這樣就能通過(guò)這一點(diǎn)來(lái)判斷操作系統(tǒng)了呢？

然后我翻看了《TCP/IP詳解·卷1》，試圖在里面尋找答案，果然，這本神書(shū)從來(lái)沒(méi)有讓我失望過(guò)：

這一段說(shuō)了個(gè)什么事情呢？大意是說(shuō)RFC標(biāo)準(zhǔn)中建議有兩個(gè)參數(shù)R1和R2來(lái)控制重傳的次數(shù)，Linux中，這倆參數(shù)可以這樣看：

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

tcp_retries1默認(rèn)值是3，tcp_retries2默認(rèn)值是15。

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

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

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

鍵值路徑：
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters

鍵值名：
TcpMaxDataRetransmissions

默認(rèn)值：5

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

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

TCP之SYN+ACK的重傳

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

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

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

Linux：

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

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

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

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

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

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

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

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

為了進(jìn)一步驗(yàn)證，我使用Python寫(xiě)了一段代碼，用來(lái)手動(dòng)發(fā)送TCP報(bào)文，里面使用的發(fā)包庫(kù)是scapy，這個(gè)我之前寫(xiě)過(guò)一篇文章介紹它：面向監(jiān)獄編程，就靠它了！。

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

def tcp_syn_test(ip, port):

    # 第一次握手，發(fā)送SYN包
    # 請(qǐng)求端口和初始序列號(hào)隨機(jī)生成
    # 使用sr1發(fā)送而不用send發(fā)送，因?yàn)閟r1會(huì)接收返回的內(nèi)容
    ans = sr1(IP(dst=ip) / TCP(dport=port, sport=RandShort(), seq=RandInt(), flags='S'), verbose=False)

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

實(shí)際驗(yàn)證，服務(wù)器確實(shí)重傳了5次SYN+ACK報(bào)文。

一臺(tái)服務(wù)器說(shuō)明不了問(wèn)題，我又多找了幾個(gè)，結(jié)果都是5次。

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

接下來(lái)看一下Windows上的情況。

Windows

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

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

而且有趣的是，和Linux上的默認(rèn)值不一樣，Windows上的默認(rèn)值是2。

這就有意思了，通過(guò)這一點(diǎn)，就能把Windows和Linux區(qū)分開(kāi)來(lái)。

我趕緊用虛擬機(jī)中的XP上跑了一個(gè)nginx，測(cè)試了一下：

果然是2次，隨后我又換了一個(gè)Windows Server 2008，依舊是2次。

為了進(jìn)一步驗(yàn)證，我通過(guò)注冊(cè)表把這個(gè)值設(shè)定成了4：

再來(lái)試一下：

重傳次數(shù)果然變成了4次了。

接下來(lái)在手中的Windows XP源碼中去印證這個(gè)信息：

果然，不管是從實(shí)驗(yàn)還是從源碼中都得到了同一個(gè)結(jié)論：

Linux上，SYN+ACK默認(rèn)重傳5次。

Windows上，SYN+ACK默認(rèn)重傳2次。

總結(jié)

如果一個(gè)IP開(kāi)啟了基于TCP的服務(wù)，不管是不是HTTP服務(wù)，都可以通過(guò)向其發(fā)送SYN包，觀察其回應(yīng)來(lái)判斷對(duì)方是一個(gè)Linux操作系統(tǒng)還是一個(gè)Windows操作系統(tǒng)。

當(dāng)然，這種方法的局限性還是挺大的。

首先，本文只介紹了一些默認(rèn)的情況，但TCP的重傳次數(shù)是可以更改的，如果網(wǎng)絡(luò)管理員更改了這個(gè)數(shù)值，判斷的結(jié)果就不準(zhǔn)確了。

其次，對(duì)于有些網(wǎng)絡(luò)服務(wù)器開(kāi)啟了防DDoS功能，測(cè)試發(fā)現(xiàn)，其根本不會(huì)重傳SYN+ACK包，比如我用百度的IP測(cè)試就得到了這樣的結(jié)果。

最后，沒(méi)有測(cè)試其他操作系統(tǒng)上的情況，比如Unix和MAC OSX，為什么呢？

因此，文中介紹的這種方法只能作為一種輔助手段，僅供參考，大家能順便了解一些關(guān)于TCP重傳的知識(shí)也是很有意義的。

好了，以上就是今天的分享了，寫(xiě)作不易，大家看完給個(gè)三連支持呀~