電信服務商監(jiān)控并記錄網(wǎng)民上網(wǎng)記錄

1、電信服務商監(jiān)控并記錄網(wǎng)民上網(wǎng)記錄電信服務商監(jiān)控并記錄網(wǎng)民上網(wǎng)記錄原理分析及案例分析近段時間，一個在電信上班的朋友經(jīng)常說，他們有辦法知道一個NAT網(wǎng)關內(nèi)部的電腦主機數(shù)，而且能夠記錄里面任何人的上網(wǎng)記錄，聽得我是心癢癢的，可問他方法，他又死活不說，郁悶。今天比較閑，腦袋里又想起了這事，想來想去，認為電信很可能采用欺騙客戶端的方法，讓客戶端的信息首先發(fā)到監(jiān)控主機，然后再發(fā)到目標服務器。為證實推斷是否合理，抱著試試的心態(tài)，立即在自己的機器上做了以下實驗，步驟如下：1.打開機器上的科來網(wǎng)絡分析系統(tǒng)。2.添加一個圖1所示的過濾器，為的是只捕獲我的機器（）和網(wǎng)關（00: D0:41:26:3F:9E）以及外

2、網(wǎng)的數(shù)據(jù)通訊，即不捕獲我與內(nèi)部網(wǎng)之間的通訊。（圖1設置過濾器）3.為減少數(shù)據(jù)干擾，在關閉本機上運用的其它應用程序后，開始捕獲。4.在本機上訪問一個網(wǎng)頁，這里以訪問為例。5.在頁面出來后，停止捕獲，并開始分析系統(tǒng)捕獲到的數(shù)據(jù)包。6.此次網(wǎng)頁訪問系統(tǒng)共捕獲到了22個數(shù)據(jù)包，原始數(shù)據(jù)包的列表如圖2所示。（圖2原始數(shù)據(jù)包列表）從圖2中可知，編號1,2,3的數(shù)據(jù)包是TCP的三次握手數(shù)據(jù)包，第4個數(shù)據(jù)包是客戶端發(fā)起的HTTP GET請求，后面是服務器端的返回數(shù)據(jù)。從這些數(shù)據(jù)包來看，感覺通訊是正常的，于是切換到矩陣視圖，查看通訊的節(jié)點情況，如圖3。（圖3訪問的矩陣圖）在圖3中，發(fā)現(xiàn)了一個奇怪的地址，由于我此

3、次的操作僅僅只訪問了，所以是不應該出現(xiàn)這個地址的。這個引起了我的注意，會不會這個地址在作怪呢？7.再切換到數(shù)據(jù)包視圖，發(fā)現(xiàn)客戶端（）的確存在和的通訊。奇怪了，為什么會主動和進行通訊呢，會不會是有人在偽造數(shù)據(jù)包呢？為確定是否存在偽造數(shù)據(jù)包的情況，我強制顯示數(shù)據(jù)包的IP層摘要信息，在圖2所示的數(shù)據(jù)包視圖中，單擊右鍵，在彈出的菜單中選擇“數(shù)據(jù)包摘要->IP摘要”，查看這些數(shù)據(jù)包IP層的信息，如圖4。（圖4通過IP層摘要查看的偽造數(shù)據(jù)包）從圖4可知，TCP三次握手的服務器返回數(shù)據(jù)包（編號2）的生存時間是48，而第5個數(shù)據(jù)包的生存時間卻是119，同一個服務器返回的兩個數(shù)據(jù)包生存時間差別如此之大，表

4、示它們經(jīng)過的路由存在較大的差異，這與正常通訊的狀態(tài)明顯不符，由此我們懷疑編號為5的數(shù)據(jù)包可能是某個主機偽造的。查看該數(shù)據(jù)包的解碼（圖4中間，紅色圈住部份），發(fā)現(xiàn)該數(shù)據(jù)包是由發(fā)起的，這表示主動向發(fā)起了一個欺騙數(shù)據(jù)包，雙擊第5個數(shù)據(jù)包，打開該數(shù)據(jù)包的詳細解碼窗口，如圖5。（圖5偽造的數(shù)據(jù)包的詳細解碼信息）從圖5解碼信息中可知，該數(shù)據(jù)包的TCP標記中，同時將確認位、急迫位、終止位置為1，這表示這個數(shù)據(jù)包想急于關閉連接，以防止客戶端（）收到服務器（）的正常響應，它這樣做的目的是獲取客戶端（）傳輸?shù)臄?shù)據(jù)信息，其獲得的信息如圖4中的右下角紅色圈住部份，這是一個base64的編碼信息，其具體的信息我會在后面

5、進行詳細說明。8.由于客戶端（）被偽造的數(shù)據(jù)包5欺騙，所以它向服務器（）確認并發(fā)送一個關閉連接請求的數(shù)據(jù)包，也就是第6和第7這兩個數(shù)據(jù)包9.第9和第10這兩個數(shù)據(jù)包，也是偽造的重置連接數(shù)據(jù)包，它的目的是欺騙客戶端（）關閉連接。10.接著，客戶端（）主動向發(fā)起TCP的三次握手，即第8,11,12這三個數(shù)據(jù)包，以和建立連接。11.13,14,15,17這幾個數(shù)據(jù)包，是客戶端（）和之間的數(shù)據(jù)通訊。從第15這個數(shù)據(jù)包的解碼中，可以清楚地看到將重新將訪問重定向到，從而讓客戶端（）向再次發(fā)起頁面訪問請求，以讓客戶端（）完成正常的網(wǎng)頁訪問，其解碼如圖6。（圖6向發(fā)起的數(shù)據(jù)包）12.  &

6、#160;     16,18,19是客戶端（）向服務器（）發(fā)起三次握手數(shù)據(jù)包。13.        20,21,22是三次握手成功后，客戶端和服務器正常的HTTP通訊數(shù)據(jù)包，也就是傳遞客戶端所請求的頁面，這里是。14.        查看會話，選擇TCP，發(fā)現(xiàn)此次的網(wǎng)頁訪問共連接起了3個連接，如圖7。這三個連接的TCP流重組信息分別如圖7,8,9，通過流的重組信息，我們也可以較為清楚地

7、看到客戶端和服務器（），以及客戶端和之間的數(shù)據(jù)通訊信息。（圖7此次網(wǎng)頁訪問產(chǎn)生的三個TCP連接及第一個連接的TCP流信息）圖7中，客戶端（）向發(fā)起GET請求，但從服務器端返回的數(shù)據(jù)可知，返回服務器是，且?guī)Я艘淮産ase64編碼的參數(shù)， “ABcHJvdmluY2VpZD04Jm隨機刪除部份MTIwNDExJnNvdXJjZXVybD13d3cuY29sYXNvZnQuY29tLw=”，對其進行反編譯后的內(nèi)容如下：“provinceid=8&cityid=2&classid=1000541&username=adsl撥號用名&sourceurl=注意：上面的紅色刪

8、除部份和adsl撥號用戶名已經(jīng)過筆者更改。這里很清楚了吧，主動欺騙客戶端讓客戶端告訴自己的相關信息。客戶端在收到此請求后，由于不知道被欺騙，所以它會立即主動和建立連接，并發(fā)送相關信息給，從而導致信息被電信監(jiān)控，讓電信可以輕易的知道我們的網(wǎng)頁訪問情況。（圖8欺騙客戶端的TCP流信息）圖8即客戶端（）主動向發(fā)起的連接，并告知其相應的信息。在圖中的下面我們可以看到，在收到相應的信息后，再次強客戶端的請求重定向到，即用戶需要訪問的頁面。（圖9客戶端和第二次連接的TCP流信息）圖9即是客戶端在被欺騙后，再次向發(fā)起GET請求，且服務器正常返回數(shù)據(jù)的信息，這讓電信在不知不覺中完成了對用戶網(wǎng)頁訪問的監(jiān)控。至此

9、，訪問的過程全部分析完畢。從該分析中，我們明白了電信監(jiān)控我們普通用戶訪問網(wǎng)頁的具體方法，其訪問流程如圖10所示。（圖10客戶端實際的訪問流程圖）1.客戶端主機（）向發(fā)起正常的訪問網(wǎng)頁請求。2.監(jiān)控服務器（這里是，不同地方該服務器可能不同）就立刻向客戶端發(fā)起一個偽造數(shù)據(jù)包，這個數(shù)據(jù)包的源地址被偽造成客戶端請求的服務器地址，同時該數(shù)據(jù)包的內(nèi)容是預先設定好的。3.客戶端主機在收到該數(shù)據(jù)包后，以為是服務器端返回的，于是它根據(jù)收到的偽造數(shù)據(jù)包的要求，主動向發(fā)起連接，并向傳輸一些客戶端的私人敏感信息，如客戶端的撥號用戶名、訪問的網(wǎng)址、NAT內(nèi)網(wǎng)主機數(shù)等信息。再次將訪問重定向的指令發(fā)給。5.客戶端根據(jù)第4步中收到的指令，再