View a markdown version of this page

事故响应和取证 - Amazon EKS
事故响应计划示例建议工具和资源

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

事故响应和取证

你对事故做出快速反应的能力可以帮助最大限度地减少漏洞造成的损失。拥有一个可靠的警报系统来警告你可疑行为是制定良好事件响应计划的第一步。当事故发生时，你必须快速决定是销毁和更换受影响的容器，还是隔离和检查容器。如果您选择隔离容器作为取证调查和根本原因分析的一部分，则应遵循以下一系列活动：

事故响应计划示例

识别违规的 Pod 和工作节点

你的第一个行动方针应该是隔离伤害。首先确定漏洞发生的地点，将该 Pod 及其节点与基础设施的其余部分隔离开来。

使用工作负载名称识别违规的 Pod 和工作节点

如果您知道违规 Pod 的名称和命名空间，则可以按如下方式识别运行 pod 的工作节点：

kubectl get pods <name> --namespace <namespace> -o=jsonpath='{.spec.nodeName}{"\n"}'

如果诸如部署之类的工作负载资源遭到破坏，则作为工作负载资源一部分的所有 pod 都可能受到损害。使用以下命令列出工作负载资源的所有容器及其运行的节点：

selector=$(kubectl get deployments <name> \
 --namespace <namespace> -o json | jq -j \
'.spec.selector.matchLabels | to_entries | .[] | "\(.key)=\(.value)"')

kubectl get pods --namespace <namespace> --selector=$selector \
-o json | jq -r '.items[] | "\(.metadata.name) \(.spec.nodeName)"'

以上命令用于部署。您可以对其他工作负载资源（例如副本集、有状态集等）运行相同的命令。

使用服务账号名称识别违规的 Pod 和工作节点

在某些情况下，您可能会发现服务帐号已被盗用。使用已识别服务帐号的 Pod 很可能会遭到入侵。你可以使用服务账户识别所有的 pod 以及它们运行的节点，使用以下命令：

kubectl get pods -o json --namespace <namespace> | \
    jq -r '.items[] |
    select(.spec.serviceAccount == "<service account name>") |
    "\(.metadata.name) \(.spec.nodeName)"'

识别具有易受攻击或受损映像和工作节点的 Pod

在某些情况下，你可能会发现集群上的 pod 中使用的容器镜像是恶意的或被泄露的。如果容器镜像被发现包含恶意软件、是已知的错误映像或其 CVE 已被利用，则该容器映像是恶意的或受损的。你应该考虑所有使用容器镜像的 Pod 都被泄露了。你可以通过以下命令使用运行它们的镜像和节点来识别 pod：

IMAGE=<Name of the malicious/compromised image>

kubectl get pods -o json --all-namespaces | \
    jq -r --arg image "$IMAGE" '.items[] |
    select(.spec.containers[] | .image == $image) |
    "\(.metadata.name) \(.metadata.namespace) \(.spec.nodeName)"'

通过创建网络策略来隔离 Pod 的所有入口和出口流量

拒绝所有流量规则可以通过切断与 pod 的所有连接来帮助阻止已经在进行的攻击。以下网络策略将应用于带有标签的 Pod app=web。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  - Egress
重要

如果攻击者获得了底层主机的访问权限，则网络策略可能会失效。如果您怀疑发生了这种情况，则可以使用 AWS 安全组将受感染的主机与其他主机隔离开来。更改主机的安全组时，请注意，这将影响该主机上运行的所有容器。

必要时撤消分配给 pod 或工作节点的临时安全证书

如果已为工作节点分配了一个允许 Pod 访问其他 AWS 资源的 IAM 角色，则将这些角色从实例中移除，以防止攻击造成进一步损害。同样，如果已为容器组分配了 IAM 角色，请评估您是否可以在不影响其他工作负载的情况下，从该角色安全删除 IAM 策略。

封锁工作节点

通过封锁受影响的工作节点，你是在通知调度器避免将 pod 调度到受影响节点上。这将允许您在不中断其他工作负载的情况下移除该节点进行取证研究。

注意

本指南不适用于每个 Fargate 吊舱都在自己的沙盒环境中运行的 Fargate。与其进行封锁，不如应用拒绝所有入口和出口流量的网络策略来隔离受影响的 Fargate Pod。

在受影响的工作节点上启用终止保护

攻击者可能会尝试通过终止受影响的节点来抹去自己的不当行为。启用终止保护可以防止这种情况发生。实例缩容保护将保护节点免受缩减事件的影响。

警告

您无法在竞价型实例上启用终止保护。

给违规行为贴 Pod/Node 上标签，表明这是正在进行的调查的一部分

这将警告集群管理员，在调查完成 Pods/Nodes 之前不要篡改受影响的人。

捕获工作节点上的易失性工件

  • 捕获操作系统内存。这将捕获 Docker 守护程序（或其他容器运行时）及其每个容器的子进程。这可以通过使用 Lime 和 Volatility 等工具来实现，也可以通过更高级别的工具来实现，例如基于这些工具的 Amazon EC2 https://aws.amazon.com/solutions/implementations/automated-forensics-orchestrator-for-amazon-ec2/ 自动取证协调器。

  • 对正在运行的进程和打开的端口执行 netstat 树转储。这将捕获 docker 守护程序及其每个容器的子进程。

  • 在修改证据之前，运行命令保存容器级状态。您可以使用容器运行时的功能来捕获有关当前正在运行的容器的信息。例如，使用 Containerd，您可以执行以下操作：

    • crictl ps用于正在运行的进程。

    • crictl logs CONTAINER用于守护程序级别的日志。

      使用 nerdctl C LI 代替docker（例如）的 containerd 也可以实现同样的效果。nerdctl inspect根据容器运行时间，还有一些其他命令可用。例如，Docker docker diff 必须查看容器文件系统的更改或docker checkpoint保存所有容器状态，包括易失性内存 (RAM)。有关容器或运行时的类似功能的讨论，请参阅这篇Kubernetes博客文章。 CRI-O

  • 暂停容器以进行取证捕获。

  • 快照实例的 EBS 卷。

重新部署受感染的 Pod 或工作负载资源

收集了用于取证分析的数据后，您可以重新部署受感染的 pod 或工作负载资源。

首先推出已受损漏洞的修复程序，然后启动新的替换 pod。然后删除易受攻击的 pod。

如果易受攻击的 pod 由更高级别的 Kubernetes 工作负载资源（例如，部署或 DaemonSet）管理，则删除它们将安排新的 Pod。因此，易受攻击的吊舱将再次启动。在这种情况下，你应该在修复漏洞后部署新的替代工作负载资源。然后，您应该删除易受攻击的工作负载。

建议

查看 AWS 安全事件响应白皮书

虽然本节简要概述了处理可疑安全漏洞的一些建议，但该主题已在白皮书《 AWS 安全事件响应》中进行了详尽的介绍。

练习安全游戏日

将您的安全从业人员分成两个小组：红色和蓝色。红队将专注于探测不同的系统是否存在漏洞，而蓝队将负责防御漏洞。如果你没有足够的安全从业人员来组建单独的团队，可以考虑雇用一个了解 Kubernetes 漏洞的外部实体。

Kubesploit 是一个渗透测试框架 CyberArk ，你可以用它来进行游戏日。与其他扫描集群漏洞的工具不同，kubesploit 模拟的是真实世界的攻击。这让你的蓝队有机会练习对攻击的反应并评估其有效性。

对您的集群运行渗透测试

定期攻击自己的集群可以帮助您发现漏洞和错误配置。在开始之前，请遵循渗透测试指南，然后再对您的集群进行测试。

工具和资源