分析兩例特殊的網(wǎng)絡丟包排錯
遠程商業(yè)竊密引發(fā)丟包
中天設計院是甘肅省建設廳直屬單位，網(wǎng)絡規(guī)模不大。152臺主機根據(jù)單位職能部門分為5個子網(wǎng)，分別由Hub連接到交換機。由于公司內部的協(xié)同辦公比較頻繁，除了一個在線視頻系統(tǒng)外還部署了一臺文件服務器，單獨為一個子網(wǎng)提供數(shù)據(jù)的共享和交流。單位對外的Internet需求不是很大，通過路由器連接到Internet。
故障現(xiàn)象
某天，該單位的網(wǎng)絡突然出現(xiàn)嚴重堵塞，主機間的數(shù)據(jù)頻頻中斷導致協(xié)同辦公不能正常進行，在線視頻系統(tǒng)經(jīng)常掉線。另外，無論是從文件服務器上傳還是下載文件都異常緩慢，有時會因超時而中斷。主機能夠連接到Internet，但是網(wǎng)速緩慢。
初步判斷
首先在一臺主機上用ping命令測試到網(wǎng)關的連通性，輸入命令“ping 192．168．2．1 -n 1000”發(fā)送1000個Ping包測試網(wǎng)關。測試結果是可以ping通網(wǎng)關，但是掉包現(xiàn)象很嚴重：1000個包有720個包丟了，丟包率為72%，持續(xù)掉包時間也很長。運行arp -a命令，發(fā)現(xiàn)網(wǎng)關IP和網(wǎng)關MAC地址指向正確。通過上面的測試基本排除網(wǎng)絡設置錯誤以及ARP欺騙。
監(jiān)控分析
于是在核心交換機上做鏡像，用Sniffer對整個內網(wǎng)（五個子網(wǎng)）進行監(jiān)控。首先進入“dashboard”（儀表面板），發(fā)現(xiàn)網(wǎng)絡利用率達到了97%，這是很不正常的現(xiàn)象。筆者判斷以該單位的網(wǎng)絡規(guī)模以及日常業(yè)務量，網(wǎng)絡利用率應該在20%~30%之間，有較大的網(wǎng)絡冗余。這樣我們可以斷定，造成網(wǎng)絡丟包的根源應該是異常流量占用大量的網(wǎng)絡帶寬所致。那這些異常流量來自何處呢？
切換到“matrix”（矩陣面板），發(fā)現(xiàn)MAC為00-0A- E6-98-84-B7的主機占了整個網(wǎng)絡流量的57．87%。于是初步把目標鎖定在該主機上，然后切換到“hosttable”（主機列表）繼續(xù)分析。從該面板中，沒有發(fā)現(xiàn)大量的廣播包，因此完全排除了廣播風暴影響。找到00-0A-E6-98-84-B7，對此主機分析，發(fā)現(xiàn)該主機的網(wǎng)絡活動非?？梢?，進入該主機的數(shù)據(jù)包才700多個，而出去的數(shù)據(jù)包在10多分鐘內就有了幾十萬個包。
故障解決
為了確認上述主機在進行什么網(wǎng)絡活動，筆者在交換機上對它單獨抓包分析。對數(shù)據(jù)包解碼后發(fā)現(xiàn)，該主機通過UDP協(xié)議項向外網(wǎng)的一個IP為60．164．82．185主機進行數(shù)據(jù)拷貝。這個IP怎么這么眼熟，這不是本地的一個IP嗎？另外，還發(fā)現(xiàn)該主機與文件服務器的連接也十分頻繁。筆者根據(jù)網(wǎng)段和MAC地址，在交換機上對該主機隔離，斷開其網(wǎng)絡連接，整個網(wǎng)絡馬上就恢復了正常，丟包故障排除。
至此，我們通過層層排錯找到了造成這次網(wǎng)絡丟包的原因——該主機被黑客植了木馬，然后遠程控制通過8888端口向遠程拷貝文件。另外，該主機正在從文件服務器上下載大量文件，估計攻擊者正在通過該主機竊取文件夾服務器上的資料。
該主機本來安裝了殺毒軟件，但不報毒應該是攻擊者做了免殺處理。手工清除木馬，將該主機連接到網(wǎng)絡，網(wǎng)絡丟包再也沒有發(fā)生。事后機主回憶可能是中了移動硬盤中的木馬，因為當天他曾經(jīng)將工程規(guī)劃書拷貝到客戶的移動硬盤中。丟包排錯中引出商業(yè)竊密這是大家都沒有想到的。
循環(huán)自動掃描攻擊引起丟包
筆者所在地某中學的局域網(wǎng)約有電腦1000臺，通常情況下同時在線的有600臺左右，網(wǎng)絡一直很穩(wěn)定。期末放假前網(wǎng)絡出現(xiàn)異常，具體癥狀為：整個校園網(wǎng)突然出現(xiàn)網(wǎng)絡通信中斷，內部用戶均不能正常訪問互聯(lián)網(wǎng)。在機房中進行ping包測試時發(fā)現(xiàn)，中心機房客戶機對中心交換機管理地址的ping包響應時間較長且出現(xiàn)隨機性丟包，主機房客戶機對二級交換機的通信丟包情況更加嚴重。
深入分析
筆者初步判斷這種現(xiàn)象可能是交換機ARP表更新問題、廣播或路由環(huán)路故障、病毒攻擊等引起的。為此，需要進一步獲取ARP信息、交換機負載、網(wǎng)絡中傳輸?shù)脑紨?shù)據(jù)包等信息。
配置抓包。在中心交換機上做好端口鏡像配置操作，并將分析用筆記本電腦接到此端口上，啟動網(wǎng)絡分析工具捕獲分析網(wǎng)絡的數(shù)據(jù)通信，約10分鐘后停止捕獲并分析捕獲到的數(shù)據(jù)包。
查看連接，定位攻擊源。在停止捕獲后，筆者在網(wǎng)絡分析系統(tǒng)主界面左邊的節(jié)點瀏覽器中發(fā)現(xiàn)，內部網(wǎng)絡同時在線的IP主機達到了6515臺，這表示網(wǎng)絡存在許多偽造的IP主機，網(wǎng)絡中可能存在偽造IP地址攻擊或自動掃描攻擊。選擇連接視圖，發(fā)現(xiàn)在10分鐘內，網(wǎng)絡中共發(fā)起了12108個連接，且狀態(tài)大多都是客戶端請求同步。據(jù)此，我們斷定校園網(wǎng)中存在自動掃描攻擊。
詳細查看連接信息，發(fā)現(xiàn)這些連接大多都是由192．168．5．119主機發(fā)起，即連接的源地址是192．168．5．119。選中源地址是192．168．5．119的任意一個連接，單擊鼠標右鍵，在彈出的右鍵菜單中選擇“定位瀏覽器節(jié)點→ 端點1 IP”，這時節(jié)點瀏覽器將自動定位到192．168．5．119主機。
通過協(xié)議，確定攻擊方式。選擇數(shù)據(jù)包視圖查看 192．168．5．119傳輸數(shù)據(jù)的原始解碼信息，我們發(fā)現(xiàn)192．168．5．119這臺機器正在主動對網(wǎng)絡中主機的TCP 445端口進行掃描攻擊，原因可能是192．168．5．119主機感染病毒程序，或者是人為使用掃描軟件進行攻擊。通過分析圖表視圖，進一步確定192．168．5．119主機肯定存在自動掃描攻擊。
找到問題的根源后，對192．168．5．119主機進行隔離，經(jīng)過一段時間的測試，網(wǎng)絡丟包現(xiàn)象有所緩解，但沒有從根本上解決問題。難道，還有漏網(wǎng)之魚仍在興風作浪？于是再次啟動網(wǎng)絡分析系統(tǒng)捕獲并分析網(wǎng)絡的數(shù)據(jù)通信，在網(wǎng)絡中又發(fā)現(xiàn)了3臺與192．168．5．119相似情況的主機。通過這個情況，我們可以肯定192．168．5．119和新發(fā)現(xiàn)的三臺主機都是感染了病毒，且該病毒會主動掃描網(wǎng)絡中其他主機是否打開TCP 445端口，如果某主機打開該端口，就攻擊并感染這臺主機。如此循環(huán)，即引發(fā)了上述的網(wǎng)絡故障。
解除故障
立即對新發(fā)現(xiàn)感染病毒的3臺主機進行隔離，網(wǎng)絡通信立刻恢復正常。另外，在分析中筆者還發(fā)現(xiàn)，192．168．101．57主機占用的流量較大，其通信數(shù)據(jù)包的源端和目的端都使用UDP 6020端口，且與192.168.101.57通信的地址227.1.2.7是一個組播IP地址。鑒于此，我們推測192．168．101．57可能在使用在線視頻點播之類的應用，因此耗費了網(wǎng)絡資源。定位到該主機原來是學校機房的一臺服務器被配置成了一個在線視頻服務器為客戶端提供視頻服務，而該主機正在用P2P軟件下載視頻——難怪會有這么大的流量。
其實引起網(wǎng)絡丟包的原因有很多，除了上述網(wǎng)絡攻擊和病毒感染之外，連接線路、網(wǎng)卡、交換機、路由器等硬件故障也會造成網(wǎng)絡的延遲、丟包。因此，網(wǎng)絡管理人員掌握丟包排錯方法是非常重要的。
授人以魚不如授人以漁，希望上述網(wǎng)絡丟包排故障思路對大家有所幫助。
【編輯推薦】
