如果流是在接收到第一个流数据包时创建的,那么我们可以将流客户端视为真正的网络客户端。例如,从主机1.2.3.4上的客户端到主机5.6.7.8的SSH,这种通信的流程将是1.2.3.4:X<->5.6.7.8:22(我们假设SSH在端口22上运行)。看起来是对的吧?但有时你会看到,在流缓存中,这样的流被报告为5.6.7.8:22<->1.2.3.4:X。为什么?这可能是由于各种原因造成的:
- 应用程序(例如ntopng)在流开始后启动,ntopng观察到的第一个数据包是5.6.7.8:22->1.2.3.4:X,而不是1.2.3.4:X->5.6.7.8:22。
- 流使用正确的密钥存储在缓存中,但有一段时间(例如2分钟)没有交换数据包,因此应用程序已将流声明为过期,并将其从流缓存中删除。然后,如果突然观察到一个新的数据包,则该数据包可能会被发送到错误的方向(例如5.6.7.8:22->1.2.3.4:X),因为这可能是服务器的保存数据包。在这种情况下,流以相反的方向(9,因此是错误的)放置在高速缓存中。
可以配置ntopng(通过首选项)和nProbe(使用带有-t和-d的命令行)流超时,因此这些问题得到了缓解(尽管没有完全解决)。然而,仅仅调整超时是不够的,特别是对于UDP流,因为与TCP相反,没有TCP标志可以用来猜测真实的流方向。因此,ntopng实现了一些启发式来交换流向,但这种启发式不能太激进,因为我们可能会报告无效信息。
我们希望这篇文章能让大家明白基于流量的网络流量分析是如何工作的,以及为什么有时会观察到一些“意外”行为,不是因为漏洞,而是因为这些测量的性质。