红蓝对抗实战：Docker环境下的渗透测试全流程复盘

场景设定：构建一个真实的对抗靶场

为了让演练尽可能贴近真实生产环境，我们搭建了一个典型的微服务应用场景。整个靶场环境基于 Docker Compose 编排，包含多个相互依赖的服务容器。

靶场架构与攻击入口

我们模拟了一个常见的电商网站后端，其架构包括：

• Web 前端容器 (Nginx): 负责代理用户请求。
• 应用服务容器 (Python/Flask): 运行着存在漏洞的业务逻辑代码。这是我们为红方预设的初始攻击入口。
• 数据库容器 (MySQL): 存储业务数据。
• 缓存容器 (Redis): 提供缓存服务。
• 管理后台容器 (Jenkins): 用于模拟 CI/CD 流程，但在此次演练中，它成为了一个关键的横向移动目标。

所有这些容器都运行在同一台配置了 Docker Engine 的 Linux 宿主机上。我们特意在应用服务容器的启动配置中留下了一个“后门”——以特权模式（--privileged）运行，并挂载了宿主机的 Docker Socket 文件（/var/run/docker.sock）。这在一些需要容器管理其他容器的场景中并不少见，但也带来了巨大的安全风险。

红方攻击路径全景复现

红方团队的任务是，在仅知道 Web 应用访问入口的情况下，尝试获取最高控制权限。整个攻击过程清晰地分为四个阶段。

第一步：信息收集与突破口发现

攻击始于对目标 Web 应用的常规信息收集。通过端口扫描和目录爆破，红方确认了应用使用了 Flask 框架，并发现了一个未被充分保护的 /uploads 目录。进一步的指纹识别显示，应用所依赖的某个图像处理库存在已知的远程代码执行漏洞（RCE）。这成为了攻击的第一个突破口。

第二步：利用Web漏洞获取初始立足点

红方利用已知的 RCE 漏洞，精心构造了一个恶意的图像文件并上传。当后端应用调用存在漏洞的库处理该文件时，成功触发了代码执行，红方获得了一个反弹 Shell。

此时，攻击者拿到的权限仅限于 www-data 用户在应用服务容器内部的权限。这是一个受限的环境，但攻击者已经成功“进入”了第一个“盒子”。

拿到初始 Shell 只是渗透的开始。在容器化的环境中，攻击者首先要做的就是判断自己身在何处，以及是否有机会“逃”出去。

第三步：关键的容器逃逸

这是本次攻防演练中最核心的环节。在获取容器内的 Shell 后，红方立即开始进行环境探测。

通过执行 ls -la / 和 cat /proc/1/cgroup 等命令，攻击者迅速确认自己身处一个 Docker 容器内。更关键的是，他们发现了一个异常的文件挂载——/var/run/docker.sock。

Docker Socket 滥用

docker.sock 是 Docker Daemon 监听的 Unix 域套接字，本地进程可以通过它与 Docker 守护进程进行通信。如果容器内能够访问这个文件，就意味着容器内的进程可以执行 Docker 命令，从而操作宿主机上的其他容器，甚至创建新的容器。

攻击者在容器内安装了 Docker 客户端，然后通过挂载的 docker.sock 文件与宿主机的 Docker Daemon 通信：

# 在容器内执行
./docker -H unix:///var/run/docker.sock ps

这条命令成功列出了宿主机上运行的所有容器，包括数据库、缓存以及那个关键的 Jenkins 管理后台容器。至此，容器的隔离性被彻底打破。

提权至宿主机 Root

仅仅控制其他容器还不够，红方的目标是宿主机。利用对 Docker Socket 的控制权，攻击者执行了一个精心构造的 Docker 命令：

# 在容器内执行
./docker -H unix:///var/run/docker.sock run -it --rm -v /:/mnt --name=pwned alpine:latest chroot /mnt /bin/sh

这条命令的意图非常明确：

1. run -it: 创建一个新的交互式容器。
2. -v /:/mnt: 将宿主机的根目录（/）挂载到新容器的 /mnt 目录下。
3. alpine:latest: 使用一个轻量的镜像。
4. chroot /mnt /bin/sh: 在新容器启动后，将根目录切换到 /mnt（也就是宿主机的根目录），并启动一个 Shell。

当这个容器启动后，攻击者就获得了一个运行在宿主机根文件系统下的 Shell。由于 Docker Daemon 通常以 root 权限运行，这个新创建的容器进程也继承了相应的权限。攻击者成功从一个受限的容器 Shell，“逃逸”并提权为宿主机的 root 用户。

第四步：横向移动与持久化

成为宿主机的 root 后，红方的行动变得畅通无阻。他们迅速在宿主机上创建了后门账户，并通过修改 SSH 配置留下了持久化的访问方式。

接着，攻击者将目光转向了靶场环境中的其他高价值目标。通过直接访问宿主机上的容器数据卷，他们轻易地获取了数据库容器中的所有数据，并从 Jenkins 容器的配置文件中窃取了用于访问代码仓库、私有镜像库的凭证。至此，整个靶场环境对红方来说已再无秘密。

红方攻击小结： 整个攻击链条清晰且高效。从一个 Web 漏洞开始，通过利用容器的错误配置（挂载 Docker Socket）实现容器逃逸和提权，最终实现了对整个宿主机和相关业务系统的完全控制。这个过程暴露了在追求业务便利性的同时，极易忽视的安全短板。

蓝方视角：从蛛丝马迹到溯源反制

在真实的攻防场景中，蓝方的挑战在于如何从海量的系统日志和告警中，及时发现攻击行为并做出有效响应。

检测与发现：异常的进程与网络连接

蓝方的监控系统首先捕捉到了两个关键的异常信号：

1. 异常进程告警： 在应用服务容器内，检测到一个由 www-data 用户启动的反弹 Shell 进程 (/bin/bash -i)。这在正常的业务逻辑中是绝不应该出现的。
2. 异常网络连接： 监控发现应用服务容器与一个未知的外部 IP 建立了长时间的 TCP 连接，这正是反弹 Shell 的通信信道。

这些初级告警让蓝方意识到了潜在的入侵行为，并立即启动了应急响应流程。

研判与分析：串联攻击日志链

蓝方安全工程师介入后，并没有急于切断连接，而是开始对失陷容器进行隔离和快照，并深入分析日志，试图还原攻击者的完整路径。

通过审计容器内的 Bash 操作历史和进程日志，蓝方发现了攻击者执行 docker ps 和 docker run 的行为。这个发现至关重要，它直接将调查方向引向了“容器逃逸”。

随后，蓝方审查了该容器的启动配置，确认了其以 --privileged 模式运行，并挂载了 /var/run/docker.sock。至此，蓝方完整地拼凑出了攻击者的提权手法： Web RCE -> 容器内 Shell -> 滥用 Docker Socket -> 创建高权限容器 -> 获取宿主机 Root。

遏制与处置：隔离失陷容器与主机

在明确了攻击路径和影响范围后，蓝方采取了果断的处置措施：

1. 网络隔离： 使用防火墙规则，切断了失陷容器与外部攻击者 IP 的连接，同时阻断了该容器与其他内部服务的横向通信。
2. 下线容器： 停止并删除了被攻击者用来提权的恶意容器（pwned）。
3. 主机排查与加固： 对失陷的宿主机进行全面排查，清除了攻击者留下的后门账户和持久化配置，并将其从集群中隔离，准备进行重装。

溯源与反制：定位攻击者来源

通过分析反弹 Shell 的连接日志和 Web 服务器的访问日志，蓝方成功关联到了攻击者使用的跳板机 IP。虽然在演练场景下无法进行进一步的反制，但在真实世界中，这些信息对于后续的威胁情报共享和法律追溯具有重要价值。

蓝方响应小结： 蓝方的成功之处在于其具备分层检测能力和快速响应机制。从基础的进程、网络异常告警，到深入分析定位到容器逃逸的关键行为，再到果断的遏制和处置，整个过程体现了纵深防御的思想。如果缺少对容器运行时行为的监控，蓝方可能会在攻击者逃逸到宿主机后很久才发现异常，届时损失将难以估量。

演练复盘与经验沉淀

一次成功的红蓝对抗，其价值不在于分出胜负，而在于通过复盘，找到系统性的问题并沉淀为可执行的改进措施。

问题的根源在何处？

回顾整个攻击过程，Web 应用的 RCE 漏洞是攻击的起点，但真正导致灾难性后果的，是容器的错误配置。将 docker.sock 挂载到容器内，并给予容器特权模式，相当于主动为攻击者打开了从容器通往宿主机的大门。

这种配置在开发或测试环境中为了方便而偶尔使用，但如果被带到生产环境，就构成了严重的安全隐患。它完全违背了容器技术设计的初衷——隔离。

如何构建更安全的 Docker 环境

基于此次演练的发现，我们总结了几个关键的 Docker 环境安全加固措施：

最小权限原则

• 禁止挂载 Docker Socket： 除非有绝对必要且经过严格的安全评估，否则永远不要将 /var/run/docker.sock 挂载到容器内。对于需要管理容器的场景，应寻求更安全的替代方案，如提供独立的、受权限限制的 API 接口。
• 禁止使用特权模式： 避免使用 --privileged 标志。它会移除容器与宿主机之间几乎所有的隔离。应仔细评估容器真正需要的能力（Capabilities），并通过 --cap-add 和 --cap-drop 进行精细化授权。
• 使用非 Root 用户运行容器内应用： 在 Dockerfile 中使用 USER 指令，指定一个非 Root 用户来运行应用进程。这样即使应用被攻破，攻击者也只能获得一个低权限的 Shell，增加了后续提权的难度。

镜像安全与运行时监控

• 镜像扫描： 在 CI/CD 流程中集成镜像扫描工具，确保基础镜像和应用依赖中不包含已知的安全漏洞。
• 运行时安全监控： 部署专门的容器运行时安全工具（如 Falco、Trivy 等），实时检测容器内的异常行为，例如产生 Shell、执行敏感命令、对外建立异常连接等。这正是蓝方能够快速发现攻击的关键。

攻防演练的真正价值

此次演练再次证明，安全不是一个静态的目标，而是一个持续对抗的过程。通过模拟真实的攻击，我们能够以攻击者的视角审视自身的防御体系，发现那些在常规安全审计中容易被忽略的、由多个“小问题”组合而成的“大风险”。

将红蓝对抗常态化，并把演练中获得的经验转化为自动化的安全策略和监控规则，这才是提升组织整体安全水位最有效的方式之一。