如何忽略防火長城(一)

簡介:本文從TCP/IP協議安全性的角度對中國防火牆系統的工作原理、工作特性和潛在的漏洞、造成的問題進行了詳盡的調查和分析,並從多個角度提出了針對特別是防火長城這類利用TCP/IP協議進行攻擊的反制措施。

如何忽略防火長城

Richard Clayton, Steven J. Murdoch, and Robert N. M. Watson*
University of Cambridge, Computer Laboratory, William Gates Building, 15 JJ Thomson Avenue, Cambridge CB3 0FD, United Kingdom
{richard.clayton, steven.murdoch, robert.watson}@cl.cam.ac.uk

* 致謝:我們感謝一位中國公民的幫助。(我們不會透露他的名字,他對我們實驗的本質完全不知情,他的網頁也不包含任何非法內容)他爲我們理論思考提供了極爲可信的實踐材料。Richard Clayton正爲Intel Research資助的spamHINTS項目工作。Steven J. Murdoch由OpenNet Initiative資助。

摘要:所謂“防火長城”之部分工作原理即是檢測傳輸控制協議(TCP)報文中需要封鎖的關鍵詞。如果出現關鍵詞,TCP複位報文(即RST標志置位的報文)即向連接兩端發送,連接隨之關閉。而原報文完好通過防火牆,如果雙方完全忽略防火牆的複位,那麽連接仍可順暢進行而防火牆失效。一旦連接被封鎖,防火牆還會進而嘗試封鎖雙方的繼發連接。後種特性可能被利用來對第三方進行拒絕服務攻擊。

1 引言

中華人民共和國運行的互聯網過濾系統,普遍認爲是世界上最複雜的系統之一。[1]其部分工作原理即是檢測網絡(HTTP)流量判斷是否出項特定關鍵詞。[2]這些關鍵詞涉及一些中國政府封殺的組織、不可接受的政治意識形態、不願討論的曆史事件。[3]

直觀判斷,關鍵詞封鎖發生在連接中國與外界網絡的路由器組內部。[4]這些路由器利用基于入侵檢測系統(IDS)技術的設備來判斷報文內容是否匹配中國政府制訂的過濾規則。[5]如果客戶端與服務器的一個連接需要封鎖,路由器則會在數據流中注入僞TCP複位報文,于是雙方便會斷開連接。[6]這種封鎖一旦觸發,便會持續數分鍾,相同方向上的繼發連接都會被僞複位直接打斷。

在本文第2節我們將討論國家阻止其公民訪問特定網絡內容的方法,以及以往調查者認定的優點和缺點。在第3節我們提供了從中國防火牆系統封鎖的連接兩端獲取的一組報文。第4節我們提出了這個防火牆的一個模型,來解釋我們獲得的結果。然後第5節我們將展示,通過忽略防火牆發出的TCP複位我們成功傳輸了本來應該被封鎖的內容,並討論爲什麽這種手段防火牆難以應付。第6節我們展示了防火牆的封鎖行爲如何可以被利用來對第三方進行拒絕服務攻擊。最後在第7節,我們討論了這種規避審查的方法的優缺點,並思考了中國以外的網站如何免于封鎖降低訪問難度,還提出公共政策能怎樣鼓勵人們規避審查的問題。

2 內容封鎖系統

有三種顯著的內容封鎖手段:報文丟棄、DNS汙染、內容檢測。研究北威州封鎖右翼納粹內容的Dornseif的論文[7],和研究英國電信混合封鎖系統封鎖戀童癖網站的Clayton[8]的論文,一起確定了以上手段。

2.1 報文丟棄方案

在一種報文丟棄方案中,往特定IP地址的所有流量被全部丟棄,于是網站便無法訪問。這種方案費用低廉,易于實施──標准的防火牆和路由器便已提供這些必要特性。報文丟棄方案有兩個主要問題。首先,IP地址列表必須保持最新,如果內容提供者不想讓ISP輕易封鎖他們的網站,保持更新的困難便暴露出來。[9]其次,系統會導致“過度封鎖”──共用同一IP的其他網站被全部封鎖。Edelman調查了過度封鎖的潛在程度,發現69.8%的.com、.org和.net網站與50以上其他網站共用IP。[10](雖然一部分域名只是“停放”在一個普通網頁上)其詳細數字顯示網站共用IP數的連續變化圖譜,反映出在一台主機上盡量多挂網站這種盛行的商業做法。

2.2 DNS汙染方案

在一種DNS汙染方案中,當用戶查詢域名服務系統(DNS)將文字的域名轉換爲數字的IP地址時,可以返回錯誤的應答或者不返回應答導致用戶不能正常訪問。這類方案沒有過度封鎖的問題,因爲禁止訪問特定網站不會影響到其他網站。不過,郵件傳遞也需要DNS查詢,如果只是封鎖網站而不封鎖郵件服務的話,此類方案實現起來容易出錯。Dornseif展示的樣本中所有的ISP都至少有一次在實現DNS汙染時出錯。[11]

2.3 內容檢測方案

多數內容檢測方案是讓所有流量通過一個代理服務器。這個代理通過不提供禁止內容來過濾。這種系統可以做得非常精確,程度可以到屏蔽單個網頁或者單個圖像而讓其他內容順利通過。這類基于代理的系統沒有普遍使用的原因是,可以應付主幹網絡或者整個國家網絡流量的系統過于昂貴。2004年9月美國賓夕法尼亞州,要求封鎖包含兒童色情網站的一條州法令以違憲被裁定無效[12]。當初由于經費原因,賓夕法尼亞的ISP采用的是報文丟棄和DNS汙染的混合策略,導致的過度封鎖和“前置審核限制”對地區法庭作此裁決起到了相當的作用。不過,基于代理的系統已被部署到若幹國家比如沙特阿拉伯[13]、緬甸[14],以及挪威的一些網絡提供商比如Telenor[15]。Clayton研究的英國電信的系統是一種混合設計,利用廉價緩存代理處理特定目標IP的報文。不幸這導致用戶可以逆向工程得到封禁網站的列表,而這些網站提供兒童的非法圖像,這違背了此系統的公共政策目標。

進行內容檢測的另一種手段則是入侵檢測系統(IDS)。IDS設備可以檢測通過的網絡流量並判斷其內容是否可接受。如果需要封禁則會調度鄰近的防火牆攔截報文,或者就中國的情況而言,發送TCP複位報文導致威脅性連接關閉。基于IDS的系統顯然比其他方案更靈活,更難規避。Dornseif和Clayton都對如何規避各種封鎖進行了深入探討。[16]然而如果通信保持清晰不加密不變形到IDS無法辨別的程度,那麽無論采取什麽規避手段,IDS方法都能夠將其檢測出來。[17]

3 中國防火牆如何封鎖連接

我們在實驗中從英國劍橋(牆外)的若幹機器連接了中國內的一個網站(牆內)。當前中國的防火牆系統的工作方式是完全對稱的[18]──在兩個方向上檢測內容並進行過濾。[19]通過從劍橋的終端發出所有的指令我們完全避免了違反中國法律的可能性。一開始我們以正常模式訪問一個中國網頁並記錄雙方的報文流。接下來我們又發起一次有意觸發封禁的請求,觀察連接是如何被複位報文關閉的。我們繼續“正常”的(不包含觸發性詞彙的)請求,卻發現接下來的連接都意外地被封鎖了。接下來我們將詳細描述觀測結果。

3.1 複位封鎖

剛開始我們只是訪問一個普通網頁,如預期得到完全正常的返回。如下面的轉儲報文所示,起始的TCP三次握手(SYN[20],SYN/ACK[21],ACK[22])之後客戶端(此實例中使用了53382端口)向服務端http端口(tcp/80)發出了超文本傳輸協議(HTTP)的GET指令獲取頂級頁面(/),傳輸正常。我們使用netcat(nc)發出這個請求,沒有使用網頁浏覽器,從而避免了無關細節。報文用ethereal截取,用一般格式表示出來。

cam(53382) → china(http) [SYN]
china(http) → cam(53382) [SYN, ACK]
cam(53382) → china(http) [ACK]
cam(53382) → china(http) GET / HTTP/1.0<cr><lf><cr><lf>
china(http) → cam(53382) HTTP/1.1 200 OK (text/html)<cr><lf> ……
china(http) → cam(53382) ……其余頁面內容
cam(53382) → china(http) [ACK]
……接下來這個頁面就完整了。

我們發出另一個請求,包含了一小段可能觸發封禁的文字,當然這也很快發生了:

cam(54190) → china(http) [SYN]
china(http) → cam(54190) [SYN, ACK] TTL=39
cam(54190) → china(http) [ACK]
cam(54190) → china(http) GET /?falun HTTP/1.0<cr><lf><cr><lf>
china(http) → cam(54190) [RST] TTL=47, seq=1, ack=1
china(http) → cam(54190) [RST] TTL=47, seq=1461, ack=1
china(http) → cam(54190) [RST] TTL=47, seq=4381, ack=1
china(http) → cam(54190) HTTP/1.1 200 OK (text/html)<cr><lf> ……
cam(54190) → china(http) [RST] TTL=64, seq=25, ack zeroed
china(http) → cam(54190) ……其余頁面內容
cam(54190) → china(http) [RST] TTL=64, seq=25, ack zeroed
china(http) → cam(54190) [RST] TTL=47, seq=2921, ack=25

開頭三個複位報文序列號對應了GET報文的序列號+1460和+4380(3 × 1460)。[23]我們認爲防火牆發出三個不同的值是想確保發送者接受複位,即使發送者已經從目的地收到了“全長”(1460字節)ACK報文。複位報文的序列號需要“正確”設定,因爲現在多數TCP/IP實現都會嚴格檢查序列號是否落入預期窗口。[24](這個驗證序列號的內在漏洞由Watson在2004年首先提出。[25])

此結果還顯示,在連接被打斷後仍然收到了從中國機發來的一部分頁面。然後劍橋機響應了那兩個意外報文,發送了自己的TCP複位。注意它將確認號置零而沒有使用隨機初始值的相關值。收到的所有複位報文的TTL[26]都是47,而中國機來的報文的TTL都是39,說明它們來源不同。如果來源的初始值都是64,這也許說明複位産生的地方距離服務器有8跳(hop)。 traceroute顯示那是通信從Sprint網絡(AS1239)進入中國網通集團網絡(AS9929)後的第二台路由器。

我們也從中國服務器的視角看這次連接封鎖:

cam(54190) → china(http) [SYN] TTL=42
china(http) → cam(54190) [SYN, ACK]
cam(54190) → china(http) [ACK] TTL=42
cam(54190) → china(http) GET /?falun HTTP/1.0<cr><lf><cr><lf>
china(http) → cam(54190) HTTP/1.1 200 OK (text/html)<cr><lf> ……
china(http) → cam(54190) ……其余頁面內容
cam(54190) → china(http) [RST] TTL=61, seq=25, ack=1
cam(54190) → china(http) [RST] TTL=61, seq=1485, ack=1
cam(54190) → china(http) [RST] TTL=61, seq=4405, ack=1
cam(54190) → china(http) [RST] TTL=61, seq=25, ack=1
cam(54190) → china(http) [RST] TTL=61, seq=25, ack=2921
cam(54190) → china(http) [RST] TTL=42, seq=25, ack zeroed
cam(54190) → china(http) [RST] TTL=42, seq=25, ack zeroed

我們可以看到,當檢測到“壞”報文,防火牆也向中國機發送複位(“[RST]”)報文,但都在GET報文(以及其響應報文)後面。最後兩個複位報文(零確認號)是劍橋機發送的。

其他到中國機的複位(因爲有“falun”而生成的)TTL都是61,這意味著它們在3跳以外生成,初始值爲64。這跟劍橋觀測到的8跳偏移不一樣。不過這說明可能有不止一台設備在生成複位──或者初始值經過調整不是64。我們目前對于觀測到的這種不對稱性沒有確定的解釋。

開始三個複位的序列號也設置在一定範圍(+25,+1485,+4405)以確保命中,事實上+25報文就已經重置了連接。[27]第四、五個複位報文檢查確認號發現,它們可以視作連接重置前中國機成功發送的兩個報文的響應。

3.2 直接重置連接

防火牆不僅檢測內容,還有其他封鎖規則。我們發現,只要進行一次“壞”連接,在短時間內相同兩主機之間的所有網絡通信在經過檢查之前就都被封鎖了。前面也是連接被封搜,不過現在開始繼發連接也會被封鎖了。比如,在上面一例以後立刻繼續,我們看到:

cam(54191) → china(http) [SYN]
china(http) → cam(54191) [SYN, ACK] TTL=41
cam(54191) → china(http) [ACK]
china(http) → cam(54191) [RST] TTL=49, seq=1

複位報文從防火牆而來(也往服務器而去)隨之客戶端便關閉了連接。如果客戶端在複位到達前成功發送GET報文,便會接著收到多個防火牆發來的複位(即使GET報文是完全無毒的)。接下來便是從服務端來的複位──服務器收到複位後便會立刻在GET到達前關閉連接。由于GET發來時不再存在打開的連接,服務端便按照協議返回一個複位。值得注意的是,防火牆在SYN階段(三次握手階段一)沒有試圖重置連接,而是等到了SYN/ACK(階段二)。雖然可以在客戶端一發出SYN就給它複位報文,但只有等到SYN/ACK才能構造出對服務端起作用的有效複位。[28]

在實驗中我們發現,節點被阻斷通信的時間是可變的。有時候是幾分鍾,有時候可能是一小時。平均時間大概在20分鍾,不過由于觀測到時間值有在特定值附近聚集的顯著趨勢,我們懷疑不同的防火牆組件有不同的時間延遲設定;這就需要深入理解是到底是誰在處理通信,才能較准確地預測封鎖周期。

3.3 其他中國網絡的情況

我們獲取了中國自治系統(AS)的一個列表,並從中生成了在全球路由表中所有中國子網的列表。[29]然後我們利用了一個修改過的tcptraceroute,判斷出通信是通過哪個AS從國際網絡進入中國,並從中得知了中國主幹邊際網絡的實體。結果便是:AS4134,AS4837,AS7497,AS9800,AS9808,AS9929,AS17622,AS24301和AS24489。然後我們在各個AS中挑選了樣例服務器測試,發現所有網絡都有都跟前面描述相似的複位行爲(除了AS24489:跨歐亞信息網)。以此我們可以推出:我們的結果正展示了典型的“防火長城”系統。情況在2006年5月下旬是這樣的,但並不一定普遍適用。[30]

4 防火長城的設計

基于以上實驗結果,以及中國使用的技術設備類型的描述──比如思科的“安全入侵檢測系統”[31]──我們提出以下模型來描述中國防火牆中路由器的工作方式(此模型很符合觀測,但仍是推論性的,因爲中國的網絡提供商沒有發布關于這些系統的任何技術規格):

當報文到達路由便被立刻放入適當的向前傳輸隊列。此報文也被送到帶外IDS設備進行內容檢測。如果IDS(關鍵詞匹配)認爲此報文“不好”,那麽便爲連接兩端各生成三個TCP複位報文(有三個不同的序列號)交由路由器傳輸。[32]

IDS在邏輯上是與路由器分離的,很難從路由傳輸隊列中去除或者延遲“壞”報文。然而發出複位關閉連接是相對簡單的。如果路由器相對繁忙,而IDS 工作正常,複位報文會在“壞”報文之前發送;這也是我們在實驗中觀測到的主要情況,雖然有時候複位報文會拖在後面。複位報文的設定值充分顯示出,設計者擔心與路由器相比IDS的擁塞導致“壞”報文跑在複位報文前面。這種設計中如果不發送附加的複位,在繁忙情況下防火牆是無法保證封鎖的可靠性的。

一旦IDS檢測到需要封鎖的行爲,它也可以向主路由器添加一條簡單的丟棄規則而不發出複位。[33]我們相當懷疑這種做法在主幹高速路由器上擴展性差,而在IDS內的封鎖簡單而廉價。

我們還觀測封鎖的時長得知,提供防火牆功能的設備不止一個。我們進行了進一步實驗,發送256個包含威脅性字串的報文通過防火牆,雖然是從一個機器上發出的,但將它們的源地址設置分別爲256個連續的IP地址值,即中國防火牆會認爲這是256個不同機器在發送需要封鎖的內容。結果是,我們觀測到有時候返回的複位報文是亂序的。然而現代互聯網處理報文基本上是用FIFO(先進先出)隊列,[34]那麽對于這種失序的最簡單解釋便是,不同的報文給了不同的IDS,它們各有各的FIFO隊列但在發送複位時負載不一樣。可惜我們發現這個實驗引起了很多的報文丟失(不是所有的連接都返回了應有的複位報文),不能對報文失序程度有直觀感受。這樣我們也沒法(通過隊列建模)確定平行IDS設備的數量下界。我們計劃以後再做這個實驗。

4.1 防火牆“狀態”

沒有證據證明帶外IDS設備互相通信,並共享網絡連接“狀態”的記錄。實驗表明在一個邊際網絡觸發防火牆不影響通過其他邊際網絡的通信。

而在“狀態”本來應該保留的地方(IDS設備中)卻沒有關于TCP狀態的檢查。設備孤立地檢查報文,于是將?falun分散到相鄰兩個報文就足以避免檢測。更有甚者,這些設備對于是否有連接存在也不關注,我們的許多測試中甚至沒有進行三次握手打開連接就直接發送GET報文。事實上除了初始檢測之後的持續封鎖,沒有證據證明IDS設備做了其他什麽特別的事情,IDS只是一次檢查一個報文而已。

5 有意忽略複位

防火牆完全依賴于終端節點以標准兼容方式實現TCP協議[35],在收到複位報文時中斷連接。如上所述,雖然有時候防火牆有點超常,複位報文跑在GET報文前面結果被仔細驗證一番以後丟掉了,不過在下一個報文到達防火牆的時候連接就會被防火牆摧毀所以,總得來說還是沒有什麽區別。

不過現在考慮如果終端節點不遵守標准然後TCP複位被徹底忽略的情況,我們會想到,即使觸發了IDS,防火牆也對HTTP傳輸沒有任何影響。于是我們進行了深入實驗兩邊的終端節點都忽略TCP複位的情況。這有許多方法可以實現,我們選擇設置合適的報文過濾防火牆規則。在Linux可以安裝iptables並使用此命令:

iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP

來丟棄傳入的RST置位報文。如果是FreeBSD的ipfw那麽命令是這樣的:

pfw add 1000 drop tcp from any to me tcpflags rst in

當雙方都丟棄TCP複位時我們發現網頁傳輸確實沒有被封鎖。在劍橋端檢測傳輸的結果:

cam(55817) → china(http) [SYN]
china(http) → cam(55817) [SYN, ACK] TTL=41
cam(55817) → china(http) [ACK]
cam(55817) → china(http) GET /?falun HTTP/1.0<cr><lf><cr><lf>
china(http) → cam(55817) [RST] TTL=49, seq=1
china(http) → cam(55817) [RST] TTL=49, seq=1
china(http) → cam(55817) [RST] TTL=49, seq=1
china(http) → cam(55817) HTTP/1.1 200 OK (text/html)<cr><lf> ……
china(http) → cam(55817) ……其余頁面內容
cam(55817) → china(http) [ACK] seq=25, ack=2921
china(http) → cam(55817) ……其余頁面內容
china(http) → cam(55817) [RST] TTL=49, seq=1461
china(http) → cam(55817) [RST] TTL=49, seq=2921
china(http) → cam(55817) [RST] TTL=49, seq=4381
cam(55817) → china(http) [ACK] seq=25, ack=4381
china(http) → cam(55817) [RST] TTL=49, seq=2921
china(http) → cam(55817) ……其余頁面內容
china(http) → cam(55817) ……其余頁面內容
cam(55817) → china(http) [ACK] seq=25, ack=7301
china(http) → cam(55817) [RST] TTL=49, seq=5841
china(http) → cam(55817) [RST] TTL=49, seq=7301
china(http) → cam(55817) [RST] TTL=49, seq=4381
china(http) → cam(55817) ……其余頁面內容
china(http) → cam(55817) [RST] TTL=49, seq=8761
……接下來這個頁面就完整了。

網頁以正常方式傳輸,除了中間夾雜一些防火牆的TCP複位報文。由于被完全忽略(一共28個複位),它們對客戶端的TCP/IP棧沒有任何影響。客戶端仍然繼續接收網頁,正常發送ACK。中國端也能看到類似的正常傳輸夾雜複位的情形。

這樣,只是簡單地忽略防火長城發出的報文我們就讓它完全失效了!這無疑會讓它的實現者大爲惱火。

5.1 迷惑封鎖

一方面是在連接建立以後通過發出TCP複位來阻斷繼發連接,另一方面我們也觀察到一些防火牆有時還有附加策略。在一些節點(當然是隨機的),我們看見了防火牆發來的僞SYN/ACK報文。顯然其序列號是隨機而且無效的。如果防火牆的SYN/ACK 報文比真報文先到那麽連接失效──客戶端從僞SYN/ACK中獲取了隨機的序列號並發給服務端錯誤的ACK,于是服務端便返回複位報文,導致客戶端關閉連接。實際上,如果客戶端發送GET比較快,還會收到一批其他報文,導致防火牆和服務端的進一步複位:

cam(38104) → china(http) [SYN]
china(http) → cam(38104) [SYN, ACK] TTL=105
cam(38104) → china(http) [ACK]
cam(38104) → china(http) GET / HTTP/1.0<cr><lf><cr><lf>
china(http) → cam(38104) [RST] TTL=45, seq=1
china(http) → cam(38104) [RST] TTL=45, seq=1
china(http) → cam(38104) [SYN, ACK] TTL=37
cam(38104) → china(http) [RST] TTL=64, seq=1
china(http) → cam(38104) [RST] TTL=49, seq=1
china(http) → cam(38104) [RST] TTL=45, seq=3770952438
china(http) → cam(38104) [RST] TTL=45, seq=1
china(http) → cam(38104) [RST] TTL=45, seq=1
china(http) → cam(38104) [RST] TTL=37, seq=1
china(http) → cam(38104) [RST] TTL=37, seq=1

對付這種防火牆的新策略比處理僞複位報文麻煩許多。因爲即使客戶端忽略了服務端來的(完全真實的)複位,還是會繼續錯誤理解服務端的序列號,導致不能與服務端同步以完成三次握手打開連接。當然如果有時候防火牆的僞SYN/ACK跑在真報文後面,就會被客戶端忽略不造成任何混淆,不過防火牆仍然會堅持不懈用複位報文來打斷連接但是由于複位報文都被忽略了所以也沒有用,網頁照樣顯示。

重要的是確定來的兩個SYN/ACK報文誰是真的。在樣例中我們覺得它們很好區分,防火牆版的TTL值大不相同,沒有DF標志,沒有TCP選項。這些僞SYN/ACK在現在爲止還是像僞複位一樣很好過濾的,防火長城再次失效。另外,由于只有封鎖繼發連接時才會使用這種策略,那麽客戶端可以把服務端的TTL記下來,而防火牆是搞不清該往僞報文裏填什麽值的。

不過,防火牆越搞越複雜,說不定就能造出沒法區分的SYN/ACK報文來了。那客戶端直接把第一個收到的SYN/ACK當成防火牆發出的僞報文即可。不過要是防火牆又來時不時來延時一下才發送僞SYN/ACK(讓思維簡單的機器通過,打倒思維複雜的機器!)那麽這場複雜的“博弈”會升級成更深奧的戰略對決。要注意打開網頁常常會有多個連接,那麽防火牆即使只是搞掉其中一部分也會覺得有“勝利感”。

一個高效的客戶端策略(先決條件是客戶端和服務端都丟棄複位報文)是將所有傳入SYN/ACK報文視爲有效(防火牆以後也許會發好幾個過來),然後檢查全部的序列號和確認號直到從服務端收到一個ACK以確認正確的取值。不過這對于像iptables或者ipfw這種簡單的報文過濾系統來說太複雜了,超出實現能力。

新一輪“博弈”也許是防火牆開始針對所有客戶端報文僞造ACK。可能客戶端可以通過檢測從服務端獲得的真正RST來看穿防火牆的整個僞連接,于是防火牆連這些都要開始僞造了──這樣下去策略變得不知道有多複雜。不過終端節點確實有優勢來最終判斷報文是來自(有狀態的)對方還是(無狀態的)防火牆。要是防火牆也開始記錄“狀態”,那麽整個主要架構的變化(雖然一定又是一筆巨大的開支)便會帶來許多其他可用策略,優勢也會決定性地偏向防火牆這邊。

可是必須注意到,防火牆的 SYN/ACK報文僞造問題不能通過改變服務端的TCP/IP棧來安全地解決。那樣的話服務端需要發現客戶端持續地響應的那個“錯誤”的ACK值並改變自身狀態以響應這個從僞SYN/ACK報文中出來的值。但這樣就去掉了一個Bellovin記錄的重要安全步驟,進而導致惡意主機僞造源IP地址訪問的漏洞。[36]

另外,在可以“嗅探”並僞造報文的對手面前進行安全連接,這在密鑰交換協議鄰域已經得到充分研究。未決的問題是,如何利用中國防火牆目前的架構性缺陷,通過對現有TCP/IP棧的簡單修改來戰勝防火長城。

6 拒絕服務攻擊

我們前面提到,單個包含?falun之類內容的TCP報文就足以觸發節點間至多長達一個小時的封鎖。如果僞造源地址,就可以發起(但也是受限的)拒絕服務(Denial of Service)攻擊,阻斷特定節點間的通信。不過不同的人有不同的目標,這對某些攻擊者來說已經足夠。比如,識別並阻止地區政府機構的主機訪問“Windows自動更新”;或者阻止某個部委訪問一個聯合國網站;或者阻止中國海外使館訪問家鄉網站。

我們計算發現,即使是一個人通過單個撥號連接也可以發起相當有效的DoS攻擊。這樣一個人每秒可以産生大約100個觸發性報文,假設封鎖時間大約是20分鍾,那麽120000對節點便可被永久封鎖。當然,現在的DoS攻擊幾乎不會通過單個撥號方式實現,而是在快得多的網絡上以巨大的數量進行。那麽120000便可以乘到你滿意。不過防火牆的IDS組件也許沒有資源記錄如此大量的封鎖連接,所以實際的影響要考慮受到此類資源限制的情況。還要注意當IDS處理DoS攻擊的時候它處理其他連接信息的資源就會變少,于是其效用也就暫時降低。

6.1 DoS攻擊的限制

進一步實驗顯示此防火牆的封鎖方式比我們迄今爲止解釋的還要複雜一些;因此DoS攻擊的效果不一定有剛才那樣說得那麽好。

首先,封鎖只應用于相似端口上的繼發連接。[37]只有端口值前9最高有效位與觸發封鎖的端口對應時,防火牆才會封鎖這一連接,這樣的端口每次有128個。Windows這類系統會連續分配臨時端口,于是平均有64個繼發連接會被封鎖。(有時比如觸發封鎖的端口是4095那麽就不會有繼發封鎖)反之OpenBSD之類的系統會隨機分配臨時端口,于是繼發連接被封鎖的可能性只有1/500。

我們對防火牆的這種行爲沒有確定的解釋。不看端口直接封鎖所有連接似乎還簡單有效許多。[38]這麽做也許是爲了避免誤封NAT後面的其他用戶,或者是用來確定發送某報文的IDS。也許這麽做只是有意要顯得神秘而愈發有威懾力。然而從DoS攻擊者的角度,除非有特殊條件可以預測臨時端口,要讓所有可能端口段都被封鎖所需的報文發送量便增長了500倍。

中国防火墙对?坏?字符串的封锁情况。
图1:中国防火墙对“坏”字符串的封锁情况。

2006年二月上旬我們進行了一次10天的試驗,每小時一次從256個相鄰IP地址進行連接。這裏是前128的結果;其余部分模式也十分相似。黑點表明連接被封鎖,白點表明沒有封鎖,灰點是結果不定(完全沒有響應)。在110小時前後可見防火牆策略的顯著變化(封鎖更多的IP地址)。

其次,並非所有IP地址的流量都被檢測過。我們每小時進行一次突發連接,發送一組256個IP地址連續的含有“?falun”的報文。起初每組報文只有約三分之二被封鎖掉,封掉的地址每次不同。不過幾天之後幾乎所有報文被封鎖。我們無法通過逆向工程確定地址選擇的算法,不過IP地址選擇確有鮮明的模式[39],暗示背後的機制可能相當簡單。最直接的解釋是資源匮乏──流量的三分之二也許就是整個系統可以處理的極限。顯然某些時候如果一部分機器沒有進行報文檢測的工作,DoS攻擊也就不可能通過它們發起。

最終需要注意的就是,這些實驗只是在中國內外的少量節點上進行的,雖然我們得到了足夠一致的結果,但像“防火長城”這種複雜的系統我們還是可能忽略了它的某些重要特性。因此雖然我們認爲DoS攻擊可以在許多情況下成功,我們也不能保證任一節點對上的任一次攻擊都能成功。

 

如何忽略防火長城(一)
如何忽略防火長城(二)

 

來源:譯言    原文    翻譯:萬柳烈士旅

Go Back



Comment

Follow me on Twitter