20210301 -

0. 引言

大概一年半之前，让学生整理过关于DPI的内容，当时让他部署过nDPI的DPDK版本；当时给我的DPI的材料也没仔细看，这里直接贴到这里来。
（材料中的内容应该也是从别的地方复制粘贴的，基本上就是一些显而易见的材料）

1. DPI

1.1 DPI是什么

DPI（deep packet inspection）全称深度数据包检测，是一种计算机网络数据包过滤技术，用来检查通过检测点之数据包的数据部分（亦可能包含其标头），以搜索不匹配规范之协议、病毒、垃圾邮件、入侵，或以预定之准则来决定数据包是否可通过或需被路由至其他不同目的地，亦或是为了收集统计数据之目的。在传统数据包检测技术(OSI L2-L4之间包含的数据包元素的检测分析)之上增加了对应用层数据的应用协议识别，数据包内容检测与深度解码。

1.2 DPI的功能

深度数据包检测可以检查消息的内容并识别它来自的特定应用程序或服务。此外，可以对过滤器进行编程，以查找和重新路由来自特定Internet协议（IP）地址范围或某些在线服务（如Facebook）的网络流量。DPI可用于作为网络安全工具可以用于检测和拦截病毒和其他形式的恶意流量。但它也可以用于如窃听等活动。深度数据包检测也可用于网络管理，以简化网络流量的流量。例如，标记为高优先级的消息可以在不太重要或低优先级的消息或在休闲互联网浏览中涉及的数据包之前路由到其目的地。DPI还可用于限制数据传输，以防止点对点滥用，从而提高网络性能。常用功能包括以下内容：
（1）通过对流量的识别来掌握网络中承载的数据内容。
（2）分析出用户的网络行为；
（3）同时根据链路状态及功能需求，对网络流量进行限速和控制等处理
（4）通过特征匹配技术，将数据包在封装过程中所添加的各层头部信息解析并提取，然后与已有规则库中特征信息进行匹配，从而进行流量的识别。

在这里多说两句，实际上虽然这里对DPI进行了这些功能的介绍，但是以我的经验来看，平时的时候可能默认了这个功能的存在，因为经常从事流量相关的任务，那么比较简单的方法来识别协议，那就是通过字符串匹配，虽然现在很多人强调机器学习或者深度学习的方法，但是对于普通的未加密的流量来说，通过DPI的方法，无疑是最简单而且最直观的，因为通过这种方法可以让人不用从统计学的模糊角度上，去体会这个流量可能属于什么类别，而是直接用最简单字符串作为证据。当然，利用字符串匹配方法的时候，还要考虑模板的完备性和排他性来决定判定协议或者判定应用的准确度。

2. DPI使用的算法

其实这部分内容本来是想让学生去找一些DPI都是使用哪些开源的模式匹配或者字符串匹配的算法，但是他也没怎么找到。关于这部分，我知道两个内容以前了解过或者用过的，一个是hyperscan，另一个是ac自动机，本质上他们都是字符串匹配库，或者说正则表达式的库。

而对于流量处理的过程中，如果是性能要求比较高的场景，比如流量出口，那么采用的编程的语言大多都是C语言，虽然有些地方也会使用C++，但据我了解比较少。也是就是说，对于这部分而言，使用的库就是基于C语言的正则表达式库，如果这个库能够在流量处理方面增加一些专长，或者说提供一些基于流浪上的优势，那么这个库就再好不过，hyperscan就是其中一个。

2.1 l7-filter

l7-filter的基本思想使用连接的应用层数据的正则表达式匹配来确定正在使用的协议。在每个数据包上运行正则表达式匹配器是没有意义的。这不仅会浪费大量的时钟周期，而且对于匹配大多数数据包也没用，这些数据包可能包含某些文件的中间部分或诸如此类的内容。相反，l7-filter只查看“hello”消息的连接的前几个数据包，例如“ 220 ftp server ready ”，“ *ok ”或“ HTTP / 1.1 200 ok ”。
l7-filter不是让用户在命令行上提供正则表达式，而是提供一组模式定义文件。为了匹配协议“foo”，用户键入“ iptables … -m layer7 --l7proto foo”，iptables读取定义“foo”的正则表达式/etc/l7-protocols/foo.pat。

注：以上内容没有经过具体测试，仅仅是学生搜集的材料。

3. DPI的开源框架

3.1 nDPI

nDPI（OpenDPI的一分支）是用来检测非模糊协议的开源版本。PACE则包含了模糊与加密协议，与Skype或加密BitTorrent所使用的协议相关。OpenDPI已不再维护，取而代之的是nDPI，现仍积极维护与扩展包含Skype、Webex、Citrix与其他软件在内的新协议。
支持协议详见：https://www.ntop.org/products/deep-packet-inspection/ndpi/

3.2 L7-filter

L7-Filter是用于Linux的Netfilter识别应用层之数据包的分类器。L7-Filter可分类Kazza、HTTP、Jabber、Citrix、BitTorrent、FTP、Gnucleus、eDonkey2000与其他软件。L7-Filter亦可分类流、电子邮件、P2P、网络电话、协议及游戏等应用。
支持协议见http://l7-filter.sourceforge.net/protocols

L7-filter的思路就是使用正则表达式来匹配应用层的数据来判断报文使用的是什么协议。L7-filter并不是把全部包都解析一次，而是通过分析关键的包，解析payload或者连接信息来判断应用类别：L7-filter基于数据流工作，对于一个应用，可能会有多个数据流，但L7-filter并不针对所有数据包进行匹配，只选一个流的前面几个数据包，如果没有识别出任何特征信息，则此数据流无法被识别，停止匹配。
L7-filter提供了内核和用户空间的两种实现，但是似乎基于内核的比较被重视，因为用户空间的版本效率很低（由于做匹配消耗计算资源）。

3.3 Hippie

Hippie（高性能协议识别引擎）是一项开源项目，被开发作为Linux的核心模块。Hippie为Josh Ballard所开发。Hippie支持深度数据包检测与防火墙功能。

3.4 SPID

SPID（统计协议识别）项目透过识别应用程序的讯务，进行网络流量的统计分析。SPID算法可透过分析pcap档的流量（数据包大小等）与负载统计（比特值等），检测应用层协议（第7层）。SPID只是个概念验证程序，当前支持大约15个应用及协议，如eDonkey混淆讯务、Skype的UDP与TCP、BitTorrent、IMAP、IRC、MSN等。

3.5 Tstat

Tstat（TCP统计与分析工具）提供流量图像的概观，并给出许多应用与协议的细节与统计。

3.6 Libprotoident

Libprotoident引入轻度数据包检测（LPI），只检查每个方向之负载的头4个字节。这可减轻对隐私的疑虑，降低为分类而需存储数据包纪录的硬盘空间。Libprotoident支持200个不同的协议，且其分类使用负载模式匹配、负载大小、端口号与IP匹配等混合而成的方法。
支持协议见https://wand.net.nz/trac/libprotoident/wiki/SupportedProtocols
这个库是由新西兰怀卡托大学网络研究组（WAND）开发的一个DPI库，这个研究组有不少成果，主页：http://research.wand.net.nz/
这个库有个最大的特点就是仅使用4bytes的payload数据就能进行流量分类，节省储存空间之余还在一定程度上降低DPI技术对个人隐私的侵害。使用libprotoident时，需要先通过抓包工具收集数据，并确认数据包的方向：因为在网络应用的双向交互中，会产生向不同方向的流量，这个需要用户程序进行判断，判断一个每个包的方向才能交给libprotoident。
使用libprotoident前要求监控程序在双向流开始时就要初始化一个LPI数据结构并由始至终地监测到双向流的结束。
一个用户、一个服务器，两者之间运行着一个监控程序。用户浏览一个页面，此时浏览器发送第一个请求数据，从监控程序监测到请求数据的时候就创建一个lpi_data_t structure，并一直保持监控服务器和浏览器的交互过程，直到最后交互结束。
LPI数据储存着libprotoident用来判断应用协议种类的所需的双向流的信息，包含以下信息：
1.每个方向的payload的前4个字节的数据
2.每个方向的首个承载payload数据的包大小，忽略TCP/UPD/IP头
3.传输协议
4.使用的端口号
5.流所使用的IPv4地址
6.每个方向的首个承载payload数据的包的TCP序列号
7.每个方向的payload总数，最多去到32KB

为了保证重新排序TCP片段，因而需要TCP序列号和总载荷libprotoident只关心首个承载了数据的包，直接忽略其他的包。
libprotoident使用0和1来作为方向的值，一个方向定义为0，那么另一个方向肯定为1，至于具体是什么节点到什么节点、究竟是客户端到server还是server到客户端都不重要。
当方向都定义好，LPI数据也准备好，就可以传给libprotoident进行处理。
libprotoident需要先把一个包、该包所属的流的LPI数据和包的方向传给lpi_update_data函数，然后该函数会从包抽取必要的信息存进LPI数据。
最后，lpi_guess_protocol函数读取该双向流的LPI数据，以判断双向流中使用了何种应用层协议。
libprotoident使用匹配的方式来进行判断，在libprotoident中，针对每个协议都有一个模块。在判断协议时，首先使用所有协议模块对LPI数据进行匹配，直到匹配成功。
而每个模块都可能会使用以下几项规则来进行匹配：
1.payload字段匹配：比如BT协议，如果在payload中出现’B’，‘i’,'t’这样的字段就判断为BT协议。
2.payload大小：网络应用的某些数据包的大小可以用来用来进行判断，因为这些包是关键而且大小几乎是固定的，比如一些P2P应用进行初始化的包。
3.端口号：端口号就不多介绍了，这是很基本的匹配规则，对于使用固定端口的应用来说几乎很少会误判。
4.IP地址：这个规则比较少用，但有必要保留。
关于libprotoident现状：
该项目还在持续开发，最新的版本于今年4月释出，目前支持的协议已经达到300种以上。
（上述文字未考证具体时间）

4. 检测引擎的设计

检测引擎自身包括三个部件：协议解析器、算法引擎和检测结果处理，下面主要对其关键部分的协议解析器进行说明。现阶段额度协议解析器的职责主要有：
1）协议确认： 进入HTTP、HTTPS等协议解析器的条件都是固定端口映射。但越来越多的互联网应用正试图通过80、443等传统端口来逃逸传统网络设备的检测和控制。因此必要的协议确认是防止这种逃逸的前提。
2）协议切分： 协议切分是在流（会话）的基础上进一步细分出“检测流”或者叫“事物”的概念。例如：HTTP的一次transaction、FTP的一次用户登录行为、SMTP/POP3的一次邮件发送/接收等，都抽象成一条“检测流”。有时一条流可以传输多次检测流，甚至同时有并发的检测流出现。协议切分对于关心检测流的业务模块有着重要意义，例如内容过滤和应用审计。
3）协议域切分：协议域切分是在最小的粒度上细分报文。将检测流分成Header和Body部分，Header还要细分成各个Field，包含Field Value和Field Data部分。协议域切分有助于判别该头域是否需要检测，判定该头域命中的特征与之定义是否吻合，以及识别提取审计日志信息的关键位置。
4）解码： HTTP的URI部分和邮件协议的Subject部分等进行了编码，需要协议解析器进行解码，大多数情况下需要我们将解码后的字段送入算法引擎。有些情况又有个别特征基于编码前定义，需要我们将原始字段送入算法引擎，但同时发生会对性能产生一定损耗。
5）解压缩：HTTP可以用gzip、x-gzip、deflate等方式传送压缩后的数据内容，在用户的配置要求下解析器会将内容解压缩后送入算法引擎，以帮助我们发现压缩数据中的需要被检测出的特征。
6）SSL卸载：在用户的配置要求下，可以通过SSL卸载技术尽可能还原HTTPS中的原始流量，进行更加全面的检测和控制。
7）协商协议识别：FTP、SIP以及很多加密方式的P2P协议都采用协商甚至多次协商的方式来进行数据传输。对应的协议解析器需要能够通过控制通道报文的解析识别出协商协议的数据通道的五元组特征，通过协商关联表的匹配来识别其数据通道。
基于这些协议分析完成之后，通过算法引擎可以匹配查找可以发现相关的检测结果，同时送到后续的动作设计模块进行处理。在内核态，DPI支持大量的动作以及它们的组合，各个DPI的业务模块都可以基于规则或者规则分类来配置报文的动作。这些动作包括Permit/deny、Drop丢掉后续报文、Redirect或者发送双向TCP Reset断开连接、生成攻击日志告警等。
8）特征库的设计模型
在进行DPI特征库的设计时，一般都是采用统一的文件头结构和开放式TLV架构，易于软件统一处理和后续业务扩展。同时考虑到不同产品对存储空间、转发性能、并发规格的不同要求，为不同的产品（不限于NGFW）量身定制了不同的特征库。并且，为了能够快速完成升级，在服务器上放置了邻近旧版本的增量库（补丁包）。

5. 关于DPI的总结

5.1 DPI的实现过程

目前来说，虽然对DPI的概念有所了解，也知道大概的技术手段，但对于他具体的代码架构，或者说实现机制，还是不太了解，这个部分需要通过代码或者说其他的材料来进行深入理解。

因为虽然本质上就是一个字符串匹配的问题，但是对于处理流量的过程中，到底是什么匹配还是需要考究，比如说， 仅仅是为了单包检测，那么直接在IP层的数据包每个都进行匹配即可，如果是为了能够更好的减少资源效果，那么可以在TCP的流层面进行检测，例如我知道SNI必然出现在ssl握手的clienthello中，这些属于如何检测的过程。

另外，就是如果进行匹配，匹配过程中，规则引擎如何配置，也是一个问题。

往更深层次来说，例如IDS层面，在完成响应的匹配之后，还需要进行相关的处置手段，例如封堵，丢包等。

甚至于，为了能够更好的进行管理，还需要设计一定的规则管理库，甚至要有前端的功能，这部分就应该属于比较靠后的考虑内容了。

所以，如果是能够在开源的产品中，直接进行移植，而且能够满足实际的需求，那就是最好的。或者说，对于流量处理的部分我自己来处理，而实际进行匹配的部分，直接采用他们的代码，能够更好的实现匹配效率以及管理手段。

5.2 DPI的使用

前面也提到，在我的认知中，DPI已经属于了一种非常常用的功能，这种手段通过简单的规则就能识别出比较常见的协议。实际上，我个人认为，对于DPI中关键的部分，可能匹配手段已经不是最关键的问题了，而是说规则库方面，如何自动化进行规则库的挖掘，比如拥有了大量的某应用包，怎么提取出响应的字符串或者说指纹，这个问题很关键，当然如果不考虑效率的话，一般来说也有很多算法，频繁项挖掘这种，只需要将自己的数据进行响应的预处理，满足算法需求即可。
同时以及底层的应用角度，现在越来越多的厂商在强调云安全，之前的时候我也关注过，例如在云中的东西向流量，但是其实，这里比较关键的问题，就是他们是如何比较高效的捕获流量，这通常也跟底层的虚拟化设备相关，例如采用了OVS这种。这一块的内容就有点脱离了DPI的范畴了。

那么前面提到了两个问题，在实际应用中：
1）规则库的自动化提取
2）底层包捕获引擎。