Anthropic-Cybersecurity-Skills 容器逃逸检测工作流实战：实时检测流水线、应急调查与攻击面审计

Anthropic-Cybersecurity-Skills 容器逃逸检测工作流实战实时检测流水线、应急调查与攻击面审计【免费下载链接】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导读容器逃逸Container Escape是攻击者突破容器隔离、直取宿主机或横向渗透其他容器的关键攻击链环节。本指南以 Anthropic-Cybersecurity-Skills 仓库中 detecting-container-escape-attempts 技能的references/workflows.md为骨架完整拆解三条实战工作流实时检测流水线、逃逸事件应急调查、主动逃逸攻击面审计。读完本文你将掌握基于 Falco eBPF auditd seccomp 的全栈检测方案、事件调查的标准作业流程以及可落地的容器逃逸风险评分模型并能在 Docker 与 Kubernetes 环境中直接执行验证。工作流全景三条主线构成容器逃逸检测闭环references/workflows.md定义了三条互补的工作流分别对应检测Detect、响应Respond、预防Prevent三个环节形成闭环工作流定位输入输出Workflow 1实时检测流水线检测容器系统调用流Slack/SIEM/PagerDuty 告警Workflow 2逃逸事件调查响应告警/审计日志遏制动作 根因 修复Workflow 3主动攻击面审计预防全量容器清单每容器风险评分与修复建议该技能在 SKILL.md 的 YAML frontmatter 中完成了多框架映射可作为威胁建模与合规依据MITRE ATTCKT1610、T1611、T1609、T1525、NIST CSF 2.0PR.PS-01、PR.IR-01、ID.AM-08、DE.CM-01以及 MITRE D3FENDPlatform Monitoring、Process Analysis 等防御技术。执行三条工作流的前提环境为Linux 内核 5.10eBPF 支持、Falco 0.37、Docker Engine 或 containerd 运行时、已配置的 auditd以及 root 权限用于加载 eBPF/内核模块。Workflow 1实时检测流水线实时检测是整个逃逸防线的前哨核心思想是一切逃逸行为最终都会以异常系统调用的形式落到内核层因此在 syscall 层做无死角监控再交给规则引擎判定是最可靠的检测路径。流水线架构与数据流向workflows.md 给出了完整的流水线拓扑[Container Syscall] -- [eBPF/Kernel Module] -- [Falco Engine] | | v v Syscall captured Rule evaluation (setns, mount, | ptrace, etc.) -------------------------- | | v v Match found No match | (normal) v [Alert Generated] | ------------------ | | | v v v Slack SIEM PagerDuty Alert Log Incident数据流分三段理解采集层eBPF 探针或内核模块在内核态捕获容器发出的全部系统调用重点盯防setns、mount、ptrace、unshare、init_module等逃逸高危 syscall判定层Falco Engine 将捕获事件与规则库逐条比对命中即生成结构化告警未命中视为正常行为分发层告警按优先级路由到 Slack即时通知、SIEM/Elasticsearch留存检索、PagerDuty事件升级实现 SOC 全链路响应。SKILL.md 将这套流水线的检测能力细化为五个层次可作为监控覆盖度的自检清单Syscall monitoring系统调用监控eBPF/内核模块实时捕获系统调用File integrity文件完整性检测逃逸使能路径如/proc/sysrq-trigger是否被篡改Process monitoring进程监控跟踪进程创建与命名空间变更Network monitoring网络监控检测容器到宿主机方向的异常连接Audit logging审计日志Linux auditd 记录 capability 与 mount 操作。部署 Falco 运行时检测通过 Helm 将 Falco 部署到 Kubernetes核心配置项如下falco-values.yamlfalco: driver: kind: ebpf # 或 modern_ebpf内核 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: warninghelm repo add falcosecurity https://falcosecurity.github.io/charts helm install falco falcosecurity/falco \ --namespace falco-system --create-namespace \ -f falco-values.yaml参数要点driver.kind决定内核事件采集方式ebpf需内核 5.10modern_ebpf对内核 5.8 性能更优json_output必须开启——Workflow 2 中脚本解析依赖 JSON 结构化输出http_output.url指向 falcosidekick 服务用于把告警转发给 Slack/SIEM/PagerDutypriority: warning设定全局告警门槛。定制 Falco 逃逸检测规则workflows.md 的实时流水线强调规则评估环节其具体规则集合定义在 SKILL.md 中/etc/falco/rules.d/container_escape.yaml。这八条规则与 Workflow 1 的流水线直接联动覆盖了逃逸向量全谱系# 检测通过特权容器逃逸 - 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] # 检测容器访问 Docker Socket - 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] # 检测敏感 proc 文件系统访问 - 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] # 检测 cgroup 逃逸技术 - 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] # 检测容器加载内核模块 - 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] # 检测命名空间操纵 - 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] # 检测容器 mount 操作 - 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]这些规则的tags字段同时携带逃逸语义escape、container与 MITRE 编号T1611便于后续脚本过滤和威胁情报关联。仓库配套的 agent.py 在 ESCAPE_VECTORS 中维护了与之对应的逃逸向量字典——nsenter、unshare、mount、modprobe、insmod、chroot并各自标注了 CRITICAL/HIGH 严重级别与 MITRE T1611 映射恰好是这套规则的代码化镜像印证了syscall 特征 → 规则判定 → 告警的实现闭环。告警路由与事件消费告警生成后由 Falcosidekick 按优先级分发falcosidekick配置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分级策略值得注意critical 级同时推送 Slack 与 PagerDuty 触发人工响应warning 级仅写入 Elasticsearch 供事后检索避免告警风暴淹没关键事件。若想将 Falco JSON 日志离线批量解析可借助 agent.pypython agent.py --falco-log /var/log/falco/events.json其 parse_falco_json 函数逐行读取 JSON通过tags中包含escape或container过滤出逃逸相关告警并抽取time、rule、priority、output、output_fields五个字段生成结构化发现。Falco JSON 告警的标准字段格式定义在 api-reference.md示例中的output_fields会给出container.name、container.image.repository、proc.cmdline这正是 Workflow 2 分流阶段所需的全部上下文。Workflow 2逃逸事件调查当 Workflow 1 命中告警后立即进入事件调查流程。workflows.md 将其划分为五个标准步骤兼顾遏制时效与取证严谨性。Step 1告警分流Triage识别涉及的容器、镜像、命名空间检查容器是否为特权模式docker inspect --format{{.HostConfig.Privileged}} container判断攻击者尝试的逃逸向量nsenter 命名空间逃逸、cgroup release_agent、内核漏洞利用等。Step 2即时遏制Containment若逃逸正在发生kubectl delete pod pod-name -n namespace立即摘除 Pod若节点已失陷kubectl cordon node阻止新 Pod 调度并进行网络隔离遏制动作需与取证采集配合避免在取证前销毁关键证据。Step 3取证采集Forensics取证目标是在不污染证据的前提下固化容器内外的事实快照固化容器文件系统docker export id container.tar收集 Falco 事件用于时间线重建对应 Workflow 1 的 Elasticsearch 索引falco-alerts转储进程树ps auxf重点排查宿主侧是否出现新进程逃逸成功的第一信号审计日志检索ausearch -k container_escape。审计规则在 SKILL.md 中定义部署于/etc/audit/rules.d/container-escape.rules用-k打上审计键与ausearch查询键一一对应# 监控命名空间操作 -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 # 监控敏感路径 -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_runtimeagent.py 提供了审计日志的自动化解析入口python agent.py --audit-log /var/log/audit/audit.log其 parse_auditd_escape_events 函数按container_escape、container_mount、kernel_module、docker_socket、process_trace五个审计键过滤原始日志并用正则抽取msgaudit(...)时间戳、syscall系统调用名与exe...可执行文件路径输出结构化事件供时间线重建。Step 4根因分析Root Cause Analysis按以下问题链排查逃逸的根本成因容器是否以特权模式运行--privileged授予了哪些危险 capabilities--cap-add是否挂载了 Docker socket/var/run/docker.sock利用了哪个具体漏洞内核 CVE 或容器运行时 CVEStep 5修复加固Remediation修补内核/运行时漏洞参考下文 CVE 清单移除过度授予的 capabilities应用 Pod Security StandardsPSS的 restricted 配置档更新 seccomp 配置档。seccomp 是逃逸前最后一道闸门。SKILL.md 给出的默认拒绝SCMP_ACT_ERRNO 白名单放行 高危 syscall 仅记录SCMP_ACT_LOG三段式 profile既保证业务可用又让逃逸必经的unshare/setns/mount/init_module等调用被完整记录{ 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 } ] }这个设计体现纵深防御思想即使攻击者绕过 Falco 监控例如利用 0dayseccomp 的SCMP_ACT_LOG也会把逃逸路径上的 syscall 记录到审计日志为事后归因保留证据。Workflow 3主动逃逸攻击面审计前两条工作流是被动响应第三条则是前置防御——在攻击发生前系统性地盘点所有容器的逃逸暴露面。workflows.md 给出流程骨架[Inventory all containers] -- [Check for escape risk factors] | ---------------------- | | | v v v Privileged? Docker sock? Host NS? CAP_SYS_ADMIN? mounted? hostPID? | | | ---------------------- | v [Risk Score per container] | ------------------ | | v v HIGH risk LOW risk Remediate Monitor immediately continuously逃逸风险因子清单审计核心是四类风险因子SKILL.md 中给出了各因子的 MITRE 映射向量技术MITRE ID特权容器挂载宿主机文件系统、加载内核模块T1611Docker socket 挂载从容器内创建特权容器T1610内核漏洞利用CVE-2022-0185fsconfig、Dirty Pipe、runc CVEsT1068Capability 滥用CAP_SYS_ADMIN、CAP_SYS_PTRACE、CAP_NET_ADMINT1548敏感挂载/proc/sysrq-trigger、/proc/kcore、cgroup release_agentT1611命名空间逃逸nsenter、unshare 进入宿主命名空间T1611符号链接/bind 挂载经 /proc/self/root 逃逸T1611关于危险 capability 的判定standards.md 给出了分级依据CAP_SYS_ADMIN可挂载文件系统、管理 cgroup、CAP_SYS_PTRACE可跟踪任意进程、CAP_SYS_MODULE可加载内核模块为 Critical 级CAP_NET_ADMIN、CAP_SYS_RAWIO、CAP_DAC_OVERRIDE为 High 级CAP_DAC_READ_SEARCH、CAP_MKNOD为 Medium 级。风险评分模型的源码级实现workflows.md 的Risk Score per container落地为 process.py 中的量化评分器可直接运行python process.py其评分逻辑assess_escape_risk为每个风险因子赋予权重并累加上限 10 分映射为四级风险等级EscapeRisk.risk_level因子加分严重级特权模式Privileged: true10CRITICAL危险 capabilitySYS_ADMIN10、SYS_PTRACE9、SYS_MODULE10…按权重CRITICAL/HIGH共享宿主命名空间Network/PID/IPC Modehost7CRITICALDocker socket 敏感挂载9CRITICAL其他敏感路径挂载/proc/kcore 等6HIGH以 rootUID 0运行3HIGH未 drop 默认 capabilities2MEDIUM无自定义 seccomp profile2MEDIUM未启用 no-new-privileges2MEDIUM根文件系统可写1LOW其中危险 capability 权重表定义在 DANGEROUS_CAPABILITIES敏感挂载路径清单定义在 SENSITIVE_MOUNT_PATHS。每条风险因子都附带 remediation 建议例如对特权模式给出Remove--privilegedflag, use specific--cap-add。Kubernetes Pod 审计扩展Docker 环境之外process.py 通过 scan_kubernetes_pods 将同一套评分逻辑扩展到 K8s检测hostNetwork/hostPID各 7、securityContext.privileged10、hostPath敏感卷8如挂载/var/run/docker.sock评分结果按降序输出并生成escape_risk_report.json报告含containers_scanned、results、每个容器的risk_factors。若存在 CRITICAL 级容器脚本以非零退出码退出main可直接接入 CI/CD 或监控告警。审计结果落地模板仓库还提供了 template.md 审计模板将 Workflow 3 的结果文档化包括环境信息集群名、运行时、内核版本、检测工具、逃逸面清单表容器 × 特权 × Capabilities × 宿主 NS × Docker Socket × 风险分、已部署检测规则状态表如 Namespace manipulation / Docker socket access / Cgroup escape 对应的工具与检测对象、P1/P2 发现表与修复跟踪表可直接作为安全评审交付物。标准映射与已知逃逸 CVE事件调查的根因判定Workflow 2 Step 4需要 CVE 知识库支撑。standards.md 汇总了容器逃逸相关的高危 CVECVE组件描述CVSSCVE-2024-21626runc经 /proc/self/fd 泄漏的工作目录逃逸8.6CVE-2022-0185Linux 内核fsconfig 堆溢出命名空间逃逸8.4CVE-2022-0847Linux 内核Dirty Pipe——任意文件覆写7.8CVE-2021-22555Linux 内核Netfilter 堆越界容器逃逸7.8CVE-2020-15257containerd抽象 socket 命名空间逃逸5.2CVE-2019-5736runc二进制覆写宿主代码执行8.6同时api-reference.md 给出了配套的 Docker 排查命令集是 Workflow 2 分流与 Workflow 3 审计的便捷工具# 检查容器是否特权 docker inspect --format{{.HostConfig.Privileged}} container # 检查新增 capabilities docker inspect --format{{.HostConfig.CapAdd}} container # 检查 PID 命名空间模式 docker inspect --format{{.HostConfig.PidMode}} container # 检查卷挂载 docker inspect --format{{range .Mounts}}{{.Source}}:{{.Destination}} {{end}} container验证命令确保检测能力真实生效部署完成后用 SKILL.md 提供的验证命令检验整条链路Workflow 1 是否真实告警、seccomp 是否加载、审计是否落盘# 用 Falco 官方事件生成器触发一次逃逸模拟 kubectl run falco-event-generator \ --imagefalcosecurity/event-generator \ --restartNever \ -- run syscall --action PtraceAttachContainer # 查看 Falco 告警 kubectl logs -n falco-system -l app.kubernetes.io/namefalco --tail50 # 验证 seccomp profile 已加载 docker inspect --format {{.HostConfig.SecurityOpt}} container-id # 检查审计日志中的逃逸事件 ausearch -k container_escape --interpret建议将这套验证纳入每周安全巡检事件生成器模拟攻击 → Falco 产生 CRITICAL 告警 → 审计日志落盘 → 告警成功路由至 Slack/SIEM。任一步骤无输出说明检测链路存在断点需立即排查。结语容器逃逸检测不是单一工具能解决的问题而是检测—响应—预防的三段式工程。基于 Anthropic-Cybersecurity-Skills 的detecting-container-escape-attempts技能本指南完整覆盖了三条工作流用 eBPF Falco 八条定制规则 Falcosidekick 搭建实时检测流水线用五步调查法分流→遏制→取证→根因→修复规范逃逸事件的应急响应用风险评分器对 Docker 与 Kubernetes 全量容器做主动攻击面审计。文中所有规则、配置与脚本均可在仓库对应文件中直接查阅与复用SKILL.md完整操作手册、workflows.md工作流定义、api-reference.md命令与告警格式、standards.md标准与 CVE 映射、process.py 与 agent.py可执行检测脚本以及 template.md审计报告模板。建议安全团队在授权环境下自有或获得书面许可的系统按 Workflow 1 → 3 → 2 的顺序逐步落地形成先有检测、再有预防、最后有响应的完整防御闭环。【免费下载链接】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），仅供参考