数据报文解码详解

《数据报文解码详解》由会员分享，可在线阅读，更多相关《数据报文解码详解（13页珍藏版）》请在金锄头文库上搜索。

1、数据报文解码详解数据报文解码详解本章主要对：本章主要对：数据报文分层、以太报文结构、IP 协议、ARP 协议、PPPOE 协议、Radius 协议等的解码分析做了简单的描述，目的在于介绍 Sniffer 软件在协议分析中的功能作用并通过解码分析对协议进一步了解。对其其他协议读者可以通过协议文档和 Sniffer 捕获的报文对比分析。1.1 数据报文分层如下图所示，对于四层网络结构，其不同层次完成不通功能。每一层次有众多协议组成。应用层传输层网络层链路层Telnet FTP和e-mail等TCP 和 UDPIP ICMP IGMP设备驱动程序及接口卡应用层传输层网络层链路层Telnet FTP和

2、e-mail等TCP 和 UDPIP ICMP IGMP设备驱动程序及接口卡如上图所示在 Sniffer 的解码表中分别对每一个层次协议进行解码分析。链路层对应“DLC”；网络层对应“IP”；传输层对应“UDP”；应用层对对应的是“NETB”等高层协议。Sniffer 可以针对众多协议进行详细结构化解码分析。并利用树形结构良好的表现出来。1.2 以太报文结构EthernetII 以太网帧结构Ethernet_IIDMACSMACTypeDATA/PADFCSEthernet_IIDMACSMACTypeDATA/PADFCSEthernet_II 以太网帧类型报文结构为：目的 MAC 地址（6

3、bytes）源MAC 地址（6bytes）上层协议类型（2bytes）数据字段（46-1500bytes)校验（4bytes）。Sniffer自动 添加时间戳目的MAC 地址源MAC地 址上层协议 类型Sniffer自动 添加时间戳目的MAC 地址源MAC地 址上层协议 类型Sniffer 会在捕获报文的时候自动记录捕获的时间，在解码显示时显示出来，在分析问题时提供了很好的时间记录。源目的 MAC 地址在解码框中可以将前 3 字节代表厂商的字段翻译出来，方便定位问题，例如网络上 2 台设备 IP 地址设置冲突，可以通过解码翻译出厂商信息方便的将故障设备找到，如 00e0fc 为华为，01004

4、2 为Cisco 等等。如果需要查看详细的 MAC 地址用鼠标在解码框中点击此MAC 地址，在下面的表格中会突出显示该地址的 16 进制编码。IP 网络来说 Ethertype 字段承载的时上层协议的类型主要包括 0x800 为IP 协议，0x806 为 ARP 协议。IEEE802.3 以太网报文结构LLC子层MAC子层DSAPSSAPControl8bit8bit8/16bitDMACSMACLengthLLCDATA/FCSIEEE802.3帧结构LLC子层MAC子层DSAPSSAPControl8bit8bit8/16bitDMACSMACLengthLLCDATA/FCSIEEE80

5、2.3帧结构上图为 IEEE802.3SNAP 帧结构，与 EthernetII 不通点是目的和源地址后面的字段代表的不是上层协议类型而是报文长度。并多了 LLC 子层。1.3 IP 协议IP 报文结构为 IP 协议头载荷，其中对 IP 协议头部的分析，时分析 IP报文的主要内容之一，关于 IP 报文详细信息请参考相关资料。这里给出了 IP 协议头部的一个结构。版本：4IPv4首部长度：单位为 4 字节，最大 60 字节TOS：IP 优先级字段总长度：单位字节，最大 65535 字节标识：IP 报文标识字段标志：占 3 比特，只用到低位的两个比特MF（More Fragment）MF=1，后面

6、还有分片的数据包MF=0，分片数据包的最后一个DF（Dont Fragment）DF=1，不允许分片DF=0，允许分片段偏移：分片后的分组在原分组中的相对位置，总共 13 比特，单位为8 字节寿命：TTL（Time To Live）丢弃 TTL=0 的报文协议：携带的是何种协议报文1 ：ICMP6 ：TCP17：UDP89：OSPF头部检验和：对 IP 协议首部的校验和源 IP 地址：IP 报文的源地址目的 IP 地址：IP 报文的目的地址上图为 Sniffer 对 IP 协议首部的解码分析结构，和 IP 首部各个字段相对应，并给出了各个字段值所表示含义的英文解释。如上图报文协议（Protoc

7、ol）字段的编码为 0x11，通过 Sniffer 解码分析转换为十进制的 17，代表 UDP 协议。其他字段的解码含义可以与此类似，只要对协议理解的比较清楚对解码内容的理解将会变的很容易。1.4 ARP 协议以下为 ARP 报文结构ARP 分组具有如下的一些字段：HTYPE（硬件类型）（硬件类型）。这是一个 16 比特字段，用来定义运行 ARP 的网络的类型。每一个局域网基于其类型被指派给一个整数。例如，以太网是类型 1。ARP 可使用在任何网络上。PTYPE（协议类型）（协议类型）。这是一个 16 比特字段，用来定义协议的类型。例如，对 IPv4 协议，这个字段的值是 0800。ARP 可

8、用于任何高层协议。HLEN（硬件长度）（硬件长度）。这是一个 8 比特字段，用来定义以字节为单位的物理地址的长度。例如，对以太网这个值是 6。PLEN（协议长度）（协议长度）。这是一个 8 比特字段，用来定义以字节为单位的逻辑地址的长度。例如，对 IPv4 协议这个值是 4。OPER（操作）（操作）。这是一个 16 比特字段，用来定义分组的类型。已定义了两种类型：ARP 请求（1），ARP 回答（2）。SHA（发送站硬件地址）（发送站硬件地址）。这是一个可变长度字段，用来定义发送站的物理地址的长度。例如，对以太网这个字段是 6 字节长。SPA（发送站协议地址）（发送站协议地址）。这是一个可变长

9、度字段，用来定义发送站的逻辑（例如，IP）地址的长度。对于 IP 协议，这个字段是 4 字节长。THA（目标硬件地址）（目标硬件地址）。这是一个可变长度字段，用来定义目标的物理地址的长度。例如，对以太网这个字段是 6 字节长。对于 ARP 请求报文，这个字段是全 0，因为发送站不知道目标的物理地址。TPA（目标协议地址）（目标协议地址）。这是一个可变长度字段，用来定义目标的逻辑地址（例如，IP 地址）的长度。对于 IPv4 协议，这个字段是 4 字节长。上面为通过 Sniffer 解码的 ARP 请求和应答报文的结构。1.5 PPPOE 协议PPPOE 简介简单来说我们可能把 PPPOE 报文

10、分成两大块，一大块是 PPPOE 的数据报头，另一块则是 PPPOE 的净载荷（数据域），对于 PPPOE 报文数据域中的内容会随着会话过程的进行而不断改变。下图为 PPPOE 的报文的格式：数据报文最开始的 4 位为版本域，协议中给出了明确的规定，这个域的内容填充 0x01。紧接在版本域后的 4 位是类型域，协议中同样规定，这个域的内容填充为 0x01。代码域占用 1 个字节，对于 PPPOE 的不同阶段这个域内的内容也是不一样的。会话 ID 点用 2 个字节，当访问集中器还未分配唯一的会话 ID 给用户主机的话，则该域内的内容必须填充为 0x0000，一旦主机获取了会话 ID 后，那么在后

11、续的所有报文中该域必须填充那个唯一的会话ID 值。长度域为 2 个字节，用来指示 PPPOE 数据报文中净载荷的长度。数据域，有时也称之为净载荷域，在 PPPOE 的不同阶段该域内的数据内容会有很大的不同。在 PPPOE 的发现阶段时，该域内会填充一些 Tag（标记）；而在 PPPOE 的会话阶段，该域则携带的是PPP 的报文。RadiusPPPOE172.16.20.76172.16.19.1/19ISN 8850RadiusPPPOE172.16.20.76172.16.19.1/19ISN 8850捕获报文测试用例图如图所示，Radius Server IP 地址为 172.16.20.

12、76。PPPOE 用户Radius 报文交互过程分析如下。上图为 PPPOE 从发现阶段到 PPP LCP 协商，认证 IPCP 协商阶段和PPPOE 会话阶段交互过程。PPPOE 发现阶段，PADI 报文，Sniffer 解码结构如下所示。PPPOE 发现阶段PPPOE PADI报文PPPOE发起端 MAC地址以太网填 充字节PPPOE TLV报文结构PPPOE 发现阶段PPPOE PADI报文PPPOE发起端 MAC地址以太网填 充字节PPPOE TLV报文结构PPPOE 会话阶段，Sniffer 解码结构如下所示。PPPOE会话 阶段PPPOE协议 头6bytesPPP协议头 2byte

13、s承载的IP协议 报文PPPOE Session ID号PPPOE会话 阶段PPPOE协议 头6bytesPPP协议头 2bytes承载的IP协议 报文PPPOE Session ID号1.6 Radius 协议Radius 报文简介标准 Radius 协议包结构图 9 Radius 包格式Code：包类型；1 字节；指示 RADIUS 包的类型。1 Access- request 认证请求 2 Access- accept 认证响应3 Access- reject 认证拒绝4 Accounting-request 计费请求5 Accounting-response 计费响应*11 Acces

14、s-challenge 认证挑战Identifier： 包标识；1 字节，取值范围为 0 255；用于匹配请求包和响应包，同一组请求包和响应包的 Identifier 应相同。Length： 包长度；2 字节；整个包中所有域的长度。Authenticator：16 字节长；用于验证 RADIUS 服务器传回来的请求以及密码隐藏算法上。该验证字分为两种：1、请求验证字-Request Authenticator用在请求报文中,必须为全局唯一的随机值。2、响应验证字-Response Authenticator用在响应报文中，用于鉴别响应报文的合法性。响应验证字MD5(Code+ID+Length

15、+请求验证字+Attributes+Key)Attributes：属性图 10 属性格式属性域是 TLV 结构编码。RadiusPPPOE172.16.20.76172.16.19.1/19ISN 8850RadiusPPPOE172.16.20.76172.16.19.1/19ISN 8850测试用例图下图为用户端 PPPOE，Radius Server 和 BAS 交互的认证上线和下线的过程。报文 1：BAS 请求 Radius Server 认证报文。报文 2：Radius Server 回应 BAS 认证通过报文。报文 3：BAS 计费请求报文。报文 4：Radius Server 计

16、费响应报文。报文 5：BAS 计费结束报文。报文 6：Radius Server 计费结束响应报文。从中可以看出对于报文请求和响应是通过 IP 地址+Radius 协议域中 ID号进行配对识别的。上图显示了 BAS 发起的 Radius 认证请求（Code1）报文的结构。Radius 报文是承载在 UPD 协议之上的，这里我没不关注上层报文的结构。下图为 PPPOE CHAP 认证过程的 Radius 认证请求报文和 PPPOE 中CHAP 认证的 Challenge 报文。通过比较可以方便看出 BAS 发出的Challenge 值为“26fe8768341de68a72a1276771e1c1ca”与 PPPOE中 CHAP 认证过程中 BAS 发给 PPPOE 用户的 Chall