企业官网建设流程全解析

容器逃逸检测实战指南：基于 Falco、auditd 与 seccomp 的纵深防御体系（Anthropic-Cybersecurity-Skills）

【免费下载链接】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

容器逃逸是攻击者突破容器隔离、直达宿主机或其他容器的关键特权提升技术，对应 MITRE ATT&CK 中的 T1611（Escape to Host）等手法。本指南以skills/detecting-container-escape-attempts技能包为核心，系统讲解逃逸向量识别、Falco 运行时检测规则编写、seccomp 白名单收敛、auditd 审计规则配置、告警管道搭建，以及配套的 Python 风险扫描脚本agent.py与process.py，读完即可在 Docker/Kubernetes 环境中落地一套"检测—告警—应急—修复"的完整闭环。

技能包概览与适用场景

detecting-container-escape-attempts技能定位于容器安全（container-security）子域，其核心目标是：通过监控命名空间操纵、能力滥用、内核漏洞利用、敏感挂载路径与异常系统调用，检测攻击者从容器隔离环境中逃逸的行为。技能包遵循 agentskills.io 标准，映射了多个安全框架：

• MITRE ATT&CK：T1610（Deploy Container）、T1611（Escape to Host）、T1609（Container Administration Command）、T1525（Implant Container Image）；
• NIST CSF 2.0：PR.PS-01、PR.IR-01、ID.AM-08、DE.CM-01；
• D3FEND：Platform Monitoring、Process Analysis 等检测类技术。

该技能在以下场景中使用价值最高：

• 安全事件调查中需要判断是否发生容器逃逸尝试；
• 为容器运行时编写检测规则或构建威胁狩猎查询；
• SOC 分析师需要标准化的容器逃逸分析流程；
• 验证组织对相关攻击技术的监控覆盖度。

技能包文件结构（位于 skills/detecting-container-escape-attempts）由主文档 SKILL.md、三份参考文档 api-reference.md、workflows.md、standards.md，以及两个可直接运行的脚本 agent.py 与 process.py 组成。

环境前提（Prerequisites）

在部署检测体系前，需要满足以下运行环境：

常见容器逃逸向量与 MITRE 映射

逃逸向量速查表

api-reference.md 与 SKILL.md 共同给出了完整的逃逸向量清单：

关键能力与逃逸风险

standards.md 中完整枚举了与逃逸直接相关的危险 Linux 能力（Capability）：

此外，standards.md 还汇总了已知的容器逃逸 CVE，可作为规则编写与漏洞修补的优先级依据：

五层检测模型

SKILL.md 将容器逃逸检测划分为五个层次，本技能的全部规则与脚本均围绕这五层展开：

1. 系统调用监控——通过 eBPF/内核模块实时捕获 syscall；
2. 文件完整性——检测逃逸关键路径的修改；
3. 进程监控——跟踪进程创建与命名空间变更；
4. 网络监控——检测容器到宿主机的连接；
5. 审计日志——使用 Linux auditd 记录能力与挂载操作。

检测层的核心指标（Key Indicators）

api-reference.md 提供了两条关键的宿主机侧检测手段。

Docker CLI 检查命令

用于快速判断单个容器是否具备逃逸条件：

# 检查容器是否为特权模式 docker inspect --format='{{.HostConfig.Privileged}}' <container> # 检查附加的能力 docker inspect --format='{{.HostConfig.CapAdd}}' <container> # 检查 PID 命名空间模式 docker inspect --format='{{.HostConfig.PidMode}}' <container> # 检查卷挂载 docker inspect --format='{{range .Mounts}}{{.Source}}:{{.Destination}} {{end}}' <container>

Linux 审计规则模板

以下规则可写入/etc/audit/rules.d/container-escape.rules，覆盖命名空间、挂载、内核模块与 Docker socket 四类关键操作：

-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 -k kernel_module -w /var/run/docker.sock -p rwxa -k docker_socket

SKILL.md 第 4 步对上述模板做了进一步扩展，增加了delete_module、ptrace、敏感路径（/proc/sysrq-trigger、/proc/kcore）与容器运行时二进制（runc、containerd、docker）的监控，详见下文"审计规则"小节。

Falco JSON 告警格式

Falco 以 JSON 输出告警时，字段结构如下（这也是脚本agent.py解析的输入格式）：

{ "time": "2024-01-15T10:30:00.000Z", "rule": "Container Escape via Privileged Mode", "priority": "Critical", "output": "Container escape attempt...", "output_fields": { "container.name": "attacker-pod", "container.image.repository": "alpine", "proc.cmdline": "nsenter -t 1 -m -u -i -n" }, "tags": ["container", "escape", "T1611"] }

第一步：部署 Falco 运行时检测

Helm 安装 Falco

SKILL.md 提供了基于 Helm 的 Falco 部署方式，配置要点包括：使用 eBPF 驱动（内核 5.8+ 可选用modern_ebpf）、启用 JSON 输出、对接 falcosidekick 的 HTTP 输出、开启 gRPC 接口：

# 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

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

第二步：编写自定义 Falco 逃逸检测规则

SKILL.md 提供了 7 条可直接部署到/etc/falco/rules.d/container_escape.yaml的自定义规则，覆盖本技能的核心逃逸向量。规则条件中的spawned_process、container等为 Falco 内置宏与过滤字段，proc.name、fd.name、evt.type为系统事件字段。

规则 1：特权模式逃逸

检测容器内执行 nsenter、unshare、mount、umount、modprobe、insmod 等特权操作，以及chroot /host的 chroot 逃逸行为：

- 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]

规则 2：Docker socket 访问

检测容器内对/var/run/docker.sock的读写——这是攻击者从容器内部署新特权容器（T1610）的前置动作：

- 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]

规则 3：敏感 proc 路径访问

检测容器访问/proc/sysrq-trigger、/proc/kcore、/proc/kmsg、/proc/kallsyms以及/sys/kernel等宿主机敏感路径：

- 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]

规则 4：cgroup release_agent 逃逸

cgroup 逃逸是经典手法：攻击者向 cgroup 的release_agent写入宿主机命令路径并触发执行。该规则监控对release_agent与notify_on_release的写入：

- 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]

规则 5：内核模块加载

检测容器内执行 modprobe/insmod/rmmod 或触发init_module/finit_module系统调用（对应 CAP_SYS_MODULE 滥用）：

- 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]

规则 6：命名空间操纵

检测容器内的setns/unshare系统调用，并排除 runc、containerd-shim 等合法运行时进程：

- 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]

规则 7：敏感文件系统挂载

检测容器内mount宿主机设备与文件系统（/dev/、proc、sysfs）：

- 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]

第三步：用 seccomp 白名单收敛逃逸面

除了"事后检测"，SKILL.md 还给出了"事前防御"的 seccomp 配置。以下 JSON 配置采用默认拒绝（SCMP_ACT_ERRNO）策略，显式放行常规业务所需的系统调用，同时对逃逸高危系统调用（unshare、setns、mount、pivot_root、init_module、ptrace、bpf 等）设置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" } ] }

配置说明：白名单部分覆盖了通用容器运行所需的基础系统调用族（文件 I/O、socket 网络、进程管理、内存映射、定时与随机数等）；SCMP_ACT_LOG分组则是检测与防御的折中——高危调用被记录但暂不阻断，便于先评估业务兼容性后再收紧为SCMP_ACT_ERRNO。该策略与 NIST SP 800-190 中"使用 seccomp 实现系统调用过滤"的容器运行时安全要求一致。

第四步：扩展 auditd 审计规则

SKILL.md 在 api-reference 基础模板之上，给出了一套更完整的/etc/audit/rules.d/container-escape.rules，分为三类监控：

# 监控命名空间操作 -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 # 监控敏感路径 -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 # 监控容器运行时 -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

其中-w ... -p x对 runc/containerd/docker 二进制执行监控（container_runtimekey）还能覆盖 runc 类二进制覆写逃逸（如 CVE-2019-5736）的前置迹象，与 template.md 中"Binary replacement / FIM"检测项相互呼应。

第五步：实时告警管道

SKILL.md 给出了 falcosidekick 的告警路由配置，将 Falco 告警分发到 Slack、Elasticsearch 与 PagerDuty：

# 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以上告警（用于实时人工响应），Elasticsearch 从warning开始全量落库（用于事后检索与告警疲劳管理）。该配置对应 workflows.md 中"实时检测管道"工作流：容器系统调用 → eBPF/内核模块 → Falco 引擎 → 规则评估 → 告警生成 → Slack/SIEM/PagerDuty。

验证命令与规则测试

规则部署后，通过官方事件生成器与检查命令验证检测是否生效：

# 使用 Falco 事件生成器测试规则 kubectl run falco-event-generator \ --image=falcosecurity/event-generator \ --restart=Never \ -- run syscall --action PtraceAttachContainer # 查看 Falco 告警 kubectl logs -n falco-system -l app.kubernetes.io/name=falco --tail=50 # 验证 seccomp profile 已加载 docker inspect --format '{{.HostConfig.SecurityOpt}}' <container-id> # 检索审计日志中的逃逸事件 ausearch -k container_escape --interpret

脚本化检测：agent.py 与 process.py

技能包提供了两个可独立运行的 Python 脚本，将上述检测逻辑工程化，是"命令行检查 + 规则编写"之外的第三种自动化手段。

agent.py：Falco 日志与 auditd 解析

agent.py 是一个命令行检测 Agent，支持四类输入，对应 api-reference.md 的 CLI 用法：

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

其核心实现逻辑如下：

• ESCAPE_VECTORS常量表（agent.py）：将 nsenter/unshare/mount/modprobe/insmod/chroot 映射为严重级别与 MITRE 编号，例如nsenter→ CRITICAL/T1611"命名空间逃逸"；
• parse_falco_json()（agent.py）：逐行解析 Falco JSON，仅保留 tags 含escape或container的告警，并提取 time/rule/priority/output/output_fields 字段——与上文 Falco JSON 告警格式一一对应；
• parse_auditd_escape_events()（agent.py）：按container_escape、container_mount、kernel_module、docker_socket、process_trace五个审计 key 过滤 auditd 日志，用正则提取时间戳、系统调用名与可执行文件路径；
• check_privileged_containers()（agent.py）：枚举运行容器并 inspect，标记privileged_mode、host_pid_namespace、docker_socket_mounted三类风险，命中特权模式判为 CRITICAL；
• check_dangerous_capabilities()（agent.py）：对比CapAdd与危险能力集合 {SYS_ADMIN, SYS_PTRACE, NET_ADMIN, SYS_RAWIO, SYS_MODULE, DAC_READ_SEARCH}。

最终输出统一为带timestamp、findings、total_findings的 JSON 报告。

process.py：全量逃逸面风险评估

process.py 是一个打分式的逃逸风险评估扫描器，实现了 workflows.md 中"主动逃逸面审计"工作流的自动化版本。

风险评分机制：DANGEROUS_CAPABILITIES（process.py）为每个危险能力赋予 3–10 分的权重（如 SYS_ADMIN=10、SYS_PTRACE=9、SYS_MODULE=10）；assess_escape_risk() 累加以下维度的分值，最终封顶 10 分，并通过EscapeRisk.risk_level属性映射为 CRITICAL（≥8）/ HIGH（≥5）/ MEDIUM（≥3）/ LOW：

Kubernetes 支持：当无 Docker 容器时，scan_kubernetes_pods() 会自动切换为kubectl get pods -A -o json扫描，检查hostNetwork、hostPID、securityContext 的privileged字段以及敏感hostPath卷（对照SENSITIVE_MOUNT_PATHS列表）。

输出：终端打印按风险分数降序的评估结果与统计摘要，同时生成escape_risk_report.json；存在 CRITICAL 风险时进程以退出码 1 结束，便于接入 CI/CD 或定时任务。运行方式：

python process.py

逃逸事件的应急响应流程

workflows.md 的"逃逸事件调查"工作流给出了告警触发后的五步操作序列：

Step 1: 告警分流（Triage） - 识别容器、镜像、命名空间 - 检查容器是否特权 - 判断尝试的逃逸向量 Step 2: 立即隔离（Containment） - kubectl delete pod <pod-name> -n <namespace>（活跃逃逸时） - kubectl cordon <node>（节点已被入侵时） - 对节点做网络隔离 Step 3: 取证收集（Forensics） - 导出容器文件系统：docker export <id> > container.tar - 收集 Falco 事件构建时间线 - 导出进程树：ps auxf - 检查宿主机是否出现新进程 - 审计日志：ausearch -k container_escape Step 4: 根因分析（Root Cause） - 容器是否特权？ - 授予了哪些能力？ - 是否挂载了 Docker socket？ - 利用了哪个漏洞？ Step 5: 修复（Remediation） - 修补内核/运行时漏洞 - 移除多余能力 - 应用 PSS restricted 配置 - 更新 seccomp 配置

评估模板：将检测落地为可追踪的清单

template.md 提供了可直接复用的评估模板，包含四张表格：

1. 环境信息表：记录集群名称、容器运行时（Docker/containerd/CRI-O）、内核版本、运行时检测工具（Falco/Sysdig/Tetragon）、评估日期；
2. 逃逸面清单：逐容器登记 Privileged、Capabilities、Host NS、Docker Socket 与风险分数（/10）；
3. 检测规则部署表：按"命名空间操纵 / Docker socket 访问 / 内核模块加载 / 敏感 proc 访问 / cgroup 逃逸 / 挂载操作（auditd）/ 二进制替换（FIM）"逐项核对部署状态；
4. 发现与修复追踪表：按 P1/P2 优先级记录风险因素、分数与修复动作，跟踪负责人、状态与验证结果。

该模板与process.py的评分体系互补：模板用于人工评估归档，脚本用于自动化持续扫描。

检测覆盖率参考

在 mappings/attack-navigator-layer.json 中，detecting-container-escape-attempts与detecting-container-escape-with-falco-rules共同覆盖了 MITRE ATT&CK 容器相关技术的检测层，并与detecting-privilege-escalation-in-kubernetes-pods、detecting-t1548-abuse-elevation-control-mechanism等技能形成能力互补（见 coverage-summary.md）。在组织监控覆盖度验证或威胁建模时，可将本技能作为容器逃逸检测能力的核心参考项。

小结：纵深防御的落地组合

完整的容器逃逸检测不是单一工具，而是"收敛 + 检测 + 自动化"的组合：

1. 事前收敛：seccomp 默认拒绝 + 高危 syscall 记录、最小能力（--cap-drop ALL）、no-new-privileges、只读根文件系统、非 root 运行，从配置层面压缩逃逸面；
2. 事中检测：Falco 7 条自定义规则覆盖特权操作、Docker socket、敏感 proc、cgroup、内核模块、命名空间与挂载向量；auditd 规则提供不依赖 Falco 的内核级审计兜底；
3. 事后自动化：agent.py解析 Falco/auditd 日志与容器配置，process.py持续评分逃逸面并生成报告；falcosidekick 将 CRITICAL 告警实时推送至 Slack/PagerDuty，warning 级别落库 SIEM。

所有配置与脚本均可在技能包目录中直接查看与复用，并可与 Kubernetes Pod Security Standards（PSS）restricted profile 结合，形成从容器编排到内核 syscall 的全链路防护。

【免费下载链接】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