上个月早些时候，Ripple20变得很流行，因为它已经列出了许多物联网设备使用的定制IP堆栈中发现的一些漏洞。尽管Ripple20上大肆宣传，但本质上，用于识别易受攻击设备的工具会发送格式错误或有效的数据包(有些值在允许的范围内，但值已弃用或过时)，这些数据包很容易捕获(有关检测，请参阅Suricata和Zeek规则)。本质上，IDS规则/脚本是在检查线上发送的数据包是否有效，或者是否包含Ripple20使用的意外值。请注意，这些规则通常不检查数据包（例如检查TLS报头是否有效，或者ICMP数据包是否包含未被废弃的有效类型/代码），但它们仅用于发现Pipple2.0，所以如果未来的Ripple21会使用相同的方法，但却使用不同的值，我们就会回到原点，需要定义新的一套或规则/脚本。这就是基于签名的系统的工作方式，正如你所看到的那样，它们很容易规避在网络流量上做一些小小的改变，更不用说不断添加新的规则/脚本会让这些系统变得很慢。
为了有一个更通用的解决方案来解决这个问题，我们决定在nDPI（以及所有使用它的应用程序中）中引入一个新的分析类型，我们将其命名为 “risk factor”，它可以分析流量并产生流量上发现的问题的位图。当然，这不是基于签名/脚本，以准备抓住Ripple21如果/何时会被披露。本质上nDPI在分析流量时，也会评估一些风险，并向使用它的应用报告，这是在应用协议之外。这个机制是可扩展的，我们也在不断的增加新的数值，使其更加普及。使用nDPI的应用可以使用risk factor来阻止或发出警报，这不需要实现复杂的检测方法，因为nDPI已经完成了一切。截至目前，nDPI能够检测以下问题。
- XSS（跨站点脚本）
- SQL注入
- 任意代码注入/执行
- Binary / .exe应用程序传输（例如在HTTP中）
- 非标准端口上的已知协议
- TLS自签名证书
- TLS过时版本
- TLS弱密码
- TLS证书已过期
- TLS证书不匹配
- HTTP可疑用户代理
- 已联系HTTP数字IP主机
- HTTP可疑网址
- HTTP可疑协议标头
- 不带HTTPS的TLS连接（例如，基于TLS的VPN）
- 可疑DGA域联络
- 数据包格式错误（此处检测到Ripple20）
如果您的基于nDPI的应用程序可以为上述风险进行评分，您就已经发现IDS检测到的大多数问题，这就不必再为不断更新规则/脚本而头疼了。例如在这个pcap中，一个恶意软件将一个二进制应用程序（.exe）转换为PNG文件，以逃避安全策略。
如上图所示，ntopng（使用nDPI，因此可以从此流量分析中受益，而无需执行任何操作，而只是解释nDPI报告的risk factor）就会报告此问题并触发警报。简单而有效不是吗？
