（轉）深入理解GFW：DNS污染

初識DNS污染

翻牆新手們往往遇到這樣的問題：我明明已經設置了socks代理為127.0.0.1:xxxx，為什麼還是上不去youtube？這時經驗豐富的翻牆高手就會告訴你：firefox需要設置network.proxy.socks_remote_dns為true，也就是遠程解析網域。這是怎樣一回事呢？為什麼要遠程解析？這就涉及到了GFW的DNS污染技術。

DNS（Domain Name System）污染是GFW的一種讓一般用戶由於得到虛假目標主機IP而不能與其通信的方法，是一種DNS緩存投毒攻擊（DNS cache poisoning）。其工作方式是：對經過GFW的在UDP連線埠53上的DNS查詢進行入侵檢測，一經發現與關鍵詞相匹配的請求則立即偽裝成目標網域的解析伺服器（NS，Name Server）給查詢者返回虛假結果。由於通常的DNS查詢沒有任何認證機制，而且DNS查詢通常基於的UDP是無連接不可靠的協議，查詢者只能接受最先到達的格式正確結果，並丟棄之後的結果。對於不了解相關知識的網民來說也就是，由於系統默認使用的ISP提供的NS查詢國外的權威伺服器時被劫持，其緩存受到污染，因而默認情況下查詢ISP的伺服器就會獲得虛假IP；而用戶直接查詢境外NS（比如OpenDNS）又可能被GFW劫持，從而在沒有防範機制的情況下仍然不能獲得正確IP。然而對這種攻擊有著十分簡單有效的應對方法：修改hosts文件。但是Hosts文件的條目一般不能使用通配符（例如*.blogspot.com），而GFW的DNS污染對網域匹配進行的是部分匹配不是精確匹配，因此Hosts文件也有一定的局限性，網民試圖訪問這類網域仍會遇到很大麻煩。

觀測DNS污染

｢知己知彼，百戰不殆｣。這一節我們需要用到前面提到的報文監聽工具，以及參考其DNS劫持診斷一節。在Wireshark的filter一欄輸入udp.port eq 53可以方便地過濾掉其他無關報文。為了進一步減少干擾，我們選擇一個並沒有提供網域解析服務的國外IP作為目標網域解析伺服器，例如129.42.17.103。運行命令nslookup -type=A www.youtube.com 129.42.17.103。如果有回答，只能說明這是GFW的偽造回答，也就是我們要觀測和研究的對象。

偽包特徵

經過一番緊密的查詢，我們可以發現GFW返回的IP取自如下列表：

4.36.66.178
203.161.230.171
211.94.66.147
202.181.7.85
202.106.1.2
209.145.54.50
216.234.179.13
64.33.88.161

關於這八個特殊IP，鼓勵讀者對這樣兩個問題進行探究：1、為什麼是特定的IP而不是隨機IP，固定IP和隨機IP各自有什麼壞處；2、為什麼就是這8個IP不是別的IP，這8個IP為什麼倒了GFW的霉？關於搜尋這類信息，除了www.google.com之外，www.bing.com有專門的搜尋IP對應網站的功能，使用方法是輸入ip:IP地址搜尋。www.robtex.com則是一個專門收集網域解析信息的網站。歡迎讀者留下自己的想法和發現:lol:。

從Wireshark收集到的結果分析（實際上更好的辦法是，將結果保存為pcap文件，或者直接使用tcpdump，由tcpdump顯示成文本再自行提取數據得到統計），我們將GFW發送的DNS污染包在IP頭部的指紋特徵分為兩類：

一型：
ip_id == ____（是一個固定的數，具體數值的查找留作習題）。
沒有設置｢不分片｣選項。
沒有設置服務類型。
對同一對源IP、目標IP，GFW返回的污染IP在上述8個中按照給出的順序循環。與源連線埠無關、與源IP目標IP對相關。
TTL返回值比較固定。TTL為IP頭部的｢Time to Live｣值，每經過一層路由器這個值會減1，TTL為1的IP包路由器將不再轉發，多數路由器會返回源IP一條｢ICMP time to live exceed in transit｣消息。

二型：
每個包重複發送3次。
沒有設置｢不分片｣選項。
設置了｢保障高流量｣服務類型。
(ip_id + ? * 13 + 1) % 65536 == 0，其中?為一個有趣的未知數。ip_id在同一個源IP、目標IP對的連續查詢之間以13為單位遞減、觀測到的ip_id的最小值和最大值分別為65525（即-11，溢出了!）和65535。
對同一對源IP、目標IP，GFW返回的污染IP在上述8個中按照給出的順序循環。與源連線埠無關、與源IP目標IP對相關。
對同一對源IP、目標IP，TTL返回值時序以1為單位遞增。TTL在GFW發送時的取值有64種。註：源IP接收到的包的TTL被路由修改過，所以用戶觀測到的TTL不一定只有64種取值，這是由於網路拓撲變化的原因導致的。一型中的｢比較固定｣的｢比較｣二字也是考量到網路拓撲偶爾的變化而添加的，也許可以認為GFW發送時的初始值是恆定的。

（以上結果僅保證真實性，不保證時效性，GFW的特徵隨時有可能改變，尤其是時序特徵與傳輸層特徵相關性方面。最近半年GFW的特徵在很多方面的變化越來越頻繁，在將來介紹TCP阻斷時我們會提到。）

還可以進行的實驗有：由於當前二型的TTL變化範圍是IP個數的整數倍，通過控制DNS查詢的TTL使得恰好有GFW的返回（避免動態路由造成的接收者觀察到的TTL不規律變化），觀察IP和TTL除以8的余數是否有對應關係，在更改源IP、目標IP對之後這個關係是否仍然成立。這關係到的GFW負載平衡演算法及響應計數器（hit counter）的獨立性和一致性。事實上對GFW進行窮舉給出所有關於GFW的結果也缺乏意義，這裡只是提出這樣的研究方法，如果讀者感興趣可以繼續探究。

每次查詢通常會得到一個一型包和三個完全相同的二型包。更換查詢命令中type=A為type=MX或者type=AAAA或者其它類型，可以看到nslookup提示收到了損壞的回復包。這是因為GFW的DNS污染模組做得十分粗製濫造。GFW偽造的DNS應答的ANSWER部分通常只有一個RR組成（即一條記錄），這個記錄的RDATA部分為那8個污染IP之一。對於二型，RR記錄的TYPE值是從用戶查詢之中直接複製的。於是用戶就收到了如此奇特的損壞包。DNS響應包的UDP荷載內容特徵：

一型
DNS應答包的ANSWER部分的RR記錄中的網域部分由0xc00c指代被查詢網域。
RR記錄中的TTL設置為5分鐘。
無論用戶查詢的TYPE是什麼，應答包的TYPE總是設置為A（IPv4地址的意思）、CLASS總是設置為IN。
二型
DNS應答包的ANSWER部分的RR記錄中的網域部分是被查詢網域的全文。
RR記錄中的TTL設置為1天。
RR記錄中的TYPE和CLASS值是從源IP發送的查詢複製的。

其中的術語解釋：RR = Resource Record：dns數據包中的一條記錄；RDATA = Resource Data：一條記錄的數據部分；TYPE：查詢的類型，有A、AAAA、MX、NS等；CLASS：一般為IN[ternet]。
觸發條件

實際上DNS還有TCP協議部分，實驗發現，GFW還沒有對TCP協議上的DNS查詢進行劫持和污染。匹配規則方面，GFW進行的是子串匹配而不是精確匹配，並且GFW實際上是先將網域轉換為字元串進行匹配的。這一點值得特殊說明的原因是，DNS中網域是這樣表示的：一個整數n1代表以｢.｣作分割最前面的部分的長度，之後n1個字母，之後又是一個數字，若干字母，直到某次的數字為0結束。例如www.youtube.com則是"\x03www\x07youtube\x03com\x00"。因此，事實上就可以觀察到，對www.youtube.coma的查詢也被劫持了。
現狀分析

4.36.66.178，關鍵詞。whois：Level 3 Communications, Inc. 位於Broomfield, CO, U.S.
203.161.230.171，關鍵詞。whois：POWERBASE-HK位於Hong Kong, HK.
211.94.66.147，whois：China United Network Communications Corporation Limited位於Beijing, P.R. China.
202.181.7.85，關鍵詞。whois：First Link Internet Services Pty Ltd.位於North Rocks, AU.
202.106.1.2,whois：China Unicom Beijing province network位於Beijing, CN.
209.145.54.50，反向解析為dns1.gapp.gov.cn，新聞出版總署的網域解析伺服器？目前dns1.gapp.gov.cn現在是219.141.187.13在bjtelecom。whois：World Internet Services位於San Marcos, CA, US.
216.234.179.13，關鍵詞。反向解析為IP-216-234-179-13.tera-byte.com。whois：Tera-byte Dot Com Inc.位於Edmonton, AB, CA.
64.33.88.161，反向解析為tonycastro.org.ez-site.net, tonycastro.com, tonycastro.net, thepetclubfl.net。whois：OLM,LLC位於Lisle, IL, U.S.

可見上面的IP大多數並不是中國的。如果有網站架設到了這個IP上，全中國的Twitter、Facebook請求都會被定向到這裡——好在GFW還有HTTP URL關鍵詞的TCP阻斷——HTTPS的請求才構成對目標IP的實際壓力，相當於中國網民對這個IP發起DDoS攻擊，不知道受害網站、ISP是否有索賠的打算？

我們嘗試用bing.com的ip反向搜尋功能搜尋上面那些DNS污染專用IP，發現了一些有趣的網域。顯然，這些網域都是DNS污染的受害網域。

例如倒霉的edoors.cn.china.cn，寧波中國門業網，其實是因為edoors.cn被dns污染。一起受害的還有chasedoors.cn.china.cn，美國蔡斯門業（深圳）有限公司。
還有*.sf520.com，似乎是一個國內的遊戲私服網站。www.sf520.com也是一個私服網站。可見國內行政體系官商勾結之嚴重，一個｢國家信息安全基礎設施｣竟然還會用來保護一些網遊公司的利益。
此外還有一些個人blog。www.99tw.net也是一個遊戲網站。
還有www.why.com.cn，名字起得好。
還有www.999sw.com 廣東上九生物降解塑料有限公司生物降解樹脂|增粘母料|高效保水濟|防洪 郵遞區號:523128……這又是怎麼一回事呢？不像是被什麼反動網站連坐的。還有人問怎麼回事怎麼會有那麼多IP結果。
www.facebook.comwww.xiaonei.com，怎麼回事呢？其實是因為有人不小心把兩個地址連起來了，搜尋引擎以為這是一個鏈接，其實這個網域不存在，但是解析的時候遭到了污染，就以為存在這個網域了。
倒霉的www.xinsheng.net.cn——武漢市新勝電腦有限公司，因為www.xinsheng.net被連坐。

DNS劫持的防範和利用

之前我們已經談到，GFW是一套入侵檢測系統，僅對流量進行監控，暫沒有能力切斷網路傳輸，其｢阻斷｣也只是利用網路協議容易被會話劫持（Session hijacking）的弱點來進行的。使用無連接UDP的DNS查詢只是被GFW搶答了，真正的答案就跟在後面。於是應對GFW這種攻擊很自然的想法就是：

根據時序特性判斷真偽，忽略過早的回復。

通常情況對於分別處於GFW兩端的IP，其RTT（Round-trip time，往返延遲）要大於源IP到GFW的RTT，可以設法統計出這兩個RTT的合適的均值作為判斷真偽的標準。另外由於GFW對基於TCP的DNS請求沒有作處理，於是可以指定使用TCP而不是UDP解析網域。也可以通過沒有部署GFW的線路到沒有被DNS污染的NS進行查詢，例如文章一開始提到的｢遠程解析｣。但黑體字標出的兩個條件缺一不可，例如網上廣為流傳的OpenDNS可以反DNS劫持的說法是以訛傳訛，因為到OpenDNS伺服器的線路上是經由GFW的。

本質的解決辦法是給DNS協議增加驗証機制，例如DNSSEC（Domain Name System Security Extensions），客戶端進行遞歸查詢（Recursive Query）而不查詢已經被污染了的遞歸解析伺服器（Recursive/caching name server）。然而缺點是目前並非所有的權威網域解析伺服器（Authoritative name server）都支持了DNSSEC。Unbound提供了一個這樣的帶DNSSEC驗証機制的遞歸解析程序。

另外GFW的DNS劫持還可能被駭客利用、帶來對國際國內網際網路的嚴重破壞。一方面，GFW可能在一些緊急時刻按照｢國家安全｣的需要對所有DNS查詢都進行污染，且可能指定污染後的IP為某個特定IP，使得全球網路流量的一部分直接轉移到目標網路，使得目標網路立刻癱瘓。當然我們偉大的祖國鄭重承諾｢不率先使用核武器｣…另一方面，GFW將偽造的DNS返回包要發送給源IP地址的源連線埠，如果攻擊者偽造源IP，會怎樣呢？將會導致著名的增幅攻擊：十倍於攻擊者發送DNS查詢的流量將會返回給偽源IP，如果偽源IP的連線埠上沒有開啟任何服務，很多安全配置不嚴的系統就需要返回一條ICMP Port Unreachable消息，並且將收到的信息附加到這條ICMP信息之後；如果偽源IP的連線埠上開啟了服務，大量的非法UDP數據湧入將使得偽源IP該連線埠提供的服務癱瘓。如果攻擊者以1Gbps的速度進行查詢，一個小型IDC（DNSpod被攻擊事件）甚至一個地域的ISP也會因此癱瘓（暴風影音事件）。攻擊者還可能設置TTL使得這些流量恰好通過GFW產生劫持響應，並在到達實際目標之前被路由丟棄，實現流量｢空對空不落地｣。攻擊者還可能將攻擊流量的目標IP設置偽造成與偽源IP有正常通信或者其他關聯的IP，更難以識別。這樣實際上就將一個國家級防火牆變成了一個國家級反射放大式拒絕服務攻擊跳板。

最為嚴重的是，這種攻擊入門難度極低，任何一個會使用C語言編程的人只要稍微閱讀libnet或者libpcap的文檔，就可能在幾天之內寫出這樣的程序。而GFW作為一套入侵防禦系統，註定缺乏專門防範這種攻擊的能力，因為如果GFW選擇性忽略一些DNS查詢不進行劫持，網民就有機可乘利用流量掩護來保證真正的DNS通信不被GFW污染。尤其是UDP這樣一種無連接的協議，GFW更加難以分析應對。｢反者道之動，弱者道之用。｣

參考文獻

閆伯儒, 方濱興, 李斌, 王垚. "DNS欺騙攻擊的檢測和防範". 計算機工程, 32(21):130-132,135. 2006-11.
Graham Lowe, Patrick Winters, Michael L. Marcus. The Great DNS Wall of China. 註：這篇文章雖然試圖通過統計特性了解GFW，但由於實驗條件控制不佳、實驗結果觀察不細緻，加上缺乏對GFW的整體觀，故沒有提供什麼有意義的結論。然而美國同學的這種科學態度與實驗精神值得我們學習和思考。事實上，這篇文章仍然提供了珍貴的歷史資料，讀者不妨按照本文邏輯來分析這篇參考文獻。閱讀過這篇文獻的敏感的讀者還將在我們後續的文章中看到熟悉的數字。
KLZ畢業. 入侵防禦系統的評測和問題. 註：本文對DNS污染包的分類就是從這篇文章的分類繼承而來。