軟體 - 電信網頁訪問監控原理分析！

[psac]

近段時間，一個在電信上班的朋友經常說，他們有辦法知道一個NAT網關內部的電腦主機數，而且能夠記錄裡面任何人的上網記錄，聽得我是心癢癢的，可問他方法，他又死活不說，鬱悶。今天比較閒，腦袋裡又想起了這事，想來想去，認為電信很可能採用欺騙客戶端的方法，讓客戶端的訊息首先發到監控主機，然後再發到目標服務器。
為證實推斷是否合理，抱著試試的心態，立即在自己的機器上做了以下實驗，步驟如下：
1.打開機器上的科來網路分析系統。
2.新增一個圖1所示的過濾器，為的是只捕獲我的機器（192.168.0.88）和網關（00: D0:41:26:3F:9E）以及外網的資料通訊，即不捕獲我與內部網之間的通訊。
附加檔案 31
（圖1　設置過濾器）
3.為減少資料干擾，在關閉本機上運用的其它應用程式後，開始捕獲。
4.在本機上訪問一個網頁，這裡以訪問www.colasoft.com為例。
5.在網頁面出來後，停止捕獲，並開始分析系統捕獲到的資料包。
6.此次網頁訪問系統共捕獲到了22個資料包，原始資料包的列表如圖2所示。
附加檔案 32
（圖2　原始資料包列表）
從圖2中可知，編號1,2,3的資料包是TCP的三次握手資料包，第4個資料包是客戶端192.168.0.88發起的HTTP GET請求，後面是服務器端的返回資料。從這些資料包來看，感覺通訊是正常的，於是切換到矩陣視圖，檢視通訊的節點情況，如圖3。
附加檔案 33
（圖3　訪問www.colasoft.com的矩陣圖）
在圖3中，發現了一個奇怪的地址220.167.29.102，由於我此次的操作僅僅只訪問了http://www.colasoft.com，所以是�...��作怪呢？



7.再切換到資料包視圖，發現客戶端（192.168.0.88）的確存在和220.167.29.102的通訊。
奇怪了，為什麼192.168.0.88會主動和220.167.29.102進行通訊呢，會不會是有人在偽造資料包呢？為確定是否存在偽造資料包的情況，我強制顯示資料包的IP層摘要訊息，在圖2所示的資料包視圖中，單擊右鍵，在彈出的表菜單中選擇「資料包摘要->IP摘要」，檢視這些資料包IP層的訊息，如圖4。
附加檔案 34
（圖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。
附加檔案 35
（圖5　220.167.29.102偽造的資料包的詳細解碼訊息）




從圖5解碼訊息中可知，該資料包的TCP標記中，同時將確認位、急迫位、終止位置為1，這表示這個資料包想急於關閉連接，以防止客戶端（192.168.0.88）收到服務器（http://www.colasoft.com）的正常�...��細說明。
8.由於客戶端（192.168.0.88）被220.167.29.102偽造的資料包5欺騙，所以它向服務器（http://www.colasoft.com）確認並�...��個資料包
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將重新將訪問重定向到http://www.colasoft.com，從而讓�...�碼如圖6。


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之間的資料通訊訊息。
附加檔案 37
（圖7　此次網頁訪問產生的三個TCP連接及第一個連接的TCP流訊息）
圖7中，客戶端（192.168.0.88）向http://www.colasoft.com發起GET請�...��的參數， 「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，即用戶需要訪問的網頁面。
附加檔案 39
（圖9　客戶端和www.colasoft.com第二次連接的TCP流訊息）
圖9即是客戶端在被220.167.29.102欺騙後，再次向http://www.colasoft.com發起GET請�...��的監控。


至此，訪問http://www.colasoft.com的過程全�...圖10所示。
附加檔案 40
（圖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.http://www.coalsoft.com將客戶端�...��頁訪問。
以上便是電信網頁訪問監控原理的簡單分析過程，注意實驗的環境是內部通過NAT方式，並使用ADSL撥號上網，對於其它的連接方式以及其它的ISP接入，由於沒有相應的環境，並未進行測試。

不知道有什麼辦法可以反追蹤啊， 哪位知道說說咯。
在公司的防火牆設定規則，封掉電信監控主機的IP和連接阜，這樣局域網內部的客戶端無法連接電信監控主機
如果防火牆夠高階，能夠封掉偽造資料包，那就更棒。
封掉偽造資料包可以有兩種方式：
1、檢查HTTP flow中異常的TTL變化，缺點是：可能也會不小心封掉一些多路由返回的資料包，但是這種情況很少，而且TCP支持重傳
2、檢查HTTP flow中前幾個資料包，進行模式匹配，封掉包含特定字元串的資料包（比如電信監控主機IP地址），缺點是：可能比較消耗資源，出現性能問題。

內網的主機怎麼把內網的機器數傳遞出去,很難理解
具體內部是如何實現的不太清楚
但是從前面抓包的訊息來看，如果之前客戶端沒有發送cookie給電信監控主機，電信監控主機會push一個新的cookie給客戶端，也就是說它至少可以cookie來檢查內部的主機數量。
不過可能還會結合其他一些技術。


如果用戶通過HTTPS方式訪問外網服務器，電信只能知道用戶訪問的是哪個IP或域名；如果用戶再通過代理服務器訪問外網的話，電信就不知道用戶訪問的地址了！是嗎！呵呵！
是的，如果通過架設在國外的SSL加密代理訪問Internet，不但可以突破本機電信的監控，還可以突破The great firewall of China