容器技术给业务部署带来了极大的便利，但隔离机制一旦被突破，攻击者就能从容器内部跳到宿主机上，进而控制整个节点甚至集群。检测容器逃逸不能只靠笼统的告警，需要针对具体的逃逸路径编写细化的检测规则。本文从常见逃逸手法入手，逐步展开规则的编写思路和落地细节。
一、先理清常见的容器逃逸路径
写规则之前必须先知道要检测什么。容器逃逸的手法虽然多，但归纳起来基本可以分成三类：配置不当导致的逃逸、内核漏洞导致的逃逸，以及运行时软件本身的漏洞利用。
配置类逃逸是最常见的，比如容器被以--privileged特权模式启动，或者把宿主机的/var/run/docker.sock挂载进了容器，又或者把/、/proc、/etc这类敏感目录以可写方式挂载进来。这类问题在自建集群和开发测试环境里特别普遍，因为图方便往往会放宽安全配置。检测这类逃逸的核心是识别容器内的异常操作特征，比如容器内出现了docker客户端命令调用、容器内向挂载的宿主机路径写入了计划任务文件等。
内核漏洞类逃逸包括利用Dirty COW、Dirty Pipe这类内核漏洞提权后逃出命名空间。这类攻击在行为上表现为容器内进程尝试调用某些罕见的系统调用，或者对/proc/self下的关键文件有异常读写。运行时漏洞则以各种CVE形式出现，比如历史上影响较大的runC漏洞CVE-2019-5736，攻击方式是覆写宿主机上的runC二进制文件。针对这类漏洞，规则要关注容器内是否有进程打开了指向自身可执行文件路径的写操作。
二、把逃逸特征转化为可执行的检测规则
规则编写的本质是把攻击行为翻译成可计算的条件表达式。以最常见的docker.sock挂载逃逸为例，攻击者在容器内通常会经历几个步骤：确认socket文件存在、查找docker客户端或下载一个静态编译的客户端、通过socket在宿主机上再启动一个挂载宿主机根目录的容器。检测规则就可以拆成多个信号点组合判断。
下面是一段基于Falco规则语法的示例，检测容器内访问docker.sock的行为：
- rule: Contact docker.sock from container desc: 检测容器内进程访问docker.sock文件，可能是挂载逃逸的前置动作 condition: container and fd.name=/var/run/docker.sock and evt.type in (open, openat, openat2) output: "容器内访问docker.sock (user=%user.name proc=%proc.cmdline file=%fd.name container=%container.name)" priority: WARNING tags: [container, escape, docker_sock]
这条规则的关键在condition部分：container表示事件发生在容器内，fd.name限定了被访问的文件路径，evt.type限定了系统调用类型。三个条件同时满足才告警，避免了单独匹配路径造成的漏判。实际使用时建议再加上proc.name的排除项，把容器里合法使用docker客户端的场景（比如CI构建容器）从规则中剔除出去。
对于特权容器，可以在容器启动阶段就做规则拦截。如果使用Kubernetes，可以通过校验准入控制的方式拒绝不合规的Pod：
apiVersion: apps.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
name: deny-privileged-pod
spec:
failurePolicy: Fail
rules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE", "UPDATE"]
resources: ["pods"]
validations:
- expression: "!has(object.spec.containers) || object.spec.containers.all(c, !has(c.securityContext) || !has(c.securityContext.privileged) || c.securityContext.privileged != true)"
message: "禁止创建特权容器"
事前拦截和事中检测要配合使用。准入规则挡住了大部分配置类风险，运行时规则负责捕捉漏网的行为，两层结合才能形成完整的防护面。
三、关注行为链而不是单一动作
单条规则匹配单一动作，误报率往往偏高。比如容器内执行mount命令本身在正常业务里也可能出现，但如果一个容器先访问了/proc/sysrq-trigger，又尝试挂载宿主机设备文件，接着向/etc/ld.so.preload写入内容，这一连串动作组合起来就高度可疑了。
编写这类组合规则可以借助进程行为序列分析。以检测通过挂载宿主机磁盘逃逸为例，规则逻辑可以这样设计：容器内进程对/dev/下的块设备执行了open操作，且随后出现了对未知文件系统类型的mount调用，两者在时间窗口内关联到同一个进程组，即触发告警。伪逻辑如下：
# 简化的规则判断逻辑
def check_escape(event):
if event.in_container and event.path.startswith("/dev/") and event.op == "open":
# 记录可疑的设备访问，等待后续mount行为关联
mark_suspicious(event.pid, event.path)
if event.in_container and event.op == "mount":
if has_suspicious_mark(event.pid, window=60):
return ALERT("容器内出现设备访问加挂载的组合行为，疑似磁盘挂载逃逸")
return PASS
除了文件和系统调用层面，还应该关注capabilities的变化。容器默认只保留少量能力，如果发现容器内进程通过setcap给自己添加了CAP_SYS_ADMIN或CAP_DAC_READ_SEARCH，这基本就是逃逸攻击的准备工作。把capabilities变更事件单独写成一条规则，配合前面的挂载检测规则做关联，能明显提升检出率。
四、规则落地时的误报调优
规则写出来只是第一步，能不能用起来取决于误报控制。容器逃逸检测规则最常见的误报来源有三个：一是合法的运维工具行为，比如安全扫描容器本身就会访问docker.sock；二是CI/CD流水线中的构建容器，行为特征和攻击者非常相似；三是规则条件写得太宽，比如只匹配路径不匹配操作类型。
针对这些情况，调优建议从白名单和行为基线两个方向入手。白名单要具体到容器标签或镜像维度，而不是简单按命名空间放行。比如给CI构建容器打上allow-docker-client的标签，规则里针对该标签做排除。行为基线则是观察正常业务的文件访问和系统调用模式，把高频出现的正常模式固化到规则的条件排除项里，逐步收紧告警范围。
最后要建立规则的验证闭环。每条规则写完后，用可复现的逃逸测试场景去验证是否能命中，比如在测试环境里模拟挂载docker.sock逃逸、模拟写入hostPath下的crontab文件，确认规则可以触发，再确认正常业务跑一天下来告警量可控。规则不是写完就结束的，随着新的逃逸手法出现和业务变化，需要持续补充特征和调整条件，让检测能力跟上攻防的节奏。