第1章Sniffer軟體簡介

概述

Sniffer軟體是NAI公司推出的功能強大的協議分析軟體。本文針對用Sniffer Pro網路分析器進行故障解決。利用Sniffer Pro網路分析器的強大功能和特徵，解決網路問題，將介紹一套合理的故障解決方法。

與Netxray比較，Sniffer支援的協議更豐富，例如PPPOE協議等在Netxray並不支援，在Sniffer上能夠進行快速解碼分析。Netxray不能在Windows 2000和Windows XP上正常執行，Sniffer Pro 4.6可以執行在各種Windows平臺上。

Sniffer軟體比較大，執行時需要的計算機記憶體比較大，否則執行比較慢，這也是它與

功能簡介

下面列出了Sniffer軟體的一些功能介紹，其功能的詳細介紹可以參考Sniffer的線上幫助。

捕獲網路流量進行詳細分析

利用專家分析系統診斷問題

實時監控網路活動

收集網路利用率和錯誤等

在進行流量捕獲之前首先選擇網路介面卡，確定從計算機的哪個網路介面卡上接收資料。位置：File->select settings

選擇網路介面卡後才能正常工作。該軟體安裝在Windows 98作業系統上，Sniffer可以選擇撥號介面卡對窄帶撥號進行操作。如果安裝了EnterNet500等PPPOE軟體還可以選擇虛擬出的PPPOE網絡卡。對於安裝在Windows 2000/XP上則無上述功能，這和作業系統有關。

本文將對報文的捕獲幾網路效能監視等功能進行詳細的介紹。下圖為在軟體中快捷鍵的位置。

第2章報文捕獲解析

2.1捕獲面板

報文捕獲功能可以在報文捕獲面板中進行完成，如下是捕獲面板的功能圖：圖中顯示的是處於開始狀態的面板

2.2捕獲過程報文統計

在捕獲過程中可以通過檢視下面面板檢視捕獲報文的數量和緩衝區的利用率。

2.3捕獲報文檢視

Sniffer軟體提供了強大的分析能力和解碼功能。如下圖所示，對於捕獲的報文提供了一個Expert專家分析系統進行分析，還有解碼選項及圖形和表格的統計資訊。

專家分析

專家分分析系統提供了一個只能的分析平臺，對網路上的流量進行了一些分析對於分析出的診斷結果可以檢視線上幫助獲得。

在下圖中顯示出在網路中

對於某項統計分析可以通過用滑鼠雙擊此條記錄可以檢視詳細統計資訊且對於每一項都可以通過檢視幫助來了解起產生的原因。

解碼分析

下圖是對捕獲報文進行解碼的顯示，通常分為三部分，目前大部分此類軟體結構都採用這種結構顯示。對於解碼主要要求分析人員對協議比較熟悉，這樣才能看懂解析出來的報文。使用該軟體是很簡單的事情，要能夠利用軟體解碼分析來解決問題關鍵是要對各種層次的協議瞭解的比較透徹。工具軟體只是提供一個輔助的手段。因涉及的內容太多，這裡不對協議進行過多講解，請參閱其他相關資料。

對於MAC地址，Snffier軟體進行了頭部的替換，如00e0fc開頭的就替換成Huawei，這樣有利於瞭解網路上各種相關裝置的製造廠商資訊。

功能是按照過濾器設定的過濾規則進行資料的捕獲或顯示。在選單上的位置分別為Capture->Define Filter和Display->Define Filter。

過濾器可以根據實體地址或IP地址和協議選擇進行組合篩選。

統計分析

對於Matrix，Host Table，Portocol Dist. Statistics等提供了豐富的按照地址，協議等內容做了豐富的組合統計，比較簡單，可以通過操作很快掌握這裡就不再詳細介紹了。

2.4設定捕獲條件

基本捕獲條件

基本的捕獲條件有兩種：

1、鏈路層捕獲，按源MAC和目的MAC地址進行捕獲，輸入方式為十六進位制連續輸入，如：00E0FC123456。

2、IP層捕獲，按源IP和目的IP進行捕獲。輸入方式為點間隔方式，如：10.107.1.1。如果選擇IP層捕獲條件則ARP等報文將被過濾掉。

高階捕獲條件

在“Advance”頁面下，你可以編輯你的協議捕獲條件，如圖：

高階捕獲條件編輯圖

在協議選擇樹中你可以選擇你需要捕獲的協議條件，如果什麼都不選，則表示忽略該條件，捕獲所有協議。

在捕獲幀長度條件下，你可以捕獲，等於、小於、大於某個值的報文。

在錯誤幀是否捕獲欄，你可以選擇當網路上有如下錯誤時是否捕獲。

在儲存過濾規則條件按鈕“Profiles”，你可以將你當前設定的過濾規則，進行儲存，在捕獲主面板中，你可以選擇你儲存的捕獲條件。

任意捕獲條件

在Data Pattern下，你可以編輯任意捕獲條件，如下圖：

用這種方法可以實現複雜的報文過濾，但很多時候是得不償失，有時截獲的報文字就不多，還不如自己看看來得快。

第3章報文放送

3.1編輯報文傳送

Sniffer軟體報文傳送功能就比較弱，如下是傳送的主面板圖：

傳送前，你需要先編輯報文傳送的內容。點擊發送報文編輯按鈕。可得到如下的報文編輯視窗：

首先要指定資料幀傳送的長度，然後從鏈路層開始，一個一個將報文填充完成，如果是NetXray支援可以解析的協議，從“Decode”頁面中，可看見解析後的直觀表示。

3.2捕獲編輯報文傳送

將捕獲到的報文直接轉換成傳送報文，然後修修改改可也。如下是一個捕獲報文後的報文檢視視窗：

選中某個捕獲的報文，用滑鼠右鍵啟用選單，選擇“Send Current Packet”，這時你就會發現，該報文的內容已經被原封不動的送到“傳送編輯視窗”中了。這時，你在修修改改，就比你全部填充報文省事多了。

傳送模式有兩種：連續傳送和定量傳送。可以設定傳送間隔，如果為0，則以最快的速度進行傳送。

第4章網路監視功能

網路監視功能能夠時刻監視網路統計，網路上資源的利用率，並能夠監視網路流量的異常狀況，這裡只介紹一下Dashbord和ART，其他功能可以參看線上幫助，或直接使用即可，比較簡單。

4.1Dashbord

Dashbord可以監控網路的利用率，流量及錯誤報文等內容。通過應用軟體可以清楚看到此功能。

4.2Application Response Time (ART)

Application Response Time (ART)是可以監視TCP/UDP應用層程式在客戶端和伺服器響應時間，如HTTP,FTP,DNS等應用。

對與TCP/UDP響應時間的計算方法如下

TCPFor each socket, ART stores the sequence numbers for packets sent by the client and waits for the corresponding ACK packets from the server. It then measures the time difference between the packet with the stored sequence number and the packet with the ACK to arrive at the response time.

UDP For each socket, ART measures the time between packets going from a client to a server and the next packet going from the server to the client.

第5章資料報文解碼詳解

本章主要對：資料報文分層、以太報文結構、IP協議、ARP協議、PPPOE協議、Radius協議等的解碼分析做了簡單的描述，目的在於介紹Sniffer軟體在協議分析中的功能作用並通過解碼分析對協議進一步瞭解。對其其他協議讀者可以通過協議文件和Sniffer捕獲的報文對比分析。

5.1資料報文分層

如下圖所示，對於四層網路結構，其不同層次完成不通功能。每一層次有眾多協議組成。

如上圖所示在Sniffer的解碼錶中分別對每一個層次協議進行解碼分析。鏈路層對應“DLC”；網路層對應“IP”；傳輸層對應“UDP”；應用層對對應的是“NETB”等高層協議。Sniffer可以針對眾多協議進行詳細結構化解碼分析。並利用樹形結構良好的表現出來。

5.2以太報文結構

EthernetII乙太網幀結構

Ethernet_II乙太網幀型別報文結構為：目的MAC地址（6bytes）＋源MAC地址＋（6bytes）上層協議型別（2bytes）＋資料欄位（46-1500bytes)＋校驗（4bytes）。

Sniffer會在捕獲報文的時候自動記錄捕獲的時間，在解碼顯示時顯示出來，在分析問題時提供了很好的時間記錄。

源目的MAC地址在解碼框中可以將前3位元組代表廠商的欄位翻譯出來，方便定位問題，例如網路上2臺裝置IP地址設定衝突，可以通過解碼翻譯出廠商資訊方便的將故障裝置找到，如00e0fc為華為，010042為Cisco等等。如果需要檢視詳細的MAC地址用滑鼠在解碼框中點選此MAC地址，在下面的表格中會突出顯示該地址的16進位制編碼。

IP網路來說Ethertype欄位承載的時上層協議的型別主要包括0x800為IP協議，0x806為ARP協議。

IEEE802.3乙太網報文結構

上圖為IEEE802.3SNAP幀結構，與EthernetII不通點是目的和源地址後面的欄位代表的不是上層協議型別而是報文長度。並多了LLC子層。

5.3IP協議

IP報文結構為IP協議頭＋載荷，其中對IP協議頭部的分析，時分析IP報文的主要內容之一，關於IP報文詳細資訊請參考相關資料。這裡給出了IP協議頭部的一個結構。

版本：4——IPv4

首部長度：單位為4位元組，最大60位元組

TOS：IP優先順序欄位

總長度：單位位元組，最大65535位元組

標識：IP報文標識欄位

標誌：佔3位元，只用到低位的兩個位元

MF（More Fragment）

MF=1，後面還有分片的資料包

MF=0，分片資料包的最後一個

DF（Don't Fragment）

DF=1，不允許分片

DF=0，允許分片

段偏移：分片後的分組在原分組中的相對位置，總共13位元，單位為8位元組

壽命：TTL（Time To Live）丟棄TTL=0的報文

協議：攜帶的是何種協議報文

1：ICMP

6：TCP

17：UDP

89：OSPF

頭部檢驗和：對IP協議首部的校驗和

源IP地址：IP報文的源地址

目的IP地址：IP報文的目的地址

上圖為Sniffer對IP協議首部的解碼分析結構，和IP首部各個欄位相對應，並給出了各個欄位值所表示含義的英文解釋。如上圖報文協議（Protocol）欄位的編碼為0x11，通過Sniffer解碼分析轉換為十進位制的17，代表UDP協議。其他欄位的解碼含義可以與此類似，只要對協議理解的比較清楚對解碼內容的理解將會變的很容易。

5.4ARP協議

以下為ARP報文結構

ARP分組具有如下的一些欄位：

HTYPE（硬體型別）。這是一個16位元欄位，用來定義執行ARP的網路的型別。每一個區域網基於其型別被指派給一個整數。例如，乙太網是型別1。ARP可使用在任何網路上。

PTYPE（協議型別）。這是一個16位元欄位，用來定義協議的型別。例如，對IPv4協議，這個欄位的值是0800。ARP可用於任何高層協議。

HLEN（硬體長度）。這是一個8位元欄位，用來定義以位元組為單位的實體地址的長度。例如，對乙太網這個值是6。

PLEN（協議長度）。這是一個8位元欄位，用來定義以位元組為單位的邏輯地址的長度。例如，對IPv4協議這個值是4。

OPER（操作）。這是一個16位元欄位，用來定義分組的型別。已定義了兩種型別：ARP請求（1），ARP回答（2）。

SHA（傳送站硬體地址）。這是一個可變長度欄位，用來定義傳送站的實體地址的長度。例如，對乙太網這個欄位是6位元組長。

SPA（傳送站協議地址）。這是一個可變長度欄位，用來定義傳送站的邏輯（例如，IP）地址的長度。對於IP協議，這個欄位是4位元組長。

THA（目標硬體地址）。這是一個可變長度欄位，用來定義目標的實體地址的長度。例如，對乙太網這個欄位是6位元組長。對於ARP請求報文，這個欄位是全0，因為傳送站不知道目標的實體地址。

TPA（目標協議地址）。這是一個可變長度欄位，用來定義目標的邏輯地址（例如，IP地址）的長度。對於IPv4協議，這個欄位是4位元組長。

上面為通過Sniffer解碼的ARP請求和應答報文的結構。

5.5PPPOE協議

PPPOE簡介

簡單來說我們可能把PPPOE報文分成兩大塊，一大塊是PPPOE的資料報頭，另一塊則是PPPOE的淨載荷（資料域），對於PPPOE報文資料域中的內容會隨著會話過程的進行而不斷改變。下圖為PPPOE的報文的格式：

資料報文最開始的4位為版本域，協議中給出了明確的規定，這個域的內容填充0x01。

緊接在版本域後的4位是型別域，協議中同樣規定，這個域的內容填充為0x01。

程式碼域佔用1個位元組，對於PPPOE的不同階段這個域內的內容也是不一樣的。

會話ID點用2個位元組，當訪問集中器還未分配唯一的會話ID給使用者主機的話，則該域內的內容必須填充為0x0000，一旦主機獲取了會話ID後，那麼在後續的所有報文中該域必須填充那個唯一的會話ID值。

長度域為2個位元組，用來指示PPPOE資料報文中淨載荷的長度。

資料域，有時也稱之為淨載荷域，在PPPOE的不同階段該域內的資料內容會有很大的不同。在PPPOE的發現階段時，該域內會填充一些Tag（標記）；而在PPPOE的會話階段，該域則攜帶的是PPP的報文。

捕獲報文測試用例圖

如圖所示，Radius Server IP地址為172.16.20.76。PPPOE使用者Radius報文互動過程分析如下。

上圖為PPPOE從發現階段到PPP LCP協商，認證IPCP協商階段和PPPOE會話階段互動過程。

PPPOE發現階段，PADI報文，Sniffer解碼結構如下所示。

PPPOE會話階段，Sniffer解碼結構如下所示。

5.6Radius協議

Radius報文簡介

標準Radius協議包結構

圖9Radius包格式

Code：包型別；1位元組；指示RADIUS包的型別。

1Access- request認證請求

2Access- accept認證響應

3Access- reject認證拒絕

4Accounting-request計費請求

5Accounting-response計費響應

*11Access-challenge認證挑戰

Identifier：包標識；1位元組，取值範圍為0～255；用於匹配請求包和響應包，同一組請求包和響應包的Identifier應相同。

Length：包長度；2位元組；整個包中所有域的長度。

Authenticator：16位元組長；用於驗證RADIUS伺服器傳回來的請求以及密碼隱藏演算法上。

該驗證字分為兩種：

1、請求驗證字---Request Authenticator

用在請求報文中,必須為全域性唯一的隨機值。

2、響應驗證字---Response Authenticator

用在響應報文中，用於鑑別響應報文的合法性。

響應驗證字＝MD5(Code+ID+Length+請求驗證字+Attributes+Key)

Attributes：屬性

圖10屬性格式

屬性域是TLV結構編碼。

測試用例圖

下圖為使用者端PPPOE，Radius Server和BAS互動的認證上線和下線的過程。

報文1：BAS請求Radius Server認證報文。

報文2：Radius Server迴應BAS認證通過報文。

報文3：BAS計費請求報文。

報文4：Radius Server計費響應報文。

報文5：BAS計費結束報文。

報文6：Radius Server計費結束響應報文。

從中可以看出對於報文請求和響應是通過IP地址+Radius協議域中ID號進行配對識別的。

上圖顯示了BAS發起的Radius認證請求（Code＝1）報文的結構。Radius報文是承載在UPD協議之上的，這裡我沒不關注上層報文的結構。

下圖為PPPOE CHAP認證過程的Radius認證請求報文和PPPOE中CHAP認證的Challenge報文。通過比較可以方便看出BAS發出的Challenge值為“26fe8768341de68a72a1276771e1c1ca”與PPPOE中CHAP認證過程中BAS發給PPPOE使用者的Challenge值是一致的。

下圖為PPPOE使用者發為BAS的經過CHAP加密後的使用者密碼和BAS發給Radius Server中認證請求報文使用者祕密屬性域的比較。可以看出在Radius認證過程中，BAS裝置將Challenge屬性和使用者加密後的密碼發給Radius進行驗證。

通過比較可以清楚瞭解協議各欄位含義相互關係，為問題處理提供有效的手段。

下面為PPPOE使用者Radius認證的Sniffer捕獲的報文。

轉載於:https://blog.51cto.com/zaizai1573/1566506