什么是Kubernetes？Kubernetes是一种全新的基于容器技术的分布式架构解决方案。是谷歌开源的容器集群管理系统。Kubernetes简称为K8S。用于自动部署、扩展和管理容器化应用程序。在本文中，我们将解释为什么Kubernetes的DFIR如此重要，以及如何评估容器的DFIR能力。我们还将看到一个完整的场景，深入挖掘影响Kubernetespod的事件，以及要采取的相应步骤。什么是DFIR数字取证和事件响应(DFIR)是网络安全领域，包括在发生事件时采用的技术，重点是识别、检查和响应网络攻击。事件响应计划每家公司都应在发生安全事件时应用其事件响应计划(IRP)中概述的技术。这是一个文件化的过程，它建立了在发生违规事件时要采用的指导方针。虽然每个公司的IRP可能不同，但可以概括为以下四个主要步骤：识别：对攻击及其相关风险进行快速深入的调查可以在整个过程中发挥关键作用。此步骤通常涉及与受影响环境相关的所有安全事件、日志和报告。协调：一旦检测到可能的事件，响应团队必须评估该事件是否代表真正的安全事件。因此，它还必须决定是否响应它。解决方案：流程的这一步用于调查事件本身的原因，限制其影响，并在必要时将其隔离。在此步骤中，团队应解决安全风险并实施补救措施。最终，它可以从备份中恢复受影响的系统、数据和服务，甚至修复受影响的环境。工具推荐工具可以在识别、调查和响应网络攻击方面发挥关键作用。前面描述的所有阶段都应始终得到有效工具的支持，以便于调查和响应攻击。通过执行它们，您可以深入了解您控制的一切。您可以自动将证据存储在您的私人远程存储中。此外，您可以监控当前拥有的资源，以检测意外的工作负载峰值，在发生事件或可疑网络流量时接收警报，并及时做出响应。以下是本文将用到或可能在DFIRKubernetes期间派上用场的工具：识别阶段。Falco：一种开源威胁检测引擎，可根据一组规则在运行时触发警报。Falco触发的警报可以发送到SIEM以收集运行时事件的证据。Falcosidekick：一种开源工具，它从Falco获取事件并以扇出方式将它们转发到不同的输出。Prometheus：使用领先的开源监控解决方案为您的指标和警报提供支持。DockerExplorer：一个开源项目，支持对快照卷进行离线取证分析。kube-forensics：一个开源项目，允许Kubernetes集群管理员将任何受影响的pod的工件存储到AWS存储桶中。CloudForensicsUtils：一个开源项目，使用一组工具加速和简化取证过程。kubesploit：一个开源渗透测试框架，可以改善扫描集群的网络安全状况。因此，拥有工具并规划正确的策略可以让您跟踪和收集环境证据，从而简化管理和调查。Kubernetes的分步取证程序现在，我们将模拟如何在Kubernetes集群中发生网络安全事件时评估DFIR。在这个场景中，我们将看到如何检测可能的事件，如何监控事件及其相关资源。最后，我们还将了解如何采取措施来减少其影响。识别过程我们使用我们自我管理的Kubernetes集群通过Kubernetes负载均衡器服务将我们的应用程序、网站和Web服务器部署到网络。如上步骤所示，我们使用Falco在运行时检测事件。Falco是事实上的Kubernetes威胁检测引擎。它作为守护进程部署在我们集群的每个节点上，Falcosidekick配置为向此场景中使用的SIEM（Elasticsearch和Prometheus）发送警报。为了使用Falco监控整个集群，我们设置了自定义检测规则，当我们的pod中发生远程命令执行攻击时触发。其中一条Falco规则是这样的：就在几分钟前，其中一条规则被触发，产生了一些警报，现在我们可以在FalcosidekickUI中查看所有事件信息。似乎我们的一个Tomcatpod允许奇怪的下载，这可能是一件值得研究的有趣事情。一旦发现可疑情况，可能需要对事件进行深入的风险评估。您拥有的工具可以告诉您很多有关正在运行的可疑命令、敏感文件系统路径中的已更改文件以及意外网络流量的信息。此外，高CPU使用率和内存使用率可能表示恶意执行，可以使用Prometheus等工具快速监控。在这个特定的案例中，它被检测到具有高资源消耗（特别是，受影响的pod使用了超过2GB的内存）！减少暴露时间的协调-Kubernetes网络策略首先，我们需要减少影响。让我们首先通过Kubernetes网络策略隔离受影响的pod。这样，您将有机会控制入站和出站流量。首先，删除将受影响的Pod绑定到部署的当前标签。通过这样做，我们会自动丢弃传入流量。接下来，我们必须标记受影响的Pod：这个新标记将我们将要创建的网络策略的范围限制为仅标记的Pod，而不是整个命名空间。然后，根据文档，无法通过网络策略来明确拒绝策略的能力。为了实现我们隔离pod的目标，我们修改了最严格的策略（拒绝所有）和podSelector以仅应用于受影响的pod。如果有其他NetPols影响所有pod，行为可能不会像预期的那样。这将阻止与受影响的pod之间的任何入站或出站连接。这是另一个例子，我们无法从带有蓝色标签的pod中获取信息，而带有绿色标签的pod不受影响。标记和阻止工作节点为了隔离攻击并使调查更容易，我们可以标记部署pod的工作节点。这简化了该节点的区分。另一个最佳实践是“阻止”工作节点。它确保Kubernetes调度程序认为该节点不可调度，并防止在其上部署新的pod。因此，如果资源允许，新的pod将被安排在其他地方，而已经在受影响节点上运行的pod将被保留。这不会更改受影响的Pod，也不会更改要在其中执行的调查过程。这对于隔离节点和调查由于容器逃逸造成的危害很有用。顺便说一句，在本文中，我们只是假设攻击仍将仅限于受影响的pod。我们已采取必要措施隔离受影响Pod中的恶意执行。使用Kubernetes网络策略，我们已确定不允许来自受影响pod的传入或传出连接。此外，我们标记涉及的pod并防止在运行pod的节点中进行新部署。有时，您还可以删除或撤销受影响的工作节点/Pod权限或安全凭证，以防止攻击传播到其他云资源。然而，我们仍然需要了解攻击是如何发生的，我们冒了什么风险，以及它可能产生的影响。DFIRKubernetes方法-快速方法它可以被认为是最快的方法。正在运行的容器被隔离并仍在Kubernetes集群中运行，您可以直接从其工作节点检查它。现在，让我们跳转到该节点并开始搜索受影响的容器ID。现在我们知道哪个是容器ID，我们可以开始深入了解它的细节。似乎在Elasticsearch收到日志前几秒，Tomcat上部署了一个新的war文件。这可能是攻击的初始访问，但让我们继续检查容器文件系统自创建以来的变化。更改：C行是更改后的目录。Append：A行是新添加的文件。前面说了，Tomcat管理器里面添加的文件好像很少。此外，文件系统中还写入了其他文件，例如zzz（已显示在上面的Elasticsearch日志中）。要查看机器上还有什么在运行，我们还可以启动dockertop和stats命令。高CPU使用率，确认之前检测到的内容。我们还可以将容器更改提交到新图像（通过dockercommit）或将受影响的文件系统导出为tar文件（通过dockerexport）以存储更改的工件。如果您想了解有关此技术的更多信息，请查看对恶意Docker容器进行分类。DFIRKubernetes-离线方法Docker-explorer是一个开源项目，可以对快照卷进行离线取证分析。一旦我们确定了受影响的Pod所在的Kubernetes工作节点，最佳做法是为其文件系统拍摄快照。这可以通过云提供商控制台或通过使用其他一些开源项目（例如cloud-forensics-utils）来完成。有了快照卷，就可以进行事后分析，将其附加并安装到将使用docker-explorer的新虚拟机。Docker-explorer可以列出所有docker容器或仅列出挂载卷中正在运行的容器。一旦我们有了要调查的容器ID，就可以提取日志，就像我们之前使用docker日志所做的那样，但最重要的功能是使用docker-explorer将容器文件系统挂载到VM中。这将使我们能够访问受影响的容器文件系统。因此，从现在开始，我们将能够调查之前监控的进程和文件（zzz、kdevtmpfsi、kinsing）。例如，我们可以读取zzzbash脚本，或者我们可以提取ELF文件的哈希值，以便它可以被VirusTotal扫描。正如预期的那样，kdevtmpfsi进程是一个矿工，因为它的CPU使用率很高。Kube-forensicskube-forensics是一个开源项目，它允许集群管理员将任何受影响的pod的工件存储到S3存储桶中。它要求kube-forensics创建的workerpod具有将对象写入AWS存储桶的必要权限。这允许我们将受影响的Pod的证据存储到应用此PodCheckpoint的S3存储中：几分钟后，PodCheckpoint将完成其执行，证据也将出现在目标S3存储桶中。因此，除了保存pod描述之外，kube-forensics还存储与dockerinspect和dockerdiff命令相关的结果，其方式与我们之前在实时主机部分所做的类似。对于“...export.tar”文件，它是通过dockerexport命令可用的文件，它将容器文件系统存储在可以检查分发的“.tar”文件中。Kubernetes事件的解决和总结通过分析和调查违规行为，您可以识别集群中部署的易受攻击的资产。在此示例中，攻击入口点由暴露在网络上的易受攻击的TomcatPod表示。取证分析得出的结论是Tomcat管理器不安全，因为它配置错误并且不影响其他pod或命名空间。但是，有时受感染的pod可能会由于众所周知或未知的漏洞而被利用。作为事件响应阶段的一部分，您应该从受感染的pod中学习并用更新的安全pod替换它们。但是，如果您的工作负载无法得到保护，可能是因为它们还没有可用的补丁，您应该求助于其他解决方案。例如，第一个是在发布新补丁之前删除和删除你的部署，只要你对发生的事情有足够的信息。这是防止任何违规行为发生的最严格方法，但它也会在可用性方面影响您的业务。在其他一些情况下，您可能希望使用Falco和Falcosidekick来设置您的Kubernetes响应引擎。当通过Falco触发特定事件时，它允许您在Kubernetes集群内做出响应。例如，在前面的场景中，如果将具有通用文件名的新.war文件部署到Tomcat管理器或检测到RCE，我们可以制定终止pod的规则。本文翻译自：https://sysdig.com/blog/guide-kubernetes-forensics-dfir/如有转载请注明出处
