云可见性和端口欺骗：已知的未知因素

与所有技术一样，新工具都是在以前的基础上进行迭代，经典的网络日志记录和指标也不例外。

在私有云和内部部署中，网络流量的工具、仪器和监控几乎没有变化。现在使用的许多日志和指标都有近20年的历史，最初是为了解决账单等问题而设计的。

对交通流模式的可见性是一个额外的好处。流量日志恰好是经久不衰的用例。然而，这种对既定方法的依赖在网络和端口欺骗中留下了一些漏洞。

但是什么是端口欺骗，为什么它很重要?

就像网络上的应用程序和数据可见性一样，现在使用的许多规则和rfc都是在十多年前编写的，描述了一些东西“应该”如何工作，尽管没有真正的规则强制执行。

这为很少使用的部署提供了很大的灵活性。当应用程序或服务配置错误或恶意参与者想要逃避检测时，即使对标准端口进行最轻微的更改也会妨碍大多数当前的可见性和检测方案。

端口欺骗是一种已知的技术，MITRE ATT&CK有一个专门针对这种规避的完整类别。

在非标准端口上使用安全外壳(SSH)协议是规避可见性的最常见和最通用的示例之一。SSH通常分配给端口22。

安全工具假定SSH流量将使用端口22，并且世界上几乎每个安全团队都严格锁定该端口。常见的做法是在外围阻止此端口，并将其称为安全。很容易，对吧?

还没那么快。如果恶意参与者更改了其SSH流量上的默认端口，该怎么办?端口443广泛用于HTTPS/TLS，并且几乎总是处于打开状态。

HTTPS流量在现代企业中无处不在，无论是关键业务活动还是个人活动。IT防火墙不会例行公事地阻止端口443/HTTPS，因此使其成为攻击者的理想入口点。

将SSH更改为在443上运行很简单。有许多论坛提供了关于这样做的合法和不合法原因的详细说明。几乎所有的现代云可见性工具都会如实报告流量，而不是实际情况。

即使是云中的工作负载也可能错误识别自己的连接。活动的SSH会话可能会被错误报告为TLS，因为linux操作系统仅根据端口采用连接类型。

网络会出错，而操作系统工具也会出错，因为它们会将此流量报告为已知流量。

如今，几乎所有流量都由其TCP和UDP端口进行评估。这导致了对流量性质的许多假设。在公共云、私有云和本地云中都是如此。

在当今越来越注重安全的世界里，对交通性质做出假设已经不像以前那么安全了。SSH是一种非常强大的工具，威胁参与者可以使用它在任何网络上进行文件传输、隧道传输和横向移动。

这只是一个工具可以有多种用途的一个例子。考虑到其他应用和协议，意识到有多少东西是不可见的变得令人望而生畏。Mitre有自己的端口欺骗类别，而且这种趋势只会越来越大。

东西交通也需要深入的可观察性。下一代防火墙(NGFW)在周边点内部解决了这一问题。然而，公共云则是另一回事，这个问题尚未在东西方或横向规模上得到解决。

VPC流日志仅记录与端口号一起发生的对话，并不真正了解正在使用的应用程序或协议。具有深度数据包检测的深度可观察性可调查会话，并可以正确识别正在使用的应用程序和协议。

我的公司称之为应用程序智能，它目前在网络流量检查中识别了5000多个应用程序、协议和属性。

应用程序元数据智能不仅查看外部报头，还更深入地查看数据包。我们深入研究定义给定应用程序的数据包的独特特征。这被称为深度可观测性。

如果攻击者通过SSH从同一子网中的工作负载A连接到工作负载B，我的公司的深度可观察性管道会使用应用程序智能来查看流量的真实情况，并将其报告给安全工具。

在这种情况下，我们可以提醒技术人员端口443上有伪装成Web流量的SSH流量。这种可观察性的深度可以轻松地横跨整个企业，包括公共云和集装箱到集装箱通信。

在公有云中，深度包检测面临着一系列独特的挑战。没有广播，要检查流量，要么需要安全VPC来引导流量通过，要么需要流量镜像。

第二个也是不太复杂的选项是将流量镜像到适当的工具。Gigamon解决了第二个问题。好处包括减少部署复杂性和操作摩擦，而不会像在线检测路径那样影响性能。

已知的情况是，开发人员将继续快速运行，DevOps将无意中部署未知或错误配置的应用程序，威胁参与者将不断寻求利用这些漏洞来创建盲区。

SecOps将尝试验证规则和保护，这只有通过网络衍生的智能和洞察力的深度可观察性才能真正实现。

如果一个组织无法在非标准端口上检测到SSH的简单用例，那么其混合云基础设施中还可能潜藏着什么其他已知的未知因素呢?