電信網頁訪問監控原理分析
近段時間，一個在電信上班的朋友經常說，他們有辦法知道一個NAT 網關內部的電腦主機
數，而且能夠記錄里面任何人的上網記錄，聽得我是心癢癢的，可問他方法，他又死活不說，
郁悶。今天比較閑，腦袋里又想起了這事，想來想去，認為電信很可能采用欺騙客戶端的方
法，讓客戶端的信息首先發到監控主機，然后再發到目標服務器。
為證實推斷是否合理，抱著試試的心態，立即在自己的機器上做了以下實驗，步驟如下：
1. 打開機器上的科來網絡分析系統。
2. 添加一個圖1 所示的過濾器，為的是只捕獲我的機器（192.168.0.88）和網關
（00:D0:41:26:3F:9E）以及外網的數據通訊，即不捕獲我與內部網之間的通訊。
（圖1 設置過濾器）
3. 為減少數據干擾，在關閉本機上運用的其它應用程序后，開始捕獲。
4. 在本機上訪問一個網頁，這里以訪問www.colasoft.com 為例。
5. 在頁面出來后，停止捕獲，并開始分析系統捕獲到的數據包。
6. 此次網頁訪問系統共捕獲到了22 個數據包，原始數據包的列表如圖2 所示。
（圖2 原始數據包列表）
從圖2 中可知，編號1,2,3 的數據包是TCP 的三次握手數據包，第4 個數據包是客戶端
192.168.0.88 發起的HTTP GET 請求，后面是服務器端的返回數據。從這些數據包來看，
感覺通訊是正常的，于是切換到矩陣視圖，查看通訊的節點情況，如圖3。
（圖3 訪問www.colasoft.com 的矩陣圖）
在圖3 中，發現了一個奇怪的地址220.167.29.102，由于我此次的操作僅僅只訪問了
www.colasoft.com，所以是不應該出現這個地址的。這個220.167.29.102 引起了我的
注意，會不會這個地址在作怪呢？
7. 再切換到數據包視圖，發現客戶端（192.168.0.88）的確存在和220.167.29.102
的通訊。
奇怪了，為什么192.168.0.88 會主動和220.167.29.102 進行通訊呢，會不會是有人在
偽造數據包呢？為確定是否存在偽造數據包的情況，我強制顯示數據包的IP 層摘要信息，
在圖2 所示的數據包視圖中，單擊右鍵，在彈出的菜單中選擇“數據包摘要->IP 摘要”，
查看這些數據包IP 層的信息，如圖4。
（圖4 通過IP 層摘要查看220.167.29.102 的偽造數據包）
從圖4 可知，TCP 三次握手的服務器返回數據包（編號2）的生存時間是48，而第5 個數
據包的生存時間卻是119，同一個服務器返回的兩個數據包生存時間差別如此之大，表示
它們經過的路由存在較大的差異，這與正常通訊的狀態明顯不符，由此我們懷疑編號為5
的數據包可能是某個主機偽造的。
查看該數據包的解碼（圖4中間，紅色圈住部份），發現該數據包是由220.267.29.102發
起的，這表示220.267.29.102主動向192.168.0.88發起了一個欺騙數據包，雙擊第5個
數據包，打開該數據包的詳細解碼窗口，如圖5。
（圖5 220.167.29.102 偽造的數據包的詳細解碼信息）
從圖5解碼信息中可知，該數據包的TCP標記中，同時將確認位、急迫位、終止位置為1，
這表示這個數據包想急于關閉連接，以防止客戶端（192.168.0.88）收到服務器
（www.colasoft.com）的正常響應，它這樣做的目的是獲取客戶端（192.168.0.88）傳
輸的數據信息，其獲得的信息如圖4中的右下角紅色圈住部份，這是一個base64的編碼信
息，其具體的信息我會在后面進行詳細說明。
8. 由于客戶端（192.168.0.88）被220.167.29.102 偽造的數據包5 欺騙，所以它向
服務器（www.colasoft.com）確認并發送一個關閉連接請求的數據包，也就是第6
和第7 這兩個數據包
9. 第9 和第10 這兩個數據包，也是220.167.29.102 偽造的重置連接數據包，它的目
的是欺騙客戶端（192.168.0.88）關閉連接。
10. 接著，客戶端（192.168.0.88）主動向220.167.29.102 發起TCP 的三次握手，即
第8,11,12 這三個數據包，以和220.167.29.102 建立連接。
11. 13,14,15,17 這幾個數據包，是客戶端（192.168.0.88）和220.167.29.102 之間
的數據通訊。從第15 這個數據包的解碼中，可以清楚地看到220.167.29.102 將重
新將訪問重定向到www.colasoft.com，從而讓客戶端（ 192.168.0.88 ） 向
www.colasoft.com 再次發起頁面訪問請求，以讓客戶端（192.168.0.88）完成正
常的網頁訪問，其解碼如圖6。
（圖6 220.167.29.102 向192.168.0.88 發起的數據包）
12. 16,18,19 是客戶端（192.168.0.88）向服務器（www.colasoft.com）發起三次握
手數據包。
13. 20,21,22 是三次握手成功后，客戶端和服務器正常的HTTP 通訊數據包，也就是傳遞
客戶端所請求的頁面，這里是www.colasoft.com。
14. 查看會話，選擇TCP，發現此次的網頁訪問共連接起了3 個連接，如圖7。這三個連
接的TCP 流重組信息分別如圖7,8,9，通過流的重組信息，我們也可以較為清楚地看
到客戶端和服務器（www.colasoft.com），以及客戶端和220.167.29.102 之間的
數據通訊信息。
（圖7 此次網頁訪問產生的三個TCP 連接及第一個連接的TCP 流信息）
圖7中，客戶端（192.168.0.88）向www.colasoft.com發起GET請求，但從服務器端返
回的數據可知，返回服務器是220.167.29.102，且帶了一串base64編碼的參數，
“ABcHJvdmluY2VpZD04Jm隨機刪除部份
MTIwNDExJnNvdXJjZXVybD13d3cuY29sYXNvZnQuY29tLw==”，
對其進行反編譯后的內容如下：
“provinceid=8&cityid=2&classid=1000541&username=adsl撥號用名
&sourceurl=www.colasoft.com/”
注意：上面的紅色刪除部份和adsl撥號用戶名已經過筆者更改。
這里很清楚了吧，220.167.29.102 主動欺騙客戶端讓客戶端告訴220.167.29.102 自己
的相關信息?？蛻舳嗽谑盏酱苏埱蠛螅?由于不知道被欺騙， 所以它會立即主動和
220.167.29.102 建立連接，并發送相關信息給220.167.29.102，從而導致信息被電信
監控，讓電信可以輕易的知道我們的網頁訪問情況。
（圖8 220.167.29.102 欺騙客戶端的TCP 流信息）
圖8 即客戶端（192.168.0.88）主動向220.167.29.102 發起的連接，并告知其相應的
信息。在圖中的下面我們可以看到，220.167.29.102 在收到相應的信息后，再次強客戶
端的請求重定向到www.coalsoft.com，即用戶需要訪問的頁面。
（圖9 客戶端和www.colasoft.com 第二次連接的TCP 流信息）
圖9 即是客戶端在被220.167.29.102 欺騙后，再次向www.colasoft.com 發起GET 請
求，且服務器正常返回數據的信息，這讓電信在不知不覺中完成了對用戶網頁訪問的監控。
至此，訪問www.colasoft.com 的過程全部分析完畢。從該分析中，我們明白了電信監控
我們普通用戶訪問網頁的具體方法，其訪問流程如圖10 所示。
（圖10 客戶端實際的訪問流程圖）
1. 客戶端主機（192.168.0.88）向www.colasoft.com 發起正常的訪問網頁請求。
2. 監控服務器（這里是220.167.29.102，不同地方該服務器可能不同）就立刻向客戶
端發起一個偽造數據包，這個數據包的源地址被偽造成客戶端請求的服務器地址，同時
該數據包的內容是預先設定好的。
3. 客戶端主機在收到該數據包后，以為是服務器端返回的，于是它根據收到的偽造數據包
的要求，主動向220.167.29.102 發起連接，并向220.167.29.102 傳輸一些客戶
端的私人敏感信息，如客戶端的撥號用戶名、訪問的網址、NAT 內網主機數等信息。
4. 220.167.29.102 再次將訪問重定向的指令發給192.168.0.88。
5. 客戶端根據第4 步中收到的指令，再次向www.colasoft.com 發起正常的訪問網頁請
求。
6. www.coalsoft.com 將客戶端請求的頁面傳給客戶端（192.168.0.88），讓客戶端成
功完成網頁訪問。
以上便是電信網頁訪問監控原理的簡單分析過程，注意實驗的環境是內部通過NAT 方式，
并使用ADSL 撥號上網，對于其它的連接方式以及其它的ISP 接入，由于沒有相應的環境，
并未進行測試。
CSNA 網絡分析論壇 菜鳥人飛
2006 年4 月21 日