藉助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還有很多強大的功能，希望大家能在平時多多使用，互相交流經驗，進一步提高我們的日常維護工作效率。