CN100493094C - 基于特征码的p2p数据报文检测方法 - Google Patents
基于特征码的p2p数据报文检测方法 Download PDFInfo
- Publication number
- CN100493094C CN100493094C CNB2006101125955A CN200610112595A CN100493094C CN 100493094 C CN100493094 C CN 100493094C CN B2006101125955 A CNB2006101125955 A CN B2006101125955A CN 200610112595 A CN200610112595 A CN 200610112595A CN 100493094 C CN100493094 C CN 100493094C
- Authority
- CN
- China
- Prior art keywords
- message
- datagram
- condition code
- ppstream
- bit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Abstract
基于特征码的P2P数据报文检测方法属于互联网技术领域,其特征在于:通过对大量P2P应用的数据包进行相关性研究和应用层协议分析,根据不同报文特征来提取各种P2P应用的报文特征码样本,确定为相应P2P应用的报文特征码,依据这些特征码对通过网关设备的每一个IP包进行应用层内容过滤,一旦匹配上某类特征码就可以确定该IP包是P2P数据包,然后,将检测结果添加到P2P规则库中供硬件使用。本发明同时适用于IPv4和IPv6网络,可对任意通信协议的数据报进行全面的分析,能检测并过滤比特湍流、电驴、电骡、PPLive(P2P网络电视)、PPStream(流媒体电视)等多种目前主流的P2P应用,本发明已经在清华大学的“支持IPV6的网络隔离设备”中实现。
Description
技术领域
本发明属于互联网技术领域。
背景技术
近年来随着P2P技术的广泛应用,使得网络增量不增收,给宽带电信运营商可持续良性发展带来了较大的压力。P2P以其并行传输的特点,为用户提供了便捷和高质量的用户体验,新的P2P应用也在不断的涌现。据统计P2P应用已占ISP业务总量的60%~80%,跃然成为网络带宽的最大的消费者。在大量用户共享带宽的情况下,尤其在高峰期间,大量的P2P数据拥塞网络,因为这类应用对带宽的需求在理论上是无止境的,它们会使原来运行流畅的网络变得越来越拥塞,同时还极大改变了网络上的流量模型,并且将运营成本提30%甚至更高,还会对传统的应用造成冲击,影响正常业务流量。
在P2P应用出现之前,互联网的流量模式并没有出现太大的改变,那时的网络当用户停止使用他们的计算机的时候,网络的流量也就停止了;在P2P应用出现之后,网络变得不再有任何空闲,原因是P2P应用的用户通常将很多大型的文件放在下载队列中,然后去干其他工作,P2P应用工作在后台模式下,可以日以继夜地竭尽所能地获取网络能提供的最大带宽用以完成下载任务,另外P2P软件采用多点连接的下载方式,即每位下载者在获取数据的同时,还成为其他下载者的数据来源,这样下载的人越多,下载的速度就越快,按照这种对等的通信模型,从理论上分析,P2P软件的下载速度只受到计算机数据通信处理速度的限制,而尽可能地消耗网络的带宽资源。由此可见,面对这种特殊的通信模式,我们的网络早已变得不堪重负了。经过长期观察,我们发现这些以BT、Edonkey、KaZaA等为代表的P2P应用,消耗了网络40%以上的有效带宽,同时产生了40%的流量,而普通的Web浏览只占用了大约30%的带宽,产生了20%的流量。
由此可见,检测并有效管理P2P应用所产生的流量对于网络管理者来说至关重要,但是,由于P2P应用没有统一的网络协议标准,具有种类多、形式多样的特点,使用传统的防火墙技术难以发现和过滤P2P流量。如何有效检测网络中的P2P应用并控制P2P流量,这一直是让宽带运营商感到十分为难的问题。
我们以文件下载软件BT为例来说明目前大家采用的封堵P2P流量的方法,BT的全名叫做BitTorrent,中文译作“比特湍流”,目前国内解决BT下载造成网络堵塞的办法主要有:限制种子文件的下载、限制浏览BT网站、禁止访问跟踪服务器(Tracker)、封闭BT下载端口、限制用户带宽、限制最大连接数等办法。
(1)限制种子文件的下载
限制种子文件的下载方法比较简单,在设置好的策略中的HTTP中限制一下来禁止BT下载。当然这种方法只要下载者改个扩展名就可以继续下载,另外,如果某网站提供下载Torrent文件的端口不是标准的80端口,此方法也会失效。
(2)限制浏览BT网站
对一些比较热门的BT网站,在安全网关上配置统一资源定位过滤规则,并且在出接口上启用超级文本传输协议Http过滤功能,禁止对它们的访问也可以屏蔽一部分BT下载,但是一方面BT网站很多,无法进行全面的屏蔽;另一方面,屏蔽网站可能造成一些误判,导致一些合法的、合理的网站无法访问。
(3)禁止访问跟踪服务器Tracker
Tracker是运行于服务器上的一个程序,这个程序能够追踪到底有多少人同时在下载同一个文件。跟踪服务器的数量远少于热门BT网站的数量,很多网站都是转载其他网站的种子文件,如果可以找出这些跟踪服务器的地址,进行屏蔽也可以屏蔽掉一些BT下载。但是一方面跟踪服务器的数量众多,屏蔽服务器的操作非常麻烦;另一方面,种子文件在互联网上到处转载、传播,要找到真正的跟踪服务器将会经过多次链接,很难找到BT种子文件的真正发源地,从而使得屏蔽跟踪服务器很难实施。
(4)封闭特定端口
B一般使用TCP的6881~6889的端口,网络管理员可以根据网络流量的变化进行判断,在网关中将特定的种子发布站点和端口封掉,在BT下载软件中的跟踪服务器中可以获得这些信息。但是现在大多数BT软件可以动态分配端口,从而使得管理员无法真正掌握BT目前所使用的端口,另一方面,过多的屏蔽端口可能使得一些正常的网络访问无法进行,从而造成负面的影响。
这几种方法都只能对一些刚接触BT的新手进行限制,对于熟悉BT下载的使用者则根本没有办法;P2P应用大多采用私有通信协议,依靠传统的封堵TCP协议的屏蔽技术根本无法控制。总之,通过上述业内常用的几种方法来对BT进行控制,虽然可以在一定程度上能控制BT下载,但是单靠单一的方案很难真正做到对BT的控制,而如果同时实施很多方案,工作量大,操作复杂,增加了管理成本;上述方法或多或少要用到硬件防火墙或者其他网络设备,而这些设备的采购成本较高,系统升级复杂;最后,这些网络设备或者其他的软件系统对网络结构的要求较高,需要对网络系统进行调整,从而增加了系统实施的难度和成本。
本发明基于P2P特征码对应用层协议进行深层内容过滤,该方法通过对大量P2P应用的数据包进行深入研究分析与总结,并对大量报文进行相关性研究和应用层协议分析,根据不同报文特征来提取各种P2P应用的报文特征码样本,确定为相应P2P应用的报文特征码,依据这些特征码对通过网关设备的每一个IP包进行基于特征码的数据报文检测,一旦匹配上某类特征码就可以确定该IP包是P2P数据报,然后,将检测结果添加到P2P规则库中供硬件使用。本发明同时适用于IPv4和IPv6网络,可对任意通信协议的数据报进行全面的分析,能检测并过滤BitTorrent(比特湍流)、Edonkey(电驴)、EMule(电骡)、KaZaA(一种P2P文件下载软件)、PPLive(P2P网络电视)、PPStream(流媒体电视)等多种目前主流的P2P应用,本发明已经在清华大学的“支持IPV6的网络隔离设备”中实现。
发明内容
本发明的目的在于克服已有P2P数据报文检测方法的不足,提供一种新的基于特征码进行应用层内容过滤的同时适用于IPv4和IPv6网络的P2P数据报文检测与过滤机制。
本发明解决其技术问题所采用的技术方案是:通过对捕获的各种P2P应用的数据包进行相关性研究和应用层协议分析,提取各种P2P应用的报文中出现的特定关键字,并确定为相应P2P应用的报文特征码,依据这些特征码对通过网关设备的每一个IP包进行应用层内容匹配,也就是用特征码和数据报中的字符串进行字符串比较,如果相等就表示匹配成功,否则表示匹配失败,一旦匹配成功某个特征码就可以确定该IP包是P2P数据报,然后对该数据报进行过滤并将相应的检测结果添加到P2P过滤规则库中供硬件使用。
本发明的特征在于:
所述方法依次按以下步骤实现:
步骤1:在支持IPV6的网络隔离设备的CPU板上设立一个P2P检测模块,该支持IPv6的网络隔离设备一端经路由器连接着一个受保护的IPv4或IPv6网络,另一端经另一个路由器连接着一个IPv4或IPv6网络;
步骤2:当步骤1中所述CPU板中的软件包收发单元在收到所述支持IPv6网络隔离设备中的包处理板内多路合并部件上来的IP包后,把所述IP包转发给步骤1中所述的P2P检测模块,由该模块依次按以下步骤进行数据报文检测;
步骤3:所述P2P检测模块对收到的IP包进行解析,若最初4个比特为0100,则判定为IPv4数据包,把指向IP包头的结构指针skb向后移动ipv4headlen+head_len个字节,该ipv4headlen是IPv4包头长度,head_len是传输层报头长度;若最初4个比特是0110,则判定为IPv6数据包,把结构指针skb向后移动ipv6headlen+head_len个字节,该ipv6headlen是IPv6报头长度;再根据数据包的类型调用不同的函数:P2PDetect_IPv4或P2PDetect_IPv6来检测IPv4或IPv6报文;
步骤4:所述P2P检测模块检测比特湍流BitTorrent数据报:
若:主机为了进行比特湍流下载需要查询跟踪服务器Tracker,该服务器便通过超级文本传输协议HTTP的GET命令的参数来接收信息,所述P2P检测模块依次按下列步骤进行处理:
a.检测超级文本传输协议HTTP的净载荷数据的开始部分,如果具有特征码″User-Agent:BitTorrent″,则将此数据报判定为比特湍流数据报,这时检测成功函数返回SKP2P_BIT,SKP2P_BIT是一个宏定义,其值等于1024,否则,继续执行步骤b;
b.检测对等主机发往跟踪服务器的HTTP请求报文,依次在这类报文中匹配特征码″GET/announce?info hash=″和″GET/scrape?info_hash″,如果能匹配上其中之一,则将此数据报判定为比特湍流数据报,这时检测成功函数返回SKP2P_BIT,否则,继续执行步骤c;
c.检测对等主机之间的传输数据,如果在这类报文中出现特征码为″BitTorrent protoco1″,则将此数据报判定为比特湍流数据报,这时检测成功函数返回SKP2P_BIT,否则,继续执行步骤d;
d.检测跟踪服务器回应对等主机的HTTP报文,在跟踪服务器向对等主机返回一个B编码后的HTTP200OK报文中,如果在这类报文中出现的特征码为″Set-Cookie:bt=,则将此数据报判定为比特湍流数据报,这时检测成功函数返回SKP2P_BIT,否则检测失败,返回0;
e.检测对等主机之间的UDP协商报文,依次在这类报文中匹配特征码″d1:ad2:id″和″d1:rd2:id20:″,如果匹配上其中之一,则将此数据报判定为比特湍流数据报,这时检测成功函数返回SKP2P_BIT,否则,返回0;
步骤5:所述P2P检测模块检测电驴EDonkey数据报,属于电驴的应答报文,电驴的TCP数据部分特征码为:″e3 ** 00 00 00 47″;电驴的UDP数据部分的特征码为:″e3 9a″或″e3 96″或″e3 94″;
步骤6:所述P2P检测模块检测基于电驴EDonkey协议的电骡EMule数据报,电骡的TCP数据部分的特征码为″e3 ** 00 00 00 4c″和″c5 ** 00 00 00″,这种报文为电骡的应答报文,电骡的UDP数据部分的特征码为″e3 a3 ff f0″和″02 00 00 3c 02 00″;
步骤7:所述P2P检测模块检测P2P文件下载软件KaZaA数据报,KaZaA的TCP数据报开头部分有特征码″0d 0a GET/?″,随后有特征码″X-Kazaa-Username:″或″User-Agent:PeerEnabler/″,还有″0d 0a GIVE?″或″0d 0a GET/.hash?″;KaZaA的UDP数据报中的特征码为″KaZaA″;
步骤8:所述P2P检测模块检测P2P网络电视PPLive数据报,这类报文中的特征码为″www.pplive.chinacache.net″,这类报文的TCP数据包中的特征码为″e9 03 44 01″或″e9 0345 01″或″e9 03 46 01″,PPLive的UDP报文中的特征码为″e9 03 42 01 98 ab 01 02″或″70 70 6c 69 76 65″;
步骤9:所述P2P检测模块检测流媒体电视PPStream数据报,有如下几种情况:
主机在登录PPStream服务器时,要先访问PPStream的网站,在这类数据报中的特征码为″list1.PPStream.com″或″stat.PPStream.com″或″notice.PPStream.com″或″xmll.PPStream.com″;
在主机间开始传输媒体数据之前的协商报文中含有特征码″GET/?ppNotice&lang=″和″PSProtocol″;
主机向PPStream服务器发出的HTTP请求报文的结尾处都有特征码″PPStream.com″;
步骤10:所述P2P检测模块按步骤4~步骤9对所述的各种特征码和接收到的报文中的字符串进行字符串比较,如果相等,就表示匹配成功,并确认所接收报文的类型;
步骤11:所述P2P检测模块把检测到的信息组成一条条包含有六元组的P2P过滤规则插入到所述CPU板的P2P规则库中去,以此提供给底层硬件访问,所述六元组是指:源地址、目的地址、源端口、目的端口、协议类型、P2P类型,所述CPU板中的操作和维护模块0AM根据不同的控制策略和需求来过滤或限制相应的P2P流量。
本发明所提出的基于特征码的P2P数据报文检测方法,克服了现有P2P数据报文检测方法的不足,提供了一种新的检测和过滤P2P应用流量的技术方法,该方法可以满足检测各种P2P应用流量的需求,并具有很好的可扩展性,图6~图17列出了本方法检测几种主流P2P应用的步骤,从而解决了现有方法效率低下和检测不完全的问题。目前清华大学已经将该项研究成果运用在“支持IPv6的网络隔离设备”中,是该设备的重要组成部分。
附图说明
图1.隔离设备功能定位示意图;
图2.支持IPv6的网络隔离设备接口图;
图3.设备总体功能结构图;
图4.基于特征码的P2P数据报文检测方法流程图;
图5.基于特征码的P2P数据报文检测方法整体框架;
图6.检测BitTorrent的TCP数据包的流程图;
图7.检测BitTorrent的UDP数据包的流程图;
图8.检测EDonkey的TCP数据包的流程图;
图9.检测EDonkey的UDP数据包的流程图;
图10.检测EMule的TCP数据包的流程图;
图11.检测EMule的UDP数据包的流程图;
图12.检测KaZaA的TCP数据包的流程图;
图13.检测KaZaA的UDP数据包的流程图;
图14.检测PPLive的TCP数据包的流程图;
图15.检测PPLive的UDP数据包的流程图;
图16.检测PPStream的TCP数据包的流程图;
图17.检测PPStream的UDP数据包的流程图;
图18.P2P规则库数据结构图。
具体实施方式
步骤1:定义如下三个函数
static int P2PDetect(const struct skBuff*skb,int ip_version)
static int P2PDetect_IPv4(const struct skBuff*skb)
static int P2PDetect_IPv6(const struct skBuff*skb)
skb是指向IP包头的指针,当ip_version=4时,函数P2PDetect调用函数P2PDetect_IPv4检测IPv4报文,当ip_version=6时,函数P2PDetect调用函数P2PDetect_IPv6检测IPv6报文,函数P2PDetect_IPv4或P2PDetect_IPv6分别对从软件包收发单元接收到的IP报文进行判断,并将指针skb向后移动ipv4headlen+head_len或ipv6headlen+head_len个字节,其中ipv4headlen为IPv4报头长度,ipv6headlen是IPv6报头长度,head_len是传输层报头长度,图4是基于特征码的P2P数据报文检测方法流程图,首先对收到的IP包进行版本判断,如果是IPv4数据包,那么对IPv4包解析并对它进行P2P特征码检测,根据检测结果如果是P2P包就添加P2P规则库并返回P2P类型,否则直接返回,如果是IPv6数据包,那么对IPv6包解析并对它进行P2P特征码检测,根据检测结果如果是P2P包就添加P2P规则库并返回P2P类型,否则直接返回,图5是基于特征码的P2P数据报文检测方法的整体框架,首先对IP包进行解析,然后依次调用各个子模块进行P2P检测,然后将检测结果添加到P2P规则库中并返回检测到的P2P类型,这里我们给出一些宏定义来标识某种特定的P2P应用,令SKP2P_BIT=1024,SKP2P_EDK=2,SKP2P_EMU=512,SKP2P_KZA=8,SKP2P_PPL=16,SKP2P_PPS=32;
步骤2:定义检测BitTorrent数据报的函数
int seek BitTorrent(unsigned char *haystack,int packet_len,int head_len)
int udp_seek_BitTorrent(unsigned char *haystack,int packet_len)
seek_BitTorrent为检测TCP报文中的BitTorrent数据的函数,图6是检测BitTorrent的TCP数据包的流程图,图中依次对每种特征码进行匹配,并返回检测结果,udp_seek_BitTorrent为检测UDP报文中的BitTorrent数据的函数,图7是检测BitTorrent的UDP数据包的流程图,图中依次对每种特征码进行匹配,并返回检测结果,参数haystack为指向传输层报头的指针,packet_len为净载荷数据长度,head_len为传输层报头长度,在IP包的净载荷数据的开头位置会出现特征码,函数seek_BitTorrent分别匹配特征码:″BitTorrentprotocol″,″User-Agent:BitTorrent″,″GET/scrape?info_hash″,″GET/announce?info_hash″,″Set-Cookie:bt=,函udp_seek BitTorrent分别匹配特征码:″d1:ad2:id″,″d1:rd2:id20:″,匹配成功则返回SKP2P_BIT,说明该报文为BitTorrent数据报,否则返回0;
步骤3;定义检测EDonkey数据报的函数
int seek_EDonkey(unsigned char *haystack,int packet_len,int head_len)
int udp_seek_EDonkey(unsigned char *haystack,int packet_len)
seek_EDonkey为检测TCP报文中的EDonkey数据的函数,图8是检测EDonkey的TCP数据包的流程图,图中依次对每种特征码进行匹配,并返回检测结果,udp_seek_EDonkey为检测UDP报文中的EDonkey数据的函数,图9是检测EDonkey的UDP数据包的流程图,图中依次对每种特征码进行匹配,并返回检测结果,参数haystack为指向传输层报头的指针,packet_len为净载荷数据长度,head_len为传输层报头长度,函数seek_EDonkey匹配特征码:″e3 01 00 00 00 47″,″e3 03 00 00 00 47″,″e3 1a 00 00 00 47″,函数udp_seek_Edonkey分别匹配特征码:″e3 9a″,″e3 96″,″e3 94″,匹配成功则返回SKP2P_EDK,说明该报文为EDonkey数据报,否则返回0;
步骤4:定义检测EMule数据报的函数
int seek_EMule(unsigned char *haystack,int packet_len,int head_len)
int udp_seek_EMule(unsigned char *haystack,int packet_len)
seek_EMule为检测TCP报文中的EMule数据的函数,图10是检测EMule的TCP数据包的流程图,图中依次对每种特征码进行匹配,并返回检测结果,udp_seek_EMule为检测UDP报文中的EMule数据的函数,图11是检测EMule的UDP数据包的流程图,图中依次对每种特征码进行匹配,并返回检测结果,参数haystack为指向传输层报头的指针,packet_len为净载荷数据长度,head_len为传输层报头长度,函数seek_EMule分别匹配特征码:″e3** 00 00 00 4c″和″c5 ** 00 00 00″,函数udp_seek_EMule分别匹配特征码:″e3 a3 ff f0″,″02 00 00 3c 02 00″,匹配成功则返回SKP2P_EMU,说明该报文为EMule数据报,否则返回0;
步骤5:定义检测KaZaA数据报的函数
int seek_KaZaA(unsigned char *haystack,int packet_len,inthead_len)
int udp_seek_KaZaA(unsigned char *haystack,int packet_len)
seek_KaZaA为检测TCP报文中的KaZaA数据的函数,图12是检测KaZaA的TCP数据包的流程图,图中依次对每种特征码进行匹配,并返回检测结果,udp_seek_KaZaA为检测UDP报文中的KaZaA数据的函数,图13是检测KaZaA的UDP数据包的流程图,图中依次对每种特征码进行匹配,并返回检测结果,参数haystack为指向传输层报头的指针,packet_len为净载荷数据长度,head_len为传输层报头长度,函数seek_KaZaA分别匹配特征码:″0d 0a GIVE?″,″0d 0a GET/.hash?″,″0d 0a GET/?X-Kazaa-Username:″,″0d 0a GET/?User-Agent:PeerEnabler/″,函数udp_seek_KaZaA匹配特征码:″KaZaA″,匹配成功则返回SKP2P_KZA,说明该报文为KaZaA数据报,否则返回0;
步骤6:定义检测PPLive数据报的函数
int seek_PPLive(unsigned char *haystack,int packet_len,int head_len)
int udp_seek_PPLi ve(unsigned char *haystack,int packet_len)
seek_PPLive为检测TCP报文中的PPLive数据的函数,图14是检测PPLive的TCP数据包的流程图,图中依次对每种特征码进行匹配,并返回检测结果,udp_seek_PPLive为检测UDP报文中的PPLive数据的函数,图15是检测PPLive的UDP数据包的流程图,图中依次对每种特征码进行匹配,并返回检测结果,参数haystack为指向传输层报头的指针,packet_len为净载荷数据长度,head_len为传输层报头长度,函数seek_PPLive分别匹配特征码:″www.pplive.chinacache.net″,″e9 03 44 01″,″e9 03 45 01″和″e9 03 46 01″,函数udp_seek_PPLive匹配特征码:″e9 03 42 01 98 ab 01 02″,″00 ef 01 00″,″e9 03 02 00 98 ab 01 02″,″70 70 6c 69 76 65″匹配成功则返回SKP2P_PPL,说明该报文为PPLive数据报,否则返回0;
步骤7:定义检测PPstream数据报的函数
int seek_PPs tream(unsigned char *haystack,int packet_len,int head_len)
int udp_seek_PPs tream(unsigned char *haystack,int packet_len)
seek_PPstream为检测TCP报文中的PPstream数据的函数,图16是检测PPStream的TCP数据包的流程图,图中依次对每种特征码进行匹配,并返回检测结果,udp_seek_PPstream为检测UDP报文中的PPstream数据的函数,图17是检测PPStream的UDP数据包的流程图,图中依次对每种特征码进行匹配,并返回检测结果,参数haystack为指向传输层报头的指针,packet_len为净载荷数据长度,head_len为传输层报头长度,函数seek_PPstream分别匹配特征码:″GET/?ppNotice&lang=″,″PSProtocol″,″ppstream.com″,″15 20 00 0004 00 5c 34 44″,函数udp_seek_PPstream匹配″list1.ppstream.com″,″stat.ppstream.com″,″notice.ppstream.com″,″lst3.ppstream.com″,″xm11.ppstream.com″,匹配成功则返回SKP2P_PPS,说明该报文为PPstream数据报,否则返回0;
步骤8:定义如下函数创建和插入P2P规则库
TrieTree CreateTrieTree(int info[8])
Node InsertList(Node T,int info[8],int j)
CreateTrieTree是创建P2P规则库的函数,InsertList是往P2P规则库中插入规则的函数,我们采用Trie树来组织P2P规则,图18是P2P规则库的数据结构图,Trie树是一种用于快速检索的多叉树结构,在Trie树中每个结点上并非存储一个元素,Trie树把要查找的关键词看作一个字符序列,并根据构成关键词字符的先后顺序构造用于检索的树结构,我们将检测到的结果归结成一条条含有六元组(源地址,源端口,目的地址,目的端口,协议类型,P2P类型)的P2P过滤规则插入到P2P规则库中,以此提供给底层硬件访问,根据隔离设备中OAM模块所配置的不同控制策略和需求来过滤或限制相应的P2P流量。
步骤9:本发明依次按以下步骤实现:
步骤9.1:本发明已在“支持IPV6的网络隔离设备”中实现,支持IPV6的网络隔离设备是能够支持IPv6、同时兼容IPv4、并能实现IPv6网络与IPv4网络互连的高性能网络安全隔离设备。该设备位于边缘接入网与骨干网之间,或者骨干网之上。设备主要功能如下:
1)IPv6到IPv6、IPv4到IPv6、IPv6到IPv4、IPv4到IPv4网络的隔离和数据交换,支持的IPv4/v6过渡技术包括配置隧道、IPv6向IPv4隧道转换、IPv6上的IPv4隧道、IPv4向IPv6过渡技术;
2)IPv4/IPv6六元组(源地址、目的地址、源端口、目的端口、协议类型、P2P类型)黑名单和白名单过滤;
3)入侵检测与动态阻断,支持连接状态检查和入侵特征检查;
4)P2P数据报文检测和过滤;
5)P2P控制,可以根据需要限制P2P应用流量;
6)网络管理,实现基于XML的网络管理;
7)操作与管理,实现远程仿真和控制台两种形式的操作;
该设备支持的接口有4个2.5G接口、4个1000M以太接口、2个10/100M以太接口和1个串口;在“支持IPv6的网络隔离设备”中,P2P数据报文检测模块位于设备的CPU板上,软件包收发单元接收到包处理板中的多路合并部件传上来的IP包以后,将IP包转发给P2P检测模块进行P2P数据报文检测,P2P数据报文检测模块采用本发明所指的基于特征码的P2P数据报文检测方法对IP包进行检测,并将检测到的结果写入P2P规则库;
步骤9.2:设:skb是指向IP包头的结构指针,ipv4headlen是IPv4报头长度,ipv6headlen是IPv6报头长度,head_len是传输层报头长度,首先,对收到的IP包进行解析,如果最初4个比特是0100,就可以判断该包是IPv4数据包,并将指针skb向后移动ipv4headlen+head_len个字节,如果最初4个比特是0110,就可以判断该包是IPv6数据包,并将指针skb向后移动ipv6headlen+head_len个字节;
步骤9.3:所述P2P检测模块检测比特湍流BitTorrent数据报,当一台主机进行BT下载时,必须进行跟踪服务器Tracker查询,跟踪服务器通过超级文本传输协议HTTP的GET命令的参数来接收信息,而响应给对方(下载者)的是B编码的消息,在超级文本传输协议HTTP请求报文的净载荷数据的开头位置,携带有BT的特征码″User-Agent:BitTorrent″,现在还有一些BT软件不通过HTTP来获取对等主机(Peers)列表,而是采用UDP协议,但其BT流中还是包含″BitTorrent″特征码,我们同样能够对其″BitTorrent″特征码进行识别,所述P2P检测模块分别检测如下四类报文发现所有的BitTorrent流量:
(1)检测Peers发向Tracker的HTTP请求报文,在这类报文中出现的特征码为″User-Agent:BitTorrent″、″GET/announce?info_hash=″和″GET/scrape?info_hash″;
(2)检测过滤Peers之间的传输数据,在这类报文中出现的特征码为″BitTorrent protocol″;
(3)检测过滤Peers之间的UDP协商报文,当一个Peer从Tracker获取Peers列表以及相关信息以后,本Peer首先要向列表中的所有Peers发送UDP报文进行协商,一旦协商成功,本Peer就可以与这些Peers建立TCP连接,并开始下载数据片断,在这类报文中出现的特征码为″d1:ad2:id″或″d1:rd2:id20:″;
(4)检测Tracker回应Peer的HTTP报文,Tracker质询是双向的,Tracker通过HTTPGET参数获得信息,然后返回一个B编码后的HTTP 200 OK报文,在这类报文中出现的特征码为″Set-Cookie:bt=,我们对每一个数据报用这些特征码进行匹配,也就是用特征码和数据报中的字符串进行字符串比较,如果相等就表示匹配成功,否则表示匹配失败,一旦匹配成功这些特征码就可以确定该报文为BitTorrent数据报;
步骤9.4:所述P2P检测模块检测电驴EDonkey数据报,EDonkey的TCP数据部分特征码为:e3 ** 00 00 00 47,这种报文为EDonkey的应答报文,EDonkey的UDP数据部分特征码为:″e3 9a″,″e3 96″,″e3 94″,一旦匹配上这些特征码就可以确定该报文为EDonkey数据报;
步骤9.5:所述P2P检测模块检测电骡EMule数据报,EMule是基于EDonkey协议的,EMule网络是由数百个EMule服务器和数百万的EMule客户端组成的,客户端必须连接到服务器来获得网络服务,这个连接要一直保持直到客户端关闭,EMule的TCP数据部分的特征码为″e3 ** 00 00 00 4c″和″c5 ** 00 00 00″,这种报文为EMule的应答报文,EMule的UDP数据部分的特征码为″e3 a3 ff f0″和″02 00 00 3c 02 00″,一旦匹配上这些特征码就可以确定该报文为EMule数据报;
步骤9.6:所述P2P检测模块检测P2P文件下载软件KaZaA数据报,KaZaA的TCP数据报开头部分有特征码″0d 0a GET/?″,随后会有特征码″X-Kazaa-Username:″或″User-Agent:PeerEnabler/″,还有″0d 0a GIVE?″或″0d 0a GET/.hash?″,一旦匹配上这些特征码就可以确定该报文为KaZaA的TCP数据报,KaZaA的UDP数据报中经常出现的特征码为″KaZaA″,匹配上这个特征码就可以确定该报文为KaZaA的UDP数据报;
步骤9.7:所述P2P检测模块检测P2P网络电视PPLive数据报,PPLive在运行时首先要向服务器请求节目列表,在这类请求报文中会出现特征码″www.pplive.chinacache.net″,PPLive还有大量的TCP数据包中含有特征码″e9 03 44 01″,″e9 03 45 01″和″e9 03 46 01″,PPLive的UDP报文中有特征码″e9 03 42 01 98 ab 01 02″和″70 70 6c 69 76 65″等,所以我们可以依据这些特征码检测过滤掉PPLive的报文;
步骤9.8:所述P2P检测模块检测流媒体电视PPStream数据报,主机在登录PPStream服务器时会首先访问PPStream的网站,在这一类数据中会出现″listl.PPStream.com″或″stat.PPStream.com″或″notice.PPStream.com″或″xmll.ppstream.com″等特征码,PPStream软件在启动时首先会自动去访问list1.PPStream.com等web服务器来获取当前节目列表,在主机间开始真正传输媒体数据之前的协商报文中含有特征码″GET/?ppNotice&lang=″和″PSProtocol″,我们可以据此检测过滤掉这类TCP报文,还有一些PPStream报文结尾处都有特征码″PPStream.com″,这类报文都是主机向PPStream服务器发出的HTTP请求报文,一旦匹配上这些特征码就可以确定该报文为PPStream数据报;
步骤9.9:插入P2P规则库,我们采用Trie树来组织P2P规则,Trie树是一种用于快速检索的多叉树结构,在Trie树中每个结点上并非存储一个元素,Trie树把要查找的关键词看作一个字符序列,并根据构成关键词字符的先后顺序构造用于检索的树结构,在Trie树中查找一个关键字的时间和树中包含的结点数无关,而取决于组成关键字的字符数,而二叉查找树的查找时间和树中的结点数有关0(log2n),我们将检测到的结果归结成一条条含有六元组的P2P过滤规则插入到P2P规则库中,以此提供给底层硬件访问,根据隔离设备中OAM模块所配置的不同控制策略和需求来过滤或限制相应的P2P流量。
我们针对目前网络上最为流行的4类P2P应用在清华校园网上进行了实验测试,测试结果如下:
1.BitTorrent
■报文总数:15239
■TCP报文数:13746 UDP报文数:1363
■检测到的BitTorrent报文总数:1430
■检测到的BitTorrent报文中TCP报文数:290
■检测到的BitTorrent报文中UDP报文数:1140
■BitTorrent报文所占比例:9.38%
2.EMule
■报文总数:16601
■TCP报文数:14588 UDP报文数:2009
■检测到的EMule报文总数:2446
■检测到的EMule报文中TCP报文数:1235
■检测到的EMule报文中UDP报文数:1211
■EMule报文所占比例:14.73%
3.PPLive
■报文总数:17501
■TCP报文数:17131 UDP报文数:350
■检测到的PPLive报文总数:2409
■检测到的PPLive报文中TCP报文数:2087
■检测到的PPLive报文中UDP报文数:322
■PPLive报文所占比例:13.77%
4.PPStream
■报文总数:17350
■TCP报文数:15133 UDP报文数:2140
■检测到的PPStream报文总数:2103
■检测到的PPStream报文中TCP报文数:2103
■检测到的PPStream报文中UDP报文数:0
■PPStream报文所占比例:12.12%
由此可见,本发明达到了预期目的。
Claims (1)
1.基于特征码的P2P数据报文检测方法,其特征在于,依次具有以下步骤:
步骤1:在支持IPV6的网络隔离设备的CPU板上设立一个P2P检测模块,该支持IPv6的网络隔离设备一端经路由器连接着一个受保护的IPv4或IPv6网络,另一端经另一个路由器连接着一个IPv4或IPv6网络;
步骤2:当步骤1中所述CPU板中的软件包收发单元在收到所述支持IPv6网络隔离设备中的包处理板内多路合并部件上来的IP包后,把所述IP包转发给步骤1中所述的P2P检测模块,由该模块依次按以下步骤进行数据报文检测;
步骤3:所述P2P检测模块对收到的IP包进行解析,若最初4个比特为0100,则判定为IPv4数据包,把指向IP包头的结构指针skb向后移动ipv4headlen+head_len个字节,该ipv4headlen是IPv4包头长度,head_len是传输层报头长度;若最初4个比特是0110,则判定为IPv6数据包,把结构指针skb向后移动ipv6headlen+head_len个字节,该ipv6headlen是IPv6报头长度;再根据数据包的类型调用不同的函数:P2PDetect_IPv4或P2PDetect_IPv6来检测IPv4或IPv6报文;
步骤4:所述P2P检测模块检测比特湍流BitTorrent数据报:
若:主机为了进行比特湍流下载需要查询跟踪服务器Tracker,该服务器便通过超级文本传输协议HTTP的GET命令的参数来接收信息,所述P2P检测模块依次按下列步骤进行处理:
a.检测超级文本传输协议HTTP的净载荷数据的开始部分,如果具有特征码″User-Agent:BitTorrent″,则将此数据报判定为比特湍流数据报,这时检测成功函数返回SKP2P_BIT,SKP2P_BIT是一个宏定义,其值等于1024,否则,继续执行步骤b;
b.检测对等主机发往跟踪服务器的HTTP请求报文,依次在这类报文中匹配特征码″GET/announce?info_hash=″和″GET/scrape?info_hash″,如果能匹配上其中之一,则将此数据报判定为比特湍流数据报,这时检测成功函数返回SKP2P_BIT,否则,继续执行步骤c;
c.检测对等主机之间的传输数据,如果在这类报文中出现特征码为″BitTorrent protocol″,则将此数据报判定为比特湍流数据报,这时检测成功函数返回SKP2P_BIT,否则,继续执行步骤d;
d.检测跟踪服务器回应对等主机的HTTP报文,在跟踪服务器向对等主机返回一个B编码后的HTTP 200 OK报文中,如果在这类报文中出现的特征码为″Set-Cookie:bt=″,则将此数据报判定为比特湍流数据报,这时检测成功函数返回SKP2P_BIT,否则检测失败,返回0;
e.检测对等主机之间的UDP协商报文,依次在这类报文中匹配特征码″d1:ad2:id″和″d1:rd2:id20:″,如果匹配上其中之一,则将此数据报判定为比特湍流数据报,这时检测成功函数返回SKP2P_BIT,否则,返回0;
步骤5:所述P2P检测模块检测电驴EDonkey数据报,属于电驴的应答报文,电驴的TCP数据部分特征码为:″e3 ** 00 00 00 47″;电驴的UDP数据部分的特征码为:″e3 9a″或″e3 96″或″e3 94″;
步骤6:所述P2P检测模块检测基于电驴EDonkey协议的电骡EMule数据报,电骡的TCP数据部分的特征码为″e3 ** 00 00 00 4c″和″c5 ** 00 00 00″,这种报文为电骡的应答报文,电骡的UDP数据部分的特征码为″e3 a3 ff f0″和″02 00 00 3c 02 00″;
步骤7:所述P2P检测模块检测P2P文件下载软件KaZaA数据报,KaZaA的TCP数据报开头部分有特征码″0d 0a GET/?″,随后有特征码″X-Kazaa-Username:″或″User-Agent:PeerEnabler/″,还有″0d 0a GIVE?″或″0d 0a GET/.hash?″;KaZaA的UDP数据报中的特征码为″KaZaA″;
步骤8:所述P2P检测模块检测P2P网络电视PPLive数据报,这类报文中的特征码为″www.pplive.chinacache.net″,这类报文的TCP数据包中的特征码为″e9 03 44 01″或″e9 0345 01″或″e9 03 46 01″,PPLive的UDP报文中的特征码为″e9 03 42 01 98 ab 01 02″或″70 70 6c 69 76 65″;
步骤9:所述P2P检测模块检测流媒体电视PPStream数据报,有如下几种情况:
主机在登录PPStream服务器时,要先访问PPStream的网站,在这类数据报中的特征码为″list1.PPStream.com″或″stat.PPStream.com″或″notice.PPStream.com″或″xml1.PPStream.com″;
在主机间开始传输媒体数据之前的协商报文中含有特征码″GET/?ppNotice&lang=″和″PSProtocol″;
主机向PPStream服务器发出的HTTP请求报文的结尾处都有特征码″PPStream.com″;
步骤10:所述P2P检测模块按步骤4~步骤9对所述的各种特征码和接收到的报文中的字符串进行字符串比较,如果相等,就表示匹配成功,并确认所接收报文的类型;
步骤11:所述P2P检测模块把检测到的信息组成一条条包含有六元组的P2P过滤规则插入到所述CPU板的P2P规则库中去,以此提供给底层硬件访问,所述六元组是指:源地址、目的地址、源端口、目的端口、协议类型、P2P类型,所述CPU板中的操作和维护模块OAM根据不同的控制策略和需求来过滤或限制相应的P2P流量。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006101125955A CN100493094C (zh) | 2006-08-25 | 2006-08-25 | 基于特征码的p2p数据报文检测方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006101125955A CN100493094C (zh) | 2006-08-25 | 2006-08-25 | 基于特征码的p2p数据报文检测方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1913528A CN1913528A (zh) | 2007-02-14 |
CN100493094C true CN100493094C (zh) | 2009-05-27 |
Family
ID=37722295
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB2006101125955A Expired - Fee Related CN100493094C (zh) | 2006-08-25 | 2006-08-25 | 基于特征码的p2p数据报文检测方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100493094C (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101895469A (zh) * | 2010-07-19 | 2010-11-24 | 重庆邮电大学 | 对等网络流量牵引系统及流量牵引方法 |
Families Citing this family (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2003845B1 (en) * | 2007-06-15 | 2015-07-29 | Alcatel Lucent | Peer chosen as tester for detecting misbehaving peer in structured peer-to-peer networks |
CN101247281A (zh) * | 2008-03-21 | 2008-08-20 | 华为技术有限公司 | 一种协议报文的检测方法、系统及设备 |
CN101282331B (zh) * | 2008-05-09 | 2011-06-01 | 西安交通大学 | 基于传输层特征的p2p网络流量识别方法 |
CN101388848B (zh) * | 2008-10-13 | 2010-12-22 | 北京航空航天大学 | 网络处理器结合通用处理器的流量识别方法 |
CN101741867B (zh) * | 2008-11-14 | 2012-07-25 | 电子科技大学 | 一种捕获BitTorrent网络中节点信息的方法 |
CN101459554B (zh) * | 2008-12-30 | 2011-02-09 | 成都市华为赛门铁克科技有限公司 | 数据流检测的方法和装置 |
CN101778006B (zh) * | 2009-01-09 | 2012-01-25 | 华为技术有限公司 | 媒体即时信息的上报方法及系统、媒体网关 |
CN101494663B (zh) * | 2009-01-23 | 2012-05-23 | 北京网御星云信息技术有限公司 | 基于对等网络的主动识别方法及设备 |
EP2216958B1 (en) * | 2009-02-10 | 2011-10-26 | Alcatel Lucent | Method and device for reconstructing torrent content metadata |
CN101567811B (zh) * | 2009-05-26 | 2011-09-14 | 西北工业大学 | 基于BitTorrent的主动式特定信息传播监测方法 |
CN101582897A (zh) * | 2009-06-02 | 2009-11-18 | 中兴通讯股份有限公司 | 一种深度报文检测方法和装置 |
CN101577626B (zh) * | 2009-06-05 | 2011-04-13 | 西北工业大学 | 基于eMule的主动式特定信息传播监测方法 |
CN101599976B (zh) * | 2009-07-10 | 2012-10-17 | 成都市华为赛门铁克科技有限公司 | 过滤用户数据报协议数据包的方法和装置 |
CN101741644B (zh) * | 2009-12-16 | 2012-05-30 | 成都市华为赛门铁克科技有限公司 | 流量检测方法及装置 |
CN101764815A (zh) * | 2009-12-23 | 2010-06-30 | 杭州华三通信技术有限公司 | 一种xml报文的获取方法和装置 |
CN101783816B (zh) * | 2010-03-22 | 2013-04-17 | 杭州华三通信技术有限公司 | 一种下载流量控制方法和设备 |
CN102148854B (zh) * | 2010-10-19 | 2013-08-28 | 北京华为数字技术有限公司 | 对等节点共享流量识别方法和装置 |
CN102014065A (zh) * | 2010-12-10 | 2011-04-13 | 中兴通讯股份有限公司 | 报文包头的解析方法、包头解析预处理装置和网络处理器 |
CN102497371A (zh) * | 2011-12-13 | 2012-06-13 | 曙光信息产业(北京)有限公司 | 一种基于五元组和负载内容的采样设备 |
CN102437936B (zh) * | 2011-12-20 | 2013-12-18 | 东南大学 | 基于双过滤机制的高速网络僵尸报文的检测方法 |
CN103384240B (zh) * | 2012-12-21 | 2016-09-07 | 北京安天电子设备有限公司 | 一种p2p主动防御方法及系统 |
CN103166963A (zh) * | 2013-03-05 | 2013-06-19 | 汉柏科技有限公司 | 一种解除封装的协议识别方法及系统 |
CN103139315A (zh) * | 2013-03-26 | 2013-06-05 | 烽火通信科技股份有限公司 | 一种适用于家庭网关的应用层协议解析方法 |
CN103595729A (zh) * | 2013-11-25 | 2014-02-19 | 北京锐安科技有限公司 | 一种协议解析方法及装置 |
US10050892B2 (en) * | 2014-01-14 | 2018-08-14 | Marvell International Ltd. | Method and apparatus for packet classification |
CN105991465B (zh) * | 2015-02-09 | 2020-12-04 | 中兴通讯股份有限公司 | 一种应用程序业务处理的方法、设备和系统 |
CN110602038B (zh) * | 2019-08-01 | 2020-12-04 | 中国科学院信息工程研究所 | 一种基于规则的异常ua检测和分析的方法及系统 |
CN111787026B (zh) * | 2020-07-27 | 2022-09-27 | 北京飞讯数码科技有限公司 | 一种媒体数据的传输方法、装置、设备及存储介质 |
-
2006
- 2006-08-25 CN CNB2006101125955A patent/CN100493094C/zh not_active Expired - Fee Related
Non-Patent Citations (6)
Title |
---|
IPv4/IPv6 双栈防火墙的设计与实现. 肖文曙,陈雷,张玉军.计算机工程,第32卷第4期. 2006 |
IPv4/IPv6 双栈防火墙的设计与实现. 肖文曙,陈雷,张玉军.计算机工程,第32卷第4期. 2006 * |
P2P业务流量识别、分析和控制研究. 李君,王攀,孙雁飞,王浩云.计算机工程,第32卷第11期. 2006 |
P2P业务流量识别、分析和控制研究. 李君,王攀,孙雁飞,王浩云.计算机工程,第32卷第11期. 2006 * |
Transport Layer Identification of P2P Traffic. T. Karagiannis, A. Broido, M. Faloutsos, K. claffy.Proceedings of the 4th ACM SIGCOMM conference on Internet measurement table of contents. 2004 |
Transport Layer Identification of P2P Traffic. T. Karagiannis, A. Broido, M. Faloutsos, K. claffy.Proceedings of the 4th ACM SIGCOMM conference on Internet measurement table of contents. 2004 * |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101895469A (zh) * | 2010-07-19 | 2010-11-24 | 重庆邮电大学 | 对等网络流量牵引系统及流量牵引方法 |
Also Published As
Publication number | Publication date |
---|---|
CN1913528A (zh) | 2007-02-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN100493094C (zh) | 基于特征码的p2p数据报文检测方法 | |
Williamson | Internet traffic measurement | |
Rotem-Gal-Oz | Fallacies of distributed computing explained | |
DK2241058T3 (en) | A method for configuring the ACLS on a network device on the basis of the flow information | |
JP4759389B2 (ja) | パケット通信装置 | |
EP3151470A1 (en) | Analytics for a distributed network | |
Wu et al. | On the growth of Internet application flows: A complex network perspective | |
US7907543B2 (en) | Apparatus and method for classifying network packet data | |
US9055113B2 (en) | Method and system for monitoring flows in network traffic | |
US20080104688A1 (en) | System and method for blocking anonymous proxy traffic | |
Park et al. | NetCube: a comprehensive network traffic analysis model based on multidimensional OLAP data cube | |
US20050283639A1 (en) | Path analysis tool and method in a data transmission network including several internet autonomous systems | |
KR102423039B1 (ko) | 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 저장 방법 및 장치 | |
Trammell et al. | Identifying Skype traffic in a large-scale flow data repository | |
Yu et al. | Traffic identification and overlay measurement of Skype | |
Freire et al. | On metrics to distinguish skype flows from http traffic | |
Ptácek | Analysis and detection of Skype network traffic | |
KR102423038B1 (ko) | 대용량 네트워크 모니터링을 위한 실시간 패킷 데이터 수집 방법 및 장치 | |
Islam et al. | Network traffic analysis and packet sniffing using UDP | |
CN116458120A (zh) | 保护网络资源免受已知威胁 | |
Kumar et al. | Comparison: Wireshark on different parameters | |
Ilie | Gnutella network traffic: Measurements and characteristics | |
KR102537370B1 (ko) | 대용량 네트워크 모니터링을 위한 실시간 패킷 분석 방법 및 장치 | |
Hall | Multi-layer network monitoring and analysis | |
Yu et al. | The heterogeneity of inter‐domain internet application flows: entropic analysis and flow graph modelling |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
C17 | Cessation of patent right | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20090527 Termination date: 20120825 |