1、准确高效的应用层协议分析识别方法牟 乔北京德星电子科技公司 BSP Dept.，北京市海淀区理想国际大厦 9 层，100080摘 要: 对现行应用层协议分析方法进行总结概述，并介绍一套全新的、模块化的、分为低、中、高、补等四个级别十二大类的协议分析识别方法，可准确高效地将网 络上的各种通讯数据分门别类，以便于随后 进行网络流量监控与管理。尤其针对加密或伪装类数据包，可不 经过解密等需要深入 进行数据剖析或产生过多计算量的复杂途径进行分析。即使是不能分析的未知流量，亦有相关特殊方法进行强制性或使用者控制的非 强制性操作而将其纳入可控范围进行管理。列 举了利用模块化特性，在 Linux 平台上实现
2、本方法并进行实验后得到的数据的比较，以及整套系统在真实应用环境中的分析效果。关键词: 准确，高效，应用层，协议分析，协议识别中图法分类号: TP 文献标识码: A 文章编号：290142A suite of Precise and Efficient Analyzing Technique for Application ProtocolsMU Qiao（ BSP Dept., Beijing Destiny Electronic Technology Co. Ltd., Beijing 100080）Abstract: Collect and summarize the protocol a
3、nalysis method currently, and introduce a new suite of analyzing technique divided into 4 levels and 12 sorts. We can assort the application data including the unrecognizable data running on the internet into different kinds of protocols efficiently and precisely using this technique. For those encr
4、ypted or masked packets, it may finish the analysis task without decrypt or any other complicated calculation. Once they have been classified as protocols, Network Traffic Control could be done easily. Key words: Precise, Efficient, Application Layer, Protocol Analysis, Data Distinguishing近年来，随着人们对信
5、息量需求的增长，P2P 和流媒体等非关键性应用不断抢占网络带宽，如何禁止或控制非核心应用从而保障关键业务应用已成为热门话题。根据美国 Ellacoya 网络研究公司发布的调查一百万宽带用户的网络流量状况的统计报告，结果表明基于 HTTP 协议的互联网流量已占据全部流量的 46；排名第二的是P2P 应用的流量，其占据 37%的比例。排在后面的流量分别属于新闻组（9%） 、非 HTTP 协议的视频流媒体（3%） 、网络游戏（2%） ，以及 VOIP 网络电话（1%） 。网络中的数据是呈现多元化，复杂化的，而对其加以控制管理的前提是分析出各种类型数据的所属，因此，协议分析识别是网络带宽管理与分配的必
6、要前提条件。 1.现行识别方法随着网络通讯技术的日新月异，许多现行识别方法均已过时甚至失效，不能作为准确的识别标准来使用。目前最典型的方法为纯端口判定识别与 L7filter 对比识别。但由于协议的端口，特别是新协议的运行端口变得不可预期，从而使得纯端口判定识别开始走出人们的视野；而L7filter 对比识别因为在识别过程中会造成不可预估的延时并大大影响整体管理系统的运行效率也在逐步地被淘汰。另外，在真实的网络中，无法识别的流量一般会占到总流量的 30%以上，而鉴于这些未知流量的不确定性和大数据量等原因，对其进行控制就显得尤为重要。但遗憾的是现行绝大多数方法均不能做到对其进行管理。所以，对于新
7、识别方法的需求就显得尤为迫切。2. 新的识别方法经过深入分析大量数据包后，在实践中总结出以下新的识别方法，并分为初、中、高、补四个级别、十二类，限于篇幅每类方法仅作简单叙述。2.1 新识别方法的理论依据分析的实现过程是基于链表遍历和字符对比，识别匹配所需时间、准确率与整体识别引擎的规模大小均成正比。另外，哈希表的效率也是一个非常重要的参数。将协议大致分为 N 类，基于 HTTP 协议的互联网流量与 P2P 应用流量等，有计算等式：第 N 类引擎数第 N 类比对字符数平均计算次数 哈希参数补级保留值第 N 类协议占总流量的百分比其中，哈希参数哈希表效率100，补级保留值为补级分析方法消耗计算次数
8、2.2 整体系统架构概述整体架构基于 Linux 的环境，秉承模块化的概念，由前至后，在内核的网桥上可划分为连接跟踪模块(Conntrack) ，协议分析模块(Protocol Analysis)，条件匹配模块(Matching)，流量控制模块(Traffic Control)以及数据传导模块等。新的识别方法应用于协议分析模块。连接跟踪模块C o n n t r a c k协议分析模块P r o t o c o l A n a l y s i s条件匹配模块M a t c h i n g流量控制模块T r a f f i c C o n t r o ls k b连接已建立连接尚未建立c o n
9、 n e c t i o n 协议号 M a r k 号s k b - p r i o r i t y协议分析已经完成协议分析尚未完成条件匹配已完成尚未经过条件匹配字段值为I N T _ M A X字段值即为 f i l t e r 号s k b进入有 r c u 锁机制保护的引擎链申请内存初始化c o n n e c t i o n 结构进入有 r c u 锁机制保护的条件分类树进入相应的队列等待发送s k b f r e e发送至 T G 模块进行后续复制 、 吐数据等操作s k b s k b s k b连接跟踪哈希表协议 、 行为统计流量控制队列数据传导模块T r a f f i c
10、G a t h e r用户空间U s e r S p a c e让 s k b 继续在网桥上前行并最终由网卡发送走复制一份 s k b 吐至用户空间 ， 以进行数据统计等操作条件匹配查找树应用协议引擎链处理完毕 匹配完毕分析完毕图-1 各主要模块在网桥上的架构与基本功能描述2.3 初级识别方法2.3.1 端口初级判定法端口判定是指基于指定特殊端口，或基于可由公式计算出来的端口序列的初级识别方式。端口判定一般用于初始判定，仅作为一个条件来淘汰那些不符合的数据。在引擎链中，端口引擎即是针对端口初级判定的，类似于哈希表，有一个包含 65536 项的指针数组，每一个成员指向一个引擎链，而当数据包经过时
11、，根据其自身的端口号而进入相应的引擎链进行判定。如 Https 数据就会自动进入TCP 443 引擎链进行对比识别判定。虽然端口初级判定一般仅作为一个初始筛选条件，但针对 1024 端口以下、有 RFC 文档的公认协议，仍可由端口初级判定来确定其所属协议。例如，Tacacs 协议一般走49 端口，SQLnet 协议一般走 66 端口，Finger 协议一般走79 端口，SunRPC 协议一般走 111 端口，AppleTalk 会利用201 到 209 端口等。2.3.2 首字符初级判定法首字符判定是指基于指定第一个有效数据包的有效数据第一位，或基于可由公式计算出来的首字符、双首字符的对应值的
12、初级识别方式。首字符判定仅用于初始判定, 在引擎链中，首字符引擎即是针对首字符初级判定的。与端口引擎链类似，但其大小为指定的。如针对 TCP、UDP的首字符引擎链哈希表大小为 256，因为第一字符从 0x00到 0xff 的 256 种可能。而对于特殊的，如 tcp80series 或udp53series 上的首字符、双首字符引擎哈希表大小则指定为 1296。因为其数据为肯定是地址的明码，故共有az、0 9 等 36 种可能（特殊字符如 “_”、 “-”等均看作与 0 相同） ，故而 36 * 36 = 1296 种可能。其后各类数据就会进入相应的引擎链进行匹配，大大缩短了其所遍历的引擎链长
13、度。如电骡的数据以 0xe4 开头居多，则此类数据会进入哈希值为 0xe4 的 UDP 首字符引擎链进行查找；再例如中华网的邮件服务，为，即 “6d 61 69 6c 2e 63 68 69 6e 61 2e 63 6f 6d”，通过提取双首字符“m”和“c ”，则可以得到对应的key 值 23 与 13，通过公式，有其最终 key 值（即对应的引擎链编号）298，以进入 tcp80series_engine298引擎链进行识别判定。无论当前通过或正在进行判定的是所属连接的第几个数据包，首字符一直都是第一个有效数据包的有效第一位！此值是在连接跟踪中成立连接的时候赋给的，在连接消亡或中断之前不会
14、有任何改变！2.3.3 长度/二重长度初级判定法长度判定广泛应用在众多协议识别中最常用的淘汰性判定方式，根据连接跟踪中赋给的包长度值去判定当前数据包是否满足条件。而基于结构，有针对第一个有效数据包的单独长度判定或针对前两个有效数据包的二重长度判定。而在连接跟踪处理数据包并将前两个有效数据包的长度记录下来的同时，需同时记录一个已通过的有效数据包的包数统计值。这个统计值非常重要，因为实际分析中并非总是可以根据第一个有效数据包长度就完成识别，这样一来就需要这个统计值来定位当前的数据包究竟在连接中是第几个有效包。值得一提的是，虽然理论上应该将这个统计数据一直进行下去，但因为绝大多数的判定过程均可在前三
15、个有效数据包之内结束，故在此只会统计到第四个，对于其后的情况则不予理会。这也是效率与准确性之间妥协的一个结果。三类初级识别方法均是非常迅速的判定方法，但由于初级方法都是在表层对数据包进行识别，其利用的是在连接跟踪的处理完成的特殊指定字段，故判定中并不会触及数据包本身的真正有效数据。因此，其在准确性上有欠缺，故仅作为预处理，与中、高级识别方法配合使用。而基于初级方法速度快这个特性，在真正应用中一般都是判定数据包是否“不符合”当前协议，一旦不符合，则立刻跳出当前引擎，以缩短协议分析识别的耗时及网络延时。2.4 中级识别方法2.4.1 字符串、关 键字比对识别法从整体架构来说，在明确分析出数据是属于
16、 TCP 或者UDP 后，会令当前数据包所属连接的一个 char 型指针指向当前数据包的有效数据的第一位。其后，可用移动指针的方式来指向每个字符，并根据简单的“=”和“!=”来判定当前字符是否符合条件。对于连续或基本连续（即某个长字符串中间或夹杂这少数不确定的字符）的字符串，则可用位比对来实现，因为位运算的操作要比“=”和“!=”效率高。字符串、关键字比对一般不会单独使用，因为移动指针或进行位比较都是在剖析数据包内部数据。一般常用的方法是先用初级判定方法来淘汰掉大多数不符合的数据包之后，再开始进行字符串、关键字比对。另外，有一些特殊的应用，特别是游戏类的通讯协议，由于需要额外检测连接状态，经常
17、会出现连接的第一个甚至是前两个有效数据包都只包含少量数据的情况，即不得不从第二个甚至第三、第四个包开始进行比对。由此可见，有效数据包统计量就变得不可或缺了。例如游戏类，完美时空协议簇（完美时空开发和运营的一系列网络游戏，包括完美世界、武林外传、赤壁、诛仙、热舞派对等） ，经过数据分析，可发现其基本全部利用TCP 29000 端口进行通讯，而且第一个有效数据包的有效数据第二位总是比第一个有效数据包的长度大 2，而且第一个有效数据包的有效数据遵循“01/03 xx 10 xx 00 00 xx xx”这个模式（“xx”代表不确定字符） 。于是，便可以很轻松地利用等于或不等于来写明判定程序。不过由于
18、位对比必须是在两块内存间进行，需要先将数据包中的数据用 memcpy 复制到一个字符串中，然后与固定的字符串进行对比。但由于 memcpy 造成的延时和资源消耗要远比使用位对比节省下来的部分多得多，因此，在实际应用中不提倡使用位对比。2.4.2 五元组比对识别法协议的目的在于通讯，而网络不可能在某一时段只运行通讯双方希望获取的数据，所以，各种协议的内部就一定包含了特殊的、能够让通讯双方都认可的特定字符，以有效地从网络分复繁杂的诸多数据中找到自己需要的。即，这些特定字符中很多情况下都包含了通讯双方的自然信息，如 IP 地址，正在使用端口或下一连接使用的端口等。虽然连接已经建立之后依旧告知当前使用
19、的 IP 地址和端口（准备使用的下一端口等情况放在连接跟踪部分讨论）实质上是没有意义的，但其却为识别提供了极大的方便。连接信息五元组包括源 IP 地址、目的 IP 地址、源端口、目的端口以及所属协议（并非应用层协议号，而是四层协议号） ，其中又以源 IP 地址最为常见。从本质上来说，五元组识别是一种动态的字符串比对识别。例如流媒体类，PPlive，经过抓包分析，发现它承载主要数据流量的连接大部分是 UDP，且以0x0b、0x0c 、0x0d 开头。于是便可在 UDP 0x0b，UDP 0x0c，UDP 0x0d 分别注册三个首字符引擎，而其第一个有效数据包的有效数据的第 49（+0x30）位到
20、第 52 位恰恰是源 IP 地址的十六进制表示，同时发现第 65（+0x40）位到第 68 位恰恰是其目的 IP 地址的十六进制表示。这样就可以首先利用 ntohl 来获取连接信息中的源、目的 IP 地址并转换成本机模式，之后用一个包含 4 个成员的数组用整形记录下每段的地址，如 192.168.2.46 记录为0xc0、0xa8、0x02 和 0x2e。再用数组的各成员同经过移动的数据指针所指数据进行对比以确定其是否属于 PPlive 通讯数据。虽然五元组中可用的还包括源端口和目的端口，但一般不用端口来进行判定。一方面由于有 IP 地址的 4 位判定已经足够，不需再用端口的 2 位数据进行匹
21、配，另一方面基于连接的不确定性，在这里端口并非是一个较好的判定依据。2.4.3 库比对识别法库比对识别是指，当其某个或某些特殊数据的固定位置的数值总是在某一个范围或一定属于某几个值中间的一个的情况下，而采取的将所有可能的值录入一个数组或数据库，以进行比对判定的方式。这种方法一般常应用于判定即时通讯类软件产生的数据的识别和 P2P 类的初始连接数据识别。例如即时通讯类，腾讯 QQ，虽然它的协议是加密的，客户端不断在升级，协议也经常有伪装，但对于腾讯QQ2008 以后的客户端来说，其版本号是一个固定的 2 位数值，而且在每次连接的开始都会检测传递当前客户端的版本号。截至腾讯 2008 KB7 为止
22、（包括腾讯 2009） ，其版本号可以罗列如下：0x12, 0x03, 0x11, 0x5b, 0x12, 0x21, 0x12, 0x37, 0x15, 0x01, 0x11, 0x4d。在利用版本号判定的同时, 还发现命令号也是一个固定的 2 位指令集，包括初始连接、握手、失败、聊天文字传输、密钥传输等等，例如0x00, 0x91, 0x00, 0x62, 0x00, 0xba, 0x00, 0xdd,0x00, 0x22, 0x00, 0x16, 0x00, 0x17, 0x00, 0x02, 0x00, 0x01, 0x00, 0xd4, 0x00, 0x0d等（具体各命令的对应功能在
23、此暂不详述） 。由此，判定程序可以很明了地写出，对比其第一个有效数据包的有效数据第二、三位是否符合版本号中之一，而且第四、五位是否符合 QQ 的指令集之一。2.3.4 白名单、黑名单过滤识别法白名单、黑名单过滤实质上是一种专门针对 Http 的库比对识别，采取取得地址关键字与库中的关键字进行匹配的方式来进行识别。属于白名单即为绝对安全的网址（如各个网页邮箱的访问， 等） ，会在流量控制中为此类 Http 数据单独建立一个保障队列，以保证其访问速度，而相对应的属于黑名单即为绝对禁止访问的网址（如色情网站或游戏网站， 等） ，一旦识别出当前数据是访问当前这类地址时，条件匹配模块会立即为其连接打上禁
24、止的标识，并在流量控制模块中进行丢弃数据包操作。由于这是专门针对 Http 的操作，所以可以利用tcp80series_engine 来缩短查找过程，依旧是首先在注册引擎前计算出其哈希值并挂载到相应的引擎链上。当 Http 数据包到来是，就会进入相应的链表进行对比查找。白名单、黑名单可根据具体使用环境来进行自行设置，例如 ，关键部分为 x.google.x（“x”代表不确定部分） 。所有的白名单、黑名单都可用“.”和“/”这两个特殊符号来确定关键部分的指针位置的。2.4.5 字段标志获取识别法根据 Http 的 RFC 文档，可知其各部分数据在初始连接交互时是以明码传输，并由如Referer、
25、Host 、Connection-type 等几个标识而划分成的几个字段引领各段数据。在进入 tcp80series 引擎链之前，数据包需要经过循环移动指针来确定地址信息（如）的位置来计算双首字符关键值。此信息有时存在于 Referer 字段中，有时出现在 Host 字段中。在定位到字段后，便可随意读取各所需的信息了。需要注意的一点是，因为进行字段标识获取之前就已经确定了当前数据肯定是 Http 协议，且字段的第一位肯定是大写，最后肯定跟着一个特殊符号“：” ，所以对字段的字符串对比判定可以精简到三位，即：字段的第一位的大写字符，最后跟着的特殊符号“：” ，以及中间的某一个必要位（如特殊符号、
26、大写、或在没有必要位时直接利用第二位即可） 。以上所述的仅仅是字段标志获取识别的一种应用，更为重要的功能是辅助进行“嵌入式”协议的识别。对于迅雷和很多 P2SP 类协议（分块下载协议） ，其传输数据都会伪装成 Http 协议，但它们有一个共同的特性，就是存在Pragma 字段，且随后一定紧跟 Range 字段。Pragma 的作用是标明当前是一个分块下载型的连接（一般显示为“Pragma: no-cache”） ，而 Range 则是确定接下来传输的数据在整体数据中的位置（如“Range: bytes=638837539-”） 。于是，根据先“Pragma ”后紧跟“ Range”这个独一无二
27、的特征，迅雷等协议的传输数据可以准确地被识别出。不过，即便已将对比过程精简又精简，其仍会消耗大量的时间用于循环判定。所以，字段查找过程可以“嵌入”到查找 tcp80series 的地址信息的过程中。这样一来就不存在进行多次循环对比的问题，可大大减少因为判定迅雷等协议而在 TCP 80/8080 端口造成的延时（即造成网页浏览缓慢） 。但是有其利必有其弊，在协议进行“嵌入式”判定的同时也决定了此模块必须融入当前“嵌入”的模块，不可自由加载卸载。如迅雷等协议嵌入在 tcp80series 引擎链预处理的循环查找判定中，而 tcp80series 引擎链又整合在 TCP 总判定的模块内，所以，迅雷等
28、 P2SP 类、分块下载协议实际上就成为了系统默认协议。五类中级识别方法与初级识别方法相比，最重要的区别是开始剖析数据包内部的有效数据，所以，尽管会造成一定的延时问题，其判定效果要远比初级识别方法好。一般除极特殊协议外，都需要利用中级识别方法来准确识别数据。2.5 高级识别方法2.5.1 连接跟踪识别法连接跟踪识别在本身 Linux 系统中已经有所描述，不过那是针对 FTP、 Amanda 等协议，且其过分考虑的通用性，这并不符合应用层协议识别的标准，需加以简化改进。首先需要明白一个结构，就是 expect。这个结构会由指针连接成一个链表存在于连接跟踪模块之中，在每个连接建立之初，会查找 ex
29、pect 链表，看是否有相吻合的五元组存在。如存在，则表明此新连接是被一个已经建立的连接所期待出现的，而且可以称这个新连接为已建立的连接的子连接，已建立的连接就相对应地称之为父连接。现有的连接跟踪识别不符合需求。首先在本方法中不需要区别二、三层和四层的协议，因为在判定之前，已经很明确地识别出其是属于 TCP 还是 UDP 了（其他数据已由其他各层引擎判定结束） 。其次，FTP、Amanda 等协议每个父连接只会拥有一个单一的子连接，而诸如 BitTorrent等协议，每个父连接会对应几十甚至上百个子连接。故综合以上需求和条件，确立了使用一个一元数组进行记录的方式来读取、传输和记录写入 Expe
30、ct 的五元组信息。Expect 链表的五元组信息是由读取特定父连接的特定数据包的特定数据而确定录入的，于是，如何确定父连接并且找到关键数据包和关键数据包内的关键数据就成为了连接跟踪识别的关键。以 BitTorrent 协议为例，可发现在初始连接服务器过程中，会有以下伪装成 Http 的通讯数据， “GET /announce.php?info_hash= HTTP/1.1”（“ ”部分为略去的部分非关键数据） ，从字面很容易理解，这里本机正在跟服务器声明某些关键信息，而紧跟着从服务器的返回数据中在“HTTP/1.1 200 OK”之后可以发现“:interval”和“:peers”等渴望已久
31、的节点信息。但是仍需注意的是，这里是把特殊符号同时放在字段的前面和后面来传输的，如“:peers300: ”代表有 300 / 6 = 50 个节点信息（每个节点信息包含 4 位的 IP 信息和 2 位的端口信息） 。先用一个暂存结构数组将信息读出，然后再逐个导入Expect 链表，这样一来 BitTorrent 的父连接就分析完毕了，接下来的就是等待子连接的出现。当然，BitTorrent 并非是那样照章办事，而是总会进行一定地伪装以欺骗分析技术人员，如它有可能将“GET /announce.php?info_hash=”更改成 “GET /?info_hash=”或“announce?in
32、fo_hash=”等，并且这个父连接使用的端口也不会总是固定在 80 和 8080 上，但它却会总以“GET /”开头。这样，分析过程中可以做的就是在 TCP 0x47 上加一个首字符引擎。另外，BitTorrent 的父连接在传输节点信息时，实质上有简、繁两种模式，以上所提及的 6 位数据表示一个节点是简洁模式，繁杂模式即是完整模式，它会把地址用十进制数值包括“.”来完整地表示出来，具体采取哪种模式会在首包（请求包）中标明。不论是简洁还是完整模式，只要锁定了关键连接的关键数据包，一切均可迎刃而解。需要注意的是，并非所有注册到 Expect 链表的信息节点都会被用到，为避免长时间运行而造成内存
33、溢出等后果，需对每个信息节点设定一个死亡时间，虽然 BitTorrent 的官方文档中定义的是 30 分钟，但在实际试验中发现，只要300 秒的时间即可确定当前子连接信息是否是可被激活的。2.5.2 可疑性模糊识别法可疑性模糊识别仅仅是针对 P2P 而言。鉴于加密等原因，在为效率着想而不可对数据进行解密时，可首先根据现行统计数据或其它相关现况而判定出一个分别针对各个用户的可疑程度（如该地址是否出现了某种 P2P 的初始连接数据包等） ，并扫描可疑端口（如电骡的 UDP 4661 到4669 端口等）和可疑首字符（如电骡的 0xe2、0xe3 和0xe4 等） ，一旦发现这些可疑处的流量超过某个
34、值（由经验来讲，一般办公室正常上网带宽平均不会超过 10K） ，就可以立即认定此用户（地址）正在使用相应的 P2P 软件。虽然这样可较准确地判定出 P2P 流量，但其并不能很好地区分其究竟属于何种 P2P，比如当网络中检测出某个用户同时有电骡和 Limewire 的初始连接包，且其可疑端口上的数据超出了正常上网的流量范围时，尽管在判定中可以确定这部分流量属于 P2P，却无法区分开它是属于电骡还是 Limewire。但在实际使用中，基本不会有同时使用两种 P2P 软件同时进行下载，并且对于三大最常见 P2P，即BitTorrent、电骡和迅雷来说，迅雷已经在字段标识搜索对比判定方法中描述得很清楚
35、，它绝大多是流量还是来源于P2SP 中的“S ”，即服务器，而部分流量肯定是伪装成Http 来进行传输的。对于 BitTorrent，一般它用伪装的 Http以及 UDP 来进行与服务器的通讯和 DHT 网络的资源探索，但最终的承载流量的数据包会利用没有任何规律的加密过的 TCP 大数据包来进行传输。电骡虽然一般情况下使用UDP 和 TCP（很少，一般仅在 UDP 失效的情况下才会发生）来进行资源探索，但真正的数据传输却都是依靠 UDP数据包。如此，三大 P2P 便可以非常简单地区分开来。虽然这种可以行模糊识别存在一定的误判性，但其结果却是在可以接受的范围内的。如同连接跟踪中需要额外的 Exp
36、ect 链表进行子连接信息五元组的暂时存储一样，可疑性模糊识别也需要二维数组来暂存各个 P2P 协议的可能性 IP 地址。由于一般的网络均采用 B 类或 C 类网址，故所需要顾及的仅仅是内网地址的后两位。首先每当检测出某种 P2P 协议的初始连接包时，除了要为连接赋上相应的协议号，还要向这个可疑性判定二维数组中的对应项中填入当前连接的源地址的后两位。这样每当可疑端口或可疑首字符上的流量出现异常时，只要其 IP 存在于这个二维数组中，那么就可以直接将这些未能识别出的大流量数据判定为相应的 P2P 协议。有添加过程就必须有删除过程，否则这个二维数组会很快被塞满。每当发现某个已经被判定成在使用某种
37、P2P的 IP 的全部流量低于某个警戒值时（如 5K） ，则即可认为其已经关闭了 P2P 下载，并将此地址对应的所有项统统从数组中删除。2.5.3 用户行为识别法行为特征与行为识别是非常新的一种技术，其主要面向的对象也是 P2P 协议。因为 P2P 协议会自动跳转端口并且对自身数据进行加密，所以其对防火墙和安全代理的穿透性以及对网络管理人员的欺骗性非常强，很多时候单纯地去基于数据字符本身来进行判定只会竹篮打水一场空，这时，就需要一种站在更高的角度去看待和识别 P2P 的方法。首先，不论 P2P 如何伪装，它的数据量是无法掩饰的，而且，它的多连接数、单个包数据量异常大以及使用非常规端口（1024
38、 以上，实际上经常在 5000 以上）等特性也是无所隐遁。因此，数据包内的数据究竟如何可以完全不去理会，改而从统计上入手。总的来说，虽然 P2P 在每次使用时的通讯端口都不同，但在每次使用中的通讯端口却是固定的。有以下几个行为特征可以总结出：(1) 每次使用的某段时间内总是用固定的几个本地端口进行通讯；(2) 发起大量的连接，并且是一个内网 IP 对一群外网 IP；(3) 其利用的通讯端口是非常规端口，一般会在 5000 以上；(4) 数据流量一定有异常，单个数据包的长度有异常； 由此，便可根据统计数据来简单而轻松地进行判定。P2P 类，Poco，经过反复抓包并查看数据后，发现软件启动时会首先
39、大量发 UDP 1107 探测包（吻合第 2 条行为特征）以检测当前本机的 peer 表中的各个节点是否能够连通；每次使用过程中会在固定的时间内使用用固定端口通信，如 UDP 8009，UDP13018 等（符合第 1、3 条行为特征） ；还有最重要的就是使用 Poco 的 IP 的流量远远大于正常上网的流量（符合第 4 条行为特征） 。需要补充的是，行为识别或多或少仍然存在一定的不足，在实际应用中，一般还会与可疑性模糊识别的混合使用。三类高级识别方法与前两个级别相比，最大区别就是不仅限于对当前数据包本身的分析，其还包括诸如利用链表暂存连接信息而构造出的父子连接关系跟踪识别，利用特定条件触发而
40、记录 IP 后轮询可疑性而进行的模糊识别，以及基于行为层面的判定等。所有本类方法均需要额外向系统申请内存用以存储辅助判定的各数据表或库。虽然高级识别方法可以极大地加强识别率和准确率，但延时极大，因此，需要尽量控制使用高级识别方法。2.6 补充识别方法补充识别方法是在已经过各种判定后却一直未能识别出协议之后所采取的最后的方法。因为网络中未能识别的流量一般在 30%左右，为了进一步管理这 30%的流量，需进一步将这些未知流量的部分信息解析分组并呈现于统计之中。补充识别方法是最后的方法。2.6.1 强行端口甄别强行端口甄别分为两种，一种是在分析 TCP 协议时，针对未能形成连接的数据包以及握手数据包
41、。由于在实际网络环境下，这种类型的数据虽然占据的流量并不是很大，但其数据包量非常大。所以不能简单地将其归类为未识别数据。在试验的模拟环境下，这部分数据包占据了未知数据流量的 10%，总包数的 40以上。另一种强行端口识别定位于低、中、高三个级别的识别之后，当某个正常的连接经过完整的引擎链后却无法匹配任何一个引擎（协议）时，就需要读取连接跟踪结构中的连接信息五元组中的目标端口，并将其赋值为特殊的一系列协议号，从而标识出基本特征。3. 实验数据利用以上分析方法，在 Linux 环境下运行所编写的程序。实验分为准确性和识别率两个方向，分别由加载全部协议分析模块（低、中、高、补）和仅加载基础协议分析模
42、块（低、补、及部分中级）来模拟旧识别方法和新识别方法的应用状况。另，额外地做一轮仅仅应用低级分析识别方法的实验，以同前两种情况进行对比。3.1 环境搭建如下图：安装了 L i n u x 内核与各分析模块的工控机不挂载任何协议分析引擎安装了 L i n u x 内核与各分析模块的工控机仅挂载部分协议分析引擎安装了 L i n u x 内核与各分析模块的工控机挂载全部协议分析引擎测试用 P CI n t e r n e t测试用 P C 经过三台设备访问I n t e r n e t ， 这样三台设备统计的流量都是完全相同的 。图-2 实验环境搭建示意图3.2 实验中进行的操作实验的 4 个小时
43、内，在本地终端上主要进行了以下应用操作：(1) 浏览网页(2) 观看网页视频(3) 使用 PPStream 流媒体软件(4) 使用皮皮在线影视流媒体软件(5) 使用迅雷下载 Bittorrent(6) 内网互传文件(7) 登录 Poco 下载歌曲(8) 使用 Windows Messenger（即 MSN）(9) 登录网页邮箱收发带附件的邮件3.3 准确性与识别率3.3.1 第一组实验：图-3 与图-4 为仅应用低级分析识别方法（即，除了基础架构外的分析模块均未加载）而得到的统计结果。很遗憾一个协议都没有分析出来，因为现在的协议已经不能仅仅依赖与端口进行判定。图-3 仅应用低级分析识别方法的应
44、用流量协议统计饼图图-4 仅应用低级分析识别方法的应用流量协议统计列表3.3.2 第二组实验：图-5 与图-6 为仅加载基础协议分析模块（即，除了最常用的 20 余种协议以及内置的协议外，其他的分析模块均为加载）而得到的统计结果。很明显，现在的效果要比前一组好得多。对于同样的数据，至少已经分析出迅雷、Http、PPStream 等协议，但依旧存在着许多端口未能分析。图 -5 仅加载基础协议分析模块的应用流量协议统计饼图图 -6 仅加载基础协议分析模块的应用流量协议统计列表3.3.3 第三组实验：图-7 与图-8 为加载全部协议分析模块（即，已经使用了全套的低、中、高、补等级别的协议分析识别方法
45、）而得到的统计结果。对比起前两组统计来说，这第三组是最好的。不但分析出了所有正在应用的协议，而且还将 Http流量进行了细分，将 FLV 格式在线视频、网页邮箱服务等从 HTTP/类 HTTP 中剥离出来。而且在加上行为分析等高级分析方法后，UDP 10007 等以前无法识别的流量也被识别出来。图 -7 加载全部协议分析模块的应用流量协议统计饼图图 -8 加载全部协议分析模块的应用流量协议统计列表总之，由三组实验统计数据，很好地证明了这套新的协议识别方法的识别效果和准确率。3.4 网络延时/分析效率延时统计是由 thrulay 程序从内网端的一台终端向外网端的另一台终端不断发送不能被识别的数据
46、包（这样，数据包就会遍历最多的引擎，也就是这时延时最大）而计算得出的一个平均值。第一组实验不加载引擎第二组实验加载部分引擎第三组实验加载全部引擎模块总数包括基础模块 6 131 324引擎总数应用层引擎数 0 976 2489延时量单位：毫秒 0.384 0.422 0.998 2.303 4.691 31.392由上表明显看出，随着引擎挂载数目的增加，延时量也呈现一个加速度增长，这主要是受哈希表的运算效率所影响。所以，在真实应用中，一般只会根据实际情况选择性地挂载引擎。4 真实环境的分析效果经过在准确性、识别率以及网络延时方面的协调后，使用者最终可以根据各种具体实际情况来得到一个最佳协议加载
47、量。以下图-9 与图-10 为在某 200 人规模的集团总部的出口布置设备上的协议分析效果统计图和统计列表。图 -9 某集团某时段的应用流量协议统计饼图图-10 某集团某时段的应用流量协议统计列表实际统计中，在挂载了 257 种协议（216 个模块，且包括诸如迅雷、BitTorrent、电骡、Poco 等利用了高级协议识别方法的协议分析模块）后其整体网络延时小于 9.2 毫秒，正常上网没有任何异常感觉。而且识别率大于 95。5 结束语实质上，本协议分析识别方法除了最后的行为识别以外，依旧是基于数据包数据的特征进行处理，但考虑的范围更广，着眼层次更高，分析的深度更专，对突发事件（如未知流量）的处
48、理能力更强，速度更快。但单独的协议分析识别是没有意义的，它需配合其他模块来实现其商业价值，如：(1) 配合统计，进行网络状况监视与流量控制；(2) 配合瞬间握手等功能，对 TCP 流量进行网络提速；(3) 构建应用防火墙，入侵监测，进行上网行为监控； 以上是我近几年涉猎 Linux 设备模型特别是 Linux 内核的网络部份，在学术探讨交流和具体的网络流量控制设备的研发中，实践总结提炼出的一些方法和经验，主要涉及应用层协议分析与条件模式匹配等内核模块的研发，以及 Linux 内核中的连接跟踪模块和网络流量控制等模块的改进，期望能得到诸位前辈同仁的指教，以在研讨中前进提高。参考文献:1 Jona
49、than Corbet & Alessandro Rubini & Greg Kroah-Hartman, Linux Device Drivers (3rd Edition), 2005 by OReilly Media, Inc.2 Daniel P. Bovet & Marco Cesati, Understanding the Linux Kernel (3rd Edition), 2008 by OReilly Media, Inc.3 Christian Venvenuti, Understanding Linux Network Internals, 2006 by OReilly Media Inc.4 小高知宏, 基礎 TCP/IP - 作成解析, 社 20025 W. Richard Stevens, TCP/IP Illustrated - Volume 1: The Prot
