毕业设计(论文)-基于DPI的应用层协议解析.doc_第1页
毕业设计(论文)-基于DPI的应用层协议解析.doc_第2页
毕业设计(论文)-基于DPI的应用层协议解析.doc_第3页
毕业设计(论文)-基于DPI的应用层协议解析.doc_第4页
毕业设计(论文)-基于DPI的应用层协议解析.doc_第5页
已阅读5页,还剩35页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

i 摘摘要要 随着互联网在中国的迅速发展,全国各大网络运营商的网络规模都在不 断扩张,网络结构日渐复杂,网络业务日趋丰富,网络流量高速增长,这使 得网络管理的要求和难度都大大提高。因此,网络运营商需要利用协议分析 对网络进行可靠、有效的监测与控制,而传统依靠端口识别的协议分析已经 无法实现对协议的准确识别。在这种情况下,如何通过一种新的协议分析方 法对网络进行流量控制、网络计费、内容过滤、以及流量管理,为用户提供 一个良好的网络环境成为了一个热门的研究课题。 首先,对应用层协议解析的研究现状和已有的检测方法进行了分析和介 绍,在此基础上采用了深度包检测(dpi)技术对应用层协议解析;其次, 对应用层协议解析系统的系统架构及各子系统的功能做了概要介绍,同时将 协议分析模块(包括 http 分析、dhcp 分析)作为核心模块详细加以说明; 再次,对整个应用层协议解析做了详细设计,阐述了各个模块的设计原理及 实现流程,并通过系统测试,证实了系统设计方案的可行性和正确性。最后, 对研究工作进行了总结与展望,肯定了其研究意义和价值,同时也指出了系 统存在的不足及今后的改进方向。 关键词:关键词:深度包检测,应用层协议解析,数据包捕获函数库, 超文本传输协议 ii abstract with the rapid development of internet in china, the major network operators, network size 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 monitoring 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 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 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 principles 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. keywords:deep packet inspection, the application layer protocol analysis, libpcap, hypertext transfer protocol analysis iii 目录目录 摘要i abstractii 1 绪言 1.1 课题背景及研究的目的和意义.1 1.2 深度数据包检测(dpi)国内外研究概况.2 1.3 应用层协议概述.3 1.4 论文的组织结构11 2 应用层协议解析系统设计方案的研究 2.1 系统需求分析.13 2.2 基于 dpi 的应用层协议解析系统设计方案 14 2.3 协议分析系统设计方案.15 2.4 系统开发语言、工具及环境.16 3 基于 dpi 的应用层协议解析与设计 3.1 数据包捕获模块17 3.2 http 分析模块.23 3.3 dhcp 分析模块25 4 系统测试 4.1 测试指标.28 4.2 测试环境.28 4.3 测试步骤及结果分析.28 5 总结与展望30 致谢31 参考文献32 1 1 绪绪言言 1.1 课题背景及研究的目的和意义课题背景及研究的目的和意义 1.1.1 课题背景课题背景 在如今 internet 高速发展,网络的内容安全是网络安全的重要组成部分。 对于网络管理来说,最重要的就是识别和区分网络流量,通过协议识别可以 对网络进行流量控制、网络计费、内容过滤、以及流量管理。 传统的协议识别采用的是端口识别,如检测到端口号为 80 时,则认为该 应用代表着普通上网应用。这种识别能达到较高的速率,但是现在大量的应 用层协议为了避免识别,逃避防火墙的检查,不使用固定的端口进行通信。 这不仅包括众多近年新出现的 p2p 协议,而且包括了越来越多的传统协议, 比如 bittorrent、emule 等 p2p 协议,其采用动态端口进行通信;而 skype、qq 等协议则共用 80 端口。并且当前网络上的一些非法应用会采用 隐藏或假冒端口号的方式躲避检测和监管,造成仿冒合法报文的数据流侵蚀 着网络2。越来越多诸如此类协议的产生,采用 l2l4 层的传统检测方法已 无能为力了,因此近年来很多的研究工作都致力于开发新的方法来识别应用 层协议。 1.1.2 课题研究的目的和意义课题研究的目的和意义 dpi(deep packet inspection,深度包检测)技术就是近年来出现的一种 协议识别技术。dpi 技术不同于传统的协议(如图 1.1) 。 传统报文检测仅仅分析 ip 包的四层以下的内容,包括源地址、目的地址、 源端口、目的端口以及协议类型。而是在在分析包头的基础上,增加了对应 用层的分析,是一种基于应用层的流量检测和控制技术,当 ip 数据包、tcp 或 udp 数据流经过基于 dpi 技术的网络设备时,dpi 引擎通过深入读取 ip 包载荷的内容来对 osi 7 层协议中的应用层信息进行重组,从识别出 ip 包的 应用层协议。 随着对应用层协议解析的要求越来越高,对基于 dpi 的应用层协议解析 技术的研究也变得越来越重要。 2 图 1.1 两种报文检测的区别 1.2 深度数据包检测深度数据包检测(dpi)国内外研究概况国内外研究概况 深度数据包检测(dpi)是一项已经在流量管理、安全和网络分析等方面获 得成功的技术,同时该技术能够对网络数据包进行内容分析,但又与 header 或者基于元数据的数据包检测有所不同,这两种检测通常是由交换机、防火 墙和入侵检测系统 ips 设备来执行的。通常的 dpi 解决方案能够为不同的应 用程序提供深度数据包检测。只针对 header 的处理限制了能够从数据包处理 过程中看到的内容,并且不能够检测基于内容的威胁或者区分使用共同通信 平台的应用程序。dpi 能够检测出数据包的内容及有效负载并且能够提取出 内容级别的信息,如恶意软件、具体数据和应用程序类型。 随着网络运营商、互联网服务提供商(isp)以及类似的公司越来越依赖于 其网络以及网络上运行的应用程序的效率,管理带宽和控制通信的复杂性以 及安全的需要变得越来越重要。dpi 恰好能够提供这些要求3,寻求更好的 网络管理以及合规的用户企业应该把 dpi 作为一项重要的技术。 dpi 技术能够将数据包组装到网络的流量中20,23,数据处理(包括协议分 类)接着可以从流量内容中提取信息,流量重组和内容提取都需要大量处理能 力,尤其是在高流量的数据流中。成功的 dpi 技术必须能够提供基本功能, 如高性能计算和对分析任务的灵活的支持。 dpi 的识别技术可以分为三大类:基于“特征字”的识别技术,应用层网 3 关识别技术和行为模式识别技术。 (1)基于“特征字”的识别技术1。不同的应用通常依赖于不同的协议, 而不同的协议都有其特殊的指纹,这些指纹可能是特定的端口、特定的字符 串或者特定的 bit 序列。基于“特征字”的识别技术通过对业务流中特定数据 报文中的“指纹”信息的检测以确定业务流承载的应用。 根据具体检测方式的不同,基于“特征字”的识别技术又可以被分为固定 位置特征字匹配、变动位置的特征匹配以及状态特征匹配三种技术。通过对 “指纹”信息的升级,基于特征的识别技术可以很方便的进行功能扩展,实现 对新协议的检测。 (2)应用层网关识别技术。某些业务的控制流和业务流是分离的,业务 流没有任何特征。这种情况下,我们就需要采用应用层网关识别技术。应用 层网关需要先识别出控制流,并根据控制流的协议通过特定的应用层网关对 其进行解析,从协议内容中识别出相应的业务流。对于每一个协议,需要有 不同的应用层网关对其进行分析。 (3)行为模式识别技术。行为模式识别技术基于对终端已经实施的行为 的分析,判断出用户正在进行的动作或者即将实施的动作。行为模式识别技 术通常用于无法根据协议判断的业务的识别。 1.3 应用层协议概述应用层协议概述 应用层(application layer)是七层 osi 模型4,5(如图 1.2 所示)的第七 层。应用层直接和应用程序接口并提供常见的网络应用服务。下面对几种常 见的应用层协议的通信过程进行简单的分析。 1.3.1 http 协议协议 http 协议6,7(hypertext transport protocol,超文本传输协议)是一个属于应用层 的面对对象协议,它是工作在 tcp/ip 协议体系的 tcp(transfer control protocol, 传输控制协议)之上可靠传输,采用的是 c/s(客户端/服务器)的工作模 式,如图 1.3 所示。 4 图 1.2 osi 七层网络模型 http 协议的通信过程如下: (1)由客户端向服务器发起建立链接的请求,请求过程通过 tcp 三次握手 来完成; (2)客户端继续向服务器发出请求,告知服务器自己的请求信息; (3)服务器通过响应向客户端返回其需要的信息; (4)最后通过 tcp 四次握手关闭链接,从而完成一次基本的通信过程。 图 1.3 http 工作模式图 在 http 通信过程中,http 的请求报文分为请求行、请求头部和请求 数据三部分组成,一般格式如图 1.4 所示。 5 请求方法空格url空格协议版本换行符回车符 换行符回车符 头部字段名:值换行符回车符 头部字段名:值换行符回车符 实体主体(通常不用) 请求头部 请求数据 请求行 图 1.4 http 请求报文一般格式 其中请求方法是指当前 http 请求报文中对所请求的资源的操作类型, 常用的方法8包括 get、post、head、put、connect、delete、trace 和 option;url (uniform resource locator, 统一资源定位符)是统一资源定位 符,用来指出请求资源的路径;请求头部说明了浏览器、服务器或者报文主 体的一些信息。 而 http 响应报文的格式如图 1.5 所示。 版本空格状态码空格解释状态码换行符回车符 换行符回车符 头部字段名:值换行符回车符 头部字段名:值换行符回车符 实体主体(部分响应不用) 请求头部 请求数据 请求行 图 1.5 http 相应报文一般格式 响应报文的一部分内容跟请求报文一致,不同的主要是状态码和解释状 态码的短语。状态码是用来表示当服务器收到客户端的请求报文之后返回的 一个响应状态,表示请求是否被理解或被满足。解释状态的短语是对前面状 态码的进一步的说明。http 协议有固定的状态码以及其表达的信息,分别 是:1xx 表示信息类,2xx 表示成功类,3xx 表示重定向类,4xx 表示客户 6 端错误类, 5xx 表示服务器错误类。 1.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 报文。服务器在发送 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 地址。 如果在规定的时间内没有收到回应,客户端才使用此地址。 dhcp 协议中传输的报文由链路层头(承载链路层信息) ,ip 头(标准 ip 协议头,20b) ,udp 头(8b)和 dhcp 报文四部分组成。其中 dhcp 报 文格式如图 1.6 所示。 其中各字段的说明如下: op:报文的操作类型,分为请求报文和响应报文,1 为请求报文;2 为 响应报文。具体的报文类型在 option 字段中标识。 htype:硬件地址类型。 hlen:硬件地址长度。系统目前只对以太网支持,硬件地址长度固定为 6。 hops:dhcp 报文经过的 dhcp 中继的数目。dhcp 请求报文每经过 一个 dhcp 中继,该字段就会增加 1。 7 图 1.6 dhcp 报文格式 xid:由客户端软件产生的随机数,用于匹配请求和应答报文。 secs:客户端进入 ip 地址申请进程的时间或者更新 ip 地址进程的时间; 由客户端软件根据情况设定。目前没有使用,固定为 0。 flags:标志字段。第一个比特为广播响应标识位,用来标识 dhcp 服务 器响应报文是采用单播还是广播方式发送,0 表示采用单播方式,1 表示采用广播方式。其余比特保留不用。 ciaddr:dhcp 客户端的 ip 地址。 yiaddr:dhcp 服务器分配给客户端的 ip 地址。 siaddr:dhcp 客户端获取 ip 地址等信息的服务器 ip 地址。 giaddr:dhcp 客户端发出请求报文后经过的第一个 dhcp 中继的 ip 地址。 chaddr:dhcp 客户端的硬件地址。 sname:dhcp 客户端获取 ip 地址等信息的服务器名称。 file:dhcp 服务器为 dhcp 客户端指定的启动配置文件名称及路径信息。 options:可选变长选项字段,包含报文的类型、有效租期、dns 服务器的 ip 地址、wins 服务器的 ip 地址等配置信息。 8 1.3.3 ftp 协议协议 ftp 9(file transfer protocol,文件传输协议)支持两种模式: (1)standard 模式(也就是 port,主动模式),由 ftp 的客户端发送 port 命令到 ftp 服务器 (2)passive 模式(也就是 pasv,被动模式),由 ftp 的客户端发送 pasv 命令到 ftp 服务器。 两种模式的数据和控制链路都是分开传输的,但不同的地方在于主动模 式由服务器端发起数据链路的链接请求,而被动模式由客户端发起数据链路 的链接请求。 ftp 的一个完整的通信过程10如图 1.7 所示。 图 1.7 ftp 通信过程 从图中可以看出 ftp 通信过程中,控制链路和数据链路并不在同一个 端口进行通信,而是通过两个不同的端口来独立地进行通信。 主动模式下,ftp 的通信过程如下: (1)由客户端通过 tcp 三次握手向服务器发起控制链接的请求; (2)当和服务器建立控制链接成功之后,在主动模式下客户端将会发一 个端口号给服务器,告诉当前这次传输服务器所使用的数据传输端 口; (3)服务器收到这个信息后就向客户端发起数据链接请求,并开始传递 数据; (4)数据传输完成后,该数据链路就被拆除了,如果客户端进行一次新 的传输,则向服务器发送一个新的端口号,重新建立链接。 9 在整个过程中,控制链路的链接一直都存在,直到 ftp 的整个通信过 程结束,而数据链路每一次传输就需要建立一次新的链接。 被动模式的通信过程和主动模式基本一致,只是由客户端发起数据链路 的建立请求。 在 ftp 交互的过程中,客户端通过命令字段来告诉服务器相关的信息, 常用的有: (1)访问控制命令,包括 user,pass,cwd,quit 等八种; (2)传输参数命令,包括 port,pasv,type, stru,mode 五种; (3)ftp 服务命令,包括 retr,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 的状态码,告诉客户端服务准备成功; (3)客户端收到 220 状态码后向服务器发出 helo 或者 ehlo 的命令 告诉服务器该客户端需要的服务类型,其中 helo 是默认的 smtp 服务,ehlo 要求除了默认的服务之外还要支持扩展服务。 (4)服务器向客户端返回它支持的服务,之后双方用命令字和状态码进 行交互。 smtp 常用的命令字及其功能如表 1.1 所示。 表 1.1 smtp 常用命令 命令描述 data开始信息写作 10 expn验证给定的邮箱列表是否存在, 扩充邮箱列表,也常被禁用 helo向服务器标识用户身份,返回邮 件服务器身份 help 查询服务器支持什么命令,返回 命令中的信息 mail from在主机上初始化一个邮件会话 noop无操作,服务器应响应 ok quit终止邮件会话 rcpt to标识单个的邮件接收人;常在 mail 命令后面可有多个 rcpt to rset重置会话,当前传输被取消 saml from发送邮件到用户终端和邮箱 send from发送邮件到用户终端 soml from发送邮件到用户终端或邮箱 turn接收端和发送端交换角色 vrfy用于验证指定的用户/邮箱是否存 在;由于安全方面的原因, 服务器常禁止此命令 smtp 协议中常用到的状态码有:220 表示服务就绪;221 表示服务关 闭传输信道;250 表示要求的邮件操作完成; 550 要求的邮件操作未完成, 邮箱目前不可以用(例如邮箱未找到或不可访问) ;354 开始邮件输入,以 、结束13。 1.3.5 pop3 协议协议 pop326(post office protocol 3,邮局协议 3)协议适用于 c/s 架构模 型的电子邮件协议,pop3 是此协议发展的第三版,它规定怎样将个人计算 机连接到 internet 的邮件服务器。它是因特网电子邮件的第一个离线协议, pop3 协议允许用户从服务器上把邮件存储到本地主机(即自己的计算机) 11 上,同时根据客户端的操作删除或保存在邮件服务器上的邮件,而 pop3 服 务器则是遵循 pop3 协议的接收邮件服务器,用来接收电子邮件的。 pop3 客户端向服务器发送命令并等待响应, pop3 命令采用命令行形 式,用 ascii 码表示。服务器响应是由一个单独的命令行组成,或多个命令 行组成,响应第一行以 ascii 文本+ok 或-err 指出相应的操作状态是成 功还是失败。 在协议中有三种状态27:认可状态,处理状态,和更新状态。当客户机 与服务器建立联系时,一旦客户机提供了自己身份并成功确认,即由认可状 态转入处理状态,在完成相应的操作后客户机发出 quit 命令,则进入更新 状态,更新之后最后重返认可状态(例如测试 sina 服务器时,输入 quit 将 退出会话) 。如下图 1.8 所示。 认可处理更新 等待连接 身份确认quit 命令 重新返回认可连接 图 1.8 pop3 协议状态转换 初始时,服务器通过侦听 pop3 的指定端口(默认端口是 110)开始 pop3 服务,当客户主机需要使用服务时,它将与服务器主机建立连接。当 连接建立后, pop3 服务器发送确认消息。客户和 pop3 服务器相互(分 别)交换命令和响应,这一过程一直要持续到连接终止。 pop3 命令由一个命令和一些参数组成28。所有命令以一个 crlf 对结 束。命令和参数由可打印的 ascii 字符组成,它们之间由空格间隔。命令 一般是三到四个字母,每个参数却可达 40 个字符长。pop3 响应由一个状 态码和一个可能跟有附加信息的命令组成。所有响应也是由 crlf 对结束。 现在有两种状态码:确定(“+ok“)和失败 (“-err“)。 对于特定命令的响应是由许多字符组成的。在这些情况中,下面分别表 述:在发送第一行响应和一个 crlf 之后,任何的附加信息行发送,他们也 由 crlf 对结束。当所有信息发送结束时,发送最后一行,包括一个结束字 12 符(十进制码 46,也就是“.“)和一个 crlf 对。当检测多行响应时,客户 检测以确认此行是否以结束字符开始。如果是的,而且其后的字符不是 crlf,此行的第一个字符(结束字符)将被抛弃;如果其后紧跟 crlf,从 pop 服务器来的响应终止,包括.crlf 的行也不被认为是多行响应的一部 分了。 1.4 论文的组织结构论文的组织结构 本文从 5 个方面着手对基于 dpi 的应用层协议解析系统的研究背景以及 设计与实现作了详细的介绍。 第 1 章介绍了基于深度包检测(dpi)的应用层协议解析的研究背景和 意义,并对深度包检测的国内外研究现状作了概要介绍,说明了基于 dpi 的 应用层协议解析的基本原理,并归纳了基于 dpi 的应用层协议解析的基本方 法,为后面详细介绍整个协议解析系统做铺垫; 第 2 章根据整个系统的需求,提出了基于 dpi 的应用层解析系统的概要 设计方案,并对协议分析模块的设计方案做了详细介绍,说明了该系统开发 的语言、工具及环境; 第 3 章根据第 2 章的系统设计,介绍了整个基于 dpi 的应用层协议解析 系统的设计和实现。并且对应用层解析系统中的数据包捕获库模块、http 协议分析模块和 dhcp 协议分析模块做了详细介绍,并对其实现的核心技术 点及算法做了详细分析; 第 4 章结合实际的测试环境,根据第 2 章提出的系统需求,归纳出了针 对协议解析模块的测试目标,包括对功能需求、输入输出需求等多个方面的 测试,最终测试结果基本符合各项要求,说明了整个基于 dpi 的应用层解析 系统的可行性和正确性; 第 5 章针对本文的研究内容做了自己的总结与展望,在肯定了论文研究 的意义和价值的同时,也对基于 dpi 的应用层解析系统提出了改进建议。 13 2 应用层协议解析系统设计方案的研究应用层协议解析系统设计方案的研究 2.1 系统需求分析系统需求分析 2.1.1 功能需求功能需求 (1)能够通过抓去经过系统的数据包,并保存数据包文件,供后续解析模块 使用。 (2)通过对应用层协议的解析,识别出当前数据包中包含的应用层协议, 以此对网络进行内容控制及管理。 (3)支持多种应用层协议解析,包括超文本传输协议(http) 、文件传输协 议(ftp) 、动态主机设置协议(dhcp)等等。 (4)能够正确的解析应用层数据协议,给出解析的结果和分析报告。 2.1.2 输入输出需求输入输出需求 (1)输入需求 数据包文件:通过数据包捕获系统得到的 pcap 格式数据包。 (2)输出需求 分析出的应用层数据协议信息,包括协议类型、该协议的字节数、数 据包数等信息。 2.1.3 性能需求性能需求 (1)系统要有较快处理速度,能够高效的进行协议解析。 (2)系统应该稳定、健壮,能够独立的。 (3)能够准确识别多种应用层协议,包括 http 协议、ftp 协议、dhcp 协 议等等。 14 2.2 基于基于 dpi 的应用层协议解析系统设计方案的应用层协议解析系统设计方案 整个基于 dpi 的应用层解析系统的架构如图 2.1 所示。 图 2.1 应用层协议解析系统架构图 系统分为两个主要的子系统,各子系统的功能介绍如下: (1)数据包捕获系统,主要负责使用 libpcap 捕获网络数据包,得到 pcap 数据包文件,供协议分析系统使用。 (2)协议分析系统,应用层协议解析系统的核心模块,主要负责使用深度 包检测技术对各种应用层协议(例如:http 协议,ftp 协议等等)进行分 析,并打印分析结果。 15 2.3 协议分析系统设计方案协议分析系统设计方案 2.3.1 协议分析系统介绍协议分析系统介绍 数据包捕获系统 协议分析系统 传入数据包文件 初始化模块 设置要检测的协议初始化系统环境 打开数据包文件 数据包处理模块(调用各种协议的分析模块) http 协议ftp 协议 关闭数据包文件 输出分析结果 图 2.2 协议分析系统流程图 协议分析系统主要由初始化模块和数据包处理模块这两个核心模块组成。 16 (1)初始化模块 初始化模块主要负责处理传入的参数,根据参数设定需要解析的 协议等等,它更重要的功能是初始化系统环境,比如对一些重要的数 据结构进行初始化、对协议的回调函数进行绑定等等。 (2)数据包处理模块 这个模块主要负责各种协议的分析,是整个系统最核心的部分,它 通过调用各个协议分析函数,对预先设定的协议进行分析。 2.3.2 协议分析系统工作原理协议分析系统工作原理 协议分析系统的工作流程详细介绍如下: (1) 将之前通过数据包捕获系统得到的 pcap 数据包传入协议分析系统。 (2) 根据传入的参数设置需要分析的协议类型。 (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; 17 2.4.3 系统开发环境系统开发环境 (1) 硬件环境:双核核处理器、2g 内存 (2) 操作系统:fedora 14 (3) 相关类库:pcap 库等 18 3 基于基于 dpi 的应用层协议解析与设计的应用层协议解析与设计 3.1 数据包捕获模块数据包捕获模块 系统中数据包捕获主要依赖 libpcap(packet capture library,数据包捕获 函数库)来实现,libcap 是一个独立于系统的用户层包捕获的 api 借口,下 面介绍利用 libpcap 抓包的设计。 3.1.1libcap 工作原理工作原理 libpcap 主要由两部分构成:网络分接头(network tap)和数据过滤器 (package filter)14。其中,网络分接头从网络设备驱动中收集数据拷贝, 数据过滤器用来决定是否接收该数据包。 libpcap 支持 bpf 过滤机制15。bpf(bsd packet filter)是 1993 年初, s.mccanne 和 v.jacobson 等人推出的著名的包过滤器,它的基本工作步骤 如下:当一个数据包到达网络接口时,数据链路层的驱动会把它向系统的协 议栈传送。但如果 bpf 监听接口,驱动首先调用 bpf;bpf 首先进行过滤 操作,然后把数据包存放在过滤器相关的缓冲区中,根据用户定义的规则决 定是否接收此数据包以及需要拷贝该数据包的哪些内容;最后将过滤后的数 据给与过滤器相关联的上层应用程序,设备驱动再次获得控制。 libpcap 的包捕获机制16就是在数据链路层加一个旁路处理。当一个数 据包到达网络接口时,libpcap 首先利用已经创建的 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_open_live(char *device, int snaplen, int promisc, int to_ms, 19 char *ebuf),函数用于打开网络设备,并且返回用于捕获网络数据包的 数据包捕获描述字。device 参数为指定打开的网络设备名。snaplen 参 数定义捕获数据的最大字节数。promisc 指定是否将网络接口置于混杂 模式。to_ms 参数指*定超时时间(毫秒) 。ebuf 参数则仅在 pcap_open_live()函数出错返回 null 时用于传递错误消息。对于此网 络设备的操作都要基于此网络设备描述字。 (3)int pcap_lookupnet(char *device, bpf_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 参数控制结果代码的优化。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) ,都 用于捕获并处理数据包,不同的是 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,且可调用 pcap_perror()或 pcap_geterr()函数来获取错误消息。 3.1.3 libpcap 工作流程工作流程 基于 libpcap 总体框架, libpcap 实现捕获数据包的流程基本如下: (1)设置设备,即选择嗅探接口。有两种方式,一种是用户通过传递参 20 数来制指定设备;另一种是通过 pcap_lookupdev( )函数自己查找设 备; (2)打开设备进行嗅探,即创建一个嗅探任务,需要使用 pcap_open_live()函数;其中如果设置指定接口为混杂模式时,主 机将嗅探整个传输线路上的所有通信,这样也是非常占用系统资源的房 方式;非混杂模式只嗅探与主机直接相关的通信。 (3)设定过滤规则,即将自己的过滤表达式保存为一个字符数组,然后将字 符数组编译到指定的过滤程序之中,整个过程通过使用 pcap_compile() 与 pcap_setfilter()这两个函数完成。通过这个指定过滤程序,我们就可 以自己定义一些过滤规则,对数据包进行符合自己要求的过滤操作。 (4)嗅探,即进入主体执行数据包的捕获,捕获包有两种方式,一种利用 pcap_next()函数一次只捕捉一个包,还有一种就是进入一个循环,捕 捉多个包之后,再进行数据包处理。 3.1.4 pcap 数据包数据包 通过数据包捕捉系统的到就是 pcap 格式的数据包,pcap 文件格式是常用 的数据报存储格式,下面对这种格式的文件简单分析一下: pcap 文件的格式如图 3.1 所示。 文件头数据包头 1数据包 1数据包头 2数据包 2 24 字节16 字节16 字节 图 3.1 pcap 文件格式 (1)pcap 文件头,pcap header pcap 文件的文件头有 24 字节,主要用来存储 pcap 文件的基本信息, 在 pcap.h 文件中定义了文件头的格式: struct pcap_file_header bpf_u_int32 magic; u_short version_major; u_short version_minor; bpf_int32 thiszone; 21 bpf_u_int32 sigfigs; bpf_u_int32 snaplen; bpf_u_int32 linktype; ; pcap 文件的头部具体结构也就如上面结构体定义的一样,具体的结构图, 如图 3.2 所示。 thiszone 4b sigfigs 4b snaplen 4b linktype 4b major 2bminor 2b magic 4b pcap header 图 3.2 pcap header 结构 pcap 文件头的各字段说明: magic:4 字节,01a 2b 3c 4d,用来识别文件自己和字节顺序。其中 0xa1b2c3d4 用来表示按照原来的顺序读取,0xd4c3b2a1 表示下面的字 节都要交换顺序读取。一般,我们使用 0xa1b2c3d4 major:2 字节,002 00,表示当前文件主要的版本号 minor:2 字节,004 00,表示当前文件次要的版本号 thiszone:4 字节,表示时区。gmt 和本地时间的相差,用秒来表示。如果 本地的时区是 gmt,那么这个值就设置为 0.这个值一般也设置为 0 sigfigs:4b 时间戳的精度;全零 snaplen:4 字节,表示最大的存储长度(该值设置所抓获的数据包的最大长 度,如果所有数据包都要抓获,将该值设置为 65535;例如:想获取 数据包的前 64 字节,可将该值设置为 64) 22 linktype:4 字节,表示链路类型 (2)数据报头,packet 包头 packet 包头格式为: struct pcap_pkthdr struct timeval ts; bpf_u_int32 caplen; bpf_u_int32 len; ; struct timeval long tv_sec; suseconds_t tv_usec; ; packet 包头具体结构如图 3.3 所示。 packet header timestamp 4b len 4b caplen 4b timestamp 4b 图 3.3 packet 包头结构图 packet 包头字段说明: timestamp:时间戳高位,精确到 seconds(值是自从 january 1, 1970 00:00:00 gmt 以来的秒数来记) timestamp:时间戳低位,精确到 microseconds (数据包被捕获时候的 微秒(microseconds)数,是自 ts-sec 的偏移量) caplen:当前数据区的长度,即抓取到的数据帧长度,由此可以得到下 23 一个数据帧的位置。 len:离线数据长度:网络中实际数据帧的长度,一般不大于 caplen, 多数情况下和 caplen 数值相等。 (3)数据包,packet 数据 packet 数据就是数据包的具体内容,通常就是链路层的数据帧。数 据报的长度就是 caplen,这个长度的后面,就是当前 pcap 文件中存放的 下一个 packet 数据包。因此,pcap 文件里面并没有规定捕获的 packet 数据包之间有什么间隔字符串,下一组数据在文件中的起始位置。 数据包的格式如图 3.4 所示。 0123456789abcdef 数据包包头,包含一些文件信息(24 字节) 数据包包头数据报报头(16 字节) 以太网帧头(14 字节) 以太网帧头ip 头(20 字节) ip 头tcp 头 tcp 头(20 字节)数据域 数据域 数据报报头 下一个数据报的以太网帧头 以太网帧头下一个数据报 ip 头 ip 头tcp 头 tcp 头数据域 数据域数据报报头 图 3.4 数据包的基本格式 24 3.2 http 分析模块分析模块 3.2.1 协议分析的初始化协议分析的初始化 协议分析所有的初始化工作都在函数 setupdetection()中,其流程图如图 3.5 所示。 图 3.5 协议分析初始化流程图 初始化过程具体流程是: (1)初始 ipq_struct,即定义 ipoque_init_detection_module,作用是用 malloc 函数分配了一个 ipoque_detection_module_struct,该结构体中 开开始始 定定义义全全局局的的数数据据结结构构 ipoque_init_detection_module 给给i ip po o_ _s st tr ru uc c分分配配空空间间,并并将将 其其初初始始化化,主主要要设设置置不不同同协协 议议的的初初始始值值 给给数数组组o os sd dp pi i_ _i id ds s分分配配空空间间, 用用来来存存储储每每一一个个数数据据流流及及其其 信信息息 给给数数组组o os sd dp pi i_ _f fl lo ow ws s分分配配空空 间间,用用来来存存储储每每一一个个数数据据流流 及及其其信信息息 将将要要检检测测的的协协议议类类型型设设置置为为 a al ll l,识识别别全全部部协协议议 根根据据需需要要识识别别的的协协议议类类型型不不 同同进进行行分分类类,设设置置 i ip pq q_ _c ca al ll l_ _f fu un nc ct ti io on n_ _s st tr ru uc ct t 成成员员变变量量 根根据据协协议议类类型型分分类类 u ud dp pt tc cp p其其他他 复复制制其其对对应应的的i ip pq q_ _f fu un nc ct ti io on n_ _s st tr ru uc ct t结结构构到到新新 的的i ip pq q_ _c ca al ll l_ _f fu un nc ct ti io on n_ _s st tr ru uc c

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论