Linux& 云检测工程 - 开始使用 Defend for Containers (D4C)

简介

Linux 系统仍然是现代基础架构的重要基础，尤其是在云原生环境中，容器和协调平台已成为常态。随着工作负载从长期存在的主机转移到短暂存在的容器，攻击者的手段也随之改变。曾经在磁盘上留下持久痕迹的活动越来越多地局限于短暂的运行时行为，而传统的日志源很难捕捉到这些行为。

因此，这些环境中的检测工程在很大程度上取决于运行时的可见性。了解进程如何在容器内执行、文件如何被访问以及工作负载如何与主机交互，这比依赖静态指标或事件发生后的工件更为重要。

Elastic 提供了多个以 Linux 为重点的遥测源，以支持此类检测工作。在本系列的前几篇文章中，我们重点介绍了使用 Auditd 和 Auditd Manager 的主机级可视性，展示了如何将低级系统事件转化为高保真检测。在这篇文章中，重点将转向 Elastic 的 Defend for Containers：专为容器化 Linux 工作负载构建的运行时安全集成。

本文的目的不是记录 Defend for Containers 的每项功能，而是为检测工程师提供一个实用的出发点：集成会产生哪些数据以及如何推理这些数据。下一部分，我们将探讨如何将其应用到现实的容器攻击场景中。

利用容器防御功能简化可见性

我们很高兴地宣布，9.3.0 版中的 "容器防御 "功能已经推出。释放。这种集成为容器安全带来了一种简化的方法，为云原生基础设施的可视性奠定了坚实的基础。用户可以利用一套专为抵御现代 Kubernetes 威胁和特定容器漏洞而定制的检测规则。在推出 Defend for Containers 的同时，还推出了容器专用检测规则集，该规则集是根据现实的容器和 Kubernetes 威胁模型设计的。

在撰写本文时，Defend for Containers 规则集提供了常见容器攻击技术的基准覆盖范围，包括侦察活动、凭证访问尝试、kubelet 攻击、服务帐户令牌滥用、交互式进程执行、文件创建和修改、解释器滥用、编码有效载荷执行、工具安装、隧道行为和多种权限升级向量。重要的是，所有现有的特定于容器和 Kubernetes 的检测规则都已与 Defend for Containers 兼容，允许以前以主机为中心的逻辑直接在容器运行时遥测数据上运行。

这使得 Defend for Containers 成为一个实用的数据源，可供专注于行为驱动运行时检测的 Linux 检测工程师立即使用。本文章的其余部分将重点介绍遥测技术在实践中的应用，以及如何将其应用到真实的容器攻击场景中。

容器防御简介

Defend for Containers是一个运行时安全集成，可在 Linux 容器执行时提供其可见性。它不依赖静态图像扫描或执行后日志，而是侧重于实时观察容器行为。

在高层次上，Defend for Containers 可从运行的容器中捕获与安全相关的运行时事件，如进程执行和文件访问。这些事件通过容器和协调上下文得到丰富，并被传送到 Elasticsearch，在那里可以对其进行分析，并将其作为检测规则的输入。

从检测工程的角度来看，Defend for Containers 处于传统 Linux 行为和容器环境的交叉点上。进程、系统调用和文件活动仍然是核心信号，但现在它们的作用域扩展到了容器、命名空间和工作负载，而这些工作负载可能只存在很短的时间。

Defend for Containers 作为 Elastic Agent 的一部分部署，并直接与 Elastic Security 集成。启用后，它将提供一个专用的容器运行时事件流，可使用 KQL 或 ES|QL 进行查询，也可由检测分析直接使用。这样，检测工程师就可以应用熟悉的分析技术，同时考虑到云原生工作负载的实际运行情况。

在接下来的章节中，我们将更详细地检查 Defend for Containers 事件，并通过几个容器攻击场景来说明如何在实践中使用这些数据。

为容器设置防御

在利用 Defend for Containers 的运行时可视性和分析功能之前，您需要部署集成并配置策略，以定义要观察的事件和遇到匹配活动时要采取的措施。有关集成及其设置的更多信息，请点击此处。在高层次上，这种设置包括

在 Kubernetes 环境中通过 Elastic Agent 部署 Defend for Containers 集成。
配置或自定义 "为容器防御 "策略，该策略由定义匹配哪些操作的选择器和定义采取哪些措施的响应组成。
根据观察到的工作负载行为验证和改进策略。

部署方法

Defend for Containers 作为 Elastic Agent 集成交付，依靠 Elastic Agent 收集容器运行时遥测数据并将其转发到你的 Elastic Stack。对于 Kubernetes 工作负载，你可以通过 Elastic Security UI 安装集成，然后在群集节点上注册代理。

基本部署流程是

在 Elastic Security UI 中，导航至Fleet并创建新的代理策略（或将集成添加到现有策略中）。创建代理策略后，我们就可以在策略中添加 "为容器防御 "集成。

为集成命名，并可选择调整默认选择器和响应（我们将在本出版物的后续部分介绍可用选项）。选择 "添加集成 "后，就会出现一个带有正确集成的新代理策略。

在本演示中，我们将利用 Kubernetes 部署方法。要将此策略部署到工作负载，我们可以导航到操作 → 添加代理 → Kubernetes。在这里，我们可以看到复制或下载 Kubernetes 清单的说明。

需要注意的一点是："请注意，以下清单包含的资源限制可能不适合生产环境。在部署此清单之前，请查看我们的" 在 Kubernetes 上扩展弹性代理"指南"。

您需要在 Kubernetes YAML 的securityContext 下包含以下capabilities ，服务才能正常运行：

securityContext:
    runAsUser: 0
    capabilities:
      add:
        - BPF ## Enables both BPF & eBPF
        - PERFMON
        - SYS_RESOURCE

复制或下载所提供的elastic-agent-managed-kubernetes.yml 清单后，您可以根据需要编辑清单，并通过以下方式应用清单：

kubectl apply -f elastic-agent-managed-kubernetes.yml

正如清单中提到的，请查看 "在由 Fleet 管理的 Kubernetes 上运行 Elastic Agent"指南，了解更多部署信息。

等待 Elastic Agent pod 完成调度，数据开始流入 Elasticsearch。

部署完成后，Elastic Agent 将与 Fleet 建立连接，在所选策略下注册，并开始发布 Elastic Security 可以使用的 Defend for Containers 遥测信息。

下一节，我们将了解集成配置选项，并探讨哪些功能可供使用。

为容器政策辩护

Defend for Containers 配置的核心是策略。政策决定观察哪些活动，以及发生匹配事件时如何应对。政策由两个基本组成部分组成：

选择器：通过指定操作和条件来定义哪些事件值得关注；
响应：定义当选择器的条件满足时要采取的操作。

Defend for Containers 策略可在部署前进行编辑，也可在部署后通过 Elastic Security UI 的策略编辑器进行修改。

政策结构

每个策略必须包含至少一个选择器和至少一个响应。典型的选择器会指定一个或多个操作（如进程事件或文件活动），并使用条件（如容器映像名称、命名空间或 pod 标签）来缩小范围。响应会引用选择器，并指出事件匹配时应采取的操作。

默认的 Defend for Containers 策略包括两个选择器-响应对："威胁检测 "和 "漂移检测& 预防"。

威胁检测：名为allProcesses 的selector 会匹配来自容器的所有fork 和exec 事件。

相关response 的操作设置为Log ，确保事件被摄取和分析。

漂移检测& 预防：名为executableChanges 的选择器匹配createExecutable 和modifyExecutable 操作。

而响应被配置为创建警报（并可修改以阻止这些操作）。

这些策略可以通过用户界面修改，但在引擎盖下，这些策略是简单的 YAML 配置文件，可以轻松修改并用于任何 CI|CD 流程：

process:
  selectors:
    - name: allProcesses
      operation:
        - fork
        - exec
  responses:
    - match:
        - allProcesses
      actions:
        - log
file:
  selectors:
    - name: executableChanges
      operation:
        - createExecutable
        - modifyExecutable
  responses:
    - match:
        - executableChanges
      actions:
        - alert

接下来，我们将举例说明选择器和响应，并讨论如何根据自己的喜好设置集成。

选择器示例代码段

选择器允许使用诸如以下字段的条件进行精细匹配：

containerImageFullName：完整图像名称，如docker.io/nginx ；
containerImageName：部分图像名称；
containerImageTag特定标签，如最新；
kubernetesClusterId:Kubernetes 集群 ID；
kubernetesClusterName:Kubernetes 集群名称；
kubernetesNamespace命名空间：工作负载运行的命名空间；
kubernetesPodNamepod 名称，支持尾部通配符；
kubernetesPodLabel标签：标签键/值对，支持通配符。

selectors:
  - name: nodeExports
    file:
      operations:
        - createExecutable
        - modifyExecutable
      containerImageName:
        - "nginx"
      kubernetesNamespace:
        - "prod-*"

在本例中，名为nodeExports 的选择器会匹配在映像名称包含 "nginx "且 Kubernetes 名称空间以“prod-” 开头的容器中创建或修改可执行文件的文件事件。

响应代码段示例

响应决定了在满足选择器条件时会发生什么。常见的行动包括

log：将事件作为遥测数据发送，以供分析；
alert在 Elastic Security 中创建警报；
block：阻止操作（对于支持的类型）。

responses:
  - name: alertAndBlockNodeExports
    matchSelectors:
      - nodeExports
    actions:
      - alert
      - block

在这里，名为alertAndBlockNodeExports 的响应引用了之前定义的 nodeExports 选择器，并将生成警报和阻止操作。

通配符和匹配

Defend for Containers 中的选择器在基于字符串的条件（如 pod 名称或图像标记）中支持尾部通配符。这样就可以进行广泛的匹配，而无需枚举所有可能的值。例如，backend-* 的 pod 选择器将匹配名称以backend- 开头的所有 pod，而role:api* 等标签条件将匹配以api 开头的标签值。

在工作负载快速扩展和变化的动态环境中，这种通配符功能至关重要。

除了简单的字符串匹配外，Defend for Containers 选择器在匹配文件路径时还支持基于路径的通配符语义。请看下面的选择器示例：

- name:
  targetFilePath:
    - /usr/bin/echo
    - /usr/sbin/*
    - /usr/local/**

在本示例中：

/usr/bin/echo 只匹配该路径下的echo 二进制文件。
/usr/sbin/* 与/usr/sbin 的直系子代相匹配。
/usr/local/** 匹配/usr/local 下的所有递归内容，包括/usr/local/bin/something 等路径。

有了这些区别，就可以对基于文件的选择器进行精确定位，在覆盖范围和噪音之间取得平衡。在实践中，它们允许检测工程师根据使用情况，针对特定的二进制文件、整个目录或深层目录树进行检测，而无需诉诸过于宽松的规则。

将一切联系起来

到此为止，我们已经了解了 Defend for Containers 选择器、通配符语义、事件类型以及它们如何在运行时显示攻击者行为。最后一步是了解这些部分如何在政策中结合在一起，以表达真正的检测逻辑。

请看下面的政策片段：

file:
  selectors:
    - name: binDirExeMods
      operation:
        - createExecutable
        - modifyExecutable
      targetFilePath:
        - /usr/bin/**
    - name: etcFileChanges
      operation:
        - createFile
        - modifyFile
        - deleteFile
      targetFilePath:
        - /etc/**
    - name: nginx
      containerImageName:
        - nginx

  responses:
    - match:
        - binDirExeMods
        - etcFileChanges
      exclude:
        - nginx
      actions:
        - alert
        - block

该策略定义了三个选择器。两个选择器（binDirExeMods 和etcFileChanges ）描述了感兴趣的文件系统活动，而第三个选择器（nginx ）描述了要排除的容器上下文。

响应部分将这些选择器联系在一起。match 下所列的选择器在逻辑上是OR'd'，这意味着任一条件都足以触发响应。exclude 下所列的选择器充当逻辑NOT ，在容器图像nginx 时移除匹配事件。

通俗地理解，该政策表达了以下逻辑：

如果在/usr/bin 下的任何位置创建或修改了可执行文件，或在/etc 下创建、修改或删除了文件，而该活动并非源于nginx 容器，则应生成警报并阻止该操作。

用布尔形式可以表示为

IF (binDirExeMods OR etcFileChanges) AND NOT nginx
→ alert + block

这正是防御容器策略变得强大的地方。与在查询语言中编写复杂的检测逻辑相比，选择器可以让你将行为分解成小的、可重复使用的构件，然后以声明的方式将它们组合起来。通过混合基于路径的选择器、操作类型、容器上下文和排除项，您可以表达细微的检测逻辑，同时保持可读性和可维护性。

在实践中，该模型允许检测工程师将威胁假设直接转化为策略逻辑：哪些行为重要、在哪里发生、在 哪些工作负载中发生以及发生时应该采取什么措施。

政策验证和完善

一旦部署了策略，就必须先根据实际工作负载行为对其进行验证，然后再启用封堵等激进响应。限制性太强的政策可能会破坏容器的正常运行；过于宽松的政策可能会让不需要的活动被忽视。

推荐的工作流程是

在监控模式下部署默认策略（例如，选择器记录事件）。
观察 Elasticsearch 中出现的事件，了解正常的工作负载模式。
逐步收紧选择器和响应，从仅有日志→警报→块，在每个阶段进行测试。
使用暂存或测试集群验证阻塞行为，然后再将其应用到生产中。

容器防御测试版限制

截至本文撰写之时，Defend for Containers 还处于测试版集成状态，其当前功能和平台支持也反映了这一状态。

Defend for Containers 正式支持 Amazon EKS 和 Google GKE。虽然可以在 Azure AKS 上部署集成，但官方并不支持这种配置。特别是，AKS 部署目前缺乏文件事件遥测，这限制了这些环境中基于文件的攻击技术的检测范围。

当前的 Beta 版也无法捕捉网络事件。因此，与出站连接、横向网络移动或数据外渗相关的检测必须依赖网络数据包捕获集成或 Packetbeat 集成等补充数据源，而不能仅依赖 Defend for Containers 遥测数据。

对于文件活动，Defend for Containers 故意只在以写入意图打开时记录文件打开事件。这种设计选择可减少噪音，并侧重于改变系统状态的行为。不过，这也意味着目前无法观察到对敏感文件的只读访问，如秘密发现、配置搜刮或失败的访问尝试。

这种限制会影响检测使用情况，例如

搜索和读取 Kubernetes 服务帐户令牌、
扫描.env 文件或凭证材料。

在这些领域，未来的 Defend for Containers 迭代可能会提供更精细的遥测数据，以支持高级检测工程用例。

启用 Defend for Containers 预置检测规则

Defend for Containers 随附一套预建检测规则，为常见的容器攻击技术提供基线覆盖。启用集成后，这些规则可直接从 Elastic Security 激活，无需额外配置。

建议将启用预置规则作为起点，因为这些规则旨在与 Defend for Containers 的运行时遥测保持一致，并涵盖容器内的执行、文件修改、持久性和漏洞后行为。在此基础上，可以对规则进行扩展或改进，以匹配特定环境的工作负载和威胁模型。

通过筛选 "数据源：Elastic Defend for Containers"，就能找到与此集成相关的所有规则。

注意：如果没有弹出任何规则，请确保堆栈运行的是 9.3.0 版本、因为这些规则只在 9.3.0+ 上部署。

在映射了所有重要的 Beta 限制、部署了集成、安装并启用了预构建的检测规则和工作策略后，下一步就是探索 Defend for Containers 产生的事件语义，包括检测逻辑中常用的字段、性能考虑因素以及这些事件与 Elastic Defend 事件有何不同。

分析防御容器事件

现在，Defend for Containers 已经部署完毕，策略也已就位，下一步就是了解它生成的事件。与使用 Elastic Defend 或 Auditd Manager 类似，一旦你建立了一个关于事件结构和哪些字段与检测工程最相关的心智模型，Defend for Containers 遥测就会变得更有价值。

Defend for Containers 可生成多种事件类型，其中最主要的是进程事件和文件事件，每种类型都包含容器、主机和协调上下文。虽然底层信号仍植根于 Linux 行为，但额外的 Kubernetes 和容器元数据使您能够以仅主机遥测无法实现的方式对活动进行推理。

以下各节将以真实的 Defend for Containers 事件为参考点，介绍最重要的字段组和事件类型。

常见领域

在深入了解具体的事件类别之前，了解 Defend for Containers 遥测中经常出现的字段非常有用。这些字段提供了上下文粘合剂，将单个运行时操作与内核中的策略、选择器和底层执行点联系起来。

虽然进程和文件事件在细节上有所不同，但下面描述的字段存在于 Defend for Containers 数据流中，通常是验证检测或排查策略行为时首先要查看的字段。

针对集装箱特定上下文进行防御

Defend for Containers 为如何收集事件和应用策略添加了几个特定字段。

cloud_defend.hook_point 字段表示捕获事件的内核位置。在所示示例中，tracepoint__sched_process_fork 和tracepoint__sched_process_exec 等值表明，事件是由与进程创建和执行相关的内核跟踪点生成的。

cloud_defend.matched_selectors 字段显示活动策略中与事件匹配的选择器。在示例中，值allProcesses 表示该事件与捕获所有流程活动的广泛选择器相匹配。在调整策略或调查警报时，该字段对了解捕获事件的原因至关重要。

cloud_defend.package_policy_id 和cloud_defend.package_policy_revision 字段将事件与特定的 Elastic Agent 策略及其修订版联系起来。这样就可以将事件与一段时间内的配置变化联系起来，并验证事件发生时哪个版本的策略处于活动状态。

事件元数据

Defend for Containers 事件遵循Elastic Common Schema约定，包括描述活动类型和生命周期的标准事件元数据。

event.category 字段标识活动的高级类型，如process 或file ，通常是筛选 Defend for Containers 数据时使用的第一个字段。event.action 字段描述了发生的事件，例如，进程活动为fork 或exec ，文件事件为open,creation,modification 和deletion 。

event.type 字段添加了生命周期上下文，如用于流程执行的start ，通常与event.action 一起用于区分活动的不同阶段。event.dataset 字段表示 Defend for Containers 数据流的来源，如cloud_defend.process ，这在构建数据集范围查询或检测时非常有用。

附加元数据字段，如event.id 、event.ingested 和event.kind ，主要用于关联、排序和故障排除，而非检测逻辑。

主机信息

Defend for Containers 事件包括完整的主机上下文，类似于 Elastic Defend 和 Auditd Manager。这使得将容器运行时活动与底层 Kubernetes 节点关联起来成为可能。

host.name 字段标识了运行容器的节点，而host.os.* 则提供了操作系统的详细信息，如发行版和内核版本。host.architecture 字段表示 CPU 架构，这在分析二进制执行或内核特定行为时可能很重要。

host.pid_ns_ino 是一个特别有用的字段，用于标识 PID 命名空间。该字段允许将容器活动与主机级进程和内核遥测相关联，在调查容器逃逸尝试或节点级影响时尤其有价值。

在分析云原生攻击时，这种主机上下文至关重要，因为多个容器通常共享同一主机和内核，而容器的运行时行为可能会影响到其边界之外的地方。

容器和协调器上下文

Defend for Containers 的主要优势在于其集装箱意识。每个运行时事件都有丰富的容器和协调元数据，可以根据运行内容、运行地点和权限对活动进行分析。

在容器级别，container.id 和container.name 等字段可唯一标识运行中的容器，而container.image.name 、container.image.tag 和映像哈希值则可提供工作负载的来源和版本的可见性。这对于区分预期的实用程序图像和意外或临时工作负载特别有用。

风险评估的一个关键领域是container.security_context.privileged 。该字段明确指示容器是否在特权模式下运行。当特权执行与其他信号（如交互式 shell 或广泛的 Linux 功能）相结合时，任何被检测到的活动的风险都会大大增加。

Defend for Containers 还通过协调上下文来丰富事件。orchestrator.cluster.name 、orchestrator.namespace 和orchestrator.resource.name （通常是 Pod 名称）等字段将运行时行为与 Kubernetes 工作负载联系起来。通过orchestrator.resource.label 公开的标签可进一步将工作负载意图和所有权纳入检测范围。

对于探测工程而言，这种情况可使探测范围精确到

特定命名空间（例如kube-system ）、
特权容器或高风险容器、
带有敏感标签的工作负载、
或已知的实用图像，如netshoot,kubectl 或curl 。

通过这层丰富的功能，可以直接表达容器感知检测逻辑，而无需从文件系统路径、cgroup 或命名空间标识符间接推断意图。

过程事件

进程执行是 Defend for Containers 提供的最重要的信号类型之一。进程事件可捕获fork 、exec 和end 容器内的活动，并揭示详细的沿革信息，这对了解运行时的执行情况至关重要。

有几个领域对检测工程尤为重要。process.name 和process.executable 的组合可确定执行了什么以及从哪里执行的，而process.args 则提供了如何调用的信息。process.pid,process.start,process.end, 和process.exit_code 等字段描述了进程的生命周期，对时序分析和执行流重建很有用。process.entity_id 提供了一个稳定的标识符，可在多个相关事件中跟踪流程。

Defend for Containers 还能捕捉丰富的祖先信息。process.parent.* 下的字段描述了直接父进程，从而可以检测出可疑的父子关系，如意外二进制文件产生的 shell。此外，process.entry_leader.* 和process.session_leader.* 在流程树中提供了更高层次的锚点。

与 Elastic Defend 相似，Defend for Containers 将流程建模为图形，而不是孤立的事件。入口领导者在容器环境中尤其有用，因为它通常代表容器运行时启动的初始进程（例如containerd 、runc 或指定为容器入口点的 shell）。将检测锚定在入口领导者上，即使容器产生了许多短暂的子进程，也能对进程树进行一致的解释。

会话领导者字段提供了有关交互式执行和会话边界的更多信息，有助于将后台服务与交互式或攻击者驱动的活动区分开来。

这些字段结合在一起，使我们能够表达超出单次执行的检测逻辑，并对执行链、执行过程和意图进行推理，这对于检测真实世界中的容器攻击技术至关重要。

能力和特权背景

Defend for Containers 进程事件更强大的功能之一是包含 Linux 能力信息。对于每个流程，Defend for Containers 都会通过以下方式公开有效和允许的能力集：

process.thread.capabilities.effective
process.thread.capabilities.permitted

这些字段描述了进程在运行时实际允许做的事情，与其用户 ID 或容器边界无关。

在特权容器中，进程通常会暴露大量有效的功能，包括高度敏感的功能，如CAP_SYS_ADMIN,CAP_SYS_MODULE,CAP_SYS_PTRACE,CAP_SYS_RAWIO 和CAP_BPF 。这些功能的存在极大地改变了任何已执行命令的风险状况，因为它们可以执行直接影响主机内核或其他工作负载的操作。

从检测工程的角度来看，这种背景至关重要。它使检测超越了简单的流程名称匹配，而是对影响进行推理。同样是执行二进制文件，其影响可能大相径庭，这取决于它是以最小的能力集运行，还是以接近主机级的权限运行。

实际上，能力数据使探测工程师能够

识别在过度许可的容器内执行的可疑工具。
将运行时行为与危险的能力组合相关联。
根据实际开发潜力而非表面活动确定警报的优先级。

这一点与集装箱突破研究尤为相关，因为特定能力的存在与否往往决定了漏洞利用是否可行。

互动执行

process.interactive 字段表示进程是否与交互会话相关联。在容器环境中，交互式执行在生产工作负载中相对罕见，而且通常与后妥协或键盘操作活动密切相关。

Defend for Containers 不仅在进程层面，而且在相关执行上下文（包括process.parent.interactive 、process.entry_leader.interactive 和process.session_leader.interactive ）之间暴露交互性。这样就可以确定整个执行链是否是交互式的，而不是孤立地依赖于单个进程标志。

在容器内交互式执行的常见例子包括生成bash 或sh shell，运行curl 、kubectl 或busybox 等交互式实用程序，或在被入侵的 Pod 内进行操作员驱动的侦查。虽然这些操作在调试过程中可能是合法的，但在稳态生产工作负载中并不常见。

当与容器映像、命名空间和权限上下文相结合时，交互式执行就会成为一个强烈的异常信号。它允许检测逻辑区分预期的自动化容器行为和更符合人工干预或攻击者驱动的探索活动。

文件事件

Defend for Containers 文件事件可捕获容器内的文件系统活动，并在进行各种操作时发出。与传统的文件完整性监控不同，这些事件可在运行时感知，并针对容器工作负载，提供有关文件更改发生的方式和原因的上下文。

Defend for Containers 可检测文件活动，如带有写入意图的文件打开、内容修改、文件创建、重命名、权限更改和删除。Defend for Containers 专注于面向写入的操作，强调改变系统状态的行为，而不是被动的文件访问。

这样，检测工程师就能在运行时对文件使用模式进行推理，而不仅仅是对变更的结果进行推理。

在建立基于文件的检测时，有几个字段尤为重要。file.path 和file.name 字段可识别受影响的文件及其位置，而file.extension 则有助于区分二进制文件、脚本和配置文件。event.action 和event.type 字段说明发生了什么操作，以及在事件生命周期中应如何解释。

通过这些字段，Defend for Containers 可以将良性文件访问与可疑的修改模式（如在敏感目录中写入二进制文件或更改权限）区分开来。

汇聚一堂

与任何其他数据源一样，一旦了解了如何在流程、文件、容器和协调域中组合字段，Defend for Containers 遥测就会变得真正有价值。Defend for Containers 不依赖于静态指标，而是根据运行时行为、权限上下文和工作负载身份进行检测工程。

结论

在 Elastic Stack 9.3.0 中为容器进行防御将容器运行时检测作为 Linux 检测工程的核心组成部分。它具有明确的范围、策略驱动的配置模型以及专为容器化工作负载设计的运行时遥测功能。

在这篇文章中，我们研究了如何部署 Defend for Containers、其策略模型的结构，以及运行时事件是如何生成并丰富容器和协调上下文的。我们探索了进程和文件事件、能力元数据、交互式执行信号以及容器特定字段的结构，这些字段允许以工作负载感知的方式表达检测结果。

我们从中得到的主要启示是，有效的容器检测需要在上下文中对运行时行为进行推理：必须同时评估进程、文件修改、权限和工作负载身份。Defend for Containers 提供了必要的遥测技术，使之成为可能。

在下一篇文章中，我们将在此基础上，通过一个真实的容器攻击场景，演示 Defend for Containers 遥测如何在实践中揭示入侵的每个阶段。