Vulhub 漏洞环境起不来10 分钟定位原因把容器拉起来【免费下载链接】vulhubPre-Built Vulnerable Environments Based on Docker-Compose项目地址: https://gitcode.com/GitHub_Trending/vu/vulhub启动 Vulhub 漏洞环境时你敲进struts2/s2-045跑完docker compose up -d等回来的却是一行红色的context deadline exceeded或者容器在docker compose ps里明明亮着三秒后状态变成Exit 1又或者环境起来了浏览器打开 8080页面却是白的。这三种现象覆盖了 Vulhub 启动故障的大头难就难在大多数人的第一反应是反复down再up结果一次比一次绝望。这篇文章不讲原理只讲怎么查。读完之后你遇到任何一个报错都能按现象 → 定位 → 处置 → 验证的路径自己对号入座独立处理掉绝大部分启动类故障不用再怀疑是自己操作错了。 开工前的 4 道硬门槛动手之前先把这 4 项过完任何一项不过后面的步骤都会白跑检查项验证命令通过标准Docker 服务在运行docker versionClient 和 Server 两段都能正常打印compose 命令可用docker compose version打印Docker Compose version v2.x磁盘空间够df -h /var/lib/docker可用空间 ≥ 20GB能拉通镜像docker pull vulhub/struts2:2.3.30拉取成功无超时本地还没有仓库的话先把它拉下来git clone --depth 1 https://gitcode.com/GitHub_Trending/vu/vulhub # 浅克隆省时间 cd vulhub ls struts2/s2-045/docker-compose.yml # 确认目录结构完整能列出文件即通过镜像拉不下来卡死在 context deadline exceeded现象进环境目录后的第一条命令卡了几分钟后报错退出Error: request ID xxx: pull access denied for vulhub/struts2, repository does not exist or may require docker login: context deadline exceeded定位绝大多数情况不是镜像不存在而是这台机器到 Docker Hub 的链路被墙或被限速拉取一直等响应直到超时。先排除手滑写错镜像名的可能grep image struts2/s2-045/docker-compose.yml # 确认镜像名是 vulhub/struts2:2.3.30处置给 Docker 配上镜像源再重启服务。编辑/etc/docker/daemon.json不存在就新建sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [https://docker.mirrors.ustc.edu.cn] } EOF sudo systemctl restart docker # 让新配置生效预期无输出然后回到环境目录重新拉cd struts2/s2-045 docker compose pull # 这次应该能看到 layer 逐层下载验证docker images | grep struts2 # 列表里出现 vulhub/struts2:2.3.30 即拉取成功 docker compose up -d # 启动不再卡在拉取阶段 端口被占住Bind for 0.0.0.0:8080 failed现象镜像拉下来了容器也创建了但冒出一条红色报错Error response from daemon: driver failed programming external connectivity on endpoint ... : Bind for 0.0.0.0:8080 failed: port is already allocated定位字面意思就是 8080 被别的进程占着。Vulhub 里 8080、3306 这类常用端口很密集本机如果开着 Tomcat 或 MySQL撞上很正常。先找到是谁在占ss -lntp | grep 8080 # 会打印出占用进程名和 PID处置占用的进程可以停就停掉不方便动的话改宿主侧映射端口。在本地副本的 docker-compose.yml 里把映射改成ports: - 8081:8080 # 只改冒号左边宿主机端口容器内的 8080 保持不变验证docker compose up -d curl -s -o /dev/null -w %{http_code} http://127.0.0.1:8081/ # 返回 200/302 即映射生效容器秒退状态 Exit 1现象docker compose up -d没有任何报错可几秒后再看docker compose ps # NAME STATUS # struts2 Exit 1容器没了。这时候十有八九是容器内部自己退了看日志是最快的路径docker compose logs --tail 50 # 只看最后 50 行足够定位原因日志里两个高频报错对应的根因都很典型exec format error架构不匹配M 系列芯片的 Mac 上最常见镜像只有 amd64 构建ARM 直接跑不动。README.zh-cn.md 给了标准解法export DOCKER_DEFAULT_PLATFORMlinux/amd64 docker compose up -d # 强制按 amd64 模拟运行慢一点但能跑通启动即崩提示Too many open filesKali Linux 的ulimit nofile默认偏低部分环境吃不消需要先调高文件句柄上限再启动项目常见问题一节有对应的修复说明。⚠️ 改完ulimit后建议新开终端再跑up旧终端里环境变量不生效。验证docker compose ps # ✅ STATUS 稳定保持 Up 不退出 curl -I http://127.0.0.1:8080/ # 返回 HTTP/1.1 200 即服务就绪环境起来了但 PoC 打不通镜像版本没对上这是最磨人的一种容器 Up、页面能访问可照着 README 走复现步骤就是 403/404。根因通常一句话——容器里跑的镜像 tag 和该环境要求的漏洞版本不一致。每个环境要求哪个镜像是锁死的environments.toml 和目录内的 docker-compose.yml 都写得很清楚比如 s2-045 对应vulhub/struts2:2.3.30GhostcatCVE-2020-1938对应vulhub/tomcat:9.0.30。先查你实际跑的是什么docker compose config | grep image # 看 compose 解析出来的 tag docker ps --format {{.Names}} {{.Image}} # 看实际运行中的镜像对不上就彻底清掉再拉让 compose 按配置拉回正确版本docker compose down -v # 连数据卷一起清避免旧数据干扰新环境 docker compose pull docker compose up -d起来之后先做最简单的连通性验证再按 README 逐步打 PoC。以 Cacti 环境为例请求发出后响应里能看到敏感字段说明环境已可用Tomcat Ghostcat 环境也可以借助检测页确认服务确实带漏洞看到 Ghostcat exists 即环境就绪故障对照卡主线没展开的边角问题直接查表现象根因一句话处置拉取报 429 或 rate limitDocker Hub 对匿名拉取限流换镜像源或docker login后重试容器 Up 但访问无响应服务没起全或应用自身崩溃docker compose logs --tail 50浏览器访问your-ip超时VPS 防火墙/安全组没放行放行对应映射端口如 8081down后再起报卷冲突旧数据卷与新环境冲突docker compose down -v清卷启动报Permission denied用户对目录无读权限换有权限的用户运行 Docker日志出现exec format error镜像架构与主机不匹配export DOCKER_DEFAULT_PLATFORMlinux/amd64收尾三个长效习惯测完就清场。每复现完一个环境立刻docker compose down -v否则端口和磁盘会越堆越满下一次端口被占就是自己造成的。先看日志再改配置。九成问题的原因日志里直接写明了反复重启容器只会让故障拖得更久。别动镜像 tag。镜像版本是 README 里锁死的手痒换了 tagPoC 打不通这种玄学问题就出现了。如果你手上正卡着某个环境先对着上面对号入座跑一遍再把卡住的报错原文留言发出来——原文越具体定位越快。免责声明本文所有漏洞环境仅供合法授权环境下的安全学习与研究使用严禁将文中命令与 PoC 用于任何未授权系统。【免费下载链接】vulhubPre-Built Vulnerable Environments Based on Docker-Compose项目地址: https://gitcode.com/GitHub_Trending/vu/vulhub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考