容器逃逸与运行时痕迹

关键词：容器逃逸痕迹、特权容器、hostPath、Docker API 暴露、containerd-shim、runtimeClass、静态 Pod、DaemonSet 持久化 难度：进阶 前置知识：Linux 命名空间与 capability 机制、cgroup v1/v2、Docker overlay2 存储驱动、容器编排基础

一、概述

在案件里，"容器里出现了宿主机的东西"往往比"容器里跑着恶意程序"更能定性。

因为容器逃逸类案件的定罪关键从来不是"容器内有什么恶意文件"，而是"攻击者是否离开了容器原有的隔离边界"。一旦突破，宿主机上的所有数据都进入攻击范围，后续的横向与持久化痕迹也才得以解释。

本篇把这类案件拆成三个层次：

本篇最需要反复强调的一点：容器内改动默认只存在于 upperdir，随 docker rm 一起消失（见 Docker 取证工件地图）。

因此对逃逸类案件，取证时机的意义比任何一条命令都重要——容器一停一删，最关键的"突破时刻"就永远拿不到了。

必须先内存、后状态、最后文件系统。

在取证流程中的位置：本篇属于分析环的判定层，跨采集与分析两环：它既要抢易失证据（第 1 步），又要在固定下来的配置与状态里做判定。

它与前面几篇的分工是明确的——镜像层与 overlay2 解析 告诉你层里有什么，Volume 与绑定挂载取证 告诉你数据落在哪，本篇告诉你这些配置组合起来危不危险、运行时是不是真的被削弱了。

涉及的证据形态（四道隔离边界，每道都有可观测点）：

CapEff 是最有价值的一行：正常应用容器的 capability 集合通常只有十几项，看到 0000003fffffffff 就说明这个进程拥有全部能力。Linux 引入 capability 机制后，判断"是否特权"不再需要猜。

高危配置清单（本篇最需要交付给委托方的一张表）：这些是"把隔离关掉"的配置选择，不是漏洞。判定依据全在 HostConfig 与 Pod spec 里——--privileged（所有隔离全部关闭，★★★★★）、hostPath 挂载（挂 / 即交出根权限，★★★★★）、挂载 docker.sock（持有 Docker API 完全控制权，★★★★★）、挂载宿主 /etc/kubernetes（可读 kubelet 凭据与 PKI，★★★★★）、--device=/dev/sda（可直读宿主机磁盘，★★★★★）、--cap-add=SYS_ADMIN、--pid=host（可读 /proc/*/environ 取凭据）、--net=host（直连 localhost 上的数据库）、kind: DaemonSet（每个节点都跑一份的持久化载体）、静态 Pod（绕过 API Server 与调度）。

Docker API 暴露（2375 端口）必须单独说：2375 是明文、无认证的 TCP 端口。只要它在监听且可达，任何人都能创建特权容器、挂载宿主机根目录、读取任意文件——不需要任何漏洞。 daemon.json 里的 hosts 字段是直接证据，比推断"是否被利用"更可靠。

能回答什么：事发时这个容器的隔离配置是什么、哪些边界被削弱了、宿主机上有没有容器不该有的访问痕迹、攻击者用哪种方式活了下来。

不能回答什么：配置高危不等于被利用——这是本领域最高频的误判方向。--privileged 可能是一开始就为调试而开，DaemonSet 可能是运维部署的。配置说明的是"具备条件"，突破痕迹才说明"实际发生了"，两者必须分开表述。另一个边界是：/proc 侧的观察需要容器仍在运行，已删除容器的隔离状态只能从残留配置推断。

内容边界（本篇的红线）：只写防守侧的检测与排除误报——如何识别高危配置、如何判断突破痕迹、如何区分正常运维与攻击行为。不提供任何逃逸实现、不涉及提权方法、不给出突破隔离的具体操作步骤。 涉及 Docker API、capability、namespace 时，止步于"这个配置意味着什么、怎么观察到"。

读者前提：需要 Linux 的 namespace / capability / cgroup 机制（见 proc 虚拟文件系统取证）、容器运行时基础，以及 Docker 取证工件地图 与 镜像层与 overlay2 解析 的前置知识。如果主机还在线，强烈建议先读 3.1 第 1 步——逃逸类案件丢的不是命令，是时间。

二、核心原理

2.1 容器隔离的四道边界

理解"逃逸"必须先理解容器究竟靠什么把进程关住。这四道边界任意一道被配置削弱或被绕过，就可能脱离容器。

# 容器内执行：CapEff 全为 f 即拥有全部 capability
grep -E 'Cap(Inh|Prm|Eff|Bnd|Amb)|NoNewPrivs|Seccomp' /proc/self/status
# CapInh: 0000000000000000
# CapPrm: 0000003fffffffff   ← ★ 全集
# CapEff: 0000003fffffffff   ← ★ 全集 = 特权运行
# NoNewPrivs: 0
# Seccomp: 0                 ← ★ 0 = 未启用 seccomp 过滤

⚠️ Seccomp: 0 与 NoNewPrivs: 0 同时出现要单独记录。 默认的非特权容器通常有 Seccomp: 2（filter 模式）。seccomp 被关闭会让 syscall 面大幅放开，这是"配置本应安全、实际被削弱"的直接证据。

2.2 cgroup 路径：判断"我在哪"与"我是谁"

/proc/self/cgroup 是区分"进程在容器内"与"在宿主机上"最省事的手段，因为容器运行时必然把它写进 cgroup 路径。

# 容器内：路径里带容器 ID
cat /proc/self/cgroup
# 12:memory:/docker/6d4f7b2c1a9b...           ← ★ cgroup v1 风格
# 0::/system.slice/docker-6d4f7b2c1a9b...scope ← cgroup v2 风格

# kubelet 管理的容器：
# 0::/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod<uid>.slice/...

# 宿主机上：路径里没有容器标识
cat /proc/self/cgroup | grep -qE 'docker|kubepods|containerd|crio' && echo "在容器内" || echo "在宿主机"

cgroup 版本差异必须注意：cgroup v1 有 memory:、cpu: 等十余条层级，v2 统一为 0:: 单行。v2 下 docker-<id>.scope 结尾的容器 ID 是 64 位十六进制，可用于与 docker inspect 的容器 ID 前缀比对。

2.3 mountinfo：能不能看到宿主机，是最直观的判据

/proc/self/mountinfo 列出当前 mount namespace 内所有挂载点。普通容器里它只有二十几行；逃逸到宿主机的进程会看到宿主机真实文件系统。

wc -l < /proc/self/mountinfo          # ★ 行数是最快的分界参考

# 找宿主机特有的挂载点（容器内不应出现）
grep -E ' / /(ext4|xfs|btrfs) | /boot | /etc/kubernetes | /var/lib/docker | /home ' /proc/self/mountinfo

# 检查是否挂载了宿主机目录
grep -E 'docker\.sock|containerd\.sock|/var/lib/kubelet|/etc/kubernetes' /proc/self/mountinfo

# 是否看到宿主机块设备
ls /dev/ | head -20
lsblk 2>/dev/null

⚠️ /proc/self/mountinfo 里出现 /var/lib/docker 或 /etc/kubernetes，几乎可以断定是 hostPath 挂载或已逃逸到宿主机。 但要注意区分两种情况：配置层面的 hostPath（docker inspect 里有 HostConfig.Binds）与运行结果的挂载（mountinfo 里有）要分别取证，前者证明"被配置成高危"，后者证明"确实被访问过"。

2.4 高危配置清单：哪些参数等于"等于没隔离"

这是本文最需要交付给委托方的一张表。这些是"把隔离关掉"的配置选择，不是漏洞。

K8s 侧对应项：

2.5 Docker API 暴露：暴露即等于宿主机 root

2375 是 Docker 的明文、无认证 TCP 端口；2376 是 TLS 版本。只要 2375 在监听且可达，任何人都能创建特权容器、挂载宿主机根目录、读取任意文件——不需要任何漏洞。

# 宿主机侧：是否监听
ss -lntp | grep -E ':2375|:2376'
# ★ 出现 0.0.0.0:2375 即为高危配置

# 配置来源
grep -nE '"hosts"' /etc/docker/daemon.json
systemctl show docker | grep -i execstart

# 是否有 TLS 校验
ls -l /etc/docker/certs.d/ 2>/dev/null

取证意义：daemon.json 里的 hosts 字段是直接证据，比推断"是否被利用"更可靠。若审计显示有来自外部的 create/start 容器请求，则说明该端口曾被实际使用。

⚠️ 区分"配置了"与"被利用了"：daemon.json 里写了 0.0.0.0:2375 只能证明配置失当；证明被利用需要网络侧日志（防火墙/IDS/云厂商流量审计）、容器创建记录（/var/lib/docker/containers/*/config.v2.json）与镜像拉取记录三者至少两项相互印证。

2.6 运行时痕迹：containerd-shim 与 runc 状态

从 Docker 迁移到 containerd 的环境里，宿主机上会残留大量 containerd-shim 与 runc 相关痕迹，它们是容器"曾经运行过"的时间证据。

# 运行中的容器对应的 shim（★ 父进程是 containerd）
ps -ef | grep '[c]ontainerd-shim' | head -20

# 由 shim 反查容器 ID 与 rootfs
for p in $(pgrep -f containerd-shim); do
  echo "shim $p  cwd=$(readlink /proc/$p/cwd 2>/dev/null)"
done

# runc 生命周期日志（★ 记录 create/start/delete 的完整过程）
ls -l /run/containerd/io.containerd.runtime.v2.task/*/*/log.jsonl 2>/dev/null

# 残留 cgroup
find /sys/fs/cgroup -maxdepth 4 -name 'docker-*.scope' 2>/dev/null | head

# ★ 运行时 socket 是否存在
ls -l /run/docker.sock /run/containerd/containerd.sock 2>/dev/null

⚠️ log.jsonl 与容器生命周期日志容易被运维清理。 在 /run 下（tmpfs，重启即失）必须第一时间固定；/var/lib/docker/containers/<id>/<id>-json.log（json-file 驱动）虽在磁盘上，但会随 docker rm 删除。这是容器取证的"双重时间窗"（详见第 01 篇）。

2.7 K8s 层的异常形态

三、操作步骤

3.1