基于DPI的应用层协议解析

《基于DPI的应用层协议解析》由会员分享，可在线阅读，更多相关《基于DPI的应用层协议解析（36页珍藏版）》请在装配图网上搜索。

1、 摘要随着互联网在中国的迅速发展，全国各大网络运营商的网络规模都在不断扩张，网络结构日渐复杂，网络业务日趋丰富，网络流量高速增长，这使得网络管理的要求和难度都大大提高。因此，网络运营商需要利用协议分析对网络进行可靠、有效的监测与控制，而传统依靠端口识别的协议分析已经无法实现对协议的准确识别。在这种情况下，如何通过一种新的协议分析方法对网络进行流量控制、网络计费、内容过滤、以及流量管理，为用户提供一个良好的网络环境成为了一个热门的研究课题。首先，对应用层协议解析的研究现状和已有的检测方法进行了分析和介绍，在此基础上采用了深度包检测（DPI）技术对应用层协议解析；其次，对应用层协议解析系统的系统架

2、构及各子系统的功能做了概要介绍，同时将协议分析模块（包括HTTP分析、DHCP分析）作为核心模块详细加以说明；再次，对整个应用层协议解析做了详细设计，阐述了各个模块的设计原理及实现流程，并通过系统测试，证实了系统设计方案的可行性和正确性。最后，对研究工作进行了总结与展望，肯定了其研究意义和价值，同时也指出了系统存在的不足及今后的改进方向。关键词：深度包检测，应用层协议解析，数据包捕获函数库，超文本传输协议AbstractWith the rapid development of Internet in China, the major network operators, network si

3、ze in the ever-expanding, increasingly complex network structure, network operations are becoming increasingly rich, high-speed network traffic growth, which makes networkmanagement requirements and greatly increase thedifficulty.Therefore, network operators need to network a reliable effective moni

4、toring and control, in this case, how to protocol analysis of network flow control, network billing, content filtering, and traffic management, to provide users with a good network environment has become a hot research topic.First ,the artical has analysised on the research present situation and the

5、 existing detection method on the application layer protocol analysis, and based on this, it used the depth inspection packet (DPI) technology for application layer protocolanalysis;Second, the article given an overview on the system architecture of the application layer protocol analysis system and

6、 subsystem functions,and at the same time, it gaven a detailed description on the analysis of hypertext transfer protocol (HTTP: hypertext transport protocol) as the core module;Three, the article given a detailed design on the application layer protocol analysis system, described the design princip

7、les and processes of each module, and system testing, confirmed the feasibility of the system design.Finally, this paper summarized the research work and looking, ensured its significance and value, and also pointed out the shortcomings of the system and the future direction of the improvement.Keywo

8、rds：deep packet inspection, the application layer protocol analysis, libpcap, hypertext transfer protocol analysis 目录摘要IABSTRACTII1 绪言1.1 课题背景及研究的目的和意义11.2深度数据包检测(DPI)国内外研究概况21.3 应用层协议概述31.4论文的组织结构112 应用层协议解析系统设计方案的研究2.1 系统需求分析132.2 基于DPI的应用层协议解析系统设计方案142.3 协议分析系统设计方案152.4 系统开发语言、工具及环境163 基于DPI的应用层协

9、议解析与设计3.1数据包捕获模块173.2 HTTP分析模块233.3 DHCP分析模块254 系统测试4.1 测试指标284.2 测试环境284.3 测试步骤及结果分析285 总结与展望30致谢31参考文献32 1 绪言1.1 课题背景及研究的目的和意义1.1.1 课题背景在如今Internet高速发展，网络的内容安全是网络安全的重要组成部分。对于网络管理来说，最重要的就是识别和区分网络流量，通过协议识别可以对网络进行流量控制、网络计费、内容过滤、以及流量管理。传统的协议识别采用的是端口识别，如检测到端口号为80时，则认为该应用代表着普通上网应用。这种识别能达到较高的速率，但是现在大量的应用

10、层协议为了避免识别，逃避防火墙的检查，不使用固定的端口进行通信。这不仅包括众多近年新出现的P2P协议，而且包括了越来越多的传统协议，比如BitTorrent、eMule等P2P协议，其采用动态端口进行通信；而Skype、QQ等协议则共用80端口。并且当前网络上的一些非法应用会采用隐藏或假冒端口号的方式躲避检测和监管，造成仿冒合法报文的数据流侵蚀着网络2。越来越多诸如此类协议的产生，采用L2L4层的传统检测方法已无能为力了，因此近年来很多的研究工作都致力于开发新的方法来识别应用层协议。1.1.2 课题研究的目的和意义DPI（Deep Packet Inspection，深度包检测）技术就是近年来

11、出现的一种协议识别技术。DPI技术不同于传统的协议（如图1.1）。传统报文检测仅仅分析IP包的四层以下的内容，包括源地址、目的地址、源端口、目的端口以及协议类型。而是在在分析包头的基础上，增加了对应用层的分析，是一种基于应用层的流量检测和控制技术，当IP数据包、TCP或UDP数据流经过基于DPI技术的网络设备时，DPI引擎通过深入读取IP包载荷的内容来对OSI 7层协议中的应用层信息进行重组，从识别出IP包的应用层协议。随着对应用层协议解析的要求越来越高，对基于DPI的应用层协议解析技术的研究也变得越来越重要。图1.1 两种报文检测的区别1.2深度数据包检测(DPI)国内外研究概况深度数据包检

12、测(DPI)是一项已经在流量管理、安全和网络分析等方面获得成功的技术，同时该技术能够对网络数据包进行内容分析，但又与header或者基于元数据的数据包检测有所不同，这两种检测通常是由交换机、防火墙和入侵检测系统IPS设备来执行的。通常的DPI解决方案能够为不同的应用程序提供深度数据包检测。只针对header的处理限制了能够从数据包处理过程中看到的内容，并且不能够检测基于内容的威胁或者区分使用共同通信平台的应用程序。DPI能够检测出数据包的内容及有效负载并且能够提取出内容级别的信息，如恶意软件、具体数据和应用程序类型。随着网络运营商、互联网服务提供商(ISP)以及类似的公司越来越依赖于其网络以及

13、网络上运行的应用程序的效率，管理带宽和控制通信的复杂性以及安全的需要变得越来越重要。DPI恰好能够提供这些要求3，寻求更好的网络管理以及合规的用户企业应该把DPI作为一项重要的技术。DPI技术能够将数据包组装到网络的流量中20,23，数据处理(包括协议分类)接着可以从流量内容中提取信息，流量重组和内容提取都需要大量处理能力，尤其是在高流量的数据流中。成功的DPI技术必须能够提供基本功能，如高性能计算和对分析任务的灵活的支持。DPI的识别技术可以分为三大类：基于“特征字”的识别技术，应用层网关识别技术和行为模式识别技术。（1）基于“特征字”的识别技术1。不同的应用通常依赖于不同的协议，而不同的协

14、议都有其特殊的指纹，这些指纹可能是特定的端口、特定的字符串或者特定的Bit 序列。基于“特征字”的识别技术通过对业务流中特定数据报文中的“指纹”信息的检测以确定业务流承载的应用。根据具体检测方式的不同，基于“特征字”的识别技术又可以被分为固定位置特征字匹配、变动位置的特征匹配以及状态特征匹配三种技术。通过对“指纹”信息的升级，基于特征的识别技术可以很方便的进行功能扩展，实现对新协议的检测。（2）应用层网关识别技术。某些业务的控制流和业务流是分离的，业务流没有任何特征。这种情况下，我们就需要采用应用层网关识别技术。应用层网关需要先识别出控制流，并根据控制流的协议通过特定的应用层网关对其进行解析，

15、从协议内容中识别出相应的业务流。对于每一个协议，需要有不同的应用层网关对其进行分析。（3）行为模式识别技术。行为模式识别技术基于对终端已经实施的行为的分析，判断出用户正在进行的动作或者即将实施的动作。行为模式识别技术通常用于无法根据协议判断的业务的识别。1.3 应用层协议概述应用层（Application layer）是七层OSI模型4,5（如图1.2所示）的第七层。应用层直接和应用程序接口并提供常见的网络应用服务。下面对几种常见的应用层协议的通信过程进行简单的分析。1.3.1 HTTP协议HTTP协议6,7（hypertext transport protocol，超文本传输协议）是一个属于

16、应用层的面对对象协议，它是工作在TCP/IP协议体系的TCP(Transfer ControlProtocol, 传输控制协议)之上可靠传输，采用的是C/S（客户端/服务器）的工作模式，如图1.3所示。图1.2 OSI七层网络模型HTTP协议的通信过程如下：（1）由客户端向服务器发起建立链接的请求，请求过程通过 TCP三次握手来完成；（2）客户端继续向服务器发出请求，告知服务器自己的请求信息；（3）服务器通过响应向客户端返回其需要的信息；（4）最后通过 TCP 四次握手关闭链接，从而完成一次基本的通信过程。图1.3 HTTP工作模式图在HTTP通信过程中，HTTP 的请求报文分为请求行、请求头

17、部和请求数据三部分组成，一般格式如图 1.4 所示。请求方法空格URL空格协议版本换行符回车符换行符回车符头部字段名：值换行符回车符头部字段名：值换行符回车符实体主体（通常不用）请求头部请求数据请求行图1.4 HTTP请求报文一般格式其中请求方法是指当前 HTTP请求报文中对所请求的资源的操作类型，常用的方法8包括 GET、POST、HEAD、PUT、CONNECT、DELETE、TRACE和OPTION；URL (Uniform Resource Locator, 统一资源定位符)是统一资源定位符，用来指出请求资源的路径；请求头部说明了浏览器、服务器或者报文主体的一些信息。而HTTP 响应报

18、文的格式如图 1.5 所示。版本空格状态码空格解释状态码换行符回车符换行符回车符头部字段名：值换行符回车符头部字段名：值换行符回车符实体主体（部分响应不用）请求头部请求数据请求行图1.5 HTTP相应报文一般格式响应报文的一部分内容跟请求报文一致，不同的主要是状态码和解释状态码的短语。状态码是用来表示当服务器收到客户端的请求报文之后返回的一个响应状态，表示请求是否被理解或被满足。解释状态的短语是对前面状态码的进一步的说明。HTTP 协议有固定的状态码以及其表达的信息，分别是：1xx 表示信息类，2xx 表示成功类，3xx 表示重定向类，4xx 表示客户端错误类， 5xx 表示服务器错误类。1.

19、3.2 DHCP协议DHCP(Dynamic Host Configuration Protocol,动态主机设置协议)是TCP/IP协议簇中的一种，主要是用来给网络客户机分配动态的IP地址。DHCP协议的通信过程如下：（1）发现阶段，即dhcp客户端寻找dhcp服务器的阶段。客户端以广播方式发送dhcp_discover报文，只有dhcp服务器才会对此响应。 （2）提供阶段，即dhcp服务器提供ip地址的阶段。dhcp服务器接收到客户端的dhcp_discover报文后，从ip地址池中挑选一个尚未分配的ip地址分配给客户端，向该客户端发送包含出租ip地址和其它设置的dhcp_offer报文。

20、服务器在发送dhcp_offer报文之前，会以广播的方式发送arp报文进行地址探测，以保证发送给客户端的ip地址的唯一性。 （3）选择阶段，即dhcp客户端选择ip地址的阶段。如果有多台dhcp服务器向该客户端发来dhcp_offer报文，客户端只接受第一个收到的dhcp_offer报文，然后以广播方式向各dhcp服务器回应dhcp_request报文，该信息中包含dhcp服务器在dhcp_offer报文中分配的ip地址。（4）确认阶段，即dhcp客户端确认所提供ip地址的阶段。客户端收到dhcp_ack确认报文后，广播arp报文，目的地址是被分配的ip地址。如果在规定的时间内没有收到回应，客

21、户端才使用此地址。DHCP协议中传输的报文由链路层头（承载链路层信息），IP头（标准IP协议头，20B），UDP头（8B）和DHCP报文四部分组成。其中DHCP报文格式如图1.6所示。其中各字段的说明如下：op：报文的操作类型，分为请求报文和响应报文，1为请求报文；2为响应报文。具体的报文类型在 option字段中标识。htype：硬件地址类型。hlen：硬件地址长度。系统目前只对以太网支持，硬件地址长度固定为 6。hops：DHCP 报文经过的 DHCP 中继的数目。DHCP 请求报文每经过一个DHCP中继，该字段就会增加 1。图1.6 DHCP报文格式xid：由客户端软件产生的随机数，用于

22、匹配请求和应答报文。secs：客户端进入 IP 地址申请进程的时间或者更新 IP 地址进程的时间；由客户端软件根据情况设定。目前没有使用，固定为 0。flags：标志字段。第一个比特为广播响应标识位，用来标识 DHCP 服务器响应报文是采用单播还是广播方式发送，0 表示采用单播方式，1 表示采用广播方式。其余比特保留不用。ciaddr：DHCP客户端的 IP地址。yiaddr：DHCP服务器分配给客户端的 IP地址。siaddr：DHCP客户端获取 IP地址等信息的服务器 IP地址。giaddr：DHCP客户端发出请求报文后经过的第一个 DHCP中继的 IP地址。chaddr：DHCP客户端的

23、硬件地址。sname：DHCP客户端获取 IP地址等信息的服务器名称。file：DHCP服务器为 DHCP客户端指定的启动配置文件名称及路径信息。options：可选变长选项字段，包含报文的类型、有效租期、DNS 服务器的IP地址、WINS服务器的 IP地址等配置信息。1.3.3 FTP协议FTP 9（File Transfer Protocol，文件传输协议）支持两种模式：（1）Standard 模式(也就是PORT,主动模式),由FTP 的客户端发送 PORT 命令到 FTP 服务器（2）Passive 模式(也就是PASV,被动模式)，由 FTP 的客户端发送 PASV 命令到FTP 服

24、务器。两种模式的数据和控制链路都是分开传输的，但不同的地方在于主动模式由服务器端发起数据链路的链接请求，而被动模式由客户端发起数据链路的链接请求。FTP 的一个完整的通信过程10如图 1.7所示。图1.7 FTP通信过程从图中可以看出 FTP 通信过程中，控制链路和数据链路并不在同一个端口进行通信，而是通过两个不同的端口来独立地进行通信。主动模式下，FTP的通信过程如下：（1）由客户端通过TCP三次握手向服务器发起控制链接的请求；（2）当和服务器建立控制链接成功之后，在主动模式下客户端将会发一个端口号给服务器，告诉当前这次传输服务器所使用的数据传输端口；（3）服务器收到这个信息后就向客户端发起

25、数据链接请求，并开始传递数据；（4）数据传输完成后，该数据链路就被拆除了，如果客户端进行一次新的传输，则向服务器发送一个新的端口号，重新建立链接。在整个过程中，控制链路的链接一直都存在，直到 FTP 的整个通信过程结束，而数据链路每一次传输就需要建立一次新的链接。被动模式的通信过程和主动模式基本一致，只是由客户端发起数据链路的建立请求。在 FTP 交互的过程中，客户端通过命令字段来告诉服务器相关的信息，常用的有：（1）访问控制命令，包括USER，PASS，CWD，QUIT 等八种；（2）传输参数命令，包括PORT，PASV，TYPE， STRU，MODE 五种；（3）FTP 服务命令，包括 R

26、ETR,STOR,LIST,ABOR 等二十种。服务器端则通过状态码告诉客户端当前服务器的反馈状态。2xx 表示当前的操作成功，3xx 表示权限问题，4xx 表示文件问题，5xx 表示服务器问题。1.3.4SMTP协议SMTP11（Simple Mail Transfer Protocol,简单邮件传输协议）是一种提供可靠且有效的电子邮件传输协议。SMTP 是建模在 FTP 文件传输服务上的一种邮件服务，SMTP 服务器默认端口为25，主要用于传输系统之间的邮件信息。SMTP 交互过程12比较简单：（1）客户端向SMTP服务器的25端口发起请求，通过三次握手建立链接；（2）服务器返回 220

27、的状态码，告诉客户端服务准备成功；（3）客户端收到220状态码后向服务器发出 HELO 或者 EHLO 的命令告诉服务器该客户端需要的服务类型，其中 HELO 是默认的 SMTP 服务，EHLO 要求除了默认的服务之外还要支持扩展服务。（4）服务器向客户端返回它支持的服务，之后双方用命令字和状态码进行交互。SMTP 常用的命令字及其功能如表1.1所示。表 1.1 SMTP常用命令命令描述DATA开始信息写作EXPN验证给定的邮箱列表是否存在，扩充邮箱列表，也常被禁用HELO向服务器标识用户身份，返回邮件服务器身份HELP查询服务器支持什么命令，返回命令中的信息MAIL FROM在主机上初始化一

28、个邮件会话NOOP无操作，服务器应响应OKQUIT终止邮件会话RCPT TO标识单个的邮件接收人；常在MAIL命令后面可有多个rcpt toRSET重置会话，当前传输被取消SAML FROM发送邮件到用户终端和邮箱SEND FROM发送邮件到用户终端SOML FROM发送邮件到用户终端或邮箱TURN接收端和发送端交换角色VRFY用于验证指定的用户/邮箱是否存在；由于安全方面的原因，服务器常禁止此命令SMTP 协议中常用到的状态码有：220 表示服务就绪；221 表示服务关闭传输信道；250 表示要求的邮件操作完成； 550 要求的邮件操作未完成，邮箱目前不可以用（例如邮箱未找到或不可访问）；3

29、54开始邮件输入，以、结束13。1.3.5 POP3协议POP326（Post Office Protocol 3，邮局协议 3）协议适用于 C/S 架构模型的电子邮件协议，POP3 是此协议发展的第三版，它规定怎样将个人计算机连接到 Internet 的邮件服务器。它是因特网电子邮件的第一个离线协议，POP3协议允许用户从服务器上把邮件存储到本地主机（即自己的计算机）上，同时根据客户端的操作删除或保存在邮件服务器上的邮件，而 POP3 服务器则是遵循 POP3 协议的接收邮件服务器，用来接收电子邮件的。POP3 客户端向服务器发送命令并等待响应， POP3 命令采用命令行形式，用ASCII

30、码表示。服务器响应是由一个单独的命令行组成，或多个命令行组成，响应第一行以 ASCII 文本+OK 或-ERR 指出相应的操作状态是成功还是失败。在协议中有三种状态27：认可状态，处理状态，和更新状态。当客户机与服务器建立联系时，一旦客户机提供了自己身份并成功确认，即由认可状态转入处理状态，在完成相应的操作后客户机发出 quit 命令，则进入更新状态，更新之后最后重返认可状态（例如测试 sina 服务器时，输入 quit 将退出会话）。如下图 1.8所示。认可处理更新等待连接身份确认quit命令重新返回认可连接图 1.8 POP3 协议状态转换初始时，服务器通过侦听 POP3 的指定端口（默认

31、端口是 110）开始 POP3 服务，当客户主机需要使用服务时，它将与服务器主机建立连接。当连接建立后， POP3 服务器发送确认消息。客户和 POP3 服务器相互（分别）交换命令和响应，这一过程一直要持续到连接终止。POP3 命令由一个命令和一些参数组成28。所有命令以一个 CRLF 对结束。命令和参数由可打印的 ASCII 字符组成，它们之间由空格间隔。命令一般是三到四个字母，每个参数却可达 40 个字符长。POP3 响应由一个状态码和一个可能跟有附加信息的命令组成。所有响应也是由 CRLF 对结束。现在有两种状态码：确定(+OK)和失败 (-ERR)。对于特定命令的响应是由许多字符组成的

32、。在这些情况中，下面分别表述：在发送第一行响应和一个 CRLF 之后，任何的附加信息行发送，他们也由 CRLF 对结束。当所有信息发送结束时，发送最后一行，包括一个结束字符（十进制码 46，也就是.）和一个 CRLF 对。当检测多行响应时，客户检测以确认此行是否以结束字符开始。如果是的，而且其后的字符不是 CRLF，此行的第一个字符（结束字符）将被抛弃；如果其后紧跟 CRLF，从 POP 服务器来的响应终止，包括.CRLF 的行也不被认为是多行响应的一部分了。1.4论文的组织结构本文从5个方面着手对基于DPI的应用层协议解析系统的研究背景以及设计与实现作了详细的介绍。第1章介绍了基于深度包检测

33、（DPI）的应用层协议解析的研究背景和意义，并对深度包检测的国内外研究现状作了概要介绍，说明了基于DPI的应用层协议解析的基本原理，并归纳了基于DPI的应用层协议解析的基本方法，为后面详细介绍整个协议解析系统做铺垫；第2章根据整个系统的需求，提出了基于DPI的应用层解析系统的概要设计方案，并对协议分析模块的设计方案做了详细介绍，说明了该系统开发的语言、工具及环境；第3章根据第2章的系统设计，介绍了整个基于DPI的应用层协议解析系统的设计和实现。并且对应用层解析系统中的数据包捕获库模块、HTTP协议分析模块和DHCP协议分析模块做了详细介绍，并对其实现的核心技术点及算法做了详细分析；第4章结合实

34、际的测试环境，根据第2章提出的系统需求，归纳出了针对协议解析模块的测试目标，包括对功能需求、输入输出需求等多个方面的测试，最终测试结果基本符合各项要求，说明了整个基于DPI的应用层解析系统的可行性和正确性；第5章针对本文的研究内容做了自己的总结与展望，在肯定了论文研究的意义和价值的同时，也对基于DPI的应用层解析系统提出了改进建议。2 应用层协议解析系统设计方案的研究2.1 系统需求分析2.1.1 功能需求（1）能够通过抓去经过系统的数据包，并保存数据包文件，供后续解析模块使用。（2）通过对应用层协议的解析，识别出当前数据包中包含的应用层协议，以此对网络进行内容控制及管理。（3）支持多种应用层

35、协议解析，包括超文本传输协议（HTTP）、文件传输协议（FTP）、动态主机设置协议（DHCP）等等。（4）能够正确的解析应用层数据协议，给出解析的结果和分析报告。2.1.2 输入输出需求（1）输入需求数据包文件：通过数据包捕获系统得到的pcap格式数据包。（2）输出需求分析出的应用层数据协议信息，包括协议类型、该协议的字节数、数据包数等信息。2.1.3性能需求（1）系统要有较快处理速度，能够高效的进行协议解析。（2）系统应该稳定、健壮，能够独立的。（3）能够准确识别多种应用层协议，包括HTTP协议、FTP协议、DHCP协议等等。2.2 基于DPI的应用层协议解析系统设计方案整个基于DPI的应用

36、层解析系统的架构如图2.1所示。图 2.1 应用层协议解析系统架构图系统分为两个主要的子系统，各子系统的功能介绍如下：（1）数据包捕获系统，主要负责使用libpcap捕获网络数据包，得到pcap数据包文件，供协议分析系统使用。（2）协议分析系统，应用层协议解析系统的核心模块，主要负责使用深度包检测技术对各种应用层协议（例如：HTTP协议，FTP协议等等）进行分析，并打印分析结果。2.3 协议分析系统设计方案2.3.1 协议分析系统介绍数据包捕获系统协议分析系统传入数据包文件初始化模块设置要检测的协议初始化系统环境打开数据包文件数据包处理模块（调用各种协议的分析模块）HTTP协议FTP协议关闭数

37、据包文件输出分析结果图 2.2 协议分析系统流程图协议分析系统主要由初始化模块和数据包处理模块这两个核心模块组成。（1）初始化模块初始化模块主要负责处理传入的参数，根据参数设定需要解析的协议等等，它更重要的功能是初始化系统环境，比如对一些重要的数据结构进行初始化、对协议的回调函数进行绑定等等。（2）数据包处理模块这个模块主要负责各种协议的分析，是整个系统最核心的部分，它通过调用各个协议分析函数，对预先设定的协议进行分析。2.3.2 协议分析系统工作原理协议分析系统的工作流程详细介绍如下：(1) 将之前通过数据包捕获系统得到的pcap数据包传入协议分析系统。(2) 根据传入的参数设置需要分析的协

38、议类型。(3) 初始化环境，包括一些数据结构、回调函数等等。(4) 打开pcap数据包文件。(5) 调用需要的协议分析模块，对设定的协议进行分析。(6) 关闭pcap数据包文件。(7) 打印输出分析结果。2.4 系统开发语言、工具及环境2.4.1 系统开发语言根据项目整体设计要求，该项目需要运行在Linux系统下，程序采用C语言实现。2.4.2系统开发工具(1) 采用Linux下的文本编辑器vim以及Gedit；(2) Source Insight源代码管理和编辑器；(3) GCC编译器：gcc 3.4.3；(4) GDB调试器：gdb 6.5；2.4.3 系统开发环境(1) 硬件环境：双核核

39、处理器、2G内存(2) 操作系统：Fedora 14(3) 相关类库：pcap库等3 基于DPI的应用层协议解析与设计3.1数据包捕获模块系统中数据包捕获主要依赖libpcap（Packet Capture Library，数据包捕获函数库）来实现，libcap是一个独立于系统的用户层包捕获的API借口，下面介绍利用libpcap抓包的设计。3.1.1libcap工作原理libpcap主要由两部分构成：网络分接头（Network Tap）和数据过滤器（Package Filter）14。其中，网络分接头从网络设备驱动中收集数据拷贝，数据过滤器用来决定是否接收该数据包。libpcap 支持BPF

40、过滤机制15。BPF（BSD Packet Filter）是1993年初, S.McCanne 和V.Jacobson 等人推出的著名的包过滤器，它的基本工作步骤如下：当一个数据包到达网络接口时，数据链路层的驱动会把它向系统的协议栈传送。但如果 BPF 监听接口，驱动首先调用BPF；BPF 首先进行过滤操作，然后把数据包存放在过滤器相关的缓冲区中，根据用户定义的规则决定是否接收此数据包以及需要拷贝该数据包的哪些内容；最后将过滤后的数据给与过滤器相关联的上层应用程序，设备驱动再次获得控制。libpcap的包捕获机制16就是在数据链路层加一个旁路处理。当一个数据包到达网络接口时，libpcap首先

41、利用已经创建的Socket从链路层驱动程序中获得该数据包的拷贝，再通过Tap函数将数据包发给BPF过滤器。BPF过滤器根据用户已经定义好的过滤规则对数据包进行逐一匹配17，匹配成功则放入内核缓冲区，并传递给用户缓冲区，匹配失败则直接丢弃。如果没有设置过滤规则，所有数据包都将放入内核缓冲区，并传递给用户层缓冲区。3.1.2 libpcap的抓包框架（1）char *pcap_lookupdev(char *errbuf)，函数用于查找网络设备，并返回可被pcap_open_live()或pcap_lookupnet()函数调用的网络设备名指针。如果出错返回NULL；（2）pcap_t *pcap

42、_open_live(char *device, int snaplen, int promisc, int to_ms, char *ebuf)，函数用于打开网络设备，并且返回用于捕获网络数据包的数据包捕获描述字。device参数为指定打开的网络设备名。snaplen参数定义捕获数据的最大字节数。Promisc 指定是否将网络接口置于混杂模式。to_ms参数指*定超时时间（毫秒）。ebuf参数则仅在pcap_open_live()函数出错返回NULL时用于传递错误消息。对于此网络设备的操作都要基于此网络设备描述字。（3）int pcap_lookupnet(char *device, bpf

43、_u_int32 *netp,bpf_u_int32 *maskp, char *errbuf)，函数用于获得指定网络设备的网络号和掩码。其中，netp参数和maskp参数都是bpf_u_int32指针。如果出错，返回 -1；（4）int pcap_compile(pcap_t *p, struct bpf_program *fp,char *str, int optimize, bpf_u_int32 netmask)，函数用于将用户制定的过滤策略编译到过滤程序中。其中，：fp是一个bpf_program结构的指针，在pcap_compile()函数中被赋值。optimize参数控制结果代码

44、的优化。netmask参数指定本地网络的网络掩码。（5）int pcap_setfilter(pcap_t *p, struct bpf_program *fp)，函数用于设置过滤器。fp参数是bpf_program结构指针，通常取自pcap_compile()函数调用。出错时返回-1；成功时返回0。（6）int pcap_dispatch(pcap_t *p, int cnt,pcap_handler callback, u_char *user)和int pcap_loop(pcap_t *p, int cnt,pcap_handler callback, u_char *user)，都用

45、于捕获并处理数据包，不同的是pcap_loop（）在cnt个数据包被处理或出现错误时才返回，但读取超时不会返回。cnt参数指定函数返回前所处理数据包的最大值。（7）u_char *pcap_next(pcap_t *p, struct pcap_pkthdr *h)，函数用于获取下一个数据包，返回指向下一个数据包的u_char指针。（8）int pcap_stats(pcap_t *p, struct pcap_stat *ps)，函数用于向pcap_stat结构赋值。成功时返回0。这些数值包括了从开始捕获数据以来至今共捕获到的数据包统计。如果出错或不支持数据包统计，则返回-1，且可调用pca

46、p_perror()或pcap_geterr()函数来获取错误消息。3.1.3 libpcap工作流程基于libpcap总体框架， libpcap实现捕获数据包的流程基本如下：（1）设置设备，即选择嗅探接口。有两种方式，一种是用户通过传递参数来制指定设备；另一种是通过pcap_lookupdev( )函数自己查找设备；（2）打开设备进行嗅探，即创建一个嗅探任务，需要使用pcap_open_live（）函数；其中如果设置指定接口为混杂模式时，主机将嗅探整个传输线路上的所有通信，这样也是非常占用系统资源的房方式；非混杂模式只嗅探与主机直接相关的通信。（3）设定过滤规则，即将自己的过滤表达式保存为一

47、个字符数组，然后将字符数组编译到指定的过滤程序之中，整个过程通过使用pcap_compile()与pcap_setfilter()这两个函数完成。通过这个指定过滤程序，我们就可以自己定义一些过滤规则，对数据包进行符合自己要求的过滤操作。（4）嗅探，即进入主体执行数据包的捕获，捕获包有两种方式，一种利用pcap_next()函数一次只捕捉一个包，还有一种就是进入一个循环，捕捉多个包之后，再进行数据包处理。3.1.4 pcap数据包通过数据包捕捉系统的到就是pcap格式的数据包，pcap文件格式是常用的数据报存储格式，下面对这种格式的文件简单分析一下：pcap文件的格式如图 3.1 所示。文件头数

48、据包头1数据包1数据包头2数据包224字节16字节16字节图 3.1 pcap文件格式（1）pcap文件头，pcap headerpcap文件的文件头有24字节，主要用来存储pcap文件的基本信息，在pcap.h文件中定义了文件头的格式：struct pcap_file_header bpf_u_int32 magic;u_short version_major;u_short version_minor; bpf_int32 thiszone; bpf_u_int32 sigfigs; bpf_u_int32 snaplen; bpf_u_int32 linktype;pcap文件的头部具体

49、结构也就如上面结构体定义的一样，具体的结构图，如图 3.2 所示。thiszone 4Bsigfigs 4Bsnaplen 4Blinktype 4Bmajor 2Bminor 2Bmagic 4BPcap Header图3.2 pcap header 结构pcap文件头的各字段说明：Magic：4字节，01A 2B 3C 4D，用来识别文件自己和字节顺序。其中0xa1b2c3d4用来表示按照原来的顺序读取，0xd4c3b2a1表示下面的字节都要交换顺序读取。一般，我们使用0xa1b2c3d4Major：2字节，002 00，表示当前文件主要的版本号Minor：2字节，004 00，表示当前文

50、件次要的版本号ThisZone：4字节，表示时区。GMT和本地时间的相差，用秒来表示。如果本地的时区是GMT，那么这个值就设置为0.这个值一般也设置为0 SigFigs：4B时间戳的精度；全零SnapLen：4字节，表示最大的存储长度（该值设置所抓获的数据包的最大长度，如果所有数据包都要抓获，将该值设置为65535；例如：想获取数据包的前64字节，可将该值设置为64）LinkType：4字节，表示链路类型（2）数据报头，packet包头packet包头格式为：struct pcap_pkthdr struct timeval ts;bpf_u_int32 caplen;bpf_u_int32

51、len;struct timeval longtv_sec;suseconds_ttv_usec;packet包头具体结构如图3.3所示。packet headertimestamp 4Blen 4Bcaplen 4Btimestamp 4B图3.3 packet包头结构图packet包头字段说明：Timestamp：时间戳高位，精确到seconds（值是自从January 1, 1970 00:00:00 GMT以来的秒数来记）Timestamp：时间戳低位，精确到microseconds （数据包被捕获时候的微秒（microseconds）数，是自ts-sec的偏移量）Caplen：当前数

52、据区的长度，即抓取到的数据帧长度，由此可以得到下一个数据帧的位置。Len：离线数据长度：网络中实际数据帧的长度，一般不大于caplen，多数情况下和Caplen数值相等。（3）数据包，packet数据packet数据就是数据包的具体内容，通常就是链路层的数据帧。数据报的长度就是caplen，这个长度的后面，就是当前pcap文件中存放的下一个Packet数据包。因此，PCAP文件里面并没有规定捕获的Packet数据包之间有什么间隔字符串，下一组数据在文件中的起始位置。数据包的格式如图3.4所示。0123456789ABCDEF数据包包头，包含一些文件信息（24字节）数据包包头数据报报头（16字节

53、）以太网帧头（14字节）以太网帧头IP头（20字节）IP头TCP头TCP头（20字节）数据域数据域数据报报头下一个数据报的以太网帧头以太网帧头下一个数据报IP头IP头TCP头TCP头数据域数据域数据报报头图 3.4 数据包的基本格式3.2 HTTP分析模块3.2.1 协议分析的初始化协议分析所有的初始化工作都在函数setupDetection()中，其流程图如图3.5所示。图3.5 协议分析初始化流程图初始化过程具体流程是：（1）初始ipq_struct，即定义ipoque_init_detection_module，作用是用malloc函数分配了一个ipoque_detection_modu

54、le_struct，该结构体中的许多成员被设定成了默认值。并返回指向该结构体的指针。（2）为数组osdpi_ids 和osdpi_flows 分配空间。osdpi_ids 用来存储每一个IP 地址及其信息；osdpi_flows 用来储存每一个数据流及其信息。（3）设置要检查的协议，设置检查全部协议，通过IPOQUE_PROTOCOL_BITMASK all和IPOQUE_BITMASK_SET_ALL(all)实现。（4）设置调用协议规则库时的初始条件和函数入口地址，这里主要设置ipq_call_function_struct 结构，通过函数 ipoque_set_protocol_dete

55、ction_bitmask2(ipoque_struct, &all);实现。（5）将所有待分析协议分类划分。根据TCP/IP 协议栈的下4 层结构，将需要识别的协议进行分类，这样可以减少调用协议识别函数的数目，提高识别速度。比如DHCP协议只需要调用UDP上的协议。3.2.2 HTTP协议分析过程（1）HTTP分析模块分析的是pcap文件格式的数据报17，当传入数据包时捕获数据包时所加的帧头，记录捕获的时间，然后继续分析它的上层协议 IP 的数据包头。（2）通过IP数据包头中IP地址，使用get_id（）函数，查找全局变量osdpi_ids，如果IP地址不存在，则创建一个与指定IP地址相关联

56、的id。（3）继续分析数据包，在数组osdpi_flow中查找当前数据流，若不存在，则加入数组。实现代码如下：flow = get_osdpi_flow(iph, ipsize); /查找当前数据流if (flow != NULL) ipq_flow = flow-ipoque_flow;（4）接着对unfragmented的数据包进行处理，然后调用ipq_init_packet_header(ipoque_struct, packetlen)函数，对数据包按TCP、UDP和其他分类进行解析，针对TCP 还需要进行流的判断。（5）设置ipoque_struct中的数据包和flow的状态，分析数

57、据流的连接信息，判断数据流是上行还是下行，针对TCP 还需要设置流的发送序号seq 和确认序号ack，并判断是否进行了重传。（6）在ipoque_struct 结构中保存中间结果，调用协议识别函数18进行协议的分析。3.3DHCP分析模块3.3.1 DHCP报文类型DHCP共有八种报文，分别为DHCP Discover、DHCP Offer、DHCP Request、DHCP ACK、DHCP NAK、DHCP Release、DHCP Decline、DHCP Inform。各种报文类型功能如表 3.1 所示。表3.1 DHCP报文类型的基本功能DHCP报文类型描述DHCP DISCOVER

58、( 0x01)此为Client开始DHCP过程的第一个报文，目的是发现网络中的DHCP服务器，所有收到DISCOVER报文的DHCP服务器都会发送回应报文，DHCP客户端据此可以知道网络中存在的DHCP服务器的位置。DHCP OFFER( 0x02)此为Server对DHCPDISCOVER报文的响应，DHCP服务器收到DISCOVERr报文后，就会在所配置的地址池中查找一个合适的IP地址，加上相应的租约期限和其他配置信息（如网关、DNS服务器等），构造一个OFFER报文，发送给用户，告知用户本服务器可以为其提供IP地址。DHCP REQUEST( 0x03)此报文是Slient开始DHCP过

59、程中对server的DHCPOFFER报文的回应，DHCP客户端成功获取IP地址后，在地址使用租期过去1/2时，会向DHCP服务器发送单播REQUEST报文续延租期，如果没有收到DHCP ACK报文，在租期过去3/4时，发送广播REQUEST报文续延租期。DHCP DECLINE( 0x04)当Client发现Server分配给它的IP地址无法使用，如IP地址冲突时，将发出此报文，通知Server禁止使用IP地址。DHCP ACK( 0x05)Server对Client的DHCPREQUEST报文的确认响应报文，Client收到此报文后，才真正获得了IP地址和相关的配置信息。DHCP NAK(

60、 0x06)Server对Client的DHCPREQUEST报文的拒绝响应报文，Client收到此报文后，一般会重新开始新的DHCP过程。DHCP RELEASE( 0x07)Client主动释放server分配给它的IP地址的报文，当Server收到此报文后，就可以回收这个IP地址，能够分配给其他的Client。DHCP INFORM( 0x08)Client已经获得了IP地址，发送此报文，只是为了从DHCP SERVER处获取其他的一些网络配置信息，如route ip，DNS Ip等，这种报文极少用到。3.3.2 DHCP报文特征通过分析DHCP报文格式，我们可以得到以下DHCP协议的五

61、种特征值：(1) 数据包的payload长度不小于244，根据1.3.2节所述，可以的清楚看出。(2) 数据包的目的端口为67或68。(3) DHCP客户端的端口为68，服务器端的端口为67。(4) DHCP协议类型的packet-payload区中第236位开始取四个字节，MagicCookie位的值为DHCP。(5) DHCP协议类型的packet-payload区中第240位开始取两个字节，确认DHCP Message类型为53且长度为1。当五个特征值完全符合时，就可以判断当前数据报属于DHCP协议。3.3.3 DHCP分析流程DHCP模块，协议分析流程图如图3.6所示。其中，判断部分的核心代码如下：if(packet-payload_packet_len = 244 & (packet-udp-source = htons(67) | packet-udp-source = htons(68) & (packet-udp-dest = htons(67) | packet-udp-dest = htons(68)& get_u32(pa