王春苗 劉玥

摘要：本文基于實際發(fā)生的案例，介紹了在全國會計中級無紙化考試考前調(diào)試過程中，出現(xiàn)的考生端程序訪問服務(wù)端程序持續(xù)處于嚴(yán)重“卡頓”狀態(tài)的問題。文章針對出現(xiàn)的網(wǎng)絡(luò)訪問和Web應(yīng)用故障進行逐步分析和思考，并結(jié)合Wireshark、BurpSuite和tcpdump等工具軟件進行綜合調(diào)試，通過BurpSuite記錄了Web瀏覽器運行“加載項”列表內(nèi)容是后臺進程的全部數(shù)據(jù)訪問請求，并在此基礎(chǔ)上繼續(xù)通過tcpdump程序驗證TCP協(xié)議SYN連接超時和重發(fā)時間間隔機制，從而找出故障發(fā)生的原因和原理，并最終解決問題。

關(guān)鍵詞：Wireshark;BurpSuite;代理偵聽;加載項;tcpdump;SYN超時

中圖分類號：G642? ? ? ? 文獻(xiàn)標(biāo)識碼：A

文章編號：1009-3044（2021）18-0017-03

開放科學(xué)（資源服務(wù)）標(biāo)識碼（OSID）：

B/S架構(gòu)的Web應(yīng)用程序開發(fā)過程中，常常調(diào)用Web瀏覽器來完成向服務(wù)端的訪問請求。此時，如果Web瀏覽器本身由于種種原因出現(xiàn)問題，那么對Web應(yīng)用程序的排障將是一個很大的挑戰(zhàn)。Burpsuite是Web滲透測試領(lǐng)域的“利器”，利用它可以實現(xiàn)對Web瀏覽器的所有數(shù)據(jù)訪問過程的監(jiān)控甚至修改，而tcpdump則是一個全方位的數(shù)據(jù)包捕獲和分析程序。結(jié)合BurpSuite和tcpdump，可以輕松實現(xiàn)對Web應(yīng)用程序進行故障分析研究，并得出最佳的解決方案。

1 問題場景和故障現(xiàn)象描述

會計中級機考采用B/S網(wǎng)絡(luò)架構(gòu)，考試服務(wù)端和所有考場機房都位于互聯(lián)互通的三層交換網(wǎng)絡(luò)，考試客戶端軟件后臺通過調(diào)用IE瀏覽器的方式來訪問考試服務(wù)器的Web服務(wù)，并實現(xiàn)對桌面的鎖屏以防止切換，考試主管部門要求正式考試時必須斷開考場機房的互聯(lián)網(wǎng)連接。

在考前調(diào)試過程中，當(dāng)配置出口防火墻策略關(guān)閉考場機房到互聯(lián)網(wǎng)的連接通道后，發(fā)現(xiàn)所有考場運行考試客戶端軟件時，均出現(xiàn)卡頓和白屏現(xiàn)象，等待大約15秒，方才出現(xiàn)考生登錄輸入框界面，登錄成功后，在模擬考試的過程中，也頻繁出現(xiàn)卡頓現(xiàn)象;當(dāng)重新配置出口防火墻策略允許考場機房到互聯(lián)網(wǎng)的連接后，再次重新打開考試客戶端軟件，此時登錄輸入框界面快速顯示無延遲現(xiàn)象，登錄成功后，再次模擬考試，此時操作流暢且無卡頓現(xiàn)象。

2 故障分析研究

當(dāng)斷開考場的互聯(lián)網(wǎng)連接時，考試客戶端訪問服務(wù)端出現(xiàn)嚴(yán)重卡頓，而允許考場機房訪問互聯(lián)網(wǎng)時，考試客戶端訪問服務(wù)端一切正常。那么首先排除內(nèi)網(wǎng)服務(wù)器故障的可能性，猜測客戶機系統(tǒng)存在某個進程持續(xù)嘗試訪問互聯(lián)網(wǎng)，網(wǎng)絡(luò)斷開時，該進程頻繁訪問失敗，導(dǎo)致考試客戶端產(chǎn)生嚴(yán)重卡頓現(xiàn)象。那么如何才能找出這個進程，這是問題的焦點所在。

2.1 首先檢測客戶機系統(tǒng)是否感染了病毒

檢查內(nèi)容包括進程占用CPU情況、進程占用內(nèi)存大小情況、本地硬盤是否頻繁讀寫以及使用新版殺毒軟件掃描考試客戶端軟件和全盤掃描查殺等。通過實測，基本可以排除客戶機系統(tǒng)感染病毒的可能性。

2.2 猜測考試客戶端軟件是否存在訪問官方服務(wù)器的行為

考試服務(wù)端和考試客戶端都位于三層交換內(nèi)部網(wǎng)絡(luò)，從這個角度分析，考試客戶端沒有必要訪問考試承辦公司位于公網(wǎng)的服務(wù)器。通過木馬專殺類工具程序?qū)嶋H檢測考試客戶端，沒有發(fā)現(xiàn)此類“后門”;另外，通過和考試承辦公司技術(shù)工程師反復(fù)溝通后，確認(rèn)考試客戶端不存在訪問官方服務(wù)器的代碼;同時，經(jīng)過咨詢其他考點學(xué)校，得知并沒有發(fā)生此類故障現(xiàn)象;

2.3 TCP數(shù)據(jù)包捕獲和分析

排除了上述2.1和2.2的可能性后，依然可以猜測該進程存在訪問互聯(lián)網(wǎng)的行為，那么嘗試通過抓包獲得線索。在客戶機上啟動Wireshark抓包軟件并設(shè)置偵聽網(wǎng)卡和開啟抓包，然后打開考試客戶端軟件，等待登錄窗口界面出現(xiàn)后停止抓包。由于捕獲的數(shù)據(jù)包較多，需要應(yīng)用篩選過濾才能得到有用的數(shù)據(jù)包，篩選過濾表達(dá)式如下：

！（ip.addr == 192.168.104.249 or ip.addr == 192.168.10.1 or ip.addr == 192.168.7.84 or ip.addr == 192.168.72.255 or ip.addr == 224.0.0.252 or ipv6 or arp or lldp）

過濾表達(dá)式去除了當(dāng)前內(nèi)網(wǎng)環(huán)境的3個內(nèi)網(wǎng)服務(wù)器IP地址、一個廣播地址、一個組播地址、IPv6協(xié)議和LLDP協(xié)議，然后進行排序，顯示結(jié)果如圖1所示：

抓包結(jié)果顯示，對于同一個目標(biāo)地址存在較多的TCP-SYN連接請求，即“TCP三次握手”的第一步，顯然在斷網(wǎng)的狀態(tài)下，TCP三次握手是無法完成的，上層會話也不可能建立成功，因此可以排除TCP-SYN攻擊的可能性。但是截圖中依然存在不確定的疑點，即連續(xù)三個TCP-SYN數(shù)據(jù)包之間的時間間隔分別為3秒和6秒，記錄下該線索，作為后續(xù)分析的參考數(shù)據(jù)。

2.4 http數(shù)據(jù)包捕獲和分析

基于tcp協(xié)議的上層應(yīng)用很多，所以上述發(fā)現(xiàn)的TCP-SYN連接疑點并不能準(zhǔn)確判斷故障源，故障范圍可以進一步縮小至考試客戶端軟件本身。通過咨詢技術(shù)客服得知考試客戶端軟件的實質(zhì)構(gòu)成包括“指向內(nèi)網(wǎng)考試服務(wù)器的IP地址”“目標(biāo)HTTP端口號”“調(diào)用客戶機IE瀏覽器的代碼”以及“鎖屏防止切換的代碼”等組件，那么判斷IE瀏覽器可能會產(chǎn)生故障。

現(xiàn)場實測打開IE瀏覽器，發(fā)現(xiàn)長時間處于卡頓的狀態(tài)，甚至無響應(yīng)，而IE瀏覽器首頁已經(jīng)設(shè)置為空白頁，正常情況下，不會產(chǎn)生任何到互聯(lián)網(wǎng)的訪問請求，那么IE瀏覽器在啟動過程中究竟產(chǎn)生了什么行為呢？接下來通過BurpSuite捕獲http數(shù)據(jù)包并加以分析。

1） 在考試客戶機上啟動BurpSuite軟件，首先是配置代理偵聽：選項標(biāo)簽Proxy ->子選項標(biāo)簽Options ->選中默認(rèn)的代理偵聽，點擊Edit->Specific address：127.0.0.1 -> OK，配置結(jié)果如圖2所示：

2） 配置IE瀏覽器的代理指向BurpSuite的代理偵聽地址和端口

首先設(shè)置起始頁為空白頁，并刪除所有的緩存文件。然后設(shè)置IE代理：工具 -> Internet 選項->連接->局域網(wǎng)設(shè)置->勾選啟用代理服務(wù)器，并設(shè)置地址為127.0.0.1，設(shè)置端口為8080，即保持和Burp Suite設(shè)置的代理偵聽一致。

3） 配置出口防火墻策略，斷開考場機房到互聯(lián)網(wǎng)的連接，并暫時關(guān)閉Burp Suite的攔截功能（設(shè)置為“Intercept is off”），然后打開IE瀏覽器，發(fā)現(xiàn)即使設(shè)置了空白首頁，瀏覽器標(biāo)簽頁依然顯示“正在連接...”，等待15秒左右后，標(biāo)簽頁顯示“空白頁”，狀態(tài)欄顯示“完成”，說明瀏覽器進程后臺已經(jīng)完成了一系列操作。此時，轉(zhuǎn)到Burp Suite，點擊“HTTP History”子標(biāo)簽，可以查看到IE瀏覽器所發(fā)送的一系列http請求數(shù)據(jù)包，顯示結(jié)果如圖3所示：

根據(jù)上圖分析可知，IE瀏覽器在啟動后，后臺進程不斷嘗試從windowsupdate.com站點下載authrootstl.cab文件，即發(fā)送HTTP請求報文。而HTTP請求報文的發(fā)送前提是需要首先使用TCP協(xié)議成功建立TCP三次握手，TCP三次握手的第一個請求報文為TCP-SYN，由于設(shè)置禁止訪問互聯(lián)網(wǎng)，導(dǎo)致TCP-SYN連接超時，最終下載失敗，顯然這是導(dǎo)致“卡頓”故障的源頭。進一步測試驗證和分析如下：

使用Centos系統(tǒng)，運行telnet命令向一臺斷開網(wǎng)絡(luò)連接的內(nèi)網(wǎng)PC機請求建立會話，然后通過運行tcpdump輸出TCP-SYN的狀態(tài)信息，發(fā)現(xiàn)第一個TCP-SYN請求超時后，第二個、第三個、第四個和第五個TCP-SYN數(shù)據(jù)包的超時等待時間分別為1秒、2秒、4秒和8秒，合計為15秒（和Windows系統(tǒng)上運行Wireshark抓包結(jié)果略有誤差）。上圖顯示IE瀏覽器啟動后一共嘗試發(fā)送8次http請求，而每一次http請求之前，都將導(dǎo)致15秒的TCP-SYN超時等待，即IE瀏覽器至少在等待15秒之后，才能訪問內(nèi)網(wǎng)的考試服務(wù)端。調(diào)試結(jié)果如圖4和圖5所示：

3 問題結(jié)論和解決方法

那么IE瀏覽器產(chǎn)生的http下載請求的根源是什么呢？答案就是“瀏覽器加載項”，即IE瀏覽器啟動后，首先會加載“加載項”列表中已啟用的所有內(nèi)容，如果“加載項”列表中存在互聯(lián)網(wǎng)訪問請求指令，并且在斷網(wǎng)的前提下，那么就會產(chǎn)生本文所描述的故障現(xiàn)象。

查看和禁用IE瀏覽器的加載項內(nèi)容：點擊命令欄的“工具”按鈕 ->管理加載項，顯示結(jié)果如圖6所示。

分析截圖中的加載項列表，猜測“AccountProtectBHO Class”加載項可能就是發(fā)送http請求的源頭。點擊右下角的“禁用”按鈕禁用該加載項，然后關(guān)閉IE瀏覽器，再重新打開，此時頁面顯示不再“卡頓”;再次測試打開考試客戶端軟件，登錄輸入窗口界面立即顯示無延遲;輸入賬號密碼登錄成功后，進行模擬考試，整個過程都非常流暢……至此，問題徹底解決！

參考文獻(xiàn)：

[1] 芮辰.基于WireShark和Packet Tracer軟件的域名查詢實驗綜述報告[J].赤峰學(xué)院學(xué)報（自然科學(xué)版），2019，35（10）：61-65.

[2] 俞詩源，王譽天，劉鑫.Burpsuite工具在漏洞檢測中的應(yīng)用[J].信息網(wǎng)絡(luò)安全，2016（9）：94-97.

[3] 蔣小波，沈藝敏，龐富寧.Burpsuite抓包分析注入與提權(quán)技術(shù)研究[J].數(shù)字技術(shù)與應(yīng)用，2019，37（5）：194，196.

[4] 姜慶民，吳寧，閆申友.網(wǎng)絡(luò)分析軟件Tcpdump的研究[J].電腦學(xué)習(xí)，2007（2）：21-22.

【通聯(lián)編輯：王力】