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