交流評論、關注點贊

  • Facebook Icon臉書專頁
  • telegram Icon翻牆交流電報群
  • telegram Icon電報頻道
  • RSS訂閱禁聞RSS/FEED訂閱

Shadowsocks是如何被檢測和封鎖的

2019年12月30日 6:38 PDF版 分享轉發

中國 是最流行的翻牆軟體之一。從2019年5月起,大量的網民反饋他們的Shadowsocks伺服器被封鎖了。這篇報告是我們對中國的防火長城()是如何檢測和封鎖Shadowsocks及其衍生翻牆軟體的初步調查結果。通過網路測量實驗,我們發現GFW會被動的監視網路流量從而識別出疑似Shadowsocks的網路流量;然後對對應的Shadowsocks伺服器進行主動探測已驗證其懷疑的正確與否。Shadowsocks的封鎖程度可能受人為因素在政治敏感時期的控制。我們提出一種規避方法,即改變網路數據包在Shadowsocks握手階段的大小。這種方法被證明可以在現階段有效減少主動探測。我們會繼續與開發者合作讓Shadowsocks及其衍生工具變得更加難以封鎖。

搬瓦工翻牆 Just My Socks

推薦安卓翻牆APP:SpeedUp VPN

Android版SpeedUp ,基於ShadowsocksRb,與協議兼容,內置免費SSR伺服器。 如果您對內置SSR VPN伺服器不滿意,則可以自行添加或導入任何SSR伺服器使用。

主要發現

  • 防火長城(GFW)已經啟用主動探測的手段來識別Shadowsocks伺服器。GFW採用被動監測與主動探測相結合的方式:其首先監測網路連接找出疑似Shadowsocks的連接,然後再把自己偽裝成一個客戶端,嘗試對疑似Shadowsocks的伺服器進行連接,從而驗證自己的猜測。我們知道GFW可以對多種翻牆工具進行主動探測,現在Shadowsocks也成了其中一員。
  • 主動探測系統可以發送多種不同類型的探測。其中一些探測是基於對之前合法客戶端建立的連接的重放;而另一些探測則似乎與之前的合法連接並不相關。
  • 如同之前的研究發現,主動探測來自大量不同的源IP地址。這使得基於源IP來過濾GFW探測包不太可行。亦如之前的研究發現,網路層面的側通道顯示這些來自數以千計的IP地址的主動探測並非完全相互獨立,而是源於GFW的集中控制。
  • 很少量的(大於13個)合法連接即足以觸發對於Shadowsocks伺服器的主動探測。只要合法客戶端還在使用伺服器,主動探測就會持續下去。GFW通常在合法連接到達伺服器后的數秒內發送第一個主動探測。
  • 一旦GFW主動識別出Shadowsocks伺服器,GFW可能會丟棄所有發送自伺服器IP地址,或伺服器Shadowsocks埠的數據包。但GFW也可能不立即採取封鎖措施。Shadowsocks的封鎖程度可能受人為因素在政治敏感時期的控制。
  • GFW的被動監測模塊至少會根據網路數據包的長度來懷疑可疑流量。改變數據包的長度,比如所在服務端安裝brdgrd,即可通過干擾被動監測模塊對Shadowsocks流量的識別,進而顯著減少主動探測的數量。

我們怎麼知道的?

我們在境外搭建了自己的Shadowsocks伺服器並從中國用客戶端連接它們,與此同時,在伺服器和客戶端兩端抓包進行分析。所有的實驗都是在2019年7月5號到2019年11月11號之間進行的。其中的絕大部分實驗都是在2019年9月16日開始的一次大規模封鎖後進行的。

在絕大部分實驗中,我們使用了shadowsocks-libev v3.3.1作為客戶端和服務端,因為它是一個被積極維護且具有代表性的Shadowsocks實現。我們相信我們所發現的這些弱點在其他Shadowsocks及其衍生工具,如Outline VPN,中同樣存在。

若非明確指出,我們未對任何實驗中的客戶端及伺服器的網路功能進行修改,比如更改防火牆的設置。Shadowsocks可以使用不同的加密設置,我們對Stream ciphersAEAD ciphers都進行了測試。

主動探測的一些細節

Shadowsocks是一項加密通訊協議,其數據包的內容被設計得(應)不包含任何固定特徵。其兩種加密模式都基於一個主密碼,兩種模式分別為:Stream(不推薦使用) 和 AEAD (推薦)。這兩種加密模式雖都要求客戶端事先知道主密碼;但是Stream加密模式的伺服器僅能對客戶端進行較弱的驗證。除非使用額外的技術手段,兩種模式都不能防禦對之前發送過的驗證數據包的重放攻擊。

主動探測的類型及審查者意圖

我們目前觀察到五種不同的主動探測荷載。

基於重放的探測:

  1. 重放某一合法連接中第一個攜帶數據的數據包中的荷載。
  2. 重放某一合法連接中第一個攜帶數據的數據包中的荷載,但更改第0位元組。
  3. 重放某一合法連接中第一個攜帶數據的數據包中的荷載,但更改第0–7和第62–63位元組。

看似隨機的探測(並非基於我們所觀察到的合法連接):

  1. 荷載長度為7到50位元組,占所有看似隨機的主動探測的70%。
  2. 荷載長度為221位元組,占所有看似隨機的主動探測的30%。
CDF: Payload Lengths of PSH/ACKs Received by Outline Server

我們懷疑GFW的主動探測系統根據伺服器對這幾種不同類型的主動探測的反饋來判定其是否為Shadowsocks伺服器。

Shadowsocks-libev有一個重放過濾器; 但是大多數的Shadowsocks實現則沒有。重放過濾器可以防禦一模一樣的重放(類型1),如果載荷的最初幾位元組被改變了(類型2和3)那麼過濾器就無法防禦了。過濾器本身也不夠阻止主動探測模塊去比較伺服器對多種探測的反應。

多少次合法連接就能觸發主動探測

對主動探測的觸發似乎需要達到一定的閥值。比如在一項實驗中,僅僅13次連接就足以引起GFW的懷疑並觸發主動探測。初步結果顯示,使用了AEAD的Shadowsocks,可能需要稍微多一點點的連接才會觸發主動探測。

合法連接與主動探測的關係

我們讓客服端每5分鐘對Shadowsocks伺服器進行16次連接。雖然我們的伺服器觸發了大量的主動探測,但不知為何,其並未被GFW封鎖。

Ad:美好不容錯過,和家人朋友一起享受愉快時光,現在就訂票
Number of SYN Received Across Time

上圖顯示在客戶端與伺服器有通訊的時間里,伺服器會收到主動探測。當合法客戶端與伺服器的通訊停止下來后,大部分的主動探測也停了。值得指出的是,每小時中主動探測的數量並非固定值,與合法客服端的連接數目比也並非1:1。

主動探測的延遲性

GFW的主動探測系統可以將合法連接的載荷保存下來,然後延遲一段時間再發起一個新的連接進行重放。下圖顯示了合法連接與重放攻擊之間的延時關係。由於一個合法的載荷可能被多次重放(某一次實驗中觀察到的最大值為47次),我們呈現兩組關係:桔黃色的線代表基於一個合法載荷的第一次重放;藍色的線代表所有基於重放的探測(不限定為第一次)。

結果顯示多於90%的重放攻擊發生在合法連接發送后的一小時之內。觀察到的最短的延遲僅有0.4秒,而最長延遲竟有大約400小時。

CDF: Delay of Replay-based Probes

主動探測的源

我們在目前所有實驗中總計觀察到3,5477次主動探測。它們來自1,0547個不同的IP地址,IP地址均屬於中國。

源自治系統。主動探測來源佔比最多的兩個自治系統 AS 4837 (CHINA169-BACKBONE CNCGROUP China169 Backbone,CN) 和 AS 4134 (CHINANET-BACKBONE No.31,Jin-rong Street,CN),分別為中國聯通和中國電信的主幹網。這一結果與之前對重放攻擊的研究一致。

ASN of unique probing IPs throughout all experiments

中心化結構。儘管這些主動探測來源於上千個不同的IP地址,有跡象顯示它們的行為均受到一小撮進程的集中管控。下圖顯示了每個主動探測的SYN包所攜帶的TCP timestamp值。TCP timestamp是一個32位的計數器,其以固定的速度進行增長。其不是一個絕對值,而是一個取決於TCP實現和系統上次重啟時間的相對值。下圖顯示這些來源於上千個獨立的IP地址的主動探測,共享著很少量的TCP timestamp序列。在這次實驗中,至少觀察到9個不同的物理系統或進程,而絕大多數主動探測似乎來源於同一進程。我們說「至少」和「似乎」是因為如果兩個或以上的獨立進程的截距非常相近,那麼我們可能把它們誤認為一個進程。序列的斜率顯示timestamp的增長速度為250HZ。

TCP TSval of SYN Segments from Probers

如何規避針對Shadowsocks的封鎖?

GFW對於Shadowsocks的檢測需要兩步:

  1. 第一步,被動監測並識別疑似Shadowsocks的連接。
  2. 第二步,主動探測疑似Shadowsocks的伺服器。

因此,為避免封鎖,我們可以(1)設法避免被監測模塊懷疑到,或者(2)讓伺服器以不被懷疑的方式回應主動探測。我們將展示如何通過安裝改變數據包大小的軟體來達到目標(1)。

Brdgrd是一款可以被安裝在Shadowsocks伺服器上,從而導致Shadowsocks客服端發送較小的數據包的軟體。它設計之初衷是用來干擾GFW識別Tor節點,因為它迫使GFW在檢測之前首先對TCP流進行複雜的重組。但這裏我們利用它可以改變從客戶端到伺服器的數據包大小的功能。改變數據包的大小可以干擾流量識別環節,從而在極大程度上緩解主動探測。

Effectiveness of brdgrd on Server

上圖顯示了一個受到主動探測的Shadowsocks伺服器,在開啟brdgrd后的數小時內不再收到主動探測。而當我們關閉brdgrd,主動探測立刻繼續。我們第二次開啟brdgrd,主動探測在之後的40小時里完全停止,但之後又有些許主動探測。

另一組實驗顯示,在第一次運行Shadowoscks之初就啟用brdgrd也許更加的有效。

Brdgrd的原理是將TCP Window Size改寫為一個小得罕見的值。因此,審查者可能可以檢測出brdgrd被使用了。因此,儘管brdgrd可以在現階段有效的減少主動探測,其不能被看作是一個一勞永逸的解決方案。

尚未解決的問題

儘管我們已經清楚GFW會主動探測Shadowsocks伺服器,我們仍不清楚主動探測與Shadowsocks伺服器被封之間的關係。我們有33組Shadowsocks伺服器分佈於世界各地。儘管它們中的大多數都遭受到了大量的主動探測,但是僅有3台伺服器被封鎖。更有趣的是,其中一台被封鎖的伺服器只被使用了很短的一段時間,因此受到的主動探測數量應該比很多未被封鎖的伺服器要少得多。

我們提出3種假設試圖解釋這一有趣的現象:

  • Shadowsocks伺服器的封鎖是由人為的因素控制的。也就是說,GFW也許維護了一份在不同程度上被懷疑為Shadowsocks伺服器的清單,然後根據人工因素來決定對伺服器進行封鎖還是解封。這一假設可以解釋為什麼更多的伺服器是在政治敏感時期被封鎖的。
  • 另一個假設是GFW的主動探測對於一些我們實驗採用的Shadowsocks實現無效。確實,我們被封鎖的那3台伺服器都是使用了與其他實驗中的Shadowsocks不同的實現。如果GFW是根據某些Shadowsocks伺服器實現對主動探測的特有反應來識別判斷的話,那麼這一假設更有可能為真。
  • 第三個假設是對於Shadowsocks的封鎖在地理上存在著不一致性。我們被封鎖的那3台伺服器所在的不同於其他大多數實驗,使用的客服端也是位於一般的居民網路,而非數據中心。如果GFW更注意屬於某些數據中心的IP地址,抑或更注意來自一般居民網路的客戶端連接,那麼這一假設更有可能為真。

致謝

我們想在此感謝以下人員對此主題的討論和研究:

  • Shadowsocks-libev 的開發者們
  • OutlineVPN 的開發者們
  • Eric Wustrow以及其他多名來自科羅拉多大學博爾德分校的研究人員

聯繫我們

這篇報告首發於GFW Report。我們還在net4people和ntc.party同步更新了這篇報告。

我們鼓勵您公開或私下地分享與報告中的發現和假設相關的問題、評論或證據。我們私下的聯繫方式可見GFW Report的頁腳。

喜歡、支持,請轉發分享↓Follow Us 責任編輯:藍柱