藉助Sniffer分析網絡流量

各位作維護的同事常常會聽到用戶對網速太慢的抱怨，可是網速慢的緣由有不少，好比軟件設置不當，網絡設備故障，物理鏈路問題，感染病毒等，而單單從用戶的故障描述裏面很難有進一步的發現，因此也許你們一時也不知道從何下手。 　　
　　 Sniffer是一個很是好的流量 分析工具，利用它咱們能夠實際瞭解到當前網絡中正在發生的具體流量，而且經過 Sniffer的專家系統以及進一步對數據包的解碼 分析，咱們能夠很快的定位網絡故障，確認網絡帶寬的瓶頸，在故障發生前及時消除網絡隱患，這樣能給咱們平常的維護工做帶來很大的方便，也使得咱們的維護工做處於主動地位，不會再只有接到用戶故障投訴後才能處理故障，在時間和效率上都不能很好的讓用戶滿意。下面是藉助 Sniffer對我某地市分公司出口流量作的一個簡單的流量 分析，沒有什麼很深的技術含量，也並不須要太深的專業知識，但願能對你們平常的維護工做有必定啓發。 分析目標：瞭解目前帶寬實際利用率，檢查有無網絡隱患。

　　 分析方法：

　　在覈心交換機上作端口鏡像，利用sniffer抓包。

　　測試時間：2005.5.17 10:00～10：10

　　測試地點：中心機房

　　抓包開始時間：5.17 10:20

　　抓包持續時間：16s

　　數據包個數：88865

　　平均帶寬利用率：7％

　　1，首先咱們瞭解一下網絡中 協議的分佈狀況，經過sniffer的Protocol Distribution功能能夠直觀的看到當前網絡流量中 協議分佈圖：

從上面能夠很明顯看出，HTTP應用流量最大佔63％，其次就是NetBios流量佔35％。

　　瞭解 協議分佈狀況之後，咱們再找到網絡中流量最大的主機，由於流量越大也就意味着對網絡的影響也就越大，利用sniffer的Host Table的餅視圖功能能夠容易的找到流量最大的機器，以下圖所示：

　　能夠看到219.72.238.88，219.72.237.201這兩臺主機在目前咱們網絡內部流量較大，分別佔16.52%和15.97％。進一步利用HostTable功能的Outline視圖，能夠發現這兩個地址流量的90％都是HTTP流量，以下圖所示：

　　咱們能夠從上圖注意到，219.73.238.88這個主機上行流量要明顯小於下行的流量，而219.72.237.201這個主機則是上行流量明顯大於下行流量，經過確認219.72.238.88爲一臺Web服務器，219,72,237,201則是其餘公司託管我在我公司的一臺服務器，因此到這一步咱們就能夠大體知道這兩個主機當前正在進行的網絡活動。 　　同時咱們要注意的就是每一個地址的收發包數量是否正常，便是否收發之間存在較大差別，若是隻收不發或者只發不收，那極可能就意味着這個主機的當前流量有異常（例如受到SYN***），咱們能夠進一步經過sniffer提供的Decode功能對捕獲的數據包進行解碼，來 分析具體的數據包內容。好比咱們經過定義一個過濾器來查看上面兩個地址的具體數據流量,以下圖所示：

 　　咱們能夠看到在這些HTTP應用裏面， TCP的三次握手都很完整，排除了惡意的SYN***行爲，都是正常的HTTP流量。 　　附:也許從此次的例子看不出有什麼異常，實際上在大部分的狀況下一旦網絡出現異常，能夠在第一時間直觀的經過HostTable功能找到問題的根源。 　　2，查看sniffer的專家系統，發現存在大量的Local Routing（本地路由）告警，sniffer中對此告警的解釋爲：Two DLC stations on the same segment are communicating via a router. Packets are being transmitted via the router rather than directly from one DLC station to the other（大體意思是兩個屬於同一網段的主機之間經過路由器通訊，數據包經過路由器發送而不是直接在兩主機間轉發）。並提示可能緣由爲路由表設置不當。(以下圖所示)

　經過查看告警來源，發現流量均爲來自私網地址的139端口鏈接，經過sniffer的Protocol Distribution的Packet排序能夠看出Netbios 協議流量佔全部流量的80％，即當前網絡中80％的數據包都是Netbios 協議數據包。以下圖所示：

很明顯出現這種現象是不正常的，咱們能夠在所捕獲的數據包裏定義過濾器，選擇只查看Netbios 協議，進一步瞭解具體的數據包內容（以下圖所示）：

　　發現存在大量網內的私網地址發起的139端口鏈接請求，並且全都是 TCP的SYN請求， TCP的三次握手只有一次，極可能受到了SYN***。數據包大小都是62字節，並且每一個數據包之間發送間隔都在1ms內，排除人爲發起 TCP請求的可能。經過觀察數據包的源，目的IP地址，發現源地址很分散，目的地址均爲實際並不存在的IP地址，但根據我公司IP地址規劃都屬於某地市分公司私網地址段。根據流量的特徵，初步判斷爲私網用戶感染蠕蟲病毒，病毒經過139端口與大量虛假IP地址創建鏈接，形成網絡中存在大量短數據包，嚴重下降網絡運行效率。

　　同時咱們還發現當前網絡對每個 TCP鏈接請求進行不斷的重傳，直到TTL值過時以後才被丟棄。經過跟蹤查看某個地址的重傳數據包，發現一個奇怪的現象：

　　上面兩幅截圖是 Sniffer捕獲的172.17.60.126對172.17.46.14發起 TCP鏈接請求的兩個數據包，能夠看到在數據包的網絡層裏面有兩個選項：Identification，Time to live（TTL）。Identification是用來惟一標識主機發出的每一個數據包的，正常狀況下每一個數據包的ID都不同，而TTL是用來限制數據包在網絡中通過的跳數的，每通過一跳TTL值就減1，直到TTL值爲0的時候數據包就被丟棄，主要是防止當網絡中出現環路時數據包的循環傳送。而在上圖能夠看到，這兩個數據包的Identification是同樣，只是TTL值相差1。這就表示這兩個數據包其實是同一個數據包（由於ID同樣），只不過被髮出去之後又被送回來了。到了這裏，咱們能夠初步懷疑是否出現了路由環路。

　　進一步在中心機房嘗試tracert172.17.46.14這個IP地址跟蹤路由，發現路由在中心機房交換機和地市交換機之間造成環路，數據包在環路不斷往返，直到TTL值過時才被丟棄。

　　經過查看中心機房交換機路由表，發現配置了靜態路由，將172.17.44.0/22這段地址指向了地市分公司交換機，而在分公司交換機配置的私網地址池裏面只配置了172.17.44.0/23，並無包括172.17.46.0這段地址，因此在裏面找不到對應的路由，故將流量經過默認路由又傳回至中心機房，從而造成環路。檢查針對其餘網段的異常流量時一樣出現這種狀況。因此，當感染蠕蟲病毒的機器與大量實際並不存在的地址創建139鏈接時，藉助靜態路由設置不當的漏洞，這些數據包在網絡中循環傳送，消耗了大量網絡帶寬，下降了網絡的運行效率。 更多資料請登錄中國 協議 分析網論壇[url]www.cnpaf.net[/url]查看。因此針對以上流量 分析，咱們能夠得出如下結論：

⑴目前網絡中存在大量中毒機器，而且正在試圖經過局域網感染其餘主機，最好能及時通知客戶作殺毒處理，消除網絡隱患。

⑵出於 安全方面的考慮，建議拒絕基於139端口的流量。

⑶中心機房交換機上須要更改靜態路由，取消路由環路。
　　二，總結

　　上面的文章只是一個拋磚引玉，其實 Sniffer還有不少強大的功能，但願你們能在平時多多使用，互相交流經驗，進一步提升咱們的平常維護工做效率。

本文出自 51CTO.COM技術博客