使用Atomic Red测试与Falco实现Kubernetes实时威胁检测

本文详细介绍了如何在Kubernetes环境中使用开源工具Falco实时检测Atomic Red Team模拟的攻击测试，包括部署步骤、测试场景执行和自定义规则创建，帮助提升云原生环境的安全防护能力。

强强联合：使用Atomic Red测试与Falco实现Kubernetes实时威胁检测

作为Sysdig公司Falco项目的开发者倡导者，Nigel Douglas在推动云原生安全开源检测与响应（D&R）领域教育方面发挥着关键作用。他致力于撰写文章、博客并登台演讲，帮助提高人们对云安全需求变化的认识。

在云原生环境中，应用程序的扩展速度远快于传统的单体应用架构，因此主动实时识别和响应威胁的能力至关重要。随着更多组织采用云原生架构进行应用交付，需要引入更强大的安全措施。在本博客中，我们通过探索开源Falco如何在Kubernetes环境中无缝实时检测Atomic Red Team测试，深入探讨Kubernetes威胁检测的动态领域。

Atomic Red Team是一个强大的框架，旨在模拟真实世界攻击，为组织提供受控环境以验证其安全措施的有效性。我们通过贡献一个Kubernetes部署清单进一步推进，通过单条命令加速在Kubernetes集群中部署和测试Atomic Red测试，模拟有用的攻击场景，以测试现有开源云原生入侵检测系统（如Falco）的响应能力。

我们的旅程从轻松部署Atomic Red到Kubernetes开始，展示在容器化环境中编排安全测试的简单性和效率。部署完成后，我们调用特定的Atomic Red Team测试，模拟一系列威胁场景。真正的测试在于Falco根据MITRE ATT&CK框架检测这些威胁的能力，该框架是一个全球认可的矩阵，将对手技术映射到防御战术。

这次探索不仅仅是识别威胁；这是一项协作努力，旨在增强Kubernetes的安全覆盖范围。如果发现Falco检测能力存在任何差距，我们可以深入修改执行的技术并制定自定义规则。这个迭代过程旨在扩展MITRE ATT&CK覆盖范围，使Atomic Red测试与行业在Kubernetes中威胁检测和缓解的最佳实践保持一致。

部署Atomic Red Team

为避免生产环境中潜在的服务中断，我们建议在测试实验室环境或至少Kubernetes的暂存环境中安装Atomic Red。我们有一个分步视频，用于在Kubernetes中安装Atomic Red：https://www.youtube.com/watch?v=5QjGnHGnxxo

在开始部署之前，请记住创建atomic-red网络命名空间。

1

kubectl create ns atomic-red

将部署一个特权设置为true的单个pod。Atomic Red需要管理员级别的securityContext来执行某些需要提升权限的操作。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: atomicred
  namespace: atomic-red
  labels:
    app: atomicred
spec:
  replicas: 1
  selector:
    matchLabels:
      app: atomicred
  template:
    metadata:
      labels:
        app: atomicred
    spec:
      containers:
      - name: atomicred
        image: issif/atomic-red:latest
        imagePullPolicy: "IfNotPresent"
        command: ["sleep", "3560d"]
        securityContext:
          privileged: true
      nodeSelector:
        kubernetes.io/os: linux
EOF

注意：这将在‘atomic-red‘网络命名空间中创建一个名为‘atomicred‘的pod。

您可以使用以下命令检查安装状态：

1

kubectl get pods -n atomic-red

如果您想从Kubernetes集群中移除Atomic Red项目，只需运行：

1

kubectl delete deployment atomicred -n atomic-red

熟悉Atomic Red测试

部署完成后，您需要shell到Atomic Red pod中执行以下测试场景。

这可能有点令人困惑，但Atomic Red是围绕PowerShell开发的，因此以下说明要求用户shell到一个容器中，一旦进入运行的pod，他们必须运行PowerShell来导入和调用各种Atomic测试场景。

一旦熟悉了这个逻辑，您会发现Atomic Red是一个真正简单的安全模拟工具。

1

kubectl exec -it -n atomic-red deploy/atomicred -- bash

如前所述，进入Atomic Red pod后需要运行PowerShell：

1

pwsh

现在，您终于可以加载Atomic Red Team模块：

1

Import-Module "~/AtomicRedTeam/invoke-atomicredteam/Invoke-AtomicRedTeam.psd1" -Force

检查TTP的详细信息：

1

Invoke-AtomicTest T1070.004 -ShowDetails

检查先决条件以确保测试条件正确：

1

Invoke-AtomicTest T1070.004 -GetPreReqs

您可以在下面的屏幕截图中看到，执行这些测试不需要先决条件。因此，我们可以调用批量文件删除测试场景。

移除功能标志以执行测试模拟。

1

Invoke-AtomicTest T1070.004

此测试将尝试删除单个文件或单个目录。当我们安装Falco时，此Atomic测试应默认触发‘Warning bulk data removed from disk‘规则。接下来，我们讨论Falco的安装。

恭喜！现在我们知道Atomic Red如何工作，让我们安装Falco并将其与Atomic Red并行运行，以证明它实时检测这些测试。我们将需要打开两个终端窗口来查看实时响应检测。

安装和测试Falco

对于本实验室指南，我们可以通过Helm在固定版本上安装Falco，该版本在将规则分离到不同规则源（如‘incubating’、‘sandbox’和‘stable’）之前。我们这样做是为了确保所有Falco规则在我们的实验室场景中可访问。要使用最新版本的Falco，只需从Helm安装脚本中移除‘–version’功能标志。

1
2
3
4

helm install falco falcosecurity/falco --namespace falco \
  --create-namespace \
  --set tty=true \
  --version 3.3.0

与Atomic Red部署一样，我们需要监控Falco安装的进度。pod在安装过程中会多次更改状态，但应在大约一分钟后全部处于‘RUNNING‘状态。请使用以下命令检查Falco pod的状态变化：

1

kubectl get pods -n falco -w

一旦Falco安装完成，我们可以在第二个终端窗口中使用以下命令跟踪生成的事件。

1

kubectl logs -f --tail=0 -n falco -c falco -l app.kubernetes.io/name=falco

跳回第一个终端窗口并重新运行批量文件删除Atomic测试 – ‘T1070.004‘：

1

Invoke-AtomicTest T1070.004

您将识别检测规则中的某些噪音。例如，所有Atomic测试都在‘Root’用户下运行，因此，我们总是会检测到在root下运行的脚本。要忽略此噪音，让我们改为仅检查我们想要检测的特定Falco规则：

1

kubectl logs -f --tail=0 -n falco -c falco -l app.kubernetes.io/name=falco | grep 'Bulk data has been removed from disk'

万岁！我们看到了与Atomic Red测试场景上下文完全匹配的检测。

让我们继续调用下一个Atomic测试。今天有许多Linux测试场景可供测试。

查看官方Atomic Red Team Github项目上的列表。

T1556.003 修改认证过程

在此场景中，Atomic Red生成三个可插拔认证模块（PAM）：两个用于Linux和FreeBSD的恶意PAM规则，以及一个用于Linux的恶意PAM模块。这些程序可用于打开和读取敏感文件内容，我们可以同意它们是非受信任程序。同样，我们有一个开箱即用的规则用于这些活动：

1

kubectl logs -f --tail=0 -n falco -c falco -l app.kubernetes.io/name=falco | grep 'Sensitive file opened for reading by non-trusted program'

现在，是时候模拟我们的威胁了：

1

Invoke-AtomicTest T1556.003

T1036.005 伪装：匹配合法名称或位置

此测试场景从伪装当前父目录的目录执行进程。

1

kubectl logs -f --tail=0 -n falco -c falco -l app.kubernetes.io/name=falco | grep 'Executing binary not part of base'

现在，是时候模拟我们的威胁了。

1

Invoke-AtomicTest T1036.005

您可以看到在左侧终端窗口中，终端中有一条回显消息‘”Hello from the Atomic Red Team.”‘命令行中的任何字符串输出也可以在Falco的输出中检测到。

T1070.002 主机上的指示器移除

对手可能清除系统日志以隐藏入侵证据。macOS和Linux都通过系统日志跟踪系统或用户发起的操作。大多数本机系统日志存储在‘/var/log/‘目录下。

1

kubectl logs -f --tail=0 -n falco -c falco -l app.kubernetes.io/name=falco | grep 'Log files were tampered'

现在，是时候模拟我们的威胁了：

1

Invoke-AtomicTest T1070.002

T1070.003 清除命令历史

除了清除系统日志，对手还可能清除受损帐户的命令历史，以隐藏入侵期间采取的行动。各种命令解释器跟踪用户在终端中键入的命令，以便用户可以追溯他们所做的操作。

1

kubectl logs -f --tail=0 -n falco -c falco -l app.kubernetes.io/name=falco | grep 'Shell history had been deleted or renamed'

现在，是时候模拟我们的威胁了：

1

Invoke-AtomicTest T1070.003

您可以从下面的屏幕截图中看到执行了四个不同的操作。因此，在这些清除命令行历史的个别尝试上触发了四个独特的Falco检测。

T1014 基于可加载内核模块的Rootkit

对手可能使用Rootkit隐藏程序、文件、网络连接、服务、驱动程序和其他系统组件的存在。Rootkit是通过拦截/挂钩和修改提供系统信息的操作系统API调用来隐藏恶意软件存在的程序。

Rootkit可能驻留在操作系统的用户或内核级别或更低级别，包括虚拟机监控程序、主引导记录或系统固件。因此，Falco实时检测Rootkit至关重要。

1

kubectl logs -f --tail=0 -n falco -c falco -l app.kubernetes.io/name=falco | grep 'Linux Kernel Module injection from container detected'

现在，是时候模拟我们的威胁了：

1

Invoke-AtomicTest T1014

Falco正在检测Linux内核模块注入尝试，无论执行是否成功。

T1037.004 [自定义规则] 启动初始化 – RC脚本

对手可能通过修改在类Unix系统启动期间执行的RC脚本来建立持久性。这些文件允许系统管理员在不同运行级别映射和启动自定义服务。RC脚本需要root权限才能修改。

模拟‘T1037.004‘测试的命令：

1

Invoke-AtomicTest T1037.004

您会注意到，这是第一个我们没有获得与威胁相关的有用Falco检测的测试。因此，我们需要创建一个‘custom-rules.yaml‘文件，其中包含用于检测启动初始化脚本的自定义Falco规则。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

cat > custom-rules.yaml <<EOF
customRules:
  custom_rules.yaml: |-
    - rule: Base64-encoded Python Script Execution
      desc: >
        This rule detects base64-encoded Python scripts on command line arguments.
      condition: >
        spawned_process and (
          ((proc.cmdline contains "python -c" or proc.cmdline contains "python3 -c" or proc.cmdline contains "python2 -c") and (proc.cmdline contains "echo" or proc.cmdline icontains "base64")) or ((proc.cmdline contains "import" and proc.cmdline contains "base64" and proc.cmdline contains "decode")))
      output: >
        Potentially malicious Python script encoded on command line
        (proc.cmdline=%proc.cmdline user.name=%user.name proc.name=%proc.name
        proc.pname=%proc.pname evt.type=%evt.type gparent=%proc.aname[2]
        ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt.res=%evt.res
        container.id=%container.id container.name=%container.name file=%fd.name)
      priority: warning
      tags:
        - T1037.004
        - MITRE_Defense_Evasion
      source: syscall
EOF

对手可以通过将恶意二进制路径或shell命令添加到‘rc.local‘、‘rc.common‘和其他特定于类Unix发行版的RC脚本来建立持久性。重启后，系统以root身份执行脚本内容，从而实现持久性。

让我们尝试升级Falco以反映‘custom-rules.yaml‘文件：

1
2
3
4
5
6

helm upgrade falco falcosecurity/falco \
  -n falco \
  --set tty=true \
  --version 3.3.0 \
  --reuse-values \
  -f custom-rules.yaml

假设创建‘custom-rules.yaml‘清单时没有明显的格式问题，您应该能够成功升级Falco，并且pod应处于‘RUNNING‘状态。如果自定义规则文件有问题，Falco pod状态可能会更改为‘CrashLoopBackOff‘。

让我们看看在升级Falco后是否检测到Atomic测试与新创建的自定义规则。

记住在第二个终端窗口中运行Falco，使用以下命令：

1

kubectl logs -f --tail=0 -n falco -c falco -l app.kubernetes.io/name=falco | grep 'Potentially malicious Python script'

我们可以最后一次模拟技术ID‘T1037.004‘：

1

Invoke-AtomicTest T1037.004

万岁！我们使用上述命令检测到了启动初始化脚本。回顾一下，试图滥用这些RC脚本的对手对于使用root用户作为默认值的轻量级类Unix发行版（如IoT或嵌入式系统）特别有效。如果您想知道为什么Falco规则特别关注Base64编码的Python脚本，那么我们需要回顾与Atomic测试模拟相关的详细信息。

1

Invoke-AtomicTest T1037.004 -ShowDetails

我们可以从命令中看到它使用‘python3‘命令运行Python脚本。但是，脚本本身作为base64编码的字符串执行，以规避一些传统的检测工具。

结论

总之，Kubernetes在云原生系统中的采用开启了一个效率和可扩展性的新时代，但这些优势带来了对强大威胁检测和响应机制的迫切需求。认识到这一必要性，安全团队可以利用Kubernetes部署清单的力量来简化安全工具的部署，以Atomic Red程序为例。

与其从事从零开始构建Atomic Red程序或通过Docker容器管理其测试的繁琐任务，Kubernetes部署清单的创新使用允许安全专业人员执行单条命令。这种能力使得在Kubernetes集群中快速动态扩展Atomic Red pod，提供响应迅速且适应性强的安全解决方案。

必须承认，为Kubernetes节点提供动力的Linux端点的普遍性需要关注以Linux为中心的原子测试。虽然Kubernetes本身不限于Linux发行版，但本文介绍了Atomic Red Kubernetes清单的利用，强调其在增强Kubernetes环境中安全响应能力方面的有效性。

特别感谢Falco项目的Thomas Labarussias（@ISSIF on Github — https://github.com/Issif）为部署清单制作镜像所做的贡献。通过协作努力和像Atomic Red Kubernetes清单这样的创新解决方案，云原生生态系统中的安全格局迈出了重要一步，增强了组织在面对不断演变的威胁时的韧性和适应性。

comments powered by Disqus
© 2020 - 2025 qife
使用 Hugo 构建
主题 Stack 由 Jimmy 设计
本站总访问量次 本站访客数人次