容器逃逸检测实战：基于 Falco、Seccomp 与 auditd 的容器逃逸攻击检测指南

容器逃逸检测实战：基于 Falco、Seccomp 与 auditd 的容器逃逸攻击检测指南

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills

本文基于 Anthropic-Cybersecurity-Skills 仓库中 detecting-container-escape-attempts 技能文档，结合仓库内配套的检测脚本（agent.py、process.py）与参考标准文档，完整讲解从运行时检测、逃逸面审计到事件处置的容器逃逸检测体系。读完本文，你将掌握：使用 Falco 规则实时捕获命名空间操纵、能力滥用、敏感路径访问等逃逸征兆；用自定义 seccomp profile 收敛逃逸面；用 auditd 规则补齐系统调用审计；并用仓库提供的 Python 扫描器对 Docker/Kubernetes 工作负载做量化风险评估。

一、什么是容器逃逸，为什么要专门检测它

容器逃逸（Container Escape）是攻击者突破容器隔离边界、进入宿主机或其他容器的关键攻击手法。它往往是容器化环境中"从工作负载提权到宿主机"的分水岭：一旦逃逸成功，攻击者便获得宿主机级别的执行能力，可横向扩展至整个集群。

检测的核心思路是：围绕逃逸所需的前置条件与特征行为进行监控，包括命名空间操纵、Linux 能力（capability）滥用、内核漏洞利用、敏感路径挂载以及异常系统调用模式，并借助 Falco、Sysdig、seccomp/auditd 等运行时安全工具落地检测规则。

该技能对应的 MITRE ATT&CK 覆盖已登记在仓库的 coverage-summary.md（Container Escape / T1611）与 attack-navigator-layer.json 中，可将其作为检测覆盖率规划的参考依据。

二、适用场景

• 安全事件调查中需要判定"是否发生了容器逃逸尝试"；
• 为该领域构建检测规则或威胁狩猎查询；
• SOC 分析人员需要结构化的处置流程；
• 验证现有安全监控对相关攻击技术的覆盖缺口。

三、环境前提

在开始部署检测能力前，需确认以下前置条件：

• Linux 宿主机，内核5.10+（需支持 eBPF）；
• Falco 0.37+已安装（内核模块或 eBPF probe 驱动方式均可）；
• Docker Engine 或 containerd 运行时；
• 已配置auditd；
• 具备root 权限，用于加载 eBPF / 内核模块。

说明：eBPF 驱动方式（kind: ebpf或modern_ebpf）可避免编译内核模块，是较推荐的部署路径；modern_ebpf需要内核 5.8+。

四、核心概念：逃逸攻击面与检测分层

4.1 常见容器逃逸向量

仓库的 standards.md 进一步明确了各技术的战术归属：T1611（Escape to Host，提权战术）、T1610（Deploy Container，执行战术）、T1068（Exploitation for Privilege Escalation）以及 T1548.004（能力滥用提权）。

4.2 与逃逸直接相关的危险 Linux 能力

4.3 五层检测体系

1. 系统调用监控（Syscall monitoring）——eBPF/内核模块实时捕获系统调用；
2. 文件完整性（File integrity）——检测逃逸使能路径（如 runc/containerd 二进制、敏感文件）被篡改；
3. 进程监控（Process monitoring）——跟踪进程创建与命名空间变更；
4. 网络监控（Network monitoring）——检测容器到宿主机的异常连接；
5. 审计日志（Audit logging）——利用 Linux auditd 审计能力与挂载操作。

五、实战工作流：五步搭建检测体系

Step 1：通过 Helm 部署 Falco

falco-values.yaml的关键配置项如下：

# falco-values.yaml for Helm deployment falco: driver: kind: ebpf # or modern_ebpf for kernel 5.8+ rules_files: - /etc/falco/falco_rules.yaml - /etc/falco/falco_rules.local.yaml - /etc/falco/rules.d json_output: true json_include_output_property: true http_output: enabled: true url: "http://falcosidekick:2801" grpc: enabled: true priority: warning

各参数要点：

• driver.kind：ebpf加载 eBPF probe，modern_ebpf适配内核 5.8+，无需预编译内核模块；
• rules_files：除默认规则外挂载用户自定义规则目录rules.d，便于后续放入逃逸检测规则；
• json_output与json_include_output_property：开启 JSON 输出并包含输出字段，是下游脚本（见第六节 agent.py）解析的基础；
• http_output：将告警转发至 Falcosidekick 进行告警路由；
• priority: warning：仅上报 warning 及以上级别的告警，降低噪声。

执行安装：

# Install Falco via Helm helm repo add falcosecurity https://falcosecurity.github.io/charts helm install falco falcosecurity/falco \ --namespace falco-system --create-namespace \ -f falco-values.yaml

Step 2：编写自定义 Falco 逃逸检测规则

将以下规则保存到/etc/falco/rules.d/container_escape.yaml（Helm 挂载目录对应上文rules.d）：

# /etc/falco/rules.d/container_escape.yaml # Detect container escape via privileged container - rule: Container Escape via Privileged Mode desc: Detect attempts to escape container using privileged capabilities condition: > spawned_process and container and (proc.name in (nsenter, unshare, mount, umount, modprobe, insmod) or (proc.name = chroot and proc.args contains "/host")) output: > Container escape attempt via privileged operation (user=%user.name container=%container.name image=%container.image.repository command=%proc.cmdline pid=%proc.pid %container.info) priority: CRITICAL tags: [container, escape, T1611] # Detect Docker socket access from container - rule: Container Access to Docker Socket desc: Detect container reading/writing to Docker socket condition: > (open_read or open_write) and container and fd.name = /var/run/docker.sock output: > Docker socket accessed from container (user=%user.name container=%container.name image=%container.image.repository fd=%fd.name command=%proc.cmdline %container.info) priority: CRITICAL tags: [container, escape, docker_socket] # Detect sensitive proc filesystem access - rule: Container Access to Sensitive Proc Paths desc: Detect container accessing host-sensitive proc paths condition: > open_read and container and (fd.name startswith /proc/sysrq-trigger or fd.name startswith /proc/kcore or fd.name startswith /proc/kmsg or fd.name startswith /proc/kallsyms or fd.name startswith /sys/kernel) output: > Sensitive proc/sys access from container (user=%user.name container=%container.name path=%fd.name command=%proc.cmdline %container.info) priority: CRITICAL tags: [container, escape, proc_access] # Detect cgroup escape technique - rule: Container Cgroup Escape Attempt desc: Detect writing to cgroup release_agent (escape technique) condition: > open_write and container and (fd.name contains release_agent or fd.name contains notify_on_release) output: > Cgroup escape attempt detected (user=%user.name container=%container.name path=%fd.name command=%proc.cmdline %container.info) priority: CRITICAL tags: [container, escape, cgroup] # Detect kernel module loading from container - rule: Container Loading Kernel Module desc: Detect container attempting to load kernel modules condition: > spawned_process and container and (proc.name in (modprobe, insmod, rmmod) or (evt.type = init_module or evt.type = finit_module)) output: > Kernel module load attempt from container (user=%user.name container=%container.name command=%proc.cmdline %container.info) priority: CRITICAL tags: [container, escape, kernel_module] # Detect namespace manipulation - rule: Container Namespace Manipulation desc: Detect setns/unshare syscalls from container condition: > container and (evt.type = setns or evt.type = unshare) and not proc.name in (containerd-shim, runc) output: > Namespace manipulation from container (user=%user.name container=%container.name syscall=%evt.type command=%proc.cmdline %container.info) priority: CRITICAL tags: [container, escape, namespace] # Detect mount operations from container - rule: Container Mount Sensitive Filesystem desc: Detect container mounting host filesystems condition: > spawned_process and container and proc.name = mount and (proc.args contains "/dev/" or proc.args contains "proc" or proc.args contains "sysfs") output: > Sensitive mount operation from container (user=%user.name container=%container.name command=%proc.cmdline %container.info) priority: HIGH tags: [container, escape, mount]

七条规则的检测语义与优先级：

• Container Escape via Privileged Mode（CRITICAL）：命中nsenter/unshare/mount/modprobe/insmod等逃逸工具进程，或chroot /host型逃逸；
• Container Access to Docker Socket（CRITICAL）：容器内读写/var/run/docker.sock，对应 T1610（通过 Docker API 部署新容器实现逃逸）；
• Container Access to Sensitive Proc Paths（CRITICAL）：访问/proc/sysrq-trigger、/proc/kcore、/proc/kmsg、/proc/kallsyms、/sys/kernel；
• Container Cgroup Escape Attempt（CRITICAL）：写入 cgrouprelease_agent/notify_on_release，对应经典的 cgroup release_agent 逃逸技术；
• Container Loading Kernel Module（CRITICAL）：容器内调用modprobe/insmod/rmmod或init_module/finit_module系统调用；
• Container Namespace Manipulation（CRITICAL）：容器内调用setns/unshare（排除 containerd-shim、runc 等正常运行时代理进程，减少误报）；
• Container Mount Sensitive Filesystem（HIGH）：容器内对/dev/、proc、sysfs发起挂载。

每条规则都携带tags（含 MITRE ID）并在 output 中嵌入容器名、镜像、命令等上下文，方便与 Falco JSON 告警格式 对接。

Step 3：用 Seccomp Profile 收敛逃逸面

检测之外更推荐主动防御。seccomp 采用"白名单"思想：defaultAction设为SCMP_ACT_ERRNO（默认拒绝所有未显式放行的系统调用），仅放行应用必需的系统调用，并对逃逸相关系统调用执行SCMP_ACT_LOG（记录但不阻断，兼顾检测与兼容性）：

{ "defaultAction": "SCMP_ACT_ERRNO", "archMap": [ { "architecture": "SCMP_ARCH_X86_64", "subArchitectures": ["SCMP_ARCH_X86", "SCMP_ARCH_X32"] } ], "syscalls": [ { "names": [ "read", "write", "open", "close", "stat", "fstat", "lstat", "poll", "lseek", "mmap", "mprotect", "munmap", "brk", "rt_sigaction", "rt_sigprocmask", "ioctl", "access", "pipe", "select", "sched_yield", "dup", "dup2", "nanosleep", "getpid", "socket", "connect", "accept", "sendto", "recvfrom", "bind", "listen", "getsockname", "getpeername", "socketpair", "setsockopt", "getsockopt", "clone", "fork", "vfork", "execve", "exit", "wait4", "kill", "getuid", "getgid", "geteuid", "getegid", "epoll_create", "epoll_wait", "epoll_ctl", "epoll_create1", "futex", "set_tid_address", "set_robust_list", "openat", "newfstatat", "readlinkat", "fchownat", "clock_gettime", "clock_getres", "clock_nanosleep", "getrandom", "memfd_create", "statx", "rseq" ], "action": "SCMP_ACT_ALLOW" }, { "names": ["unshare", "setns", "mount", "umount2", "pivot_root", "init_module", "finit_module", "delete_module", "kexec_load", "kexec_file_load", "ptrace", "reboot", "swapon", "swapoff", "sethostname", "setdomainname", "keyctl", "bpf"], "action": "SCMP_ACT_LOG", "comment": "Log escape-relevant syscalls for detection" } ] }

值得注意的第二段列表：unshare、setns、mount、umount2、pivot_root、init_module、finit_module、delete_module、kexec_load、ptrace、keyctl、bpf等几乎覆盖了所有主流逃逸所需系统调用，选择"LOG 而非 DENY"可在不破坏正常业务的前提下为检测提供系统调用级证据。

Step 4：配置 auditd 审计规则

在/etc/audit/rules.d/container-escape.rules中添加：

# /etc/audit/rules.d/container-escape.rules # Monitor namespace operations -a always,exit -F arch=b64 -S setns -S unshare -k container_escape -a always,exit -F arch=b64 -S mount -S umount2 -k container_mount -a always,exit -F arch=b64 -S init_module -S finit_module -S delete_module -k kernel_module -a always,exit -F arch=b64 -S ptrace -k process_trace # Monitor sensitive paths -w /var/run/docker.sock -p rwxa -k docker_socket -w /proc/sysrq-trigger -p w -k sysrq -w /proc/kcore -p r -k kcore_read # Monitor container runtime -w /usr/bin/runc -p x -k container_runtime -w /usr/bin/containerd -p x -k container_runtime -w /usr/bin/docker -p x -k container_runtime

审计规则分为三组：系统调用审计（命名空间、挂载、内核模块、ptrace）、敏感路径写/读审计（docker socket、sysrq、kcore）、以及容器运行时二进制执行审计（runc/containerd/docker 被调用时记录，用于发现异常拉起容器运行时的行为）。这些-k标记与 agent.py 中parse_auditd_escape_events解析的 key 集合（container_escape、container_mount、kernel_module、docker_socket、process_trace）一一对应，可直接作为脚本输入。

Step 5：构建实时告警管道（Falcosidekick）

# Falcosidekick configuration for alert routing config: slack: webhookurl: "https://hooks.slack.com/services/xxx" minimumpriority: "critical" messageformat: | *Container Escape Alert* Rule: {{ .Rule }} Priority: {{ .Priority }} Output: {{ .Output }} elasticsearch: hostport: "https://elasticsearch:9200" index: "falco-alerts" minimumpriority: "warning" pagerduty: routingkey: "xxxx" minimumpriority: "critical"

告警分级路由策略：Slack/PagerDuty 仅在critical级别触发（逃逸类规则全部为 CRITICAL，恰好命中），Elasticsearch 记录warning及以上全部事件用于后续回溯分析。这也与 workflows.md 中"实时检测管道 → 告警 → 下游平台"的架构一致。

六、用仓库脚本落地检测：源码级解析

仓库在skills/detecting-container-escape-attempts/scripts/下提供了两个可直接运行的检测脚本，是上述规则体系的可执行化补充。

6.1 agent.py：告警解析与多源汇聚

agent.py 是一个命令行工具，聚合三路证据源并输出统一 JSON 报告：

python agent.py --falco-log /var/log/falco/events.json python agent.py --audit-log /var/log/audit/audit.log python agent.py --check-containers python agent.py --container-id abc123

核心逻辑：

• parse_falco_json：逐行解析 Falco JSON 日志，仅保留tags含escape或container的事件，抽取time/rule/priority/output/output_fields字段（与 Falco 的json_output配置配套使用）；
• parse_auditd_escape_events：按上文 auditd 规则中的 key 集合匹配 audit.log 行，提取时间戳、syscall、exe，统一标记为 CRITICAL；
• check_privileged_containers：遍历docker ps结果，用docker inspect检查Privileged、PidMode=host与Binds中是否包含/var/run/docker.sock，逐项输出privileged_mode、host_pid_namespace、docker_socket_mounted等风险标记；
• check_dangerous_capabilities：对指定容器执行docker inspect --format '{{.HostConfig.CapAdd}}'，与危险能力集合{SYS_ADMIN, SYS_PTRACE, NET_ADMIN, SYS_RAWIO, SYS_MODULE, DAC_READ_SEARCH}求交集。

脚本内置的ESCAPE_VECTORS与SENSITIVE_PATHS常量（agent.py 第 16-29 行）与 SKILL.md 中的规则、Falco 规则保持同一套检测口径，保证"规则告警"与"脚本复查"结论一致。

6.2 process.py：逃逸风险评估扫描器

process.py 是面向"逃逸面审计"的量化评估工具：它不为每个容器打分设限，而是给出0-10 的 risk_score与CRITICAL/HIGH/MEDIUM/LOW分级，并输出修复建议。

DANGEROUS_CAPABILITIES定义了能力风险权重（SYS_ADMIN=10、SYS_PTRACE=9、SYS_MODULE=10、SYS_RAWIO=8、NET_ADMIN=7、DAC_OVERRIDE=6、DAC_READ_SEARCH=5、MKNOD=4、NET_RAW=4、SYS_CHROOT=3），SENSITIVE_MOUNT_PATHS覆盖 docker.sock、containerd.sock、/proc/sysrq-trigger、/proc/kcore、/sys/fs/cgroup、/dev、/etc/shadow 等敏感路径。assess_escape_risk的评分模型如下：

输出示例（终值封顶 10）：

[CRITICAL] web-app-7f9c8 (score: 10/10) Image: nginx:1.25 - [CRITICAL] Privileged mode enabled Fix: Remove --privileged flag, use specific --cap-add - [CRITICAL] Host namespace: PidMode=host Fix: Remove host PidMode configuration ... SUMMARY: 12 containers scanned CRITICAL: 1 HIGH: 2 MEDIUM: 4 LOW: 5

6.3 Kubernetes Pod 逃逸面扫描

process.py 的scan_kubernetes_pods同样覆盖 K8s 场景，逐 Pod 检查：

• hostNetwork: true、hostPID: true（各 +7）；
• 容器securityContext.privileged: true（+10）；
• volumes中的hostPath是否命中SENSITIVE_MOUNT_PATHS（+8）。

当宿主机上没有 Docker 容器时，扫描器自动切换到 K8s 扫描模式，并将完整结果写入escape_risk_report.json；存在 CRITICAL 风险时进程以退出码 1 结束，便于接入 CI/告警网关。

七、验证命令

规则与脚本部署后，按以下命令验证检测链路是否工作：

# Test Falco rules with event generator kubectl run falco-event-generator \ --image=falcosecurity/event-generator \ --restart=Never \ -- run syscall --action PtraceAttachContainer # Check Falco alerts kubectl logs -n falco-system -l app.kubernetes.io/name=falco --tail=50 # Verify seccomp profile is loaded docker inspect --format '{{.HostConfig.SecurityOpt}}' <container-id> # Check audit logs for escape-related events ausearch -k container_escape --interpret

配合 Docker CLI 主动排查（详见 api-reference.md）：

# Check if container is privileged docker inspect --format='{{.HostConfig.Privileged}}' <container> # Check added capabilities docker inspect --format='{{.HostConfig.CapAdd}}' <container> # Check PID namespace mode docker inspect --format='{{.HostConfig.PidMode}}' <container> # Check volume mounts docker inspect --format='{{range .Mounts}}{{.Source}}:{{.Destination}} {{end}}' <container>

八、逃逸事件调查与处置流程

参考 workflows.md 提供的处置流程：

1. 告警分诊：确认容器、镜像、命名空间；判断容器是否特权；推断逃逸向量；
2. 立即遏制：活跃逃逸时kubectl delete pod <pod-name> -n <namespace>；节点失陷则kubectl cordon <node>并做网络隔离；
3. 取证收集：docker export <id> > container.tar保全容器文件系统；汇总 Falco 事件构建时间线；ps auxf检查宿主机上的新增进程；ausearch -k container_escape拉取审计记录；
4. 根因分析：容器是否特权、授予了哪些能力、是否挂载 Docker socket、利用了哪个漏洞；
5. 修复加固：修补内核/运行时漏洞、移除多余能力、应用 Pod Security Standards（PSS）restricted profile、更新 seccomp profile。

九、已知逃逸漏洞与合规参考

standards.md 整理了容器逃逸相关的重要 CVE（需结合运行时版本评估自身暴露面）：

同时该文档对照 NIST SP 800-190（Application Container Security Guide）的运行时安全要求：监控容器异常行为、检测宿主命名空间访问、对容器加载内核模块告警、以 seccomp 实施系统调用过滤——与本文搭建的检测体系一一对应。

十、评估模板：把检测能力固化为常态化流程

仓库的 template.md 提供了一份可直接复用的评估模板，建议按以下维度周期性审计：

• 环境信息：集群名、容器运行时（Docker/containerd/CRI-O）、内核版本、运行时检测工具、评估日期；
• 逃逸面清单：每个容器的 Privileged / Capabilities / Host NS / Docker Socket / 风险评分（0-10）；
• 已部署检测规则：命名空间操纵（Falco setns/unshare）、Docker socket 访问、内核模块加载、敏感 proc 访问、cgroup 逃逸、mount 操作（auditd）、二进制替换（FIM）等规则的部署状态；
• 发现与修复跟踪：P1/P2 分级、风险因子、评分、修复动作、责任人、验证状态。

这套"模板化审计 + 脚本化扫描 + 规则化检测"的组合，可让容器逃逸检测从一次性事件响应转化为持续的安全运营能力。

十一、参考资源

• 技能主文档：skills/detecting-container-escape-attempts/SKILL.md
• 逃逸面扫描器：skills/detecting-container-escape-attempts/scripts/process.py
• 告警解析 Agent：skills/detecting-container-escape-attempts/scripts/agent.py
• 评估模板：skills/detecting-container-escape-attempts/assets/template.md
• 标准与 CVE 参考：skills/detecting-container-escape-attempts/references/standards.md
• 工作流定义：skills/detecting-container-escape-attempts/references/workflows.md
• CLI 速查：skills/detecting-container-escape-attempts/references/api-reference.md
• MITRE ATT&CK 覆盖映射：mappings/mitre-attack/coverage-summary.md 与 mappings/attack-navigator-layer.json

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills