Learn-Web-Hacking 云安全实战：Docker 容器环境识别与容器内信息收集指南

• 文档
• 网络安全
• 教程

本文是 Learn-Web-Hacking 仓库云安全板块中《Docker 环境识别》专题的系统化展开。当你拿到一个 shell 之后，第一步往往不是急着提权或弹 shell，而是搞清楚"我到底在哪儿"：是在宿主机上、在普通容器里、还是在特权容器里？本文围绕 Docker 环境识别 的核心指标，给出可落地的判定命令、原理分析、信息收集清单，并结合仓库中的 Docker 基础概念、攻击面分析、安全加固 等文档，讲清"识别 → 收集 → 利用/加固"的完整链路。读完本文，你将掌握一套不依赖图形界面、仅靠命令行即可完成的容器内外判别方法，以及一套标准化的容器内信息收集流程。

为什么先做"环境识别"

在 Web 渗透或内网渗透中，拿到一个 shell 后的环境判断决定了后续攻击路径的方向：

• 如果你在Docker 容器内，默认隔离机制（命名空间、Cgroup、Capability、Seccomp）会限制你的感知范围和操作能力，逃逸成为后续的关键议题；
• 如果你在Docker 宿主机上，则可以直接接触 Docker 守护进程与/var/run/docker.sock，攻击面完全不同；
• 如果你面对的是Kubernetes 集群中的 Pod，还会额外涉及集群内权限提升与 Secret 获取，详见 K8s 安全。

仓库文档 Docker 基础概念 明确指出："容器的本质是进程，拥有自己独立的命名空间"，并指出 Docker 引擎由 Docker Client、Docker daemon、containerd、RunC 共同构成，daemon 默认通过/var/run/docker.sock暴露本地 IPC/Unix socket，默认非 TLS 网络端口为 2375，TLS 默认端口为 2376。这些底层事实正是环境识别指标的来源——识别指标本质上都是在探测"命名空间、挂载、进程、端口"这些层的特征。

判断是否身处 Docker 容器内

以下五类特征来自 Docker 环境识别 的"Docker 内"清单，每类都给出了判定命令与背后的原理。单条特征可能出现误判，建议组合使用、交叉验证。

特征一：MAC 地址落在 Docker 默认网段

ip addr ip link cat /sys/class/net/eth0/address

Docker 默认创建的 bridge 网络使用172.17.0.0/16网段，容器网卡 MAC 地址通常以02:42:ac:11开头。以 identify.rst 中的指标为准，容器内 MAC 地址落在02:42:ac:11:00:00～02:42:ac:11:ff:ff区间时，基本可以断定当前处于 Docker 容器内。从原理上推断，02:42是 Docker 固定前缀，ac:11正是172.17的十六进制表示，MAC 后半段随容器 IP 动态变化。

特征二：ps aux看到的进程 PID 都很小

ps aux ps -ef

容器拥有独立的 PID 命名空间，容器内 PID 从 1 开始重新分配，且进程数量远少于宿主机，因此ps aux输出的绝大多数进程 PID 都非常小（个位数到三位数以内）。若观察到 PID 大范围、高数值分布（如成千上万的 PID），则更可能是宿主机环境。

特征三：/proc/1/cgroup显示 docker 的 cgroup 路径

cat /proc/1/cgroup

在容器内执行该命令，输出中的 cgroup 路径通常带有docker标识（例如路径中包含docker/<container-id>或docker-<hash>.scope等字样）。仓库 Linux 主机信息收集 也将cat /proc/1/cgroup列为容器内信息收集的必备命令，可作为本特征的佐证。

特征四：根目录存在.dockerenv文件

ls -la /.dockerenv ls -l .dockerenv

Docker 在创建容器时会在容器根目录写入.dockerenv隐藏文件，因此该文件存在是"当前处于 Docker 容器内"的最直接证据之一。该命令同样出现在 Linux 主机信息收集 的容器内信息收集清单中。

特征五：常用命令缺失（如ping等）

which ping curl wget nc ifconfig netstat

为了减小镜像体积，大量容器镜像（如基于 Alpine、Distroless 的精简镜像）不包含网络诊断、编辑等常用工具。遇到ping: command not found这类提示，应反向佐证当前环境可能是容器。当然，这也意味着信息收集时可能没有现成工具，需要依赖/proc、/sys等虚拟文件系统来获取信息。

补充交叉验证手段

除上述五项外，还可从以下角度补充验证（部分条目源自 Linux 主机信息收集 的虚拟环境检测与容器内信息收集小节）：

• hostname：容器的主机名往往是一串随机 ID（如a1b2c3d4e5f6），与宿主机名差异明显；
• mount/cat /proc/self/mountinfo：容器挂载点列表短小且多指向 overlay、proc、sysfs 等虚拟文件系统，与宿主机冗长的挂载列表差异巨大；
• /proc/1/comm：查看 PID 1 的进程名，若为docker-containerd-shim、shim等字样的子进程，可佐证容器环境；
• 内核模块探测：容器与宿主机共享内核，但lsmod结果在容器内通常为空或受限，而宿主机能正常列出模块。仓库 Linux 主机信息收集 提供了通过lsmod | grep探测 VirtualBox、VMware、Xen、virtio、Hyper-V 等虚拟化特征的命令，可用于区分"物理机 / 虚拟机 / 容器"三层环境。

判断目标主机是否为 Docker 宿主机（容器外）

当判断出自己不在容器内（或扫描目标时），下一步是确认目标主机是否运行了 Docker，为后续攻击 Docker daemon 做准备。以下两条来自 Docker 环境识别 的"Docker 外"清单。

判据一：/var/run/docker.sock文件存在

ls -la /var/run/docker.sock

/var/run/docker.sock是 Docker daemon 暴露的本地 IPC/Unix socket，Docker 基础概念 明确说明 daemon 通过它实现 Docker 远程 API。该文件只存在于宿主机上。注意区分两种场景：

• 在宿主机上直接看到该 socket，说明本机是 Docker 宿主机，可尝试通过docker客户端或 HTTP 请求与 daemon 交互；
• 在容器内看到该 socket，则说明攻击面已经出现——容器内挂载了宿主机的 Docker socket（这是 攻击面分析 中明确列出的"危险挂载"场景之一），此时可以借助 socket 调用 Docker API 创建带宿主机目录挂载的容器，实现逃逸。

判据二：2375 / 2376 端口开启

nc -zv <target> 2375 nmap -p 2375,2376 <target>

• 2375：Docker daemon 默认非 TLS 远程 API 端口。仓库 端口信息 将 Docker Remote API (2375/TCP) 列为常见风险端口，指出其常见脆弱点为"未限制 IP / 未启用 TLS 身份认证"，并给出探测姿势：http://docker.addr:2375/version；
• 2376：Docker daemon 默认 TLS 远程 API 端口（Docker 基础概念 说明）。即便开启了 TLS，若证书与客户端信任配置不当仍可能被利用。

若 2375 未授权可直接访问，可以像调用本地 API 一样列出镜像、创建容器、读取容器日志等，这构成了"攻击 Docker 守护进程"这一攻击面的入口。攻击面分析 特别强调：Docker 守护进程默认由 root 运行，且守护进程本身没有 Seccomp/AppArmor 保护，一旦攻破守护进程即可获得宿主机 root 权限。

补充判据

• 检查 Docker 相关进程：ps aux | grep -i docker，宿主机上应有dockerd、containerd等守护进程；
• 检查 Docker 数据目录：ls /var/lib/docker。仓库文档说明非持久化数据默认存储于/var/lib/docker/下，该目录同样仅存在于宿主机；
• 检查docker/docker-compose命令是否可用：which docker。

容器内信息收集清单

确认身处容器内之后，按照 Docker 环境识别 的"容器内信息收集"清单逐项展开。收集结果将直接决定后续是走"逃逸"路线还是"横向"路线，也与 K8s 安全 中"Pod 内权限提升、容器逃逸"的关注点衔接。

1. 用户信息（当前用户、用户列表）

id whoami cat /etc/passwd cat /etc/group

关注当前 UID/GID：若为 0（root），还需进一步确认是否被 Capability 机制削减了权限（见第 4 项），因为 Docker 默认"使用白名单而非黑名单，去除了所有非必要的功能"（Docker 基础概念 的 Capability 小节），容器内 root 比宿主机 root 能力小得多。

2. 操作系统与内核版本

uname -a cat /etc/os-release cat /proc/version lsb_release -a # 部分镜像没有该命令

注意：容器与宿主机共享内核，uname -a输出的是宿主机内核版本，只能用于判断宿主机内核的发行家族与补丁情况（例如用于核对 攻击面分析 中列出的 CVE-2022-0847 Dirty Pipe、CVE-2021-4034 Polkit 等内核提权漏洞是否可能生效）；而/etc/os-release反映的是镜像自身的操作系统发行版。

3. 运行进程信息（进程名、权限等）

ps aux ps -ef ls -l /proc/<pid>/exe

确认容器主进程及子进程，注意进程以什么权限运行（root 或非 root），是否存在以 root 运行的高价值服务进程。

4. 容器是否为特权容器

capsh --print cat /proc/self/status | grep Cap

• capsh --print会列出当前进程的 Capability 集合，该命令出现在 Linux 主机信息收集 的容器内信息收集清单中；
• 查看/proc/self/status中的CapEff字段：若 Capability 集合基本齐全（如0000003fffffffff这类几乎全 1 的值），说明容器很可能以特权模式（--privileged）运行。特权容器意味着 Capability 限制基本失效、可以访问宿主机绝大部分设备节点，是 攻击面分析 中"配置不当"的第一条风险；
• 尝试执行mount -t tmpfs tmpfs /mnt/test等挂载操作，特权容器内通常可以直接成功。

5. 环境变量

env printenv

重点关注两类变量：一是与容器运行时相关的DOCKER_*、HOSTNAME等；二是在 Kubernetes 环境中注入的变量。Linux 主机信息收集 特别给出了env | grep KUBE的排查命令——若环境变量中包含 KUBE 相关字段，说明当前很可能处于 K8s 集群的 Pod 中，攻击思路应向集群层面倾斜（Service Account、API Server、Secret 等），相关风险详见 K8s 安全。

6. 判断容器挂载信息，尝试挂载 Docker Socket

mount cat /proc/mounts ls -la /var/run/docker.sock /run/docker.sock ls -la /run/secrets/Kubernetes.io/ # Pod 场景下检查 K8s 挂载的 Secret

• 检查/var/run/docker.sock是否已被挂载进容器（Linux 主机信息收集 同样将此列为检查项）。若存在，可尝试docker客户端或直接对 socket 发 HTTP 请求与宿主机 daemon 通信；
• 检查是否挂载了宿主机敏感目录（/host、/proc、/dev、/etc等）。攻击面分析 的"危险挂载"小节明确指出：挂载/var/run/docker.sock以及宿主机/dev、/proc等目录属于高风险配置，一旦发现即为高价值利用点。例如挂载了宿主机根目录时，可以直接读写宿主机文件系统；
• 若挂载了 docker.sock，可按如下思路验证与利用（仅作原理说明，需在授权范围内操作）：

curl --unix-socket /var/run/docker.sock http://localhost/containers/json

通过 socket 调用 API 创建以宿主机根目录为挂载源的特权容器，即可获得宿主机文件系统访问能力。

7. 网络环境，判断可以到达的网段

ip addr ifconfig # 精简镜像可能没有 ip route cat /etc/hosts arp -a

• 查看容器自身 IP 与网关，判断是否处于 Docker 默认 bridge 网段（172.17.0.0/16等），从而反推宿主机内网段；
• 结合 Docker 基础概念 的描述：同一 Docker 主机上的容器都位于网桥接口上，容器之间可以相互 ping、收发 UDP、建立 TCP 连接，因此可以据此横向探测同网段内的其他容器；
• 记录路由表中可达的网段，为后续内网横向做准备。

8. 在云环境中，尝试获取元数据信息

curl -s http://169.254.169.254/latest/meta-data/ # 通用云元数据地址示例

如果判断当前环境部署在云平台（云主机内或云上 K8s 集群），可尝试访问云厂商的元数据服务，常见地址形式包括169.254.169.254（AWS、GCP、Azure 等通用链路本地地址）以及国内云厂商的对应元数据地址。成功访问元数据服务可能拿到临时凭据、实例角色等信息，从而进一步扩大权限。注意：云元数据地址因厂商而异，且部分厂商已对 SSRF/容器场景做防护，此步骤以实际探测结果为准。

从识别走向利用与加固

环境识别和信息收集本身不是终点，其价值在于为后续决策提供依据。

利用侧：若确认处于特权容器、挂载了 docker.sock 或宿主机敏感目录，则具备了 攻击面分析 中列出的"配置不当"型逃逸条件（--privileged、危险挂载、--cap-add=SYS_ADMIN、--net=host/--pid=host/--ipc=host绕过 namespace 等）；若内核版本存在已知 CVE（如 attack.rst 列出的 CVE-2022-0847、CVE-2019-5736 runC 逃逸等），则可评估内核逃逸路径。

防御侧：识别出的每一项弱点都能在 安全加固 中找到对应措施：不以 privileged 模式运行容器、禁止挂载 docker.sock 等敏感路径、使用 Seccomp 限制 syscall、启用 AppArmor/SELinux、配置 Docker 守护程序 TLS 身份验证、控制 CPU/内存/磁盘资源、定期安全扫描与补丁更新等。攻防两端均围绕同一组识别指标展开，这正是环境识别在整个 Docker 安全体系中的定位。

快速自查清单

综上，Docker 环境识别的核心可以概括为三问：我在容器内吗？我在宿主机上吗？我所在的容器给了多少权限？带着这三问执行上述指标与收集命令，即可在 Docker 攻击面分析、安全加固、K8s 安全 等仓库文档的指引下，将一次"位置确认"转化为清晰的下一步行动方案。

• 文档
• 网络安全
• 教程