当前DPI（Deep Packet Inspect深度报文识别）技术是安全领域的关键技术点之一，围绕DPI技术衍生出的安全产品类型也非常的多样。在分析DPI的进一步技术实现之前，分析DPI对用户的价值可以看到主要体现在两个方面：
- 从攻击防御的角度看，Web类的安全风险正在成为目前安全风险的主流攻击形式，针对Web类应用层安全攻击的防护，依靠传统的防火墙是无法实现的，具备深度报文检测能力的IPS设备或者WAF设备开始为大家所熟知；
- 从业务应用识别分析的角度看，单纯的分析报文的头字段内容无法识别该报文所承载的具体的业务类型，要想深度了解报文所承载的业务应用类型及流量大小等信息，必须要跟踪业务应用的协议交互过程，并对报文的负载payload进行深度的识别。如果用户希望网络安全设备具备针对应用层的风险防护能力且能够对互联网出口的流量应用进行精细化的管理控制，DPI技术的能很好的满足客户的需求。
和传统的防火墙域间策略的匹配查询不同，DPI技术旨在借助字符串特征的逐包匹配来完成入侵检测和流量控制的目的，在这个过程中，深度报文检测的引擎设计和丰富的规则特征库定义是核心设计环节。从检测引擎设计的角度看，除了要有良好的设计框架之外，在收到需要检测的报文后，涉及到报文的正规化处理、检测引擎的协议解析、引擎对报文关键特征提取和高效算法查询等内容；从特征库的角度，涉及到对检测规则的定义、特征库的提取和升级更新等内容，接下来我们将针对其中的关键技术点进行说明。
1、DPI技术实现的基本框架(Deep Inspect Management)
从控制管理层面上看，DPI的各个业务模块的需求都可以抽象化成“规则”，基于这些规则定义可以生成不同的“分类”对象；规则同时具有“使能状态、报文动作”等属性，内部还设置有特征、选项等关键字部件。DIM的框架设计将业务模块的公共业务需求进行抽象并处理。控制管理层面的工作在用户态完成，主要工作包括：
- 统一开放格式的规则管理；
- 统一开放格式的特征库加载和文件解析；
- 配置变更和下发流程管理，包括引擎的编译和下发、规则的下发，以及它们的板间同步（如图1所示）。
从数据转发层面上看，DPI的各个业务需求都需要对应用层协议进行解析、解码和搜索。为了保证高效转发和单次报文处理，有别于传统防火墙的设计思路，在新一代安全产品的实现过程中必须有并行的检测引擎，尽可能保证只对报文进行一次处理。数据转发层面的需求主要在内核态进行处理，涉及到的几个功能模块如下：
- 协议解析器；
- 搜索算法引擎；
- 检测结果处理模块，或者说报文动作处理模块；一般是在I/O 接口的处理流程中（如图1所示）。
图1 DPI软件设计架构示意图（注：DIM, Deep Inspect Management）
这种将控制管理层和数据转发层相互独立的设计模型，使得CPU密集型的引擎预处理（编译和下发）和高性能的搜索算法过程分离在用户态和内核态，也可以使得我们的预处理和匹配在不同的单板甚至不同的设备上进行，易于保证转发流程的检测持续性和稳定性，匹配也易于由软件查表扩展成硬件处理器来完成。
2、DPI控制管理层面的规则定义
3、DPI检测引擎设计及典型算法模型
有别于传统的DFA(Deterministic Finite Automaton)和NFA(Non-Deterministic Finite Automaton)算法，H3C 的DPI软件引擎具有内存可伸缩特性。DIM用户态可动态感知需要加载软件引擎的单板或者子设备(的内核态)是否有充裕的内存，根据内存剩余情况和用户的配置选择最优的引擎存储方式，然后启动编译线程完成编译下发工作。海量特征的编译下发是一个CPU密集型过程，考虑到可能遇到的配置频繁变更或者特征库升级调度，DIM的编译线程设置了可中断可重入机制，不需要用户等待。
图 3 DPI 检测引擎在报文转发中的流程示意图
DPI内核态的检测引擎可能出现在入接口业务点、域间策略业务点或者出接口业务点，任何涉及DPI业务的配置启用都会开启转发流程中的DPI业务点，如果用户有多种相关配置，DPI会在报文转发流程中最早的业务点生效，其余点则不生效。在DPI的入接口处理时，数据转发层面的处理流程如协议解析、算法引擎和检测结果处理是其工作重点【图3】。
在具体的DPI检测引擎设计时，其在内核态的位置如图4所示。可以看出，DPI检测引擎包含了多种检测算法，典型的如Aho-Crassick , Boyer ,Moore算法以及PCRE算法等等，通过这些算法的配合可以有效实现关键特征的快速查找匹配，提升了查找效率。
图 4 DPI 检测引擎在内核态的部件示意图
4、DPI检测引擎的协议解析器设计模型
检测引擎自身包括三个部件：协议解析器、算法引擎和检测结果处理，下面主要对其关键部分的协议解析器进行说明。现阶段额度协议解析器的职责主要有：
1）协议确认： 进入HTTP、HTTPS等协议解析器的条件都是固定端口映射。但越来越多的互联网应用正试图通过80、443等传统端口来逃逸传统网络设备的检测和控制。因此必要的协议确认是防止这种逃逸的前提。
2）协议切分： 协议切分是在流（会话）的基础上进一步细分出“检测流”或者叫“事物”的概念。例如：HTTP的一次transaction、FTP的一次用户登录行为、SMTP/POP3的一次邮件发送/接收等，都抽象成一条“检测流”。有时一条流可以传输多次检测流，甚至同时有并发的检测流出现。协议切分对于关心检测流的业务模块有着重要意义，例如内容过滤和应用审计。
3）协议域切分：协议域切分是在最小的粒度上细分报文。将检测流分成Header和Body部分，Header还要细分成各个Field，包含Field Value和Field Data部分。协议域切分有助于判别该头域是否需要检测，判定该头域命中的特征与之定义是否吻合，以及识别提取审计日志信息的关键位置。
图 5 HTTP请求报文的协议域切分示意图
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断开连接、生成攻击日志告警等。
5、特征库的设计模型
在进行DPI特征库的设计时，一般都是采用统一的文件头结构和开放式TLV架构，易于软件统一处理和后续业务扩展。同时考虑到不同产品对存储空间、转发性能、并发规格的不同要求，为不同的产品（不限于NGFW）量身定制了不同的特征库。并且，为了能够快速完成升级，在服务器上放置了邻近旧版本的增量库（补丁包）。
图 6 DPI设备特征库升级流程示意图
结束语
DPI技术的应用和发展是一个动态不断完善的过程：一方面攻击类型在不断的发展变化，由此导致的攻击特征漏洞的提取也要与时俱进不断更新，另一方面随着攻击类型的增加，除了攻击特征漏洞匹配和应用层协议解析之外，未知的不能识别的攻击类型报文也会逐渐增加，目前已经出现的云端的未知攻击的检测识别技术可以为设备侧的DPI检测提供很好的补充，基于大数据的云端安全分析平台也会逐渐成为安全的核心竞争力，配合安全设备终端形成完整的DPI防护解决方案。
==============================================