nDPI -- 开源深度包检测库

1. 背景

传统的流量分析仅限于数据包头部，通过传输协议和应用程序端口识别应用程序协议。许多应用程序协议在开发时会遵循某些标准端口的分配。例如，SMTP使用TCP协议和端口25，Telnet使用TCP协议和端口23。这些协议和端口的关联在Unix系统下的/etc/protocols文件中明确指定。

在RPC出现之前，许多网络服务使用静态端口分配，即每个服务都有一个固定的端口号。随着服务数量的增加，固定的端口号可能会被耗尽。且静态端口分配缺乏灵活性，难以适应动态变化的网络环境。为了解决这些问题，开发了动态端口映射机制（rpcbind 和 portmap ），允许RPC等应用程序在运行时请求端口号，而不是在编译时固定。1024以下的端口号用于标识关键的系统服务，如电子邮件或远程系统登录。1024以上的端口用于用户定义的服务，通常是动态分配的。

然而，仅依靠端口来识别应用程序协议存在局限性。应用程序可以被配置为使用非标准端口，不同的应用程序也可能使用相同的端口进行通信。HTTP作为迄今为止使用最广泛的协议，尽管最初被设计用于Web浏览，但用户使用HTTP并不仅仅是为了浏览网页。实际上，HTTP已经被用于多种不同的服务和应用程序，包括社交网络、地理地图服务和视频流媒体服务等。换句话说，TCP/80 = web的言论不在有效，HTTP协议的使用已经远远超出了传统的Web浏览范畴。此外，HTTP及HTTPS得到了防火墙的广泛支持，这使得HTTP成为开发新协议时的理想选择，特别是当这些协议需要穿越防火墙而不受限制时。许多点对点协议和应用程序（例如Skype）在需要穿越防火墙且端口被阻塞时，会使用HTTP作为最后的手段(采用隧道技术，将它们的数据封装在HTTP请求中，从而利用HTTP协议的普遍开放性来穿越防火墙)。 

第一代基于端口的分析工具已经不能满足需求，网络流量可见性的增加需求催生了深度流量检测技术（DPI）。一个DPI库需要具备以下特性：

1. 高可靠性：能够以高可靠性实时检测并区分不同应用程序的网络流量，并根据既定的协议策略来执行相应的控制措施。

2. 可扩展性：支持新协议，和对现有协议持续更新。

3. 开源许可证：能够在开源许可证下集成，供现有的开源应用程序使用，并嵌入到操作系统的内核中。

4. 网络指标和元数据提取：提取基本的网络指标（例如网络和应用程序延迟）和元数据（例如DNS查询/响应），并将这些信息提供给监控应用程序使用。

2. 从OpenDPI到nDPI

OpenDPI库是用C语言编写的，其功能主要分为两个部分：

1. 核心库：处理网络中的原始数据包，解码网络层（IP）和传输层（TCP或UDP），提取IP地址以及它们使用的端口号。

2. 插件解析器：识别和分析OpenDPI支持的约100种协议网络协议。

nDPI继承了这种两层架构，并解决了OpenDPI设计中存在的几个问题：

1. OpenDPI的内部数据结构是静态的，限制了可识别协议的数量。许多用于保持所有支持协议状态的数据类型和位图，被绑定到固定大小。

2. OpenDPI在检测到协议后尝试寻找更多匹配，导致不必要的性能损失。

3. OpenDPI不支持加密协议，而nDPI可以提取一些信息来暗示连接上的信息性质。

4. OpenDPI不是线程安全的，而nDPI进行了改进以支持多线程应用。

5. OpenDPI使用了许多全局变量，这在nDPI中得到了改进，实现线程安全且不需要信号量。

6. OpenDPI在设计上存在很多问题。例如，OpenDPI在每个流上都执行了重复的初始化操作，而不是在库的启动阶段就完成一次。使用OpenDPI库的应用程序每次将新连接传递给库进行应用检测时，都必须承担这种由于重复初始化造成的性能损失。

7. OpenDPI在分析新连接时，并没有根据协议解析器与连接特征匹配的可能性来优先选择使用哪个解析器。在层次化的协议分析中，解析器的选择应该基于它们与特定连接特征匹配的概率。例如，对于TCP端口80，最可能的协议是HTTP，因此HTTP分析器应该首先被尝试。OpenDPI按照它们在库中注册的顺序应用解析器。

8. OpenDPI缺乏运行时配置能力，而nDPI可能提供了更灵活的配置选项。

9. OpenDPI没有设计来提取分析流量的元数据，这要求监控应用程序进行额外的解码工作。

OpenDPI提供了一个良好的起点。为了提高性能，nDPI对原始库的许多组件进行了更改。识别的协议数量对DPI检测性能和协议识别都有影响。识别的协议数量越多，当特定流量模式未被识别时，需要在所有可能的协议解码器上进行测试，从而花费更多的检测时间。这意味着支持许多协议的DPI库在特定情况下可能比支持较少协议的库慢。对性能的另一个影响是元数据提取：提取的属性集越丰富，处理速度就越慢。

nDPI被设计用于需要检测通信流应用协议的应用程序，支持标准协议（例如HTTP和SMTP）和在互联网社区中流行但规范不公开的专有协议（例如Skype或Citrix）。当数据包通过nDPI库时，nDPI库会尝试使用不同的解析器来匹配和解码数据包，直到找到一个能够成功解码的解析器。对于专有协议，由于缺乏公开的规范，需要通过逆向工程推断协议的工作方式。

尽管nDPI可以从分析的流量中提取特定元数据（例如HTTP URL），但它并没有被设计为用于合法拦截或数据泄露预防等领域的库，其主要目标是表征网络流量。与OpenDPI类似，nDPI可以在Linux内核中和用户空间应用程序中使用。由于可移植性是开源应用程序的主要目标之一，nDPI已经被移植到包括Linux、Windows、MacOS X和BSD系列在内的大多数操作系统上。在CPU架构方面，它目前运行在x86（32位和64位）、MIPS和ARM处理器上。

3. nDPI设计与实现

在nDPI中，应用协议由唯一的数字协议Id和符号协议名称（例如Skype）定义。使用nDPI的应用程序可能会使用协议Id，而人类则使用相应的名称。在nDPI中，协议既包括SMTP或DNS等网络协议，也包括通过网络协议进行的通信。例如，在nDPI中，脸书和推特是两种协议，尽管从网络的角度来看，它们是两个流行社交网络使用的脸书/推特服务器之间的通信。协议通常由用C编写的流量分析器检测，但也可以根据协议/端口、IP地址（例如来自/去往特定网络的流量）和协议属性来定义。例如Dropbox流量由基于局域网通信的解析器和标记为Dropbox的HTTP流量标识，其中“主机”标头字段设置为“*.Dropbox.com”。nDPI库包括170多种协议的检测，但也可以在运行时使用配置文件进一步扩展。

nDPI库继承了一些OpenDPI设计，所有库代码用于实现通用功能，协议解析在插件中实现。所有库代码现在都是完全可重入的，这意味着基于nDPI的应用程序不需要使用锁或其他技术来序列化操作。所有库初始化在启动时只执行一次，当需要解析新数据包时，不会产生运行时惩罚。nDPI期望调用者提供按流划分的数据包（即具有相同VLAN、协议、IP/端口源/目的地的数据包集），并且数据包已被解码到第三层。这意味着调用者必须处理所有第二层封装，如VLAN和MPLS，将从IP层开始解码数据包的任务留给nDPI。nDPI附带了一个名为pcapReader.c1的简单测试应用程序，该应用程序展示了如何实现数据包分类，并提供了高效流处理的实用函数。协议解析器注册了默认协议和端口等属性。例如，HTTP解析器指定了默认的TCP/80，DNS解析器指定了端口53上的TCP/UDP。这种做法有两个优点：

• 属于未分类流的数据包（即尚未检测到应用程序协议的流）会被传递给所有注册的解析器，从最有可能的一个开始。例如，端口80上的TCP数据包首先会被传递给HTTP协议解析器，如果没有检测到，则会被传递给其余注册的解析器。当然，只有针对TCP协议的解析器会被考虑，而非TCP协议的解析器则不会。这种解决方案平均减少了需要测试的解析器数量，并减少了匹配时间，因为首先检查最有可能的情况。请注意，这种优化并不妨碍在非标准端口上检测HTTP，但它通过首先测试最有可能的情况来提高检测性能。

• 当流未被分类时（即nDPI已经尝试了所有分析器但没有匹配到），nDPI可以通过检查是否有协议为该流量使用的协议/端口进行了注册以此来猜测应用程序协议。请注意，流量未被分类，不仅是因为协议分析器的限制，还可能是因为并非所有流数据包都传递给了nDPI。一个典型的例子是，在流量开始后nDPI才开始工作，导致它错过了流量的初始部分，无法获取到足够的信息来正确分类流量。

流量的协议识别生命周期如下：

• nDPI解码数据包的第3层和第4层。

• 如果为数据包的协议/端口注册了解析器，则首先尝试使用该解析器。

• 如果没有匹配，将尝试所有注册到数据包协议的解析器（例如，如果是UDP数据包，则尝试所有UDP解析器，但不考虑非UDP解析器）。如果解析器无法匹配数据包，有两种情况：要么是因为分析的数据包永远不会匹配（例如，将DNS数据包传递给SNMP分析器），要么是匹配失败但未来的数据包可能会匹配。在前一种情况下，该分析器将不会被考虑用于同一流量的后续数据包；在后一种情况下，该分析器仍将被考虑用于同一流量的后续数据包。

• 一旦有分析器匹配，协议检测就会结束。

用户通常关心的是识别流量中的应用程序协议需要多少数据包，或者如何判断一个流量是未知的。协议识别所需的数据包数量取决于正在使用的协议。不同的协议有不同的特征和识别难度。对于大多数基于UDP的协议，如DNS、NetFlow或SNMP，一个数据包就足以做出这个决定。然而，还有一些基于UDP的协议，如BitTorrent，其签名可能需要多达8个数据包才能被检测到。根据经验，在nDPI中，每个方向最多8个数据包就足以识别协议或确定流量是未知的。

3.1 处理加密流量

出于安全和隐私方面的考虑，HTTPS正在慢慢取代HTTP。HTTPS不仅仅是用于安全交易，也用于发送推文和消息到移动终端、发布笔记和执行搜索。识别协议时简单地将流量识别为SSL（安全套接层）是不够的，需要更深入地对其进行特征描述和分析。在加密通信中，只有初始的密钥交换部分可以被解码。nDPI包含一个专门用于解码SSL流量的解码器，用于提取出所联系的服务器的主机名。提取的主机名信息被放置在nDPI流量的元数据中。在HTTP流量中，nDPI通过解码HTTP头字段中的‘Host:’来提取服务器主机名，而在SSL流量中，通过解码初始密钥交换来实现类似的功能。通过这种方法，我们可以：

• 识别已知服务，并根据服务器名称对其进行标记。例如，与名为“api.twitter.com”的服务器进行的加密通信标记为twitter，“maps.google.com”标记为谷歌地图，“*.whatsapp.net”标记为whatsapp消息协议。

• 发现自签名SSL证书。自签名证书表明可能存在安全风险或是隐藏着通信背后的某些活动。例如，如果一个长期的SSL连接使用自签名证书，并且流量是对称的，这可能表明存在一个SSL VPN，用户通过它连接到远程网络。

nDPI内置了对许多已知协议的配置。用户还可以在nDPI运行时添加额外的配置文件以识别更多的协议，而无需修改现有的协议解析器代码。随着内容分发网络（CDN）的出现，这可能是识别应用程序协议的唯一方法。CDN允许多个客户使用相同的IP地址来提供服务。这使得单凭IP地址或端口号识别特定应用程序协议变得更加困难，nDPI可能需要依赖其他信息（如证书、域名等）来识别应用程序协议。当nDPI无法通过高级方法识别协议时，它可以退回到使用IP地址来识别特定的应用程序协议。例如，nDPI能够识别到许多苹果提供的服务，如iTunes和iMessage。除此之外，它还会将所有通过苹果注册的IP地址（17.0.0.0/8）进行的通信，但未被更详细识别的流量，标记为苹果的通用协议。

3.2 扩展nDPI

正如前面所解释的，nDPI用户不仅可以通过添加新的协议分析器来定义协议，还可以在运行时提供配置文件。文件格式如下：

# Format: 
# <tcp|udp>:<port>,<tcp|udp>:<port>,.....@<proto> 
tcp:81,tcp:8181@HTTP 
udp:5061-5062@SIP 
tcp:860,udp:860,tcp:3260,udp:3260@iSCSI 
tcp:3000@ntop 
# Subprotocols 
# Format: 
# host:"<value>",host:"<value>",.....@<subproto> 
host:"googlesyndacation.com"@Google 
host:"venere.com"@Venere 
host:"kataweb.it",host:"repubblica.it"@Repubblica 

通过名称定义新协议。当nDPI检测到协议名称已经被定义时（例如，在上述示例中，SIP和HTTP由本机解析器处理），配置文件扩展了nDPI中已有的默认配置。例如，在前面的示例中，每当nDPI在端口81或8181上看到TCP流量时，它将其标记为HTTP。此外，nDPI还可以使用与从nDPI流中提取的元数据（HTTP Host和SSL证书服务器名称）匹配的字符串来识别协议。定义的字符串存储在基于Multifast2库的自动机上，该库根据Aho-Corasick算法实现字符串匹配。这个库非常高效：启动时自动机的创建时间很短（对于数十个字符串几乎是瞬间的，或者对于十万个字符串需要几秒钟）。当配置数十万个字符串时，该库的搜索性能超过10Gbps。

Multifast：http://multifast.sourceforge.net

原文链接：http://luca.ntop.org/nDPI.pdf