第5章  數(shù)據(jù)報文解碼詳解

本章主要對：數(shù)據(jù)報文分層、以太報文結(jié)構(gòu)、IP協(xié)議、ARP協(xié)議、PPPOE協(xié)議、Radius協(xié)議等的解碼分析做了簡單的描述，目的在于介紹Sniffer軟件在協(xié)議分析中的功能作用并通過解碼分析對協(xié)議進一步了解。對其其他協(xié)議讀者可以通過協(xié)議文檔和Sniffer捕獲的報文對比分析。

5.1  數(shù)據(jù)報文分層

如下圖所示，對于四層網(wǎng)絡(luò)結(jié)構(gòu)，其不同層次完成不通功能。每一層次有眾多協(xié)議組成。

如上圖所示在Sniffer的解碼表中分別對每一個層次協(xié)議進行解碼分析。鏈路層對應(yīng)“DLC”；網(wǎng)絡(luò)層對應(yīng)“IP”；傳輸層對應(yīng)“UDP”；應(yīng)用層對對應(yīng)的是“NETB”等高層協(xié)議。Sniffer可以針對眾多協(xié)議進行詳細結(jié)構(gòu)化解碼分析。并利用樹形結(jié)構(gòu)良好的表現(xiàn)出來。

5.2  以太報文結(jié)構(gòu)

EthernetII以太網(wǎng)幀結(jié)構(gòu)

Ethernet_II以太網(wǎng)幀類型報文結(jié)構(gòu)為：目的MAC地址（6bytes）＋源MAC地址＋（6bytes）上層協(xié)議類型（2bytes）＋數(shù)據(jù)字段（46-1500bytes)＋校驗（4bytes）。

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

源目的MAC地址在解碼框中可以將前3字節(jié)代表廠商的字段翻譯出來，方便定位問題，例如網(wǎng)絡(luò)上2臺設(shè)備IP地址設(shè)置沖突，可以通過解碼翻譯出廠商信息方便的將故障設(shè)備找到，如00e0fc為華為，010042為Cisco等等。如果需要查看詳細的MAC地址用鼠標(biāo)在解碼框中點擊此MAC地址，在下面的表格中會突出顯示該地址的16進制編碼。

IP網(wǎng)絡(luò)來說Ethertype字段承載的時上層協(xié)議的類型主要包括0x800為IP協(xié)議，0x806為ARP協(xié)議。

IEEE802.3以太網(wǎng)報文結(jié)構(gòu)

上圖為IEEE802.3SNAP幀結(jié)構(gòu)，與EthernetII不通點是目的和源地址后面的字段代表的不是上層協(xié)議類型而是報文長度。并多了LLC子層。

5.3  IP協(xié)議

IP報文結(jié)構(gòu)為IP協(xié)議頭＋載荷，其中對IP協(xié)議頭部的分析，時分析IP報文的主要內(nèi)容之一，關(guān)于IP報文詳細信息請參考相關(guān)資料。這里給出了IP協(xié)議頭部的一個結(jié)構(gòu)。

版本：4——IPv4

首部長度：單位為4字節(jié)，最大60字節(jié)

TOS：IP優(yōu)先級字段

總長度：單位字節(jié)，最大65535字節(jié)

標(biāo)識：IP報文標(biāo)識字段

標(biāo)志：占3比特，只用到低位的兩個比特

    MF（More Fragment）

    MF=1，后面還有分片的數(shù)據(jù)包

    MF=0，分片數(shù)據(jù)包的最后一個

    DF（Don't Fragment）

    DF=1，不允許分片

    DF=0，允許分片

段偏移：分片后的分組在原分組中的相對位置，總共13比特，單位為8字節(jié)

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

協(xié)議：攜帶的是何種協(xié)議報文

    1  ：ICMP

    6  ：TCP

    17：UDP

    89：OSPF

頭部檢驗和：對IP協(xié)議首部的校驗和

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

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

上圖為Sniffer對IP協(xié)議首部的解碼分析結(jié)構(gòu)，和IP首部各個字段相對應(yīng)，并給出了各個字段值所表示含義的英文解釋。如上圖報文協(xié)議（Protocol）字段的編碼為0x11，通過Sniffer解碼分析轉(zhuǎn)換為十進制的17，代表UDP協(xié)議。其他字段的解碼含義可以與此類似，只要對協(xié)議理解的比較清楚對解碼內(nèi)容的理解將會變的很容易。

5.4  ARP協(xié)議

   以下為ARP報文結(jié)構(gòu)

ARP分組具有如下的一些字段：

HTYPE（硬件類型）。這是一個16比特字段，用來定義運行ARP的網(wǎng)絡(luò)的類型。每一個局域網(wǎng)基于其類型被指派給一個整數(shù)。例如，以太網(wǎng)是類型1。ARP可使用在任何網(wǎng)絡(luò)上。

PTYPE（協(xié)議類型）。這是一個16比特字段，用來定義協(xié)議的類型。例如，對IPv4協(xié)議，這個字段的值是0800。ARP可用于任何高層協(xié)議。

HLEN（硬件長度）。這是一個8比特字段，用來定義以字節(jié)為單位的物理地址的長度。例如，對以太網(wǎng)這個值是6。

PLEN（協(xié)議長度）。這是一個8比特字段，用來定義以字節(jié)為單位的邏輯地址的長度。例如，對IPv4協(xié)議這個值是4。

OPER（操作）。這是一個16比特字段，用來定義分組的類型。已定義了兩種類型：ARP請求（1），ARP回答（2）。

SHA（發(fā)送站硬件地址）。這是一個可變長度字段，用來定義發(fā)送站的物理地址的長度。例如，對以太網(wǎng)這個字段是6字節(jié)長。

SPA（發(fā)送站協(xié)議地址）。這是一個可變長度字段，用來定義發(fā)送站的邏輯（例如，IP）地址的長度。對于IP協(xié)議，這個字段是4字節(jié)長。

THA（目標(biāo)硬件地址）。這是一個可變長度字段，用來定義目標(biāo)的物理地址的長度。例如，對以太網(wǎng)這個字段是6字節(jié)長。對于ARP請求報文，這個字段是全0，因為發(fā)送站不知道目標(biāo)的物理地址。

TPA（目標(biāo)協(xié)議地址）。這是一個可變長度字段，用來定義目標(biāo)的邏輯地址（例如，IP地址）的長度。對于IPv4協(xié)議，這個字段是4字節(jié)長。

上面為通過Sniffer解碼的ARP請求和應(yīng)答報文的結(jié)構(gòu)。

5.5  PPPOE協(xié)議

PPPOE簡介

簡單來說我們可能把PPPOE報文分成兩大塊，一大塊是PPPOE的數(shù)據(jù)報頭，另一塊則是PPPOE的凈載荷（數(shù)據(jù)域），對于PPPOE報文數(shù)據(jù)域中的內(nèi)容會隨著會話過程的進行而不斷改變。下圖為PPPOE的報文的格式：

  數(shù)據(jù)報文最開始的4位為版本域，協(xié)議中給出了明確的規(guī)定，這個域的內(nèi)容填充0x01。

  緊接在版本域后的4位是類型域，協(xié)議中同樣規(guī)定，這個域的內(nèi)容填充為0x01。

  代碼域占用1個字節(jié)，對于PPPOE 的不同階段這個域內(nèi)的內(nèi)容也是不一樣的。

  會話ID點用2個字節(jié)，當(dāng)訪問集中器還未分配唯一的會話ID給用戶主機的話，則該域內(nèi)的內(nèi)容必須填充為0x0000，一旦主機獲取了會話ID后，那么在后續(xù)的所有報文中該域必須填充那個唯一的會話ID值。

  長度域為2個字節(jié)，用來指示PPPOE數(shù)據(jù)報文中凈載荷的長度。

  數(shù)據(jù)域，有時也稱之為凈載荷域，在PPPOE的不同階段該域內(nèi)的數(shù)據(jù)內(nèi)容會有很大的不同。在PPPOE的發(fā)現(xiàn)階段時，該域內(nèi)會填充一些Tag（標(biāo)記）；而在PPPOE的會話階段，該域則攜帶的是PPP的報文。

捕獲報文測試用例圖

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

上圖為PPPOE從發(fā)現(xiàn)階段到PPP LCP協(xié)商，認證IPCP協(xié)商階段和PPPOE會話階段交互過程。

PPPOE發(fā)現(xiàn)階段，PADI報文，Sniffer解碼結(jié)構(gòu)如下所示。

PPPOE會話階段，Sniffer解碼結(jié)構(gòu)如下所示。

5.6  Radius協(xié)議

Radius報文簡介

標(biāo)準(zhǔn)Radius協(xié)議包結(jié)構(gòu)

圖9   Radius包格式

Code：包類型；1字節(jié)；指示RADIUS包的類型。

         1     Access- request                   認證請求

         2     Access- accept                     認證響應(yīng)

         3     Access- reject                      認證拒絕

         4     Accounting-request             計費請求

         5     Accounting-response           計費響應(yīng)

       *11   Access-challenge                 認證挑戰(zhàn)

Identifier： 包標(biāo)識；1字節(jié)，取值范圍為0 ～255；用于匹配請求包和響應(yīng)包，同一組請求包和響應(yīng)包的Identifier應(yīng)相同。

Length： 包長度；2字節(jié)；整個包中所有域的長度。

Authenticator：16 字節(jié)長；用于驗證RADIUS服務(wù)器傳回來的請求以及密碼隱藏算法上。

該驗證字分為兩種：

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

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

  2、響應(yīng)驗證字---Response Authenticator

         用在響應(yīng)報文中，用于鑒別響應(yīng)報文的合法性。

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

Attributes：屬性

圖10   屬性格式

屬性域是TLV結(jié)構(gòu)編碼。

                              測試用例圖

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

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

報文2：Radius Server回應(yīng)BAS認證通過報文。

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

報文4：Radius Server計費響應(yīng)報文。

報文5：BAS計費結(jié)束報文。

報文6：Radius Server計費結(jié)束響應(yīng)報文。

從中可以看出對于報文請求和響應(yīng)是通過IP地址+Radius 協(xié)議域中ID號進行配對識別的。

上圖顯示了BAS發(fā)起的Radius認證請求（Code＝1）報文的結(jié)構(gòu)。Radius報文是承載在UPD協(xié)議之上的，這里我沒不關(guān)注上層報文的結(jié)構(gòu)。

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

下圖為PPPOE用戶發(fā)為BAS的經(jīng)過CHAP加密后的用戶密碼和BAS發(fā)給Radius Server中認證請求報文用戶秘密屬性域的比較?？梢钥闯鲈?/span>Radius 認證過程中，BAS設(shè)備將Challenge屬性和用戶加密后的密碼發(fā)給Radius進行驗證。

通過比較可以清楚了解協(xié)議各字段含義相互關(guān)系，為問題處理提供有效的手段。

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