深度包检测(DPI)技术及其相关产品的评估，乍看之下似乎不难，然而，出于某些原因，还真就难以得出准确结论。

难点有多个方面。大多数公司不肯交出描述其DPI实现的代码库。于是，想要真正对比，就得进行黑箱测试，包括对每个设备来一场模糊测试。同时，不同协议有不同的复杂度和特性，各厂商可能有自己特定的函数或实现，未必会严格遵守协议规范，这些都是在部署DPI实现的时候应该纳入考虑的内容。

产品对比中应考虑的因素远不止上述这些。或许可以经由某种方法，或者至少构建一个框架，将定性的想法转化为定量的比较体系。

首先，要搞懂控制平面和数据平面的概念。数据平面包括人机接口(HMI)读写指令，可从可编程逻辑控制器(PLC)读取压力或温度数据，或者在时钟间隔里向特定寄存器写入数据。这就是PLC上跑的实际过程数据或梯形逻辑。同时，控制平面是能够更新固件或完全停止控制器的全部操作。其指令包括了运行PLC的底层操作系统。这有点类似在 Windows PC 上执行Windows更新。由于很多PLC都利用与数据读取相同的网络流来更新固件版本，了解这一点是十分重要的。

基本上，控制平面和数据平面流量穿过的是同一个TCP连接，这也是为什么我们需要DPI的原因所在。因为用户肯定想要从HMI收取数据，但又不想冒着自家PLC遭非授权攻击者固件更新的风险。缺了DPI防火墙，你便无法区分数据平面和控制平面消息。

实现DPI防火墙的方法很多，包括完整协议实现、基于特征码的方法、基于代理的方法、或者机器学习。各有优劣。

工业控制系统(ICS)领域里，基于特征码的方法是很糟糕的机制。基于特征码的方法仅仅是反应式机制。特征码基于已发现的漏洞，意味着攻击方法早已出现，且有可能影响正在运行的系统。特征码只能提供浅薄的检查，还要求特征码数据库不断更新。(车间里有互联网接入？想都别想。)一个特征码通常专属一个特定漏洞。攻击方法只要修改了一个字节，就得新弄个特征码出来缓解。

另外，该方法实际上就是建立了一张黑名单，而不是白名单。黑名单方法很糟糕。可以将之想象成构筑了一道1.8米高的墙，然后攻击者架个2米的梯子就翻进来了。然后你把墙加高到2.3米，但是攻击者又造了个2.5米的梯子，再次翻墙进来。画面太美，不忍直视。这种被动防御的方法显然是不符合时代发展需要的。主动方法更为有效。

实现的深度比广度更重要。防火墙厂商可能宣称支持500种协议，但支持到何种程度呢？验证某个协议里的每一个字节并不意味着就支持该协议的DPI。

产品对比的评分方案是个不错的选择。我们怎么对比产品？DPI实现中最重要的因素是什么？80-90%的 ICS-CERT 漏洞都落入同一分类：恶意软件/数据包模糊/缓冲区溢出/实现糟糕。

这些都归结为一个问题：特定协议的包结构符合协议规范吗？如果不符合，丢弃该数据包。

于是，结构良好的DPI实现应该包含哪些元素，是该好好列一列了。

1. 完整性检查

DPI引擎理解协议完整性和数据包结构排列的能力。如果是 Ethernet/IP CIP 消息带了个长度域，描述对“模拟输入对象”和“获取所有属性”的操作，这意味着什么？允许的长度？还是说每个域的字节数？DPI实现必须知道内部和外部的协议，尤其是旨在捕获那80-90%的 ICS-CERT 漏洞的时候。

2. 行为过滤

允许/拒绝特定功能代码的能力，EtherNet/IP上的CIP服务，分布式网络协议3(DNP3)中的DNP3对象等等。这是区分控制平面和数据平面操作的能力，让用户可以持续监测温度或压力仪表，同时确保固件更新操作不能进行。

3. 状态检查

调查响应是否有对应的请求。如果响应不是跟在初始请求之后回来的，那就是伪造的响应数据包，应丢弃。

4. 响应验证

仔细看DNP3，你会发现，大多数已公布漏洞实际上攻击的是HMI，而不是PLC或RTU(远程终端单元)。这指示了响应消息应验证的深度。

5. 厂商特定支持

另一种说法是厂商特定验证。比如施奈尔的 Modbus FC 90 或者罗克韦尔的PCCC/CSPv4。如果DPI引擎理解你所用的厂商特定元素，那这就是一个重要的指标。

6. 管道支持

TCP/UDP消息包含多种ICS协议消息的地方。可以想象一下一帧数据里放进4条Modbus消息。DPI实现必须能处理这个，要能遍历每条消息，确保没有嵌入任何写指令或固件更新。

上述六条的类型评分方案如下图：

完整性检查得分为4的依据是什么？有什么意义？这就是更难以解释的部分了。如今，我们对要评估的方面有了共识，也有了分级评分机制。

基于该协议，”4″分意味着不是每一个域都被验证了。比如说，Modbus FC15 (写多个线圈)不验证输出的数量；或许就不验证所有回复的数量。

Modbus FC15结构

而”6″分，就意味着DPI引擎验证每一个域，确保数据包完全符合协议规范。

若缺乏产品细节，深度是个很难衡量的东西。公司愿意列出他们验证协议的深度吗？评分方案里的数字是很主观的，每个DPI特性都可以再细分，得出更精准的视图。

毫无疑问，DPI方法和基于特征码的系统也可以与完全协议遵从或代理设置进行比较。另外，每个协议的DPI引擎深度可能各不相同，所以，按协议比较而不是各产品间进行比较，也是有意义的。通过检查多个产品，产品间的关系也会改变，比如“产品X做这个比产品Y好“——这一点才是更有价值的。

最后，需要考虑的其他因素也还有。什么都支持，但用户界面晦涩难懂的DPI引擎，对客户而言也不是那么有用。

DPI引擎识别出无效帧时，有哪些操作是重要的呢？

• 丢弃该帧？
• 发送TCP重置？
• 产生事件消息？

这里没提到吞吐量和延时，因为这不是关于产品速度而是关于功能的。然而，像GOOSE这种要求低延时的协议，这些至少应该考虑到。基本上，要记住，不是所有DPI实现都是一样的。