容器逃逸检测实战基于 Falco、Seccomp 与 auditd 的容器逃逸攻击检测指南【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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 ATTCK 覆盖已登记在仓库的 coverage-summary.mdContainer Escape / T1611与 attack-navigator-layer.json 中可将其作为检测覆盖率规划的参考依据。二、适用场景安全事件调查中需要判定是否发生了容器逃逸尝试为该领域构建检测规则或威胁狩猎查询SOC 分析人员需要结构化的处置流程验证现有安全监控对相关攻击技术的覆盖缺口。三、环境前提在开始部署检测能力前需确认以下前置条件Linux 宿主机内核5.10需支持 eBPFFalco 0.37已安装内核模块或 eBPF probe 驱动方式均可Docker Engine 或 containerd 运行时已配置auditd具备root 权限用于加载 eBPF / 内核模块。说明eBPF 驱动方式kind: ebpf或modern_ebpf可避免编译内核模块是较推荐的部署路径modern_ebpf需要内核 5.8。四、核心概念逃逸攻击面与检测分层4.1 常见容器逃逸向量向量技术说明MITRE ID特权容器Privileged挂载宿主机文件系统、加载内核模块T1611Docker socket 挂载从容器内部创建特权容器T1610内核漏洞利用CVE-2022-0185fsconfig、Dirty Pipe、runc 系列 CVET1068能力滥用CAP_SYS_ADMIN、CAP_SYS_PTRACE、CAP_NET_ADMINT1548敏感挂载/proc/sysrq-trigger、/proc/kcore、cgroup release_agentT1611命名空间逃逸通过 nsenter、unshare 进入宿主命名空间T1611符号链接/bind mount 逃逸通过 /proc/self/root 突破根目录边界T1611仓库的 standards.md 进一步明确了各技术的战术归属T1611Escape to Host提权战术、T1610Deploy Container执行战术、T1068Exploitation for Privilege Escalation以及 T1548.004能力滥用提权。4.2 与逃逸直接相关的危险 Linux 能力能力逃逸风险说明CAP_SYS_ADMIN严重挂载文件系统、命名空间操纵CAP_SYS_PTRACE严重ptrace 任意进程、读取内存CAP_NET_ADMIN高网络命名空间操纵CAP_SYS_MODULE严重加载内核模块CAP_SYS_RAWIO高原始 I/O 访问iopl/iopermCAP_DAC_OVERRIDE高绕过文件读写权限CAP_DAC_READ_SEARCH中绕过文件读权限CAP_MKNOD中创建设备文件4.3 五层检测体系系统调用监控Syscall monitoring——eBPF/内核模块实时捕获系统调用文件完整性File integrity——检测逃逸使能路径如 runc/containerd 二进制、敏感文件被篡改进程监控Process monitoring——跟踪进程创建与命名空间变更网络监控Network monitoring——检测容器到宿主机的异常连接审计日志Audit logging——利用 Linux auditd 审计能力与挂载操作。五、实战工作流五步搭建检测体系Step 1通过 Helm 部署 Falcofalco-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.kindebpf加载 eBPF probemodern_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.yamlStep 2编写自定义 Falco 逃逸检测规则将以下规则保存到/etc/falco/rules.d/container_escape.yamlHelm 挂载目录对应上文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 ModeCRITICAL命中nsenter/unshare/mount/modprobe/insmod等逃逸工具进程或chroot /host型逃逸Container Access to Docker SocketCRITICAL容器内读写/var/run/docker.sock对应 T1610通过 Docker API 部署新容器实现逃逸Container Access to Sensitive Proc PathsCRITICAL访问/proc/sysrq-trigger、/proc/kcore、/proc/kmsg、/proc/kallsyms、/sys/kernelContainer Cgroup Escape AttemptCRITICAL写入 cgrouprelease_agent/notify_on_release对应经典的 cgroup release_agent 逃逸技术Container Loading Kernel ModuleCRITICAL容器内调用modprobe/insmod/rmmod或init_module/finit_module系统调用Container Namespace ManipulationCRITICAL容器内调用setns/unshare排除 containerd-shim、runc 等正常运行时代理进程减少误报Container Mount Sensitive FilesystemHIGH容器内对/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 archb64 -S setns -S unshare -k container_escape -a always,exit -F archb64 -S mount -S umount2 -k container_mount -a always,exit -F archb64 -S init_module -S finit_module -S delete_module -k kernel_module -a always,exit -F archb64 -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统一标记为 CRITICALcheck_privileged_containers遍历docker ps结果用docker inspect检查Privileged、PidModehost与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_ADMIN10、SYS_PTRACE9、SYS_MODULE10、SYS_RAWIO8、NET_ADMIN7、DAC_OVERRIDE6、DAC_READ_SEARCH5、MKNOD4、NET_RAW4、SYS_CHROOT3SENSITIVE_MOUNT_PATHS覆盖 docker.sock、containerd.sock、/proc/sysrq-trigger、/proc/kcore、/sys/fs/cgroup、/dev、/etc/shadow 等敏感路径。assess_escape_risk的评分模型如下风险因子加分说明特权模式Privilegedtrue10拥有宿主机全量访问逃逸无门槛危险能力按上表3~10能力值越高越危险默认能力未 drop--cap-drop ALL未设置2保留默认 Linux 能力集合host 命名空间Network/PID/IPC7与宿主共享命名空间敏感路径挂载6~9docker.sock 挂载计 9其余 6root 用户运行3进程以 UID 0 运行未配置自定义 seccomp2使用默认/无 seccomp未配置 no-new-privileges2setuid 提权可能可写根文件系统1便于下载工具落地输出示例终值封顶 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: PidModehost Fix: Remove host PidMode configuration ... SUMMARY: 12 containers scanned CRITICAL: 1 HIGH: 2 MEDIUM: 4 LOW: 56.3 Kubernetes Pod 逃逸面扫描process.py 的scan_kubernetes_pods同样覆盖 K8s 场景逐 Pod 检查hostNetwork: true、hostPID: true各 7容器securityContext.privileged: true10volumes中的hostPath是否命中SENSITIVE_MOUNT_PATHS8。当宿主机上没有 Docker 容器时扫描器自动切换到 K8s 扫描模式并将完整结果写入escape_risk_report.json存在 CRITICAL 风险时进程以退出码 1 结束便于接入 CI/告警网关。七、验证命令规则与脚本部署后按以下命令验证检测链路是否工作# Test Falco rules with event generator kubectl run falco-event-generator \ --imagefalcosecurity/event-generator \ --restartNever \ -- run syscall --action PtraceAttachContainer # Check Falco alerts kubectl logs -n falco-system -l app.kubernetes.io/namefalco --tail50 # 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 提供的处置流程告警分诊确认容器、镜像、命名空间判断容器是否特权推断逃逸向量立即遏制活跃逃逸时kubectl delete pod pod-name -n namespace节点失陷则kubectl cordon node并做网络隔离取证收集docker export id container.tar保全容器文件系统汇总 Falco 事件构建时间线ps auxf检查宿主机上的新增进程ausearch -k container_escape拉取审计记录根因分析容器是否特权、授予了哪些能力、是否挂载 Docker socket、利用了哪个漏洞修复加固修补内核/运行时漏洞、移除多余能力、应用 Pod Security StandardsPSSrestricted profile、更新 seccomp profile。九、已知逃逸漏洞与合规参考standards.md 整理了容器逃逸相关的重要 CVE需结合运行时版本评估自身暴露面CVE组件描述CVSSCVE-2024-21626runc工作目录经 /proc/self/fd 泄漏逃逸8.6CVE-2022-0185Linux kernelfsconfig 堆溢出命名空间逃逸8.4CVE-2022-0847Linux kernelDirty Pipe 任意文件覆写7.8CVE-2021-22555Linux kernelNetfilter 堆越界容器逃逸7.8CVE-2020-15257containerd抽象 socket 命名空间逃逸5.2CVE-2019-5736runc二进制覆写宿主机代码执行8.6同时该文档对照 NIST SP 800-190Application 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告警解析 Agentskills/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.mdCLI 速查skills/detecting-container-escape-attempts/references/api-reference.mdMITRE ATTCK 覆盖映射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 ATTCK, 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
容器逃逸检测实战：基于 Falco、Seccomp 与 auditd 的容器逃逸攻击检测指南
容器逃逸检测实战基于 Falco、Seccomp 与 auditd 的容器逃逸攻击检测指南【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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 ATTCK 覆盖已登记在仓库的 coverage-summary.mdContainer Escape / T1611与 attack-navigator-layer.json 中可将其作为检测覆盖率规划的参考依据。二、适用场景安全事件调查中需要判定是否发生了容器逃逸尝试为该领域构建检测规则或威胁狩猎查询SOC 分析人员需要结构化的处置流程验证现有安全监控对相关攻击技术的覆盖缺口。三、环境前提在开始部署检测能力前需确认以下前置条件Linux 宿主机内核5.10需支持 eBPFFalco 0.37已安装内核模块或 eBPF probe 驱动方式均可Docker Engine 或 containerd 运行时已配置auditd具备root 权限用于加载 eBPF / 内核模块。说明eBPF 驱动方式kind: ebpf或modern_ebpf可避免编译内核模块是较推荐的部署路径modern_ebpf需要内核 5.8。四、核心概念逃逸攻击面与检测分层4.1 常见容器逃逸向量向量技术说明MITRE ID特权容器Privileged挂载宿主机文件系统、加载内核模块T1611Docker socket 挂载从容器内部创建特权容器T1610内核漏洞利用CVE-2022-0185fsconfig、Dirty Pipe、runc 系列 CVET1068能力滥用CAP_SYS_ADMIN、CAP_SYS_PTRACE、CAP_NET_ADMINT1548敏感挂载/proc/sysrq-trigger、/proc/kcore、cgroup release_agentT1611命名空间逃逸通过 nsenter、unshare 进入宿主命名空间T1611符号链接/bind mount 逃逸通过 /proc/self/root 突破根目录边界T1611仓库的 standards.md 进一步明确了各技术的战术归属T1611Escape to Host提权战术、T1610Deploy Container执行战术、T1068Exploitation for Privilege Escalation以及 T1548.004能力滥用提权。4.2 与逃逸直接相关的危险 Linux 能力能力逃逸风险说明CAP_SYS_ADMIN严重挂载文件系统、命名空间操纵CAP_SYS_PTRACE严重ptrace 任意进程、读取内存CAP_NET_ADMIN高网络命名空间操纵CAP_SYS_MODULE严重加载内核模块CAP_SYS_RAWIO高原始 I/O 访问iopl/iopermCAP_DAC_OVERRIDE高绕过文件读写权限CAP_DAC_READ_SEARCH中绕过文件读权限CAP_MKNOD中创建设备文件4.3 五层检测体系系统调用监控Syscall monitoring——eBPF/内核模块实时捕获系统调用文件完整性File integrity——检测逃逸使能路径如 runc/containerd 二进制、敏感文件被篡改进程监控Process monitoring——跟踪进程创建与命名空间变更网络监控Network monitoring——检测容器到宿主机的异常连接审计日志Audit logging——利用 Linux auditd 审计能力与挂载操作。五、实战工作流五步搭建检测体系Step 1通过 Helm 部署 Falcofalco-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.kindebpf加载 eBPF probemodern_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.yamlStep 2编写自定义 Falco 逃逸检测规则将以下规则保存到/etc/falco/rules.d/container_escape.yamlHelm 挂载目录对应上文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 ModeCRITICAL命中nsenter/unshare/mount/modprobe/insmod等逃逸工具进程或chroot /host型逃逸Container Access to Docker SocketCRITICAL容器内读写/var/run/docker.sock对应 T1610通过 Docker API 部署新容器实现逃逸Container Access to Sensitive Proc PathsCRITICAL访问/proc/sysrq-trigger、/proc/kcore、/proc/kmsg、/proc/kallsyms、/sys/kernelContainer Cgroup Escape AttemptCRITICAL写入 cgrouprelease_agent/notify_on_release对应经典的 cgroup release_agent 逃逸技术Container Loading Kernel ModuleCRITICAL容器内调用modprobe/insmod/rmmod或init_module/finit_module系统调用Container Namespace ManipulationCRITICAL容器内调用setns/unshare排除 containerd-shim、runc 等正常运行时代理进程减少误报Container Mount Sensitive FilesystemHIGH容器内对/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 archb64 -S setns -S unshare -k container_escape -a always,exit -F archb64 -S mount -S umount2 -k container_mount -a always,exit -F archb64 -S init_module -S finit_module -S delete_module -k kernel_module -a always,exit -F archb64 -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统一标记为 CRITICALcheck_privileged_containers遍历docker ps结果用docker inspect检查Privileged、PidModehost与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_ADMIN10、SYS_PTRACE9、SYS_MODULE10、SYS_RAWIO8、NET_ADMIN7、DAC_OVERRIDE6、DAC_READ_SEARCH5、MKNOD4、NET_RAW4、SYS_CHROOT3SENSITIVE_MOUNT_PATHS覆盖 docker.sock、containerd.sock、/proc/sysrq-trigger、/proc/kcore、/sys/fs/cgroup、/dev、/etc/shadow 等敏感路径。assess_escape_risk的评分模型如下风险因子加分说明特权模式Privilegedtrue10拥有宿主机全量访问逃逸无门槛危险能力按上表3~10能力值越高越危险默认能力未 drop--cap-drop ALL未设置2保留默认 Linux 能力集合host 命名空间Network/PID/IPC7与宿主共享命名空间敏感路径挂载6~9docker.sock 挂载计 9其余 6root 用户运行3进程以 UID 0 运行未配置自定义 seccomp2使用默认/无 seccomp未配置 no-new-privileges2setuid 提权可能可写根文件系统1便于下载工具落地输出示例终值封顶 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: PidModehost Fix: Remove host PidMode configuration ... SUMMARY: 12 containers scanned CRITICAL: 1 HIGH: 2 MEDIUM: 4 LOW: 56.3 Kubernetes Pod 逃逸面扫描process.py 的scan_kubernetes_pods同样覆盖 K8s 场景逐 Pod 检查hostNetwork: true、hostPID: true各 7容器securityContext.privileged: true10volumes中的hostPath是否命中SENSITIVE_MOUNT_PATHS8。当宿主机上没有 Docker 容器时扫描器自动切换到 K8s 扫描模式并将完整结果写入escape_risk_report.json存在 CRITICAL 风险时进程以退出码 1 结束便于接入 CI/告警网关。七、验证命令规则与脚本部署后按以下命令验证检测链路是否工作# Test Falco rules with event generator kubectl run falco-event-generator \ --imagefalcosecurity/event-generator \ --restartNever \ -- run syscall --action PtraceAttachContainer # Check Falco alerts kubectl logs -n falco-system -l app.kubernetes.io/namefalco --tail50 # 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 提供的处置流程告警分诊确认容器、镜像、命名空间判断容器是否特权推断逃逸向量立即遏制活跃逃逸时kubectl delete pod pod-name -n namespace节点失陷则kubectl cordon node并做网络隔离取证收集docker export id container.tar保全容器文件系统汇总 Falco 事件构建时间线ps auxf检查宿主机上的新增进程ausearch -k container_escape拉取审计记录根因分析容器是否特权、授予了哪些能力、是否挂载 Docker socket、利用了哪个漏洞修复加固修补内核/运行时漏洞、移除多余能力、应用 Pod Security StandardsPSSrestricted profile、更新 seccomp profile。九、已知逃逸漏洞与合规参考standards.md 整理了容器逃逸相关的重要 CVE需结合运行时版本评估自身暴露面CVE组件描述CVSSCVE-2024-21626runc工作目录经 /proc/self/fd 泄漏逃逸8.6CVE-2022-0185Linux kernelfsconfig 堆溢出命名空间逃逸8.4CVE-2022-0847Linux kernelDirty Pipe 任意文件覆写7.8CVE-2021-22555Linux kernelNetfilter 堆越界容器逃逸7.8CVE-2020-15257containerd抽象 socket 命名空间逃逸5.2CVE-2019-5736runc二进制覆写宿主机代码执行8.6同时该文档对照 NIST SP 800-190Application 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告警解析 Agentskills/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.mdCLI 速查skills/detecting-container-escape-attempts/references/api-reference.mdMITRE ATTCK 覆盖映射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 ATTCK, 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
