借助Sniffer分析网络流量
生活随笔
收集整理的這篇文章主要介紹了
借助Sniffer分析网络流量
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
各位做維護的同事經(jīng)常會聽到用戶對網(wǎng)速太慢的抱怨,但是網(wǎng)速慢的原因有很多,比如軟件設置不當,網(wǎng)絡設備故障,物理鏈路問題,感染病毒等,而單單從用戶的故障描述里面很難有進一步的發(fā)現(xiàn),所以也許大家一時也不知道從何下手。
Sniffer是一個非常好的流量分析工具,利用它我們可以實際了解到當前網(wǎng)絡中正在發(fā)生的具體流量,并且通過Sniffer的專家系統(tǒng)以及進一步對數(shù)據(jù)包的解碼分析,我們可以很快的定位網(wǎng)絡故障,確認網(wǎng)絡帶寬的瓶頸,在故障發(fā)生前及時消除網(wǎng)絡隱患,這樣能給我們?nèi)粘5木S護工作帶來很大的方便,也使得我們的維護工作處于主動地位,不會再只有接到用戶故障投訴后才能處理故障,在時間和效率上都不能很好的讓用戶滿意。下面是借助Sniffer對我某地市分公司出口流量做的一個簡單的流量分析,沒有什么很深的技術含量,也并不需要太深的專業(yè)知識,希望能對大家日常的維護工作有一定啟發(fā)。 分析目標:了解目前帶寬實際利用率,檢查有無網(wǎng)絡隱患。 分析方法: 在核心交換機上做端口鏡像,利用sniffer抓包。 測試時間:2005.5.17 10:00~10:10 測試地點:中心機房 抓包開始時間:5.17 10:20 抓包持續(xù)時間:16s 數(shù)據(jù)包個數(shù):88865 平均帶寬利用率:7% 1,首先我們了解一下網(wǎng)絡中協(xié)議的分布情況,通過sniffer的Protocol Distribution功能可以直觀的看到當前網(wǎng)絡流量中協(xié)議分布圖: 從上面可以很明顯看出,HTTP應用流量最大占63%,其次就是NetBios流量占35%。 了解協(xié)議分布情況以后,我們再找到網(wǎng)絡中流量最大的主機,因為流量越大也就意味著對網(wǎng)絡的影響也就越大,利用sniffer的Host Table的餅視圖功能可以容易的找到流量最大的機器,如下圖所示: 可以看到219.72.238.88,219.72.237.201這兩臺主機在目前我們網(wǎng)絡內(nèi)部流量較大,分別占16.52%和15.97%。進一步利用HostTable功能的Outline視圖,可以發(fā)現(xiàn)這兩個地址流量的90%都是HTTP流量,如下圖所示: 我們可以從上圖注意到,219.73.238.88這個主機上行流量要明顯小于下行的流量,而219.72.237.201這個主機則是上行流量明顯大于下行流量,通過確認219.72.238.88為一臺Web服務器,219,72,237,201則是其他公司托管我在我公司的一臺服務器,所以到這一步我們就可以大致知道這兩個主機當前正在進行的網(wǎng)絡活動。 同時我們要注意的就是每個地址的收發(fā)包數(shù)量是否正常,即是否收發(fā)之間存在較大差異,如果只收不發(fā)或者只發(fā)不收,那很可能就意味著這個主機的當前流量有異常(例如受到SYN***),我們可以進一步通過sniffer提供的Decode功能對捕獲的數(shù)據(jù)包進行解碼,來分析具體的數(shù)據(jù)包內(nèi)容。比如我們通過定義一個過濾器來查看上面兩個地址的具體數(shù)據(jù)流量,如下圖所示: 我們可以看到在這些HTTP應用里面,TCP的三次握手都很完整,排除了惡意的SYN***行為,都是正常的HTTP流量。 附:也許從這次的例子看不出有什么異常,實際上在大部分的情況下一旦網(wǎng)絡出現(xiàn)異常,可以在第一時間直觀的通過HostTable功能找到問題的根源。 2,查看sniffer的專家系統(tǒng),發(fā)現(xiàn)存在大量的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(大致意思是兩個屬于同一網(wǎng)段的主機之間通過路由器通信,數(shù)據(jù)包通過路由器發(fā)送而不是直接在兩主機間轉發(fā))。并提示可能原因為路由表設置不當。(如下圖所示) 通過查看告警來源,發(fā)現(xiàn)流量均為來自私網(wǎng)地址的139端口連接,通過sniffer的Protocol Distribution的Packet排序可以看出Netbios協(xié)議流量占所有流量的80%,即當前網(wǎng)絡中80%的數(shù)據(jù)包都是Netbios協(xié)議數(shù)據(jù)包。如下圖所示: 很明顯出現(xiàn)這種現(xiàn)象是不正常的,我們可以在所捕獲的數(shù)據(jù)包里定義過濾器,選擇只查看Netbios協(xié)議,進一步了解具體的數(shù)據(jù)包內(nèi)容(如下圖所示): 發(fā)現(xiàn)存在大量網(wǎng)內(nèi)的私網(wǎng)地址發(fā)起的139端口連接請求,而且全都是TCP的SYN請求,TCP的三次握手只有一次,很可能受到了SYN***。數(shù)據(jù)包大小都是62字節(jié),而且每個數(shù)據(jù)包之間發(fā)送間隔都在1ms內(nèi),排除人為發(fā)起TCP請求的可能。通過觀察數(shù)據(jù)包的源,目的IP地址,發(fā)現(xiàn)源地址很分散,目的地址均為實際并不存在的IP地址,但根據(jù)我公司IP地址規(guī)劃都屬于某地市分公司私網(wǎng)地址段。根據(jù)流量的特征,初步判斷為私網(wǎng)用戶感染蠕蟲病毒,病毒通過139端口與大量虛假IP地址建立連接,造成網(wǎng)絡中存在大量短數(shù)據(jù)包,嚴重降低網(wǎng)絡運行效率。 同時我們還發(fā)現(xiàn)當前網(wǎng)絡對每一個TCP連接請求進行不斷的重傳,直到TTL值過期之后才被丟棄。通過跟蹤查看某個地址的重傳數(shù)據(jù)包,發(fā)現(xiàn)一個奇怪的現(xiàn)象:
上面兩幅截圖是Sniffer捕獲的172.17.60.126對172.17.46.14發(fā)起TCP連接請求的兩個數(shù)據(jù)包,可以看到在數(shù)據(jù)包的網(wǎng)絡層里面有兩個選項:Identification,Time to live(TTL)。Identification是用來唯一標識主機發(fā)出的每個數(shù)據(jù)包的,正常情況下每個數(shù)據(jù)包的ID都不一樣,而TTL是用來限制數(shù)據(jù)包在網(wǎng)絡中經(jīng)過的跳數(shù)的,每經(jīng)過一跳TTL值就減1,直到TTL值為0的時候數(shù)據(jù)包就被丟棄,主要是防止當網(wǎng)絡中出現(xiàn)環(huán)路時數(shù)據(jù)包的循環(huán)傳送。而在上圖可以看到,這兩個數(shù)據(jù)包的Identification是一樣,只是TTL值相差1。這就表示這兩個數(shù)據(jù)包實際上是同一個數(shù)據(jù)包(因為ID一樣),只不過被發(fā)出去以后又被送回來了。到了這里,我們可以初步懷疑是否出現(xiàn)了路由環(huán)路。 進一步在中心機房嘗試tracert172.17.46.14這個IP地址跟蹤路由,發(fā)現(xiàn)路由在中心機房交換機和地市交換機之間形成環(huán)路,數(shù)據(jù)包在環(huán)路不斷往返,直到TTL值過期才被丟棄。 通過查看中心機房交換機路由表,發(fā)現(xiàn)配置了靜態(tài)路由,將172.17.44.0/22這段地址指向了地市分公司交換機,而在分公司交換機配置的私網(wǎng)地址池里面只配置了172.17.44.0/23,并沒有包括172.17.46.0這段地址,所以在里面找不到對應的路由,故將流量通過默認路由又傳回至中心機房,從而形成環(huán)路。檢查針對其他網(wǎng)段的異常流量時同樣出現(xiàn)這種情況。所以,當感染蠕蟲病毒的機器與大量實際并不存在的地址建立139連接時,借助靜態(tài)路由設置不當?shù)穆┒?#xff0c;這些數(shù)據(jù)包在網(wǎng)絡中循環(huán)傳送,消耗了大量網(wǎng)絡帶寬,降低了網(wǎng)絡的運行效率。 更多資料請登陸中國協(xié)議分析網(wǎng)論壇[url]www.cnpaf.net[/url]查看。所以針對以上流量分析,我們可以得出以下結論: ⑴目前網(wǎng)絡中存在大量中毒機器,并且正在試圖通過局域網(wǎng)感染其他主機,最好能及時通知客戶做殺毒處理,消除網(wǎng)絡隱患。 ⑵出于安全方面的考慮,建議拒絕基于139端口的流量。 ⑶中心機房交換機上需要更改靜態(tài)路由,取消路由環(huán)路。
二,總結 上面的文章只是一個拋磚引玉,其實Sniffer還有很多強大的功能,希望大家能在平時多多使用,互相交流經(jīng)驗,進一步提高我們的日常維護工作效率。本文出自 51CTO.COM技術博客
Sniffer是一個非常好的流量分析工具,利用它我們可以實際了解到當前網(wǎng)絡中正在發(fā)生的具體流量,并且通過Sniffer的專家系統(tǒng)以及進一步對數(shù)據(jù)包的解碼分析,我們可以很快的定位網(wǎng)絡故障,確認網(wǎng)絡帶寬的瓶頸,在故障發(fā)生前及時消除網(wǎng)絡隱患,這樣能給我們?nèi)粘5木S護工作帶來很大的方便,也使得我們的維護工作處于主動地位,不會再只有接到用戶故障投訴后才能處理故障,在時間和效率上都不能很好的讓用戶滿意。下面是借助Sniffer對我某地市分公司出口流量做的一個簡單的流量分析,沒有什么很深的技術含量,也并不需要太深的專業(yè)知識,希望能對大家日常的維護工作有一定啟發(fā)。 分析目標:了解目前帶寬實際利用率,檢查有無網(wǎng)絡隱患。 分析方法: 在核心交換機上做端口鏡像,利用sniffer抓包。 測試時間:2005.5.17 10:00~10:10 測試地點:中心機房 抓包開始時間:5.17 10:20 抓包持續(xù)時間:16s 數(shù)據(jù)包個數(shù):88865 平均帶寬利用率:7% 1,首先我們了解一下網(wǎng)絡中協(xié)議的分布情況,通過sniffer的Protocol Distribution功能可以直觀的看到當前網(wǎng)絡流量中協(xié)議分布圖: 從上面可以很明顯看出,HTTP應用流量最大占63%,其次就是NetBios流量占35%。 了解協(xié)議分布情況以后,我們再找到網(wǎng)絡中流量最大的主機,因為流量越大也就意味著對網(wǎng)絡的影響也就越大,利用sniffer的Host Table的餅視圖功能可以容易的找到流量最大的機器,如下圖所示: 可以看到219.72.238.88,219.72.237.201這兩臺主機在目前我們網(wǎng)絡內(nèi)部流量較大,分別占16.52%和15.97%。進一步利用HostTable功能的Outline視圖,可以發(fā)現(xiàn)這兩個地址流量的90%都是HTTP流量,如下圖所示: 我們可以從上圖注意到,219.73.238.88這個主機上行流量要明顯小于下行的流量,而219.72.237.201這個主機則是上行流量明顯大于下行流量,通過確認219.72.238.88為一臺Web服務器,219,72,237,201則是其他公司托管我在我公司的一臺服務器,所以到這一步我們就可以大致知道這兩個主機當前正在進行的網(wǎng)絡活動。 同時我們要注意的就是每個地址的收發(fā)包數(shù)量是否正常,即是否收發(fā)之間存在較大差異,如果只收不發(fā)或者只發(fā)不收,那很可能就意味著這個主機的當前流量有異常(例如受到SYN***),我們可以進一步通過sniffer提供的Decode功能對捕獲的數(shù)據(jù)包進行解碼,來分析具體的數(shù)據(jù)包內(nèi)容。比如我們通過定義一個過濾器來查看上面兩個地址的具體數(shù)據(jù)流量,如下圖所示: 我們可以看到在這些HTTP應用里面,TCP的三次握手都很完整,排除了惡意的SYN***行為,都是正常的HTTP流量。 附:也許從這次的例子看不出有什么異常,實際上在大部分的情況下一旦網(wǎng)絡出現(xiàn)異常,可以在第一時間直觀的通過HostTable功能找到問題的根源。 2,查看sniffer的專家系統(tǒng),發(fā)現(xiàn)存在大量的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(大致意思是兩個屬于同一網(wǎng)段的主機之間通過路由器通信,數(shù)據(jù)包通過路由器發(fā)送而不是直接在兩主機間轉發(fā))。并提示可能原因為路由表設置不當。(如下圖所示) 通過查看告警來源,發(fā)現(xiàn)流量均為來自私網(wǎng)地址的139端口連接,通過sniffer的Protocol Distribution的Packet排序可以看出Netbios協(xié)議流量占所有流量的80%,即當前網(wǎng)絡中80%的數(shù)據(jù)包都是Netbios協(xié)議數(shù)據(jù)包。如下圖所示: 很明顯出現(xiàn)這種現(xiàn)象是不正常的,我們可以在所捕獲的數(shù)據(jù)包里定義過濾器,選擇只查看Netbios協(xié)議,進一步了解具體的數(shù)據(jù)包內(nèi)容(如下圖所示): 發(fā)現(xiàn)存在大量網(wǎng)內(nèi)的私網(wǎng)地址發(fā)起的139端口連接請求,而且全都是TCP的SYN請求,TCP的三次握手只有一次,很可能受到了SYN***。數(shù)據(jù)包大小都是62字節(jié),而且每個數(shù)據(jù)包之間發(fā)送間隔都在1ms內(nèi),排除人為發(fā)起TCP請求的可能。通過觀察數(shù)據(jù)包的源,目的IP地址,發(fā)現(xiàn)源地址很分散,目的地址均為實際并不存在的IP地址,但根據(jù)我公司IP地址規(guī)劃都屬于某地市分公司私網(wǎng)地址段。根據(jù)流量的特征,初步判斷為私網(wǎng)用戶感染蠕蟲病毒,病毒通過139端口與大量虛假IP地址建立連接,造成網(wǎng)絡中存在大量短數(shù)據(jù)包,嚴重降低網(wǎng)絡運行效率。 同時我們還發(fā)現(xiàn)當前網(wǎng)絡對每一個TCP連接請求進行不斷的重傳,直到TTL值過期之后才被丟棄。通過跟蹤查看某個地址的重傳數(shù)據(jù)包,發(fā)現(xiàn)一個奇怪的現(xiàn)象:
上面兩幅截圖是Sniffer捕獲的172.17.60.126對172.17.46.14發(fā)起TCP連接請求的兩個數(shù)據(jù)包,可以看到在數(shù)據(jù)包的網(wǎng)絡層里面有兩個選項:Identification,Time to live(TTL)。Identification是用來唯一標識主機發(fā)出的每個數(shù)據(jù)包的,正常情況下每個數(shù)據(jù)包的ID都不一樣,而TTL是用來限制數(shù)據(jù)包在網(wǎng)絡中經(jīng)過的跳數(shù)的,每經(jīng)過一跳TTL值就減1,直到TTL值為0的時候數(shù)據(jù)包就被丟棄,主要是防止當網(wǎng)絡中出現(xiàn)環(huán)路時數(shù)據(jù)包的循環(huán)傳送。而在上圖可以看到,這兩個數(shù)據(jù)包的Identification是一樣,只是TTL值相差1。這就表示這兩個數(shù)據(jù)包實際上是同一個數(shù)據(jù)包(因為ID一樣),只不過被發(fā)出去以后又被送回來了。到了這里,我們可以初步懷疑是否出現(xiàn)了路由環(huán)路。 進一步在中心機房嘗試tracert172.17.46.14這個IP地址跟蹤路由,發(fā)現(xiàn)路由在中心機房交換機和地市交換機之間形成環(huán)路,數(shù)據(jù)包在環(huán)路不斷往返,直到TTL值過期才被丟棄。 通過查看中心機房交換機路由表,發(fā)現(xiàn)配置了靜態(tài)路由,將172.17.44.0/22這段地址指向了地市分公司交換機,而在分公司交換機配置的私網(wǎng)地址池里面只配置了172.17.44.0/23,并沒有包括172.17.46.0這段地址,所以在里面找不到對應的路由,故將流量通過默認路由又傳回至中心機房,從而形成環(huán)路。檢查針對其他網(wǎng)段的異常流量時同樣出現(xiàn)這種情況。所以,當感染蠕蟲病毒的機器與大量實際并不存在的地址建立139連接時,借助靜態(tài)路由設置不當?shù)穆┒?#xff0c;這些數(shù)據(jù)包在網(wǎng)絡中循環(huán)傳送,消耗了大量網(wǎng)絡帶寬,降低了網(wǎng)絡的運行效率。 更多資料請登陸中國協(xié)議分析網(wǎng)論壇[url]www.cnpaf.net[/url]查看。所以針對以上流量分析,我們可以得出以下結論: ⑴目前網(wǎng)絡中存在大量中毒機器,并且正在試圖通過局域網(wǎng)感染其他主機,最好能及時通知客戶做殺毒處理,消除網(wǎng)絡隱患。 ⑵出于安全方面的考慮,建議拒絕基于139端口的流量。 ⑶中心機房交換機上需要更改靜態(tài)路由,取消路由環(huán)路。
二,總結 上面的文章只是一個拋磚引玉,其實Sniffer還有很多強大的功能,希望大家能在平時多多使用,互相交流經(jīng)驗,進一步提高我們的日常維護工作效率。本文出自 51CTO.COM技術博客
轉載于:https://blog.51cto.com/tonyjcch/235953
總結
以上是生活随笔為你收集整理的借助Sniffer分析网络流量的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Visual Studio 2010 U
- 下一篇: DB2中的权限