上机教案2sniffer_数据报文解码详解

1Sniffer数据报文解码详解本章主要对：数据报文分层、以太报文结构、IP协议、ARP协议、PPPOE协议、Radius协议等的解码分析做了简单的描述，目的在于介绍Sniffer软件在协议分析中的功能作用并通过解码分析对协议进一步了解。对其其他协议读者可以通过协议文档和Sniffer捕获的报文对比分析。1、数据报文分层如下图所示，对于四层网络结构，其不同层次完成不通功能。每一层次有众多协议组成。如上图所示：在Sniffer的解码表中分别对每一个层次协议进行解码分析。链路层对应“DLC”；网络层对应“IP”；传输层对应“UDP”；应用层对对应的是“NETB”等高层协议。Sniffer可以针对众多协议进行详细结构化解码分析。并利用树形结构良好的表现出来。2、以太报文结构EthernetII以太网帧结构Ethernet_II以太网帧类型报文结构为：目的MAC地址（6bytes）＋源MAC地址＋（6bytes）上层协议类型（2bytes）＋数据字段（46-1500bytes)＋校验（4bytes）。应用层传输层网络层链路层TelnetFTP和e-mail等TCP和UDPIPICMPIGMP设备驱动程序及接口卡应用层传输层网络层链路层TelnetFTP和e-mail等TCP和UDPIPICMPIGMP设备驱动程序及接口卡Ethernet_IIDMACSMACTypeDATA/PADFCSEthernet_IIDMACSMACTypeDATA/PADFCS2Sniffer自动添加时间戳目的MAC地址源MAC地址上层协议类型Sniffer自动添加时间戳目的MAC地址源MAC地址上层协议类型Sniffer会在捕获报文的时候自动记录捕获的时间，在解码显示时显示出来，在分析问题时提供了很好的时间记录。源目的MAC地址在解码框中可以将前3字节代表厂商的字段翻译出来，方便定位问题，例如网络上2台设备IP地址设置冲突，可以通过解码翻译出厂商信息方便的将故障设备找到，如00e0fc为华为，010042为Cisco等等。如果需要查看详细的MAC地址用鼠标在解码框中点击此MAC地址，在下面的表格中会突出显示该地址的16进制编码。对IP网络来说Ethertype字段承载的上层协议的类型主要包括0x800为IP协议，0x806为ARP协议。IEEE802.3以太网报文结构。LLC子层MAC子层DSAPSSAPControl8bit8bit8/16bitDMACSMACLengthLLCDATA/FCSIEEE802.3帧结构LLC子层MAC子层DSAPSSAPControl8bit8bit8/16bitDMACSMACLengthLLCDATA/FCSIEEE802.3帧结构上图为IEEE802.3SNAP帧结构，与EthernetII不通点是目的和源地址后面的字段代表的不是上层协议类型而是报文长度。并多了LLC子层。3、IP协议IP报文结构为IP协议头＋载荷，其中对IP协议头部的分析，时分析IP报文的主要内容之一，关于IP报文详细信息请参考相关资料。这里给出了IP协议头部的一个结构。3版本：4——IPv4首部长度：单位为4字节，最大60字节TOS：IP优先级字段总长度：单位字节，最大65535字节标识：IP报文标识字段标志：占3比特，只用到低位的两个比特MF（MoreFragment）MF=1，后面还有分片的数据包MF=0，分片数据包的最后一个DF（Don'tFragment）DF=1，不允许分片DF=0，允许分片段偏移：分片后的分组在原分组中的相对位置，总共13比特，单位为8字节寿命：TTL（TimeToLive）丢弃TTL=0的报文协议：携带的是何种协议报文1：ICMP6：TCP17：UDP89：OSPF头部检验和：对IP协议首部的校验和源IP地址：IP报文的源地址目的IP地址：IP报文的目的地址上图为Sniffer对IP协议首部的解码分析结构，和IP首部各个字段相对应，并给出了各个字段值所表示含义的英文解释。如上图报文协议（Protocol）字段的编码为0x11，通过Sniffer解码分析转换为十进制的17，代表UDP协议。其他字段的解码含义可以与此类似，只要对协议理解的比较清楚对解码内容的理解将会变的很容易。44、ARP协议以下为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字节长。5上面为通过Sniffer解码的ARP请求和应答报文的结构。5、PPPOE协议PPPOE简介PPPoE（pointtopointprotocoloverEthernet）：以太网上的PPP。在以太网上承载PPP协议（点到点连接协议，为在点对点连接上传输多协议数据包提供了一个标准方法）。利用以太网将大量主机组成网络，通过一个远端接入设备连入因特网，并对接入的每一个主机实现控制、计费功能。极高的性能价格比使pppoe在包括小区组网建设等一系列应用中广泛采用简单来说我们可能把PPPOE报文分成两大块，一大块是PPPOE的数据报头，另一块则是PPPOE的净载荷（数据域），对于PPPOE报文数据域中的内容会随着会话过程的进行而不断改变。下图为PPPOE的报文的格式：数据报文最开始的4位为版本域，协议中给出了明确的规定，这个域的内容填充0x01。紧接在版本域后的4位是类型域，协议中同样规定，这个域的内容填充为0x01。代码域占用1个字节，对于PPPOE的不同阶段这个域内的内容也是不一样的。会话ID点用2个字节，当访问集中器还未分配唯一的会话ID给用户主机的话，则该域内的内容必须填充为0x0000，一旦主机获取了会话ID后，那么在后续的所有报文中该域必须填充那个唯一的会话ID值。长度域为2个字节，用来指示PPPOE数据报文中净载荷的长度。6数据域，有时也称之为净载荷域，在PPPOE的不同阶段该域内的数据内容会有很大的不同。在PPPOE的发现阶段时，该域内会填充一些Tag（标记）；而在PPPOE的会话阶段，该域则携带的是PPP的报文。捕获报文测试用例图如图所示，RadiusServerIP地址为172.16.20.76。PPPOE用户Radius报文交互过程分析如下。上图为PPPOE从发现阶段到PPPLCP协商，认证IPCP协商阶段和PPPOE会话阶段交互过程。PPPOE发现阶段，PADI报文，Sniffer解码结构如下所示。PPPOE发现阶段PPPOEPADI报文PPPOE发起端MAC地址以太网填充字节PPPOETLV报文结构PPPOE发现阶段PPPOEPADI报文PPPOE发起端MAC地址以太网填充字节PPPOETLV报文结构PPPOE会话阶段，Sniffer解码结构如下所示。7PPPOE会话阶段PPPOE协议头6bytesPPP协议头2bytes承载的IP协议报文PPPOESessionID号PPPOE会话阶段PPPOE协议头6bytesPPP协议头2bytes承载的IP协议报文PPPOESessionID号6、Radius协议Radius报文简介RADIUS：RemoteAuthenticationDialInUserService，远程用户拨号认证系统，是一项通用的认证计费协议。标准Radius协议包结构图9Radius包格式Code：包类型；1字节；指示RADIUS包的类型。1Access-request认证请求2Access-accept认证响应3Access-reject认证拒绝4Accounting-request计费请求5Accounting-response计费响应*11Access-challenge认证挑战Identifier：包标识；1字节，取值范围为0～255；用于匹配请求包和响应包，同一组请求包和响应包的8Identifier应相同。Length：包长度；2字节；整个包中所有域的长度。Authenticator：16字节长；用于验证RADIUS服务器传回来的请求以及密码隐藏算法上。该验证字分为两种：1、请求验证字---RequestAuthenticator用在请求报文中,必须为全局唯一的随机值。2、响应验证字---ResponseAuthenticator用在响应报文中，用于鉴别响应报文的合法性。响应验证字＝MD5(Code+ID+Length+请求验证字+Attributes+Key)Attributes：属性图10属性格式属性域是TLV结构编码。测试用例图下图为用户端PPPOE，RadiusServer和BAS交互的认证上线和下线的过程。报文1：BAS请求RadiusServer认证报文。报文2：RadiusServer回应BAS认证通过报文。报文3：BAS计费请求报文。报文4：RadiusServer计费响应报文。报文5：BAS计费结束报文。报文6：RadiusServer计费结束响应报文。从中可以看出对于报文请求和响应是通过IP地址+Radius协议域中ID号进行配对识别的。9上图显示了BAS发起的Radius认证请求（Code＝1）报文的结构。Radius报文是承载在UPD协议之上的，这里我没不关注上层报文的结构。下图为PPPOECHAP认证过程的Radius认证请求报文和PPPOE中CHAP认证的Challenge报文。通过比较可以方便看出BAS发出的Challenge值为“26fe8768341de68a72a1276771e1c1ca”与PPPOE中CHAP认证过程中BAS发给PPPOE用户的Challenge值是一致的。BAS发给Radius的CHAP-Challenge属性BAS发给Radius的CHAP-Challenge属性10下图为PPPOE用户发为BAS的经过CHAP加密后的用户密码和BAS发给RadiusServer中认证请求报文用户秘密属性域的比较。可以看出在Radius认证过程中，BAS设备将Challenge属性和用户加密后的密码发给Radius进行验证。PPPOE用户发给BAS的经过CHAP加密后的用户密码PPPOE用户发给BAS的经过CHAP加密后的用户密码通过比较可以清楚了解协议各字段含义相互关系，为问题处理提供有效的手段。