DockerStop不具有原生阻断作用——它仅发送SIGTERM信号，无法拦截提权、命名空间突破等逃逸行为；真正防御依赖运行时约束（如能力限制、只读根文件系统、用户命名空间映射、seccomp过滤）。
“DockerStop”本身并不是一个标准的 Docker 安全机制或官方组件，也未被纳入 Docker 引擎、containerd 或 runc 的安全策略体系中。因此，它在容器逃逸防御中**不具有原生阻断作用**——既不能主动检测逃逸行为，也无法拦截提权、命名空间突破或 cgroup 逃逸等典型攻击路径。
为什么 DockerStop 无法构成有效防御
常见误解源于将“停止容器”等同于“阻断攻击”，但实际中：
- DockerStop（如
docker stop）仅向容器主进程发送 SIGTERM 信号，等待优雅终止；若进程已劫持或 fork 出子进程，停止原容器对后台恶意进程无影响； - 逃逸往往发生在容器运行期间（例如通过 CVE-2019-5736 感染 runc、利用 CAP_SYS_ADMIN 滥用 /proc/sys/kernel/ns_last_pid 等），此时容器仍在运行，Stop 操作尚未触发；
- 即便提前配置自动化 Stop 规则（如基于 CPU/内存突增触发），响应存在延迟，且缺乏上下文判断能力，易误杀或漏判。
真正起阻断作用的安全机制
容器逃逸防御依赖的是**运行时约束与隔离强化**，而非事后停止：
-
默认禁用危险能力：启动容器时移除
--cap-add=ALL，显式限制如--cap-drop=NET_ADMIN --cap-drop=SYS_ADMIN； -
使用只读根文件系统：添加
--read-only，配合--tmpfs挂载必要可写路径； -
启用用户命名空间映射：通过
/etc/subuid//etc/subgid配置 userns-remap，使容器内 root 映射为主机非特权 UID； -
限制 seccomp/bpf 过滤器：加载严格 profile（如
docker run --security-opt seccomp=seccomp.json），禁止 open_by_handle_at、pivot_root 等高危系统调用。
Stop 可作为辅助响应环节，但需配合检测
在完整防御闭环中，“停止容器”属于响应阶段动作，前提是已有可靠检测支撑：
- 接入 Falco、Sysdig Secure 或 eBPF 工具实时监控异常调用（如容器内执行
mount --bind / /host）； - 结合 Prometheus + Grafana 设置资源异常阈值告警（如子进程数突增至 1000+），再联动脚本执行
docker stop； - 注意：单独 Stop 不解决根本问题，必须同步隔离主机节点、审计日志、更新镜像并修复漏洞。
不复杂但容易忽略：防御容器逃逸的关键，在于让攻击者“进不去、站不稳、跑不掉”，而不是寄望于“发现后赶紧关掉”。Stop 是刹车，不是防撞梁。
