Cloudflare Radar已引入關(guān)于TCP重置和超時(shí)的洞察及見解

Cloudflare在全球范圍內(nèi)每秒處理超過6000萬個(gè)HTTP請求，其中大約70%的請求均通過TCP連接接收（其余的請求則通過QUIC/UDP連接接收）。理想情況下，與Cloudflare的每個(gè)新TCP連接都會(huì)攜帶至少一個(gè)導(dǎo)致數(shù)據(jù)交換成功的請求，但事實(shí)遠(yuǎn)非如此。實(shí)際上，我們發(fā)現(xiàn)，在全球范圍內(nèi)，大約20%與Cloudflare服務(wù)器的新TCP連接，其在請求完成之前或在初始請求之后會(huì)出現(xiàn)超時(shí)或關(guān)閉，并顯示TCP連接“中止”消息。

本文將探討Cloudflare服務(wù)器在進(jìn)行有用的數(shù)據(jù)交換之前，那些出于各種原因而意外中斷的連接。我們的研究表明，雖然連接通常由客戶端中止，但也可能因受到第三方干擾而關(guān)閉。為此，我們很高興地宣布將在Cloudflare Radar中推出一個(gè)新的儀表板和API端點(diǎn)，它會(huì)顯示因重置或超時(shí)而在前10個(gè)入口數(shù)據(jù)包內(nèi)終止的Cloudflare網(wǎng)絡(luò)TCP連接，本文中我們將此類連接稱為異常TCP連接。通過分析這種異常行為，可以獲得關(guān)于掃描、連接篡改、DoS攻擊、連接問題，以及其他行為的洞察及見解。

根據(jù)對連接篡改的全球調(diào)查，我們能夠通過Radar生成和共享這些數(shù)據(jù)。歡迎讀者閱讀同行評審研究中的技術(shù)細(xì)節(jié)，或參閱相應(yīng)的演示文稿。請繼續(xù)閱讀，了解關(guān)于使用和解讀數(shù)據(jù)的入門說明，以及我們?nèi)绾卧O(shè)計(jì)和部署檢測機(jī)制，以便其他人可以復(fù)制我們的方法。

首先，我們來論述正常與異常TCP連接的分類。

TCP連接從建立到關(guān)閉

傳輸控制協(xié)議（TCP）是用于在互聯(lián)網(wǎng)上的兩臺(tái)主機(jī)之間可靠地傳輸數(shù)據(jù)的協(xié)議（RFC 9293）。TCP連接會(huì)經(jīng)歷幾個(gè)不同的階段，也就是從連接建立到數(shù)據(jù)傳輸，再到連接關(guān)閉。

TCP通過三次握手建立連接。握手始于其中稱為“客戶端”的一方，發(fā)送一個(gè)帶有“SYN”標(biāo)志的數(shù)據(jù)包來初始化連接流程。服務(wù)器回應(yīng)一個(gè)“SYN+ACK”數(shù)據(jù)包，其中“ACK”標(biāo)志會(huì)確認(rèn)客戶端的初始化“SYN”。初始化數(shù)據(jù)包與確認(rèn)中均包含額外的同步信息。最后，客戶端發(fā)送一個(gè)最終ACK數(shù)據(jù)包，確認(rèn)接收到服務(wù)器的SYN+ACK數(shù)據(jù)包。至此，完成握手。

然后，連接準(zhǔn)備就緒，可以進(jìn)行數(shù)據(jù)傳輸。通常，客戶端會(huì)在第一個(gè)包含數(shù)據(jù)的數(shù)據(jù)包上設(shè)置PSH標(biāo)志，向服務(wù)器的TCP堆棧發(fā)出信號，要求其立即將數(shù)據(jù)轉(zhuǎn)發(fā)給應(yīng)用程序。雙方繼續(xù)傳輸數(shù)據(jù)并確認(rèn)已收到的數(shù)據(jù)，直到不再需要連接。此時(shí)，將關(guān)閉連接。

RFC 9293描述了關(guān)閉TCP連接的兩種方式：

-標(biāo)準(zhǔn)且正常的TCP關(guān)閉序列使用FIN交換。任何一方都可以發(fā)送設(shè)置了FIN標(biāo)志的數(shù)據(jù)包，表明其沒有更多數(shù)據(jù)要傳輸。在另一方確認(rèn)FIN數(shù)據(jù)包之后，關(guān)閉該方向的連接。確認(rèn)方完成數(shù)據(jù)傳輸后，它將傳輸自己的FIN數(shù)據(jù)包來關(guān)閉連接，因?yàn)楸仨毆?dú)立關(guān)閉每個(gè)方向的連接。

-中止或“重置”信號，其中一方傳輸RST數(shù)據(jù)包，指示另一方立即關(guān)閉并丟棄連接狀態(tài)。通常情況下，如果發(fā)生了某些不可恢復(fù)的錯(cuò)誤，則會(huì)發(fā)送重置請求。

下面的序列圖展示了使用FIN標(biāo)志，正常關(guān)閉連接的完整生命周期。

標(biāo)準(zhǔn)的TCP連接以三次握手開始，以FIN握手結(jié)束

此外，TCP連接可能會(huì)因超時(shí)而終止，該超時(shí)設(shè)置指定了在未收到數(shù)據(jù)或確認(rèn)的情況下，連接保持處于活動(dòng)狀態(tài)的最長持續(xù)時(shí)間。例如，可以使用keepalive消息讓非活動(dòng)狀態(tài)的連接處于打開狀態(tài)。除非設(shè)置遭到覆蓋，RFC 9293中指定的全局默認(rèn)持續(xù)時(shí)間為五分鐘。

如果TCP連接因客戶端重置或超時(shí)而關(guān)閉，我們認(rèn)為這屬于異常連接。

異常連接的來源

異常TCP連接本身可能沒有問題，但這可能是更大問題的征兆，特別是發(fā)生在TCP連接的早期（數(shù)據(jù)傳輸前）階段時(shí)。以下是一份非詳盡列表，展示了我們可能觀察到重置或超時(shí)的潛在原因：

-掃描程序：互聯(lián)網(wǎng)掃描程序可能會(huì)發(fā)送SYN數(shù)據(jù)包來探測服務(wù)器是否在指定端口上做出響應(yīng)，可一旦該探測獲得源自服務(wù)器的響應(yīng)，便無法清除連接。

-應(yīng)用程序突然關(guān)閉：應(yīng)用程序可能會(huì)突然關(guān)閉已打開但不再需要的連接。例如，Web瀏覽器可能會(huì)在關(guān)閉選項(xiàng)卡后發(fā)送RST來終止連接，或者如果設(shè)備斷電或失去連接，連接可能會(huì)超時(shí)。

-網(wǎng)絡(luò)錯(cuò)誤：網(wǎng)絡(luò)條件不穩(wěn)定（例如，電纜連接斷開可能會(huì)導(dǎo)致連接超時(shí)）

-攻擊：惡意客戶端可能會(huì)發(fā)送顯示為異常連接的攻擊流量。例如，在SYN洪水攻擊（半開連接）中，攻擊者反復(fù)向目標(biāo)服務(wù)器發(fā)送SYN數(shù)據(jù)包，企圖在維護(hù)這些半開連接時(shí)擠兌各種資源。

-篡改：防火墻或其他能夠攔截客戶端與服務(wù)器之間的數(shù)據(jù)包的中間盒可能會(huì)丟棄數(shù)據(jù)包，導(dǎo)致通信雙方超時(shí)。具備深度包檢測（DPI）功能的中間盒也可能利用TCP協(xié)議未經(jīng)身份驗(yàn)證且沒有加密的事實(shí)來注入數(shù)據(jù)包，進(jìn)而破壞連接狀態(tài)。如需了解關(guān)于連接篡改的更多詳細(xì)信息，請參閱我們隨附的博客文章。

了解異常連接的規(guī)模和根本原因，可以幫助我們減少故障并構(gòu)建一個(gè)更穩(wěn)健、更可靠的網(wǎng)絡(luò)。我們希望，公開分享這些見解有助于提高全球網(wǎng)絡(luò)的透明度并加強(qiáng)問責(zé)制。

如何使用數(shù)據(jù)集

在本小節(jié)中，我們通過廣泛描述以下三個(gè)用例，提供關(guān)于如何理解TCP重置和超時(shí)數(shù)據(jù)集的指導(dǎo)與示例：確認(rèn)之前已知的行為，探索后續(xù)研究的新目標(biāo)，以及進(jìn)行縱向研究來記錄網(wǎng)絡(luò)行為隨時(shí)間變化的情況。

在每個(gè)示例中，情節(jié)主線與異常連接關(guān)閉的連接階段相對應(yīng)，這為找出可能導(dǎo)致異常的原因提供了有價(jià)值的線索。我們將每個(gè)入站連接置于以下任一階段：

-SYN后（握手過程中）：服務(wù)器收到客戶端的SYN數(shù)據(jù)包后，連接重置或超時(shí)。我們的服務(wù)器已做出回復(fù)，但在重置或超時(shí)之前，沒有從客戶端返回確認(rèn)ACK數(shù)據(jù)包。數(shù)據(jù)包欺騙在此連接階段很常見，因此，地理位置信息特別不可靠。

-ACK后（握手后緊接著）：握手完成且成功建立連接后，連接重置或超時(shí)。后續(xù)數(shù)據(jù)（本可能已傳輸?shù)臄?shù)據(jù)）都不會(huì)到達(dá)我們的服務(wù)器。

-PSH后（第一個(gè)數(shù)據(jù)包后）：服務(wù)器收到設(shè)置了PSH標(biāo)志的數(shù)據(jù)包后，連接重置或超時(shí)。PSH標(biāo)志表明，TCP數(shù)據(jù)包中包含已準(zhǔn)備好發(fā)送給應(yīng)用程序的數(shù)據(jù)（例如，TLS客戶端問候消息）。

-后期（多個(gè)數(shù)據(jù)包后）：在服務(wù)器已接收了多個(gè)數(shù)據(jù)包后，連接在來自客戶端的前10個(gè)數(shù)據(jù)包內(nèi)重置。

-無（None）：所有其他連接。為了持續(xù)關(guān)注合法連接，我們在Cloudflare攻擊緩解系統(tǒng)處理和過濾連接后構(gòu)建了數(shù)據(jù)集。如需了解關(guān)于我們?nèi)绾螛?gòu)建數(shù)據(jù)集的更多詳細(xì)信息，請參閱下文。

從自我評估開始

首先，我們鼓勵(lì)讀者訪問Radar上的儀表板，查看全球范圍及自己所在國家/地區(qū)和ISP的結(jié)果。

如下圖所示，在全球范圍內(nèi)，大約20%的Cloudflare網(wǎng)絡(luò)新TCP連接因重置或超時(shí)，而在來自客戶端的前10個(gè)數(shù)據(jù)包內(nèi)關(guān)閉。雖然這個(gè)數(shù)字看似出奇地高，但它與之前的研究結(jié)果一致。我們可以看到，重置率和超時(shí)率因國家/地區(qū)和網(wǎng)絡(luò)而存在巨大差異，但這種差異在全球平均值中卻消失不見。

通過Cloudflare Radar

美國的異常連接率略低于全球平均水平，主要是因?yàn)樵贏CK后與PSH后階段的連接關(guān)閉率較低（這兩個(gè)階段更能反映中間盒篡改行為）。由于掃描，SYN后的異常連接率偏高在大多數(shù)網(wǎng)絡(luò)中屬于常見現(xiàn)象，但可能包括欺騙真實(shí)客戶端IP地址的數(shù)據(jù)包。同樣地，后期階段（初始數(shù)據(jù)交換后，但仍然在前10個(gè)數(shù)據(jù)包內(nèi)）的連接重置率較高可能是因?yàn)閼?yīng)用程序?qū)θ藶椴僮髯龀鲰憫?yīng)，例如在關(guān)閉選項(xiàng)卡后，瀏覽器使用RST關(guān)閉無用的TCP連接。

通過Cloudflare Radar

我的家庭ISP AS22773（Cox Communications）顯示的異常連接率與整個(gè)美國的比例不相上下。大多數(shù)在美國運(yùn)營的住宅ISP都是如此。

通過Cloudflare Radar

將其與AS15169（Google LLC）進(jìn)行對比，后者是Google的眾多爬網(wǎng)程序和提取程序的來源。此網(wǎng)絡(luò)在“后期”階段的連接重置率明顯更低，這可能是因?yàn)樽詣?dòng)化流量比例更高，而非由人類用戶操作（例如，關(guān)閉瀏覽器選項(xiàng)卡）驅(qū)動(dòng)。

通過Cloudflare Radar

事實(shí)上，我們的機(jī)器人檢測系統(tǒng)將源自AS15169的99%以上的HTTP請求歸類為自動(dòng)化請求。這顯示了整理Radar上不同類型數(shù)據(jù)的價(jià)值。

通過Cloudflare Radar

與Radar上出現(xiàn)的大多數(shù)數(shù)據(jù)集一樣，新的異常連接數(shù)據(jù)集為被動(dòng)數(shù)據(jù)，它只報(bào)告可觀察的事件，而不是導(dǎo)致這些事件的原因。本著這一精神，上面的Google網(wǎng)絡(luò)圖表強(qiáng)化了確證觀察的原因，我們接下來會(huì)展開討論。

一個(gè)視圖釋放信號，多個(gè)視圖可供確證

我們的被動(dòng)衡量方法在Cloudflare規(guī)模上行之有效。但是，它自行識別根本原因或確定基本事實(shí)。對于某個(gè)連接在特定階段關(guān)閉的原因，存在很多合理的解釋，尤其是在因重置數(shù)據(jù)包和超時(shí)而關(guān)閉連接的情況下。企圖僅僅依靠這個(gè)數(shù)據(jù)源來解釋具體原因，只能得出推測。

不過，可以通過結(jié)合其他數(shù)據(jù)源（例如，主動(dòng)衡量）來克服這種局限性。例如，與OONI或Censored Planet報(bào)告，或者實(shí)地報(bào)告相互印證，可以提供更完整的故事。因此，TCP重置和超時(shí)數(shù)據(jù)集的主要用例之一是了解之前記錄的異?，F(xiàn)象的規(guī)模和影響。

確證互聯(lián)網(wǎng)規(guī)模的衡量項(xiàng)目

查看AS398324可知，出現(xiàn)了嚴(yán)重錯(cuò)誤，一半以上連接在SYN后階段顯示為異常連接。然而，此網(wǎng)絡(luò)原來是來自互聯(lián)網(wǎng)掃描公司Censys的CENSYS-ARIN-01。SYN后的異常連接可能是網(wǎng)絡(luò)層掃描的結(jié)果，即掃描程序發(fā)送單個(gè)SYN數(shù)據(jù)包來探測服務(wù)器，但沒有完成TCP握手。“后期”階段的異常連接率也很高，這可能表明進(jìn)行了應(yīng)用層掃描，因?yàn)榻咏?00%的連接被歸類為自動(dòng)化連接。

通過Cloudflare Radar

實(shí)際上，與AS15169類似，我們將源自AS398324的99%以上的請求歸類為自動(dòng)化請求。

通過Cloudflare Radar

到目前為止，我們了解了生成大量腳本流量或自動(dòng)化流量的網(wǎng)絡(luò)。現(xiàn)在，我們可以再從相對寬泛長遠(yuǎn)的視角來看一下。

確證連接篡改

本著類似于我們在HTTPS攔截方面的工作精神，此數(shù)據(jù)集的起點(diǎn)是一個(gè)研究項(xiàng)目，旨在了解和檢測活躍連接篡改。我們著手這樣做的原因在隨附的博客文章中有詳細(xì)介紹。

強(qiáng)制關(guān)閉連接的一種有據(jù)可查的常見方法是重置注入。通過重置注入，到達(dá)目的地路徑上的中間盒會(huì)檢查數(shù)據(jù)包的數(shù)據(jù)部分。如果中間盒發(fā)現(xiàn)了發(fā)送至禁用域名的數(shù)據(jù)包，它向通信一方或雙方注入偽造的TCP重置（RST）數(shù)據(jù)包，導(dǎo)致連接中止。如果中間盒沒有首先丟棄禁用數(shù)據(jù)包，則服務(wù)器會(huì)收到觸發(fā)中間盒篡改的客戶端數(shù)據(jù)包，其中可能包含帶有服務(wù)器名稱指示（SNI）字段的TLS客戶端問候消息，隨后不久會(huì)收到偽造的RST數(shù)據(jù)包。

在TCP重置和超時(shí)數(shù)據(jù)集中，通過重置注入中斷的連接通常顯示為ACK后、PSH后或“后期”階段的異常（但需要提醒的一點(diǎn)是，并非所有異常連接都是由重置注入造成）。

例如，重置注入技術(shù)是已知的，并且通常與所謂的中國防火墻（GFW）相關(guān)。誠然，通過源自中國IP地址的連接中出現(xiàn)的PSH后階段異常情況來看，我們發(fā)現(xiàn)其異常連接率高于全球平均水平。然而，從中國的各個(gè)網(wǎng)絡(luò)來看，PSH后異常連接率差異很大，這可能是由于承載的流量類型或?qū)嵤┑募夹g(shù)不同所致。相比之下，中國大多數(shù)主要自治系統(tǒng)（AS）的SYN后階段異常連接率一直很高；可能的原因是掃描程序、欺騙性SYN洪水攻擊，或殘差塊及其附帶影響。

通過Cloudflare Radar

AS4134（CHINANET-BACKBONE）顯示的PSH后連接異常率低于其他的中國AS，但仍然遠(yuǎn)高于全球平均水平。

通過Cloudflare Radar

AS9808（CHINAMOBILE-CN）和AS56046（CMNET-Jiangsu-AP）兩個(gè)網(wǎng)絡(luò)均顯示，與PSH后異常連接相匹配的連接比例達(dá)到兩位數(shù)。

通過Cloudflare Radar

通過Cloudflare Radar

尋找后續(xù)研究的新見解和目標(biāo)

TCP重置和超時(shí)數(shù)據(jù)集也可以成為識別新的或以前未得到充分研究的網(wǎng)絡(luò)行為的數(shù)據(jù)源，幫助找到“突出”且值得進(jìn)一步研究的網(wǎng)絡(luò)。

無法歸因的ZMap掃描

這里有一個(gè)我們無法解釋的問題：每天在相同的18小時(shí)間隔內(nèi)，來自英國客戶端的超過10%的連接從未經(jīng)歷過初始SYN數(shù)據(jù)包階段，然后出現(xiàn)超時(shí)問題。

通過Cloudflare Radar

內(nèi)部檢查顯示，幾乎所有SYN后階段異常連接都源自AS396982（谷歌云平臺(tái)）上使用ZMap的掃描程序，它似乎會(huì)對所有IP地址范圍進(jìn)行完整的端口掃描。（ZMap客戶端以負(fù)責(zé)任的態(tài)度進(jìn)行自我識別，這是基于ZMap負(fù)責(zé)任的自我識別功能，請參見下文所述。）我們看到，源自AS396982的美國IP地址前綴的掃描流量也達(dá)到類似水平。

通過Cloudflare Radar

移動(dòng)網(wǎng)絡(luò)中的零費(fèi)率

粗略觀察一下國家/地區(qū)層面的異常連接率，便會(huì)發(fā)現(xiàn)一些有趣的結(jié)果。例如，看看源自墨西哥的連接，通常與連接篡改相關(guān)的ACK后和PSH后階段異常連接率均高于全球平均水平。墨西哥的連接情況也與該區(qū)域的其他國家相似。不過，墨西哥這個(gè)國家“沒有書面證據(jù)表明，該國政府或其他行為者阻止或過濾互聯(lián)網(wǎng)內(nèi)容”。

通過Cloudflare Radar

通過觀察按HTTP流量體量排名靠前的墨西哥AS，我們發(fā)現(xiàn)源自AS28403（RadioMovil Dipsa,S.A.de C.V.,operating as Telcel）的近50%的連接在完成TCP握手（ACK后連接階段）后因重置或超時(shí)而終止。在此階段，中間盒可能在數(shù)據(jù)包到達(dá)Cloudflare之前就發(fā)現(xiàn)數(shù)據(jù)包并將其丟棄。

出現(xiàn)這種行為的一種原因可能是零費(fèi)率服務(wù)，即，蜂窩網(wǎng)絡(luò)提供商允許用戶免費(fèi)訪問某些資源，例如消息發(fā)送或社交媒體應(yīng)用程序。當(dāng)用戶超出其帳戶的數(shù)據(jù)傳輸限制時(shí)，提供商可能仍然會(huì)允許流量流向零費(fèi)率目的地，但同時(shí)阻止與其他資源的連接。

為了執(zhí)行零費(fèi)率政策，ISP可能會(huì)使用TLS服務(wù)器名稱指示（SNI）來確定是否阻止或允許連接。完成TCP握手之后，立即在包含數(shù)據(jù)的數(shù)據(jù)包中發(fā)送SNI。因此，如果ISP丟棄包含SNI的數(shù)據(jù)包，服務(wù)器仍然可以看到源自客戶端的SYN和ACK數(shù)據(jù)包，但看不到后續(xù)的數(shù)據(jù)包，這與ACK后階段的連接異常相符。

通過Cloudflare Radar

再看一看秘魯，這是數(shù)據(jù)集中擁有類似特征的另一個(gè)國家，其ACK后和后PSH階段的異常連接率甚至比墨西哥更高。

通過Cloudflare Radar

就特定AS而言，我們發(fā)現(xiàn)AS12252（Claro Peru）的ACK后階段高異常連接率與墨西哥的AS28403不相上下。這兩個(gè)網(wǎng)絡(luò)均由同一家母公司América Móvil運(yùn)營，因此，人們可能會(huì)認(rèn)為二者采用了類似的網(wǎng)絡(luò)策略和網(wǎng)絡(luò)管理技術(shù)。

通過Cloudflare Radar

有趣的是，AS6147（Telefónica Del Peru）反而顯示了較高的PSH后階段異常連接率。這可能表明，此網(wǎng)絡(luò)在網(wǎng)絡(luò)層使用了不同技術(shù)來執(zhí)行其策略。

通過Cloudflare Radar

隨時(shí)間變化的縱向視圖

我們持續(xù)的被動(dòng)衡量最強(qiáng)大的一面在于，能夠衡量網(wǎng)絡(luò)在更長時(shí)間段內(nèi)的性能。

互聯(lián)網(wǎng)關(guān)閉

在2024年6月“關(guān)于敘利亞、伊拉克和阿爾及利亞最近的互聯(lián)網(wǎng)關(guān)閉事件調(diào)查”這篇博客文章中，我們從Cloudflare網(wǎng)絡(luò)的角度分享了上述國家與考試相關(guān)的全國互聯(lián)網(wǎng)關(guān)閉的觀點(diǎn)。當(dāng)時(shí)我們正在準(zhǔn)備TCP重置和超時(shí)數(shù)據(jù)集，這有助于確認(rèn)外部報(bào)告并深入了解關(guān)閉網(wǎng)絡(luò)所使用的具體方法。

作為行為改變的示例，我們可以“回到過去”，觀察考試相關(guān)的網(wǎng)絡(luò)阻止情況。在敘利亞，在與考試相關(guān)的網(wǎng)絡(luò)關(guān)閉期間，我們看到SYN后階段的異常連接率激增。實(shí)際上，我們看到這些時(shí)間段內(nèi)的流量幾乎全面下降（包括SYN數(shù)據(jù)包）。

通過Cloudflare Radar

從7月最后一周開始的第二輪網(wǎng)絡(luò)關(guān)閉相當(dāng)突出。

通過Cloudflare Radar

來看看伊拉克的情況，Cloudflare對該國與考試相關(guān)的網(wǎng)絡(luò)關(guān)閉的看法與敘利亞的情況類似，盡管沒那么明顯，但是在SYN后階段出現(xiàn)了多次異常連接的峰值。

通過Cloudflare Radar

與考試相關(guān)的網(wǎng)絡(luò)關(guān)閉博客還描述了阿爾及利亞在該國考試期間如何采取一種更微妙的方法來限制網(wǎng)絡(luò)訪問：有證據(jù)表明，阿爾及利亞沒有完全關(guān)閉互聯(lián)網(wǎng)，而是有針對性地關(guān)閉特定連接。實(shí)際上，我們發(fā)現(xiàn)，考試期間的ACK后階段連接異常有所增加。如果中間盒選擇性地丟棄包含禁止內(nèi)容的數(shù)據(jù)包，同時(shí)保留其他數(shù)據(jù)包，則會(huì)出現(xiàn)這種行為（正如初始SYN和ACK后階段）。

通過Cloudflare Radar

上述示例進(jìn)一步證明，此數(shù)據(jù)與其他信號關(guān)聯(lián)時(shí)最有用。也可以通過API獲得此數(shù)據(jù)，以便其他人可以更深入地了解。我們的檢測方法也可以轉(zhuǎn)換應(yīng)用于其他服務(wù)器和運(yùn)營商，詳見下文所述。

如何大規(guī)模檢測異常TCP連接

在本節(jié)中，我們將討論構(gòu)建TCP重置和超時(shí)數(shù)據(jù)集的方法。Cloudflare全球網(wǎng)絡(luò)的規(guī)模為數(shù)據(jù)處理和分析帶來了獨(dú)特的挑戰(zhàn)。我們在此分享各種方法，幫助讀者了解Cloudflare的方法論，解讀數(shù)據(jù)集，以及在其他網(wǎng)絡(luò)或服務(wù)器中復(fù)制這些機(jī)制。

Cloudflare的方法論可以總結(jié)為以下幾點(diǎn)：

1.記錄到達(dá)面向客戶端的服務(wù)器的連接樣本。這是一種完全被動(dòng)的取樣系統(tǒng)，也就是說，它無法解密流量，并且只能訪問通過網(wǎng)絡(luò)發(fā)送的現(xiàn)有數(shù)據(jù)包。

2.根據(jù)捕獲的數(shù)據(jù)包重建連接。我們設(shè)計(jì)的一個(gè)新穎之處在于只需要觀察一個(gè)方向，也就是從客戶端到服務(wù)器。

3.將重建的連接與一組鮮明特征進(jìn)行匹配，找出因重置或超時(shí)而終止的異常連接。這些特征由兩部分組成：一個(gè)連接階段，以及一組標(biāo)記，這些標(biāo)記表明了根據(jù)文獻(xiàn)和自身觀察得出的具體行為。

這些設(shè)計(jì)選項(xiàng)可確保加密數(shù)據(jù)包安全，并且可在任何地方加以復(fù)制，而無需訪問目標(biāo)服務(wù)器。

首先，取樣連接

我們的主要目標(biāo)是設(shè)計(jì)一種可擴(kuò)展的機(jī)制，讓我們能夠全面了解到達(dá)Cloudflare網(wǎng)絡(luò)的所有連接。雖然可以在每個(gè)面向客戶端的服務(wù)器上運(yùn)行流量捕獲，但卻無法擴(kuò)展。我們還需要確切地知道應(yīng)該在何處和何時(shí)進(jìn)行觀察，這導(dǎo)致難以持續(xù)記錄見解。相反，我們從Cloudflare的所有服務(wù)器中取樣連接并將其記錄在一個(gè)中心位置，以便在該處執(zhí)行離線分析。

這時(shí)，我們遇到了第一個(gè)障礙：Cloudflare分析系統(tǒng)使用的現(xiàn)有數(shù)據(jù)包記錄管道會(huì)記錄單個(gè)數(shù)據(jù)包，但是一個(gè)連接由許多數(shù)據(jù)包組成。為了檢測連接異常，我們需要查看指定連接中的所有數(shù)據(jù)包，或至少足夠多數(shù)量的數(shù)據(jù)包。幸好我們能夠利用Cloudflare DoS團(tuán)隊(duì)構(gòu)建的靈活日志記錄系統(tǒng)來分析DDoS攻擊中涉及的數(shù)據(jù)包，結(jié)合調(diào)用精心設(shè)計(jì)的兩個(gè)iptables規(guī)則來實(shí)現(xiàn)我們的目標(biāo)。

第一個(gè)iptables規(guī)則會(huì)隨機(jī)選擇并標(biāo)記新連接進(jìn)行取樣。在我們的案例中，我們決定每10,000個(gè)入口TCP連接中取樣一個(gè)。這個(gè)數(shù)字并沒有什么神奇之處，但考慮到Cloudflare網(wǎng)絡(luò)的規(guī)模，它在捕獲足夠多的數(shù)據(jù)與不給數(shù)據(jù)處理和分析管道帶來壓力之間取得了平衡。iptables規(guī)則僅適用于通過DDoS緩解系統(tǒng)之后的數(shù)據(jù)包。鑒于TCP連接可能會(huì)長期存在，我們只對新的TCP連接進(jìn)行取樣。以下是用于標(biāo)記待取樣連接的iptables規(guī)則：

分解來說，這個(gè)規(guī)則安裝在處理入站數(shù)據(jù)包（-A PREROUTING）的鏈中的mangle表（用于修改數(shù)據(jù)包）中。僅當(dāng)連接沒有先前狀態(tài)（--state NEW）時(shí)才考慮設(shè)置SYN標(biāo)志的TCP數(shù)據(jù)包（-p tcp--syn）。過濾器會(huì)在每10,000個(gè)SYN數(shù)據(jù)包中選擇一個(gè)數(shù)據(jù)包（-m statistic–mode random--probability 0.0001）并將標(biāo)簽應(yīng)用于連接（-m connlabel--label--set）。

第二個(gè)iptables規(guī)則會(huì)記錄連接中的后續(xù)數(shù)據(jù)包，最多記錄10個(gè)數(shù)據(jù)包。同樣地，數(shù)字10也沒有什么神奇之處，因?yàn)橥ǔＧ闆r下，這些數(shù)據(jù)包足以捕獲連接建立、后續(xù)請求數(shù)據(jù)包，以及在預(yù)期時(shí)間之前已關(guān)閉連接的重置。

這個(gè)規(guī)則安裝在與上一個(gè)規(guī)則相同的鏈中。它僅匹配來自已取樣連接（-m connlabel--label）的數(shù)據(jù)包，并且僅匹配每個(gè)連接的前10個(gè)數(shù)據(jù)包（-m connbytes!--connbytes 11--connbytes-dir original--connbytes-mode packets）。匹配的數(shù)據(jù)包將會(huì)發(fā)送到NFLOG（-j NFLOG--nflog-prefix""），日志記錄系統(tǒng)會(huì)在此處提取這些數(shù)據(jù)包并將其保存到一個(gè)集中位置，以供離線分析。

根據(jù)已取樣數(shù)據(jù)包重建連接

作為分析管道的一個(gè)步驟，在服務(wù)器上記錄的數(shù)據(jù)包會(huì)插入ClickHouse表中。每個(gè)已記錄的數(shù)據(jù)包都會(huì)存儲(chǔ)在數(shù)據(jù)庫中自己的數(shù)據(jù)行中。下一個(gè)挑戰(zhàn)是將數(shù)據(jù)包重新組裝到相應(yīng)的連接中，以供進(jìn)一步分析。但在進(jìn)一步說明之前，我們需要定義本次分析所述的“連接”的具體含義。

我們使用由網(wǎng)絡(luò)5元組，即protocol,source IP address,source port界定的連接標(biāo)準(zhǔn)定義，并進(jìn)行以下調(diào)整：

-我們僅在連接的入口（客戶端到服務(wù)器）部分對數(shù)據(jù)包進(jìn)行取樣，因此，看不到從服務(wù)器到客戶端的相應(yīng)的響應(yīng)數(shù)據(jù)包。在大多數(shù)情況下，我們可以根據(jù)對服務(wù)器配置方式的了解來推斷服務(wù)器的響應(yīng)內(nèi)容。最終，入口數(shù)據(jù)包足以用于了解異常TCP連接行為。

-我們每隔15分鐘查詢一次ClickHouse數(shù)據(jù)集，將在該間隔內(nèi)共享相同網(wǎng)絡(luò)5元組的數(shù)據(jù)包分組在一起。也就是說，連接可能會(huì)在查詢間隔結(jié)束時(shí)被截?cái)?。在分析連接超時(shí)時(shí)，我們會(huì)排除不完整的流，即該流最新的數(shù)據(jù)包時(shí)間戳與查詢截止相差不超過10秒。

-由于重置和超時(shí)最有可能影響新連接，因此，我們只考慮以SYN數(shù)據(jù)包開頭的數(shù)據(jù)包序列，這些數(shù)據(jù)包是新的TCP握手流程開始的標(biāo)志，從而將長期存在的現(xiàn)有連接排除在外。

-日志記錄系統(tǒng)無法保證精確的數(shù)據(jù)包到達(dá)間隔時(shí)間戳，因此，我們僅考慮到達(dá)的數(shù)據(jù)包集合，而不是按其到達(dá)時(shí)間排序。在某些情況下，我們可能會(huì)根據(jù)TCP序列號確定數(shù)據(jù)包順序，但事實(shí)證明，這不會(huì)對結(jié)果產(chǎn)生顯著影響。

我們會(huì)過濾掉一小部分包含多個(gè)SYN數(shù)據(jù)包的連接，以減少分析中的干擾因素。

說明上述定義連接的條件之后，我們現(xiàn)在可以更詳細(xì)地描述Cloudflare分析管道。

將連接關(guān)閉事件映射到不同階段

TCP連接從建立連接到最終關(guān)閉會(huì)經(jīng)歷一系列階段。異常連接關(guān)閉的階段會(huì)提供異常發(fā)生原因的線索。根據(jù)我們在服務(wù)器上接收的數(shù)據(jù)包，我們將每個(gè)入站連接置于四個(gè)階段之一（SYN后、ACK后、PSH后、后期），如上文所述。

僅連接關(guān)閉階段就可以提供關(guān)于源自各種網(wǎng)絡(luò)的異常TCP連接的有用見解，這正是目前Cloudflare Radar上顯示的內(nèi)容。然而，在某些情況下，我們可以通過將連接與更具體的特征進(jìn)行匹配，提供更深入的見解

應(yīng)用標(biāo)記來描述更具體的連接行為

上文所述的連接階段分組均完全基于連接中數(shù)據(jù)包的TCP標(biāo)志?？紤]各種其他因素，例如數(shù)據(jù)包的到達(dá)間隔時(shí)間、TCP標(biāo)志的精確組合以及其他數(shù)據(jù)包字段（IP標(biāo)識、IP TTL、TCP序列和確認(rèn)編號、TCP窗口大小等），可以更精細(xì)化地匹配具體行為。

例如，流行的ZMap掃描程序軟件在其生成的SYN數(shù)據(jù)包（源代碼）中將IP標(biāo)識字段固定為54321，將TCP窗口大小固定為65535。當(dāng)我們看到到達(dá)Cloudflare網(wǎng)絡(luò)的數(shù)據(jù)包中設(shè)置了確切的這些字段時(shí)，該數(shù)據(jù)包很可能是由使用ZMap的掃描程序生成。

還可以使用標(biāo)記將連接與篡改中間盒的已知特征進(jìn)行匹配。大量主動(dòng)衡量研究（例如，Weaver、Sommer和Paxson）發(fā)現(xiàn)，一些中間盒部署在通過重置注入來中斷連接的過程中表現(xiàn)出一致的行為，例如，設(shè)置與客戶端發(fā)送的其他數(shù)據(jù)包不同的IP TTL字段，或同時(shí)發(fā)送RST數(shù)據(jù)包和RST+ACK數(shù)據(jù)包。如需了解關(guān)于特定連接篡改特征的更多信息，請參閱博客文章和同行評審論文。

目前，我們定義了以下標(biāo)記，并打算隨著時(shí)間的推移逐步完善和擴(kuò)展這些標(biāo)簽。有些標(biāo)記只有在設(shè)置了另一個(gè)標(biāo)記的情況下才適用，如下面的層次結(jié)構(gòu)表示方法所示（例如，fin標(biāo)記只有在設(shè)置了reset標(biāo)記時(shí)才適用）。

-timeout：因超時(shí)而終止

-reset：因重置而終止（數(shù)據(jù)包設(shè)置了RST標(biāo)志）

-fin：至少收到了一個(gè)FIN數(shù)據(jù)包，以及一個(gè)或多個(gè)RST數(shù)據(jù)包

-single_rst：連接終止，收到了一個(gè)RST數(shù)據(jù)包

-multiple_rsts：連接終止，收到了多個(gè)RST數(shù)據(jù)包

-acknumsame：RST數(shù)據(jù)包中的確認(rèn)編號全部相同且非零

-acknumsame0：RST數(shù)據(jù)包中的確認(rèn)編號全部為零

-acknumdiff：RST數(shù)據(jù)包中的確認(rèn)編號各不相同且全部非零

-acknumdiff0：RST數(shù)據(jù)包中的確認(rèn)編號各不相同，且其中之一為零

-single_rstack：連接終止，收到了單個(gè)RST+ACK數(shù)據(jù)包（同時(shí)設(shè)置了RST和ACK標(biāo)志）

-multiple_rstacks：連接終止，收到了多個(gè)RST+ACK數(shù)據(jù)包

-rst_and_rstacks：連接終止，收到了RST和RST+ACK數(shù)據(jù)包的組合

-zmap：SYN數(shù)據(jù)包與ZMap掃描程序生成的數(shù)據(jù)包匹配

目前Radar儀表板和API中均無法查看連接標(biāo)記，但我們計(jì)劃在未來發(fā)布這項(xiàng)額外功能。

下一步

Cloudflare的使命是幫助構(gòu)建更好的互聯(lián)網(wǎng)，我們認(rèn)為提高透明度和加強(qiáng)問責(zé)制是實(shí)現(xiàn)使命的關(guān)鍵所在。希望我們分享的這些見解和工具，有助于揭示世界各地的異常網(wǎng)絡(luò)行為。

雖然現(xiàn)有的TCP重置和超時(shí)數(shù)據(jù)集應(yīng)該會(huì)立即證明對網(wǎng)絡(luò)運(yùn)營商、研究人員和互聯(lián)網(wǎng)用戶有用，但我們不會(huì)止步于此。未來，我們希望增添幾項(xiàng)改進(jìn)功能：

-擴(kuò)展用于捕獲特定網(wǎng)絡(luò)行為的標(biāo)記集，并將其在API和儀表板中公開。

-擴(kuò)展洞察及見解，涵蓋從Cloudflare到客戶源服務(wù)器的連接。

-添加QUIC支持。目前Cloudflare全球范圍內(nèi)30%以上的HTTP請求都使用QUIC。