Kubernetes 是什么，Kubernetes 是一个全新的基于容器技术的分布式架构解决方案，是 Google 开源的一个容器集群管理系统，Kubernetes 简称 K8S。用于自动部署、扩展和管理容器化（containerized）应用程序。在本文中，我们将介绍为何 Kubernetes 的 DFIR 如此重要，以及如何评估你的容器 DFIR 功能。我们还将看到一个完整的场景，深入挖掘影响 Kubernetes pod 的事件，以及要采取的对应步骤。

什么是 DFIR

数字取证和事件响应 (DFIR) 是网络安全领域，包括在事件发生时采用的技术，重点是识别、检查和响应网络攻击。

事件响应计划

发生安全事件时，每家公司都应应用其事件响应计划 (IRP) 中概述的技术。这是一个记录在案的过程，它建立了在发生违规时要采用的指导方针。尽管每个公司的 IRP 可能不同，但可以概括为以下四个主要步骤：

识别：对攻击及其相关风险的快速深入调查可以在整个过程中发挥关键作用。此步骤通常涉及与受影响环境相关的所有安全事件、日志和报告。

协调：一旦检测到可能的事件，响应团队必须评估该事件是否代表真正的安全事件。因此，它还必须决定是否响应它。

解决方案：该过程的这一步用于调查事件本身的原因，限制其影响，并在必要时将其隔离。在此步骤中，团队应解决安全风险并实施补救措施。最终，它可以从备份中恢复受影响的系统、数据和服务，甚至修复受影响的环境。

工具推荐

工具可以在识别、调查和响应网络攻击方面发挥关键作用。

前面描述的所有阶段都应该始终得到有效工具的支持，这些工具可以促进攻击的调查和响应。通过执行它们，你可以深入了解你控制的所有内容。你可以将证据自动存储在你的私人远程存储中。此外，你可以监控你当前拥有的资源，以检测意外的工作负载峰值，在发生事件或可疑网络流量时接收警报，并及时做出响应。

以下是本文将使用的工具或在 DFIR Kubernetes 期间可能用得着的工具：

SIEM（例如 ElasticSearch）：收集和存储在你要监控的环境中生成的日志和警报的应用程序，它在识别阶段非常有用。

Falco：一种开源威胁检测引擎，可根据一组规则在运行时触发警报。 Falco 触发的警报可以发送到 SIEM 以收集运行时事件的证据。

Falcosidekick：一个开源工具，它接收 Falco 的事件并以扇出方式将它们转发到不同的输出。

Prometheus：使用领先的开源监控解决方案为你的指标和警报提供支持。

Docker Explorer：一个能够对快照卷进行离线取证分析的开源项目。

kube-forensics：一个开源项目，允许 Kubernetes 集群管理员将任何受影响的 pod 的工件存储到 AWS 存储桶中。

Cloud Forensics Utils：一个开源项目，可以通过一组工具加快和简化取证过程。

kubesploit：一个开源渗透测试框架，可以改善你扫描集群的网络安全状况。

因此，拥有工具并规划正确的策略可以让你跟踪和收集环境的证据，从而使管理和调查更容易。

Kubernetes 的分步取证程序

现在，我们将模拟在 Kubernetes 集群中发生网络安全事件时如何评估 DFIR。

在这个场景中，我们将看到如何检测可能的事件、如何监控事件及其相关资源。最后，我们还将看到如何采取措施减少其影响。

识别过程

我们用自己管理的Kubernetes集群，通过Kubernetes负载均衡器服务将我们的应用程序、网站和web服务器部署到网络中。

如上述步骤所示，我们使用 Falco 在运行时检测事件。 Falco 是事实上的 Kubernetes 威胁检测引擎。它作为守护进程部署在我们集群的每个节点上，并配置了Falcosidekick，以便向本场景中采用的SIEM (Elasticsearch和Prometheus)发送警报。

为了使用 Falco 监控整个集群，我们设置了自定义检测规则，当远程命令执行攻击在我们的pod中发生时，这些规则就会触发。

其中一条Falco 规则如下所示：

就在几分钟前，触发了其中一个规则，生成了一些警报，现在我们可以在Falcosidekick UI中检查所有事件信息。

似乎我们的一个Tomcat pod允许一个奇怪的下载，这可能是值得研究的有趣的事情。

一旦发现可疑情况，就可能需要深入评估事件的风险。你所拥有的工具可以给你很多建议，比如可以检测到正在运行的可疑命令、敏感文件系统路径中的更改文件以及意外的网络流量。此外，高 CPU 使用率和内存使用率可能表明存在恶意执行，并且可以使用 Prometheus 等工具快速监控。

在这种特定情况下，已检测到它具有很高的资源消耗（特别是受影响的 Pod 使用了超过 2 GB 的内存）！

协调以减少风险暴露时间——Kubernetes 网络政策

首先，我们需要减少影响。让我们开始通过 Kubernetes 网络策略隔离受影响的 Pod。这样，你将有机会控制入站和出站流量。

首先，删除将受影响的 Pod 与部署绑定的当前标签。通过这样做，我们会自动删除传入的流量。接下来，我们必须标记受影响的 Pod：

这个新标签将我们即将创建的网络策略的范围限制为仅标记的 Pod，而不是整个名称空间。

然后，根据文档，明确拒绝策略的能力无法通过网络策略完成。为了实现我们的目标，隔离 Pod，我们修改了最严格的策略（deny-all）并将 podSelector 修改为仅适用于受影响的 pod。如果有其他 NetPol 影响所有 pod，则行为可能与预期不同。

这将阻止任何进出受影响 pod 的入站或出站连接。

这是另一个示例，表明我们无法从带有蓝色标签的 Pod 中获取信息，并且绿色标签的 pod 不受影响。

对工作节点进行标签和封锁

为了隔离攻击并使调查更容易，我们可以标记部署 pod 的工作节点。这样就可以简化该节点的区分。

另一个最佳实践是“封锁”工作节点。它确保 Kubernetes 调度程序将该节点视为不可调度，并阻止在其上部署新的 Pod。因此，如果资源允许，新的 Pod 将被调度到其他地方，而受影响节点上已经运行的 Pod 将被保留。这不会改变受影响的Pod，也不会改变要在其中进行的调查过程。

这对于隔离节点并调查由于容器逃逸而导致的危害非常有用。顺便说一句，在本文中，我们仅仅假设攻击将仍然局限于受影响的 pod。

我们已经执行了一些必要的步骤来隔离受影响 Pod 中的恶意执行。使用 Kubernetes 网络策略，我们已经确定不允许来自受影响的 pod 的传入或传出连接。此外，我们标记了涉及的 Pod，并阻止在 Pod 运行的节点中进行新的部署。有时，你还可以删除或撤销受影响的工作节点/Pod 权限或安全凭证，以避免攻击传播到其他云资源。

但是，我们仍然需要了解攻击是如何发生的，我们承担的风险是什么，以及它可能产生的影响。

DFIR Kubernetes方法——快速方法

它可以被认为是最快的方法。将正在运行的容器隔离并仍在 Kubernetes 集群中运行，你可以直接从其工作节点检查它。

现在，让我们跳转到该节点并开始搜索受影响的容器 ID。

现在我们知道了哪个是容器ID，这样就可以开始深入挖掘它的细节。

似乎在 Elasticsearch 收到日志前几秒钟，在 Tomcat 上部署了一个新的 war 文件。这可能是攻击的初始访问，但让我们继续检查容器文件系统自创建以来的更改。

更改：C 行是更改后的目录。

追加：A 行是新添加的文件。

如前所述，似乎在 Tomcat 管理器中添加的文件很少。而且，文件系统中还写入了其他文件，例如 zzz（已经在上面的 Elasticsearch 日志中显示）。

为了查看机器中还有什么在运行，我们还可以启动docker top和stats命令。

高 CPU 使用率，确认之前检测到的内容。

我们还可以将容器的更改提交到新映像（通过 docker commit）或将受影响的文件系统导出为 tar 文件（通过 docker export），以便存储发生更改的工件。如果你想了解有关此技术的更多信息，请查看对恶意 Docker 容器进行分类。

DFIR Kubernetes——离线方法

Docker-explorer 是一个开源项目，能够对快照卷进行离线取证分析。

一旦我们确定了受影响的 Pod 所在的 Kubernetes 工作节点，最好的做法是对其文件系统进行快照。这可以通过云提供商控制台或通过采用其他一些开源项目来完成，例如 cloud-forensics-utils。有了快照卷，就可以进行事后分析，将其附加并安装到将使用 docker-explorer 的新虚拟机上。

Docker-explorer 可以列出所有 docker 容器或仅列出已安装卷中正在运行的容器。

一旦我们获得了我们想要调查的容器 ID，就可以提取日志，就像我们之前使用 docker logs

但最重要的功能是使用 docker-explorer 将容器文件系统挂载到 VM 中。

这将使我们能够访问受影响的容器文件系统。因此，从现在开始，我们将能够调查之前监控的进程和文件（zzz、kdevtmpfsi、kinsing）。

例如，我们可以读取 zzz bash 脚本，或者我们可以提取 ELF 文件的哈希值，以便通过 VirusTotal 对其进行扫描。

正如预期的那样，由于使用了大量的 CPU，kdevtmpfsi 进程是一个挖矿程序。

Kube-forensics

kube-forensics 是一个开源项目，允许集群管理员将任何受影响的 pod 的工件存储到 S3 存储桶中。它要求 kube-forensics 创建的工作 pod 具有将对象写入 AWS 存储桶的必要权限。

这样我们就可以将受影响的 Pod 证据存储到应用此 PodCheckpoint 的 S3 存储中：

几分钟后，PodCheckpoint 将完成其执行，证据也会出现在目标 S3 存储桶中。

因此，除了保存 pod 描述之外，kube-forensics 还以与我们之前在实时主机部分中所做的类似方式存储与 docker inspect 和 docker diff 命令相关的结果。

对于“...export.tar”文件，它是可以通过 docker export 命令获得的文件，它可以将容器文件系统存储在可以检查发布的“.tar”文件中。

Kubernetes事件的解决和总结

通过分析和调查违规行为，你可以识别你在集群中部署的易受攻击的资产。

在此示例中，攻击入口点由暴露在网络中的易受攻击的 Tomcat Pod 表示。取证分析得出的结论是 Tomcat 管理器不安全，因为它配置错误并且没有影响其他 Pod 或命名空间。

不过，有时受感染的 Pod 可能会由于众所周知或未知的漏洞而被利用。

作为事件响应阶段的一部分，你应该从受感染的 Pod 中学习，用更新和安全的 Pod 替换它们。但是，如果无法保护你的工作负载，可能是因为它们还没有可用的补丁，你应该采用其他解决方案。

例如，第一个是在发布新补丁之前删除和删除你的部署，只要你有足够的关于发生的事情的信息。这是防止发生任何违规的最严格的方法，但它也会在可用性方面影响你的业务。

在其他一些情况下，你可能希望使用 Falco 和 Falcosidekick 来设置你的 Kubernetes 响应引擎。当通过 Falco 触发特定事件时，它允许你在 Kubernetes 集群中做出响应。例如，在前面的场景中，如果将具有通用文件名的新 .war 文件部署到 Tomcat 管理器中或检测到 RCE，我们可以采用终止 pod 的规则。