1. 项目概述为什么我们需要一个企业级漏洞测试平台在安全圈子里混了十几年我见过太多团队在安全测试这件事上“凑合”。开发同学临时搭个靶场结果环境死活起不来安全工程师想复现一个CVE花半天时间配环境漏洞还没摸到热情先耗光了。更别提在企业里新员工入职安全培训、红蓝对抗演练、产品上线前的安全自检如果每次都要从零开始折腾效率低不说还容易出错。这就是为什么一个稳定、可控、可复现的企业级漏洞测试平台不是“锦上添花”而是“雪中送炭”的基建。Vulhub的出现恰好解决了这个痛点。它不是一个复杂的平台软件而是一个精心编排的漏洞环境“食谱”集合。你可以把它理解为一个漏洞博物馆的“展品清单”和“搭建说明书”。它的核心价值在于“标准化”和“可复现”。任何一个已知的漏洞从古老的Struts2到最新的Spring Cloud GatewayVulhub都为你准备好了开箱即用的Docker Compose配置。你不需要去研究漏洞的依赖项、特定版本的服务配置甚至不需要深厚的Docker知识一条命令环境就绪。但把Vulhub用在一个人的电脑上和把它部署成一个团队乃至整个公司都能随时使用的“平台”中间隔着巨大的鸿沟。个人使用你可能只关心“这个漏洞能不能复现”但在企业级场景下你需要考虑的是环境如何持久化并供多人同时访问如何管理数十上百个不同的漏洞环境镜像如何控制资源消耗避免某个测试把服务器拖垮如何与现有的CI/CD流程或安全运营平台SOAR对接这些就是“从零搭建企业级漏洞测试平台”要解决的核心问题。这不是简单地跑通Vulhub的README而是以Vulhub为基石构建一套可持续运营的安全测试基础设施。2. 平台架构设计与核心思路拆解搭建企业级平台第一步不是敲命令而是画蓝图。我们需要一个清晰、可扩展且易于维护的架构。直接在一台物理服务器上裸跑Docker是最简单的但也是最脆弱的。我推荐的是一种分层架构它能让平台更健壮。2.1 核心架构三层分离模型我的设计思路是“三层分离”资源层、服务层和应用层。资源层是基石通常是一台或多台Linux服务器物理机或云主机。我强烈建议使用Ubuntu Server LTS版本比如22.04或24.04它在内核版本、软件包管理和Docker兼容性上最为均衡。如果预算和需求允许可以采用Kubernetes集群作为资源层这为未来的弹性伸缩和高级调度打下了基础但对于初期或中小团队一台配置足够的宿主机建议至少4核CPU8GB内存100GB SSD存储完全够用。服务层是核心运行在资源层之上。这里的主角当然是Docker Engine。但仅仅安装Docker是不够的。我们需要一套编排和管理的“管家系统”。我的方案是Docker Engine Docker Compose Plugin 反向代理Nginx/Traefik 监控cAdvisor Prometheus。Docker Compose Plugin内置于现代Docker用于定义和启动Vulhub的多个环境反向代理负责将不同的漏洞环境每个环境可能运行在不同的容器端口上通过统一的域名或路径暴露给内网用户监控组件则让我们能实时掌握CPU、内存、网络IO避免某个“重量级”漏洞环境比如一个包含完整Weblogic的漏洞吃光所有资源。应用层是用户直接交互的部分。最轻量的方式就是通过反向代理生成一个Web访问列表。例如访问http://vulhub-platform.internal.company.com/cve-2017-5638就能自动代理到运行Apache Struts2 S2-045漏洞环境的容器。更进一步我们可以开发一个简单的Web门户用数据库记录环境状态、使用记录甚至集成用户认证和权限管理。但对于MVP最小可行产品而言一个清晰的Nginx配置加上一个静态HTML索引页已经能解决80%的问题。2.2 方案选型背后的考量为什么是Docker Compose而非K8s很多刚接触容器化的朋友会想既然是企业级是不是直接上Kubernetes更“高大上”我的经验是杀鸡勿用牛刀合适比先进更重要。Vulhub的每个漏洞环境本质上都是一个独立的、一次性ephemeral的测试沙盒。它的生命周期通常是“创建 - 测试 - 销毁”。我们几乎不需要对这个环境进行滚动更新、服务发现、复杂负载均衡。Docker Compose完美匹配了这个场景一个docker-compose.yml文件定义一组服务比如一个带漏洞的Web应用和其数据库一条docker compose up命令拉起整个环境。它的学习成本低配置直观与Vulhub项目原生兼容。相反如果使用K8s我们需要为每个漏洞环境编写Deployment、Service、Ingress等一堆YAML文件引入了Pod调度、网络策略等复杂性但并没有带来对等的好处。当然如果你的企业已经全面K8s化有成熟的运维体系将Vulhub环境打包成Helm Chart在K8s中运行可以实现更精细的资源配额和命名空间隔离这是后话。对于从零开始Docker Compose是最高效、最稳妥的起点。2.3 存储与网络规划容易被忽略的关键存储和网络是平台稳定性的“暗礁”。Vulhub环境在拉取镜像和启动时会在/var/lib/docker产生大量数据。我们必须确保宿主机有充足的空间建议预留50GB以上。更关键的是所有Vulhub环境目录即你clone下来的代码应该放在一个独立的数据盘或分区并做好定期备份。因为你的平台配置、自定义脚本都存放在这里。网络方面我建议为这个平台单独规划一个VLAN或子网。所有漏洞环境容器使用一个自定义的Docker网络例如vulhub-net而不是默认的bridge。这样做有两个好处一是隔离避免漏洞测试环境意外访问到生产网络二是便于管理我们可以在这个自定义网络上为Nginx反向代理配置固定的容器别名实现稳定的内部服务发现。3. 基础环境部署与核心组件配置理论说完我们开始动手。假设我们有一台全新的Ubuntu 22.04 LTS服务器主机名设为vulhub-platform。3.1 宿主机系统级优化在安装任何服务前先对宿主机进行基础优化这能避免很多后期奇怪的问题。# 更新系统并安装常用工具 sudo apt update sudo apt upgrade -y sudo apt install -y curl wget git vim net-tools htop # 调整系统参数防止Docker容器过多导致“无法打开更多文件”的错误 echo fs.file-max 6553560 | sudo tee -a /etc/sysctl.conf echo * soft nofile 65535 | sudo tee -a /etc/security/limits.conf echo * hard nofile 65535 | sudo tee -a /etc/security/limits.conf echo session required pam_limits.so | sudo tee -a /etc/pam.d/common-session sudo sysctl -p注意ulimit设置对于运行像Elasticsearch这类在Kali上可能出问题的漏洞环境至关重要。很多Docker容器内部会继承宿主机的限制。3.2 Docker与Docker Compose Plugin安装遵循Vulhub的推荐我们使用官方脚本安装Docker。这里有个小技巧使用国内镜像加速安装过程。# 使用阿里云镜像站下载安装脚本速度更快 curl -fsSL https://get.docker.com -o get-docker.sh # 或者直接使用国内镜像 # curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun sudo sh get-docker.sh # 将当前用户加入docker组避免每次都要sudo sudo usermod -aG docker $USER newgrp docker # 刷新组权限或退出重新登录 # 验证安装 docker --version现代Docker20.10.0以上版本已经内置了Compose Plugin我们不需要单独安装docker-compose命令行工具。验证方式docker compose version如果输出类似Docker Compose version v2.24.0说明一切就绪。3.3 配置Docker镜像加速与存储驱动为了后续快速拉取漏洞环境镜像必须配置镜像加速器。这里以阿里云容器镜像服务为例需要注册阿里云账号获取专属加速器地址。sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [https://your-own-mirror.mirror.aliyuncs.com], log-driver: json-file, log-opts: { max-size: 100m, max-file: 3 }, storage-driver: overlay2 } EOF将https://your-own-mirror.mirror.aliyuncs.com替换为你从阿里云控制台获取的真实地址。log-driver配置防止容器日志撑爆磁盘storage-driver使用性能更好的overlay2。# 重启Docker服务使配置生效 sudo systemctl daemon-reload sudo systemctl restart docker sudo systemctl enable docker3.4 部署Nginx作为反向代理网关我们将使用Nginx作为统一入口根据访问路径将请求分发到不同的漏洞环境容器。# 安装Nginx sudo apt install -y nginx # 创建平台专用的Nginx配置目录 sudo mkdir -p /etc/nginx/vulhub-platform接下来创建主配置文件/etc/nginx/vulhub-platform/vulhub-proxy.conf。这个配置的核心思路是使用map指令和proxy_pass。# /etc/nginx/vulhub-platform/vulhub-proxy.conf # 定义一个映射将访问路径前缀映射到对应的容器服务名和端口 map $request_uri $backend { default localhost:8080; # 默认页或未匹配时 ~^/cve-2017-5638(/|$) vulhub_struts2_s2-045:8080; ~^/cve-2014-6271(/|$) vulhub_bash_shellshock:80; ~^/cve-2017-7494(/|$) vulhub_samba_cve-2017-7494:139; # 后续每新增一个环境就在这里添加一行映射 } server { listen 80; server_name vulhub-platform.internal.company.com; # 替换为你的内网域名或IP location / { # 如果路径匹配到映射则代理到对应的容器 if ($backend) { proxy_pass http://$backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } # 如果没有匹配访问根路径则展示一个静态索引页 root /var/www/vulhub-index; index index.html; try_files $uri $uri/ 404; } }这里有个关键点vulhub_struts2_s2-045:8080中的vulhub_struts2_s2-045是我们在Docker Compose文件中为服务定义的名字8080是该服务容器内部暴露的端口。Nginx必须能通过这个服务名解析到容器的IP这要求Nginx容器和漏洞环境容器在同一个Docker网络中。我们将在后面创建这个网络。然后在Nginx的主配置/etc/nginx/nginx.conf的http块内包含我们的自定义配置http { ... include /etc/nginx/vulhub-platform/*.conf; }最后创建索引页目录和文件sudo mkdir -p /var/www/vulhub-index sudo tee /var/www/vulhub-index/index.html -EOF !DOCTYPE html html headtitle企业漏洞测试平台/title/head body h1漏洞环境列表/h1 ul lia href/cve-2017-5638CVE-2017-5638 - Apache Struts2 S2-045/a/li lia href/cve-2014-6271CVE-2014-6271 - Bash Shellshock/a/li !-- 后续动态生成或手动添加 -- /ul /body /html EOF sudo nginx -t # 测试配置 sudo systemctl reload nginx4. Vulhub环境集成与平台化改造现在基础服务已经就绪我们要把Vulhub本身“请”进来并把它改造成适合平台化运行的样子。4.1 获取与组织Vulhub代码我们不建议直接在平台服务器上git clone因为这样会包含完整的git历史体积大且更新麻烦。更好的方式是定期下载归档的发布版本或者使用git clone --depth 1只拉取最新代码。# 在平台数据目录下操作 cd /opt sudo git clone --depth 1 https://github.com/vulhub/vulhub.git sudo chown -R $USER:$USER vulhub/ # 更改属主方便操作此时/opt/vulhub目录下是按漏洞分类的无数个子目录。我们需要为平台运行建立一个“工作区”。mkdir -p /opt/vulhub-platform/environments cd /opt/vulhub-platform我的策略是不为每个漏洞环境单独维护一份docker-compose.yml而是通过符号链接symlink指向Vulhub原目录。这样做的好处是当Vulhub官方更新时我们只需要更新源目录所有链接自动生效。# 示例将Struts2 S2-045环境链接到平台工作区 ln -s /opt/vulhub/struts2/s2-045 /opt/vulhub-platform/environments/cve-2017-5638这样我们在/opt/vulhub-platform/environments下管理的就是一个个清晰的、以CVE编号或漏洞名称命名的目录每个目录都链接着真实的Vulhub配置。4.2 创建统一的Docker网络为了让所有漏洞环境容器和Nginx能互相通信我们需要创建一个自定义的Docker网络。docker network create vulhub-platform-net这个网络名字vulhub-platform-net需要与前面Nginx配置中proxy_pass使用的网络名对应。但注意Nginx配置里写的是服务名Docker Compose会自动在它所属的网络中将服务名解析为容器的IP。因此我们需要确保每个漏洞环境的docker-compose.yml文件都指定使用这个网络。4.3 改造Vulhub的docker-compose.yml这是最关键的一步。Vulhub原生的docker-compose.yml是为单次、独立运行设计的。我们需要对它进行平台化改造主要涉及三点网络、容器命名、资源限制。以/opt/vulhub/struts2/s2-045/docker-compose.yml为例原始内容可能很简单version: 2 services: web: image: vulhub/struts2:2.3.32-s2-045 ports: - 8080:8080我们需要将其改造为version: 3.8 # 使用较新的版本以支持更多特性 services: vulhub_struts2_s2-045: # 服务名改为全局唯一且具有描述性的名字 image: vulhub/struts2:2.3.32-s2-045 container_name: platform_struts2_s2_045_${INSTANCE_ID:-default} # 容器名加入实例ID支持多实例 networks: - vulhub-platform-net # 加入我们创建的统一网络 # ports: # 注释掉端口映射我们不直接暴露宿主机端口 # - 8080:8080 expose: - 8080 # 只在Docker网络内部暴露端口 deploy: # 使用deploy限制资源Compose v3语法 resources: limits: cpus: 1 # 限制最多使用1个CPU核心 memory: 512M # 限制最多使用512MB内存 restart: no # 漏洞环境通常不需要自动重启 labels: - vulhub.platform.environmenttrue - vulhub.cveCVE-2017-5638 networks: vulhub-platform-net: external: true # 使用外部已创建的网络改造要点解析服务名改为vulhub_struts2_s2-045与Nginx配置中的$backend映射严格对应。这是服务发现的关键。网络加入vulhub-platform-net并声明为external。这确保了所有环境在同一个“局域网”内。端口将ports映射改为expose。expose只向Docker网络内的其他容器公开端口而不绑定到宿主机端口更安全也避免了端口冲突。资源限制使用deploy.resources.limits为容器设置CPU和内存上限。这是企业级平台防止单个环境耗尽资源、影响其他环境或宿主机稳定的必备措施。标签添加labels便于后期用Docker命令过滤和管理所有平台创建的环境。我们需要为每一个计划集成到平台的漏洞环境都做这样的改造。可以编写一个脚本来自动化这个过程。4.4 编写环境管理脚本手动进入每个目录执行docker compose up -d太低效。我们需要一个中心化的管理脚本。创建/opt/vulhub-platform/manage.sh#!/bin/bash # 企业级Vulhub平台管理脚本 ENV_ROOT/opt/vulhub-platform/environments NETWORKvulhub-platform-net case $1 in start) ENV_NAME$2 if [ -z $ENV_NAME ]; then echo Usage: $0 start environment-name exit 1 fi ENV_PATH$ENV_ROOT/$ENV_NAME if [ ! -d $ENV_PATH ]; then echo 环境目录不存在: $ENV_PATH exit 1 fi cd $ENV_PATH # 注入实例ID例如时间戳用于支持同一环境多实例 export INSTANCE_ID$(date %s) docker compose up -d echo 环境 [$ENV_NAME] 启动成功实例ID: $INSTANCE_ID ;; stop) ENV_NAME$2 if [ -z $ENV_NAME ]; then echo Usage: $0 stop environment-name exit 1 fi ENV_PATH$ENV_ROOT/$ENV_NAME if [ ! -d $ENV_PATH ]; then echo 环境目录不存在: $ENV_PATH exit 1 fi cd $ENV_PATH docker compose down -v echo 环境 [$ENV_NAME] 已停止并清理 ;; list) echo 已集成的漏洞环境: for env in $(ls -1 $ENV_ROOT); do if [ -f $ENV_ROOT/$env/docker-compose.yml ]; then echo - $env fi done echo echo 正在运行的环境容器: docker ps --filter labelvulhub.platform.environmenttrue --format table {{.Names}}\t{{.Status}}\t{{.Ports}} ;; status) ENV_NAME$2 if [ -z $ENV_NAME ]; then docker ps -a --filter labelvulhub.platform.environmenttrue else docker ps -a --filter labelvulhub.cve$ENV_NAME fi ;; update) # 更新Vulhub源 cd /opt/vulhub git pull origin master echo Vulhub源码更新完成。请注意检查现有环境的docker-compose.yml是否需要同步更新。 ;; *) echo 企业级Vulhub平台管理工具 echo 用法: $0 {start|stop|list|status|update} [环境名] exit 1 ;; esac给脚本执行权限chmod x /opt/vulhub-platform/manage.sh。现在你可以通过./manage.sh list查看环境通过./manage.sh start cve-2017-5638一键启动环境。5. 平台运维、监控与安全加固平台搭建起来只是第一步让它稳定、安全、易用地运行起来才是真正的挑战。5.1 资源监控与告警无监控不运维。我们需要知道平台的整体资源消耗和每个漏洞环境的运行状态。一个轻量级的方案是使用cAdvisor容器监控 Prometheus指标存储 Grafana可视化。# 使用Docker Compose部署监控栈 cd /opt/vulhub-platform mkdir -p monitoring cd monitoring创建docker-compose-monitor.yml:version: 3.8 services: cadvisor: image: gcr.io/cadvisor/cadvisor:latest container_name: cadvisor privileged: true devices: - /dev/kmsg:/dev/kmsg volumes: - /:/rootfs:ro - /var/run:/var/run:ro - /sys:/sys:ro - /var/lib/docker/:/var/lib/docker:ro ports: - 8081:8080 networks: - monitor-net restart: unless-stopped prometheus: image: prom/prometheus:latest container_name: prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - prometheus_data:/prometheus command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.path/prometheus - --web.console.libraries/etc/prometheus/console_libraries - --web.console.templates/etc/prometheus/consoles - --storage.tsdb.retention.time200h - --web.enable-lifecycle ports: - 9090:9090 networks: - monitor-net restart: unless-stopped grafana: image: grafana/grafana:latest container_name: grafana volumes: - grafana_data:/var/lib/grafana environment: - GF_SECURITY_ADMIN_PASSWORDadmin123 # 请修改 ports: - 3000:3000 networks: - monitor-net restart: unless-stopped networks: monitor-net: name: monitor-net volumes: prometheus_data: grafana_data:创建Prometheus配置文件prometheus.yml:global: scrape_interval: 15s scrape_configs: - job_name: cadvisor static_configs: - targets: [cadvisor:8080] - job_name: node static_configs: - targets: [your-host-ip:9100] # 需要额外安装node-exporter启动监控栈docker compose -f docker-compose-monitor.yml up -d。访问http://your-server-ip:3000登录Grafana初始账号admin/你设置的密码添加Prometheus数据源地址填http://prometheus:9090然后导入cAdvisor相关的Dashboard如ID193即可看到容器级别的CPU、内存、网络、磁盘监控图表。5.2 日志集中收集Docker容器的日志默认在/var/lib/docker/containers/下分散且不易查看。我们可以配置Docker的日志驱动为json-file并设置大小前面已做同时使用docker logs命令查看。对于平台化运维可以进一步使用docker-compose logs -f [service-name]来查看特定环境的日志。更高级的方案是集成ELK或Loki但对于初期平台一个简单的日志轮转和归档脚本已经足够。在/etc/logrotate.d/docker-vulhub中配置/var/lib/docker/containers/*/*.log { daily rotate 7 compress delaycompress missingok copytruncate }5.3 安全加固措施漏洞测试平台本身必须安全不能成为新的攻击入口。网络隔离我们已经使用了自定义的Docker网络。此外应在宿主机防火墙如UFW中只允许特定IP段如公司内网访问平台的80端口Nginx和监控端口如3000, 9090。sudo ufw allow from 10.0.0.0/8 to any port 80 proto tcp sudo ufw allow from 10.0.0.0/8 to any port 3000 proto tcp sudo ufw --force enable容器安全非Root用户运行在改造docker-compose.yml时尽可能在镜像支持的情况下通过user:指令指定非root用户运行容器进程。只读根文件系统对于大多数漏洞环境容器内部不需要写入。可以添加read_only: true来增强安全性。限制能力使用cap_drop:丢弃所有不必要的Linux能力如ALL然后按需添加。例如一个Web应用通常不需要SYS_ADMIN能力。镜像安全定期扫描平台使用的漏洞镜像是否有新的安全漏洞。可以使用trivy或docker scout等工具。# 示例使用Trivy扫描镜像 docker pull vulhub/struts2:2.3.32-s2-045 trivy image vulhub/struts2:2.3.32-s2-045访问控制基础的Nginx索引页没有任何权限控制。在生产环境至少应该配置HTTP Basic认证或者集成公司的单点登录SSO。可以在Nginx配置的location /块中添加auth_basic Vulhub Platform; auth_basic_user_file /etc/nginx/.htpasswd;使用htpasswd命令创建用户密码文件。6. 典型问题排查与实战技巧在实际运营中你会遇到各种各样的问题。这里记录几个最常见的问题和我的解决思路。6.1 环境启动失败镜像拉取超时或错误这是最常见的问题尤其在国内网络环境下。现象docker compose up -d时卡在Pulling或报错net/http: TLS handshake timeout。排查首先docker pull单独拉取镜像确认是否是网络问题。解决确认/etc/docker/daemon.json中的镜像加速器配置正确且生效sudo systemctl restart docker。对于某些特别大的镜像可以尝试在夜间网络空闲时拉取。如果加速器也不行考虑在海外VPS上拉取镜像然后导出为tar文件再导入到平台服务器# 在海外机器 docker pull vulhub/xxx:tag docker save vulhub/xxx:tag -o xxx.tar # 将xxx.tar传输到平台服务器 # 在平台服务器 docker load -i xxx.tar6.2 容器启动后服务不可访问现象docker compose up -d成功但通过Nginx访问返回502 Bad Gateway或连接超时。排查步骤检查容器状态docker ps查看对应容器是否处于Up状态。如果是Exited用docker logs container_id查看启动日志。检查容器内服务进入容器内部检查服务是否真的在监听端口。docker exec -it container_name sh然后netstat -tlnp或ps aux。检查网络连通性在Nginx容器内如果Nginx也容器化或在宿主机上使用docker network inspect vulhub-platform-net查看容器IP然后尝试curl http://容器IP:内部端口。检查Nginx配置确认Nginx配置中的proxy_pass地址服务名和端口与docker-compose.yml中的services名称和expose端口完全一致。服务名不能包含下划线以外的特殊字符且需在同一个网络。检查防火墙确保宿主机防火墙和Docker自身的防火墙规则如果有没有阻断容器间通信。6.3 平台性能突然下降现象平台响应变慢甚至影响宿主机。排查快速定位问题容器使用docker stats命令实时查看所有容器的CPU、内存占用。一眼就能看出哪个容器是“资源黑洞”。检查监控查看Grafana Dashboard确认是CPU、内存还是磁盘IO瓶颈。常见原因与解决某个漏洞环境被恶意循环攻击在测试时如果利用脚本写错了可能变成对平台自身的DoS攻击。通过docker logs查看异常请求并临时docker pause该容器。磁盘空间不足Docker的日志、镜像、容器层会占用大量空间。定期清理docker system prune -a -f谨慎使用会清理未使用的镜像、容器、网络。更安全的是只清理日志find /var/lib/docker/containers/ -name \*.log\ -size 100M -delete。内存泄漏某些老旧的漏洞应用可能存在内存泄漏。为容器设置更严格的内存限制mem_limit并在达到限制后自动重启在docker-compose.yml中配置restart: on-failure。6.4 如何管理多个并发的相同环境有时培训或演练需要多个学员同时操作同一个漏洞但又不希望互相干扰。解决方案利用我们脚本中的INSTANCE_ID变量和Docker Compose的项目名-p参数功能。操作启动环境时指定不同的项目名它们会创建独立的容器组但共享相同的镜像和配置。cd /opt/vulhub-platform/environments/cve-2017-5638 export INSTANCE_IDteam_a docker compose -p vulhub_struts2_team_a up -d export INSTANCE_IDteam_b docker compose -p vulhub_struts2_team_b up -d此时会启动两组容器服务名会带上前缀例如vulhub_struts2_team_a_vulhub_struts2_s2-045_1。你需要在Nginx配置中为team_a和team_b配置不同的访问路径和反向代理规则。这虽然增加了配置复杂性但实现了真正的多租户隔离。搭建企业级漏洞测试平台技术实现只是骨架真正的血肉是围绕它建立的流程和规范。比如规定所有新的漏洞环境在集成前必须经过资源评估和安全扫描建立定期更新机制同步Vulhub官方的最新漏洞环境编写详细的使用手册和培训材料。这个平台的价值会随着使用它的次数和人数呈指数级增长。它从一个小工具逐渐演变为企业安全能力的一部分让安全测试从一种“手艺”变成一种可重复、可衡量的“工艺”。
基于Vulhub与Docker Compose构建企业级漏洞测试平台
发布时间：2026/7/4 18:31:11
1. 项目概述为什么我们需要一个企业级漏洞测试平台在安全圈子里混了十几年我见过太多团队在安全测试这件事上“凑合”。开发同学临时搭个靶场结果环境死活起不来安全工程师想复现一个CVE花半天时间配环境漏洞还没摸到热情先耗光了。更别提在企业里新员工入职安全培训、红蓝对抗演练、产品上线前的安全自检如果每次都要从零开始折腾效率低不说还容易出错。这就是为什么一个稳定、可控、可复现的企业级漏洞测试平台不是“锦上添花”而是“雪中送炭”的基建。Vulhub的出现恰好解决了这个痛点。它不是一个复杂的平台软件而是一个精心编排的漏洞环境“食谱”集合。你可以把它理解为一个漏洞博物馆的“展品清单”和“搭建说明书”。它的核心价值在于“标准化”和“可复现”。任何一个已知的漏洞从古老的Struts2到最新的Spring Cloud GatewayVulhub都为你准备好了开箱即用的Docker Compose配置。你不需要去研究漏洞的依赖项、特定版本的服务配置甚至不需要深厚的Docker知识一条命令环境就绪。但把Vulhub用在一个人的电脑上和把它部署成一个团队乃至整个公司都能随时使用的“平台”中间隔着巨大的鸿沟。个人使用你可能只关心“这个漏洞能不能复现”但在企业级场景下你需要考虑的是环境如何持久化并供多人同时访问如何管理数十上百个不同的漏洞环境镜像如何控制资源消耗避免某个测试把服务器拖垮如何与现有的CI/CD流程或安全运营平台SOAR对接这些就是“从零搭建企业级漏洞测试平台”要解决的核心问题。这不是简单地跑通Vulhub的README而是以Vulhub为基石构建一套可持续运营的安全测试基础设施。2. 平台架构设计与核心思路拆解搭建企业级平台第一步不是敲命令而是画蓝图。我们需要一个清晰、可扩展且易于维护的架构。直接在一台物理服务器上裸跑Docker是最简单的但也是最脆弱的。我推荐的是一种分层架构它能让平台更健壮。2.1 核心架构三层分离模型我的设计思路是“三层分离”资源层、服务层和应用层。资源层是基石通常是一台或多台Linux服务器物理机或云主机。我强烈建议使用Ubuntu Server LTS版本比如22.04或24.04它在内核版本、软件包管理和Docker兼容性上最为均衡。如果预算和需求允许可以采用Kubernetes集群作为资源层这为未来的弹性伸缩和高级调度打下了基础但对于初期或中小团队一台配置足够的宿主机建议至少4核CPU8GB内存100GB SSD存储完全够用。服务层是核心运行在资源层之上。这里的主角当然是Docker Engine。但仅仅安装Docker是不够的。我们需要一套编排和管理的“管家系统”。我的方案是Docker Engine Docker Compose Plugin 反向代理Nginx/Traefik 监控cAdvisor Prometheus。Docker Compose Plugin内置于现代Docker用于定义和启动Vulhub的多个环境反向代理负责将不同的漏洞环境每个环境可能运行在不同的容器端口上通过统一的域名或路径暴露给内网用户监控组件则让我们能实时掌握CPU、内存、网络IO避免某个“重量级”漏洞环境比如一个包含完整Weblogic的漏洞吃光所有资源。应用层是用户直接交互的部分。最轻量的方式就是通过反向代理生成一个Web访问列表。例如访问http://vulhub-platform.internal.company.com/cve-2017-5638就能自动代理到运行Apache Struts2 S2-045漏洞环境的容器。更进一步我们可以开发一个简单的Web门户用数据库记录环境状态、使用记录甚至集成用户认证和权限管理。但对于MVP最小可行产品而言一个清晰的Nginx配置加上一个静态HTML索引页已经能解决80%的问题。2.2 方案选型背后的考量为什么是Docker Compose而非K8s很多刚接触容器化的朋友会想既然是企业级是不是直接上Kubernetes更“高大上”我的经验是杀鸡勿用牛刀合适比先进更重要。Vulhub的每个漏洞环境本质上都是一个独立的、一次性ephemeral的测试沙盒。它的生命周期通常是“创建 - 测试 - 销毁”。我们几乎不需要对这个环境进行滚动更新、服务发现、复杂负载均衡。Docker Compose完美匹配了这个场景一个docker-compose.yml文件定义一组服务比如一个带漏洞的Web应用和其数据库一条docker compose up命令拉起整个环境。它的学习成本低配置直观与Vulhub项目原生兼容。相反如果使用K8s我们需要为每个漏洞环境编写Deployment、Service、Ingress等一堆YAML文件引入了Pod调度、网络策略等复杂性但并没有带来对等的好处。当然如果你的企业已经全面K8s化有成熟的运维体系将Vulhub环境打包成Helm Chart在K8s中运行可以实现更精细的资源配额和命名空间隔离这是后话。对于从零开始Docker Compose是最高效、最稳妥的起点。2.3 存储与网络规划容易被忽略的关键存储和网络是平台稳定性的“暗礁”。Vulhub环境在拉取镜像和启动时会在/var/lib/docker产生大量数据。我们必须确保宿主机有充足的空间建议预留50GB以上。更关键的是所有Vulhub环境目录即你clone下来的代码应该放在一个独立的数据盘或分区并做好定期备份。因为你的平台配置、自定义脚本都存放在这里。网络方面我建议为这个平台单独规划一个VLAN或子网。所有漏洞环境容器使用一个自定义的Docker网络例如vulhub-net而不是默认的bridge。这样做有两个好处一是隔离避免漏洞测试环境意外访问到生产网络二是便于管理我们可以在这个自定义网络上为Nginx反向代理配置固定的容器别名实现稳定的内部服务发现。3. 基础环境部署与核心组件配置理论说完我们开始动手。假设我们有一台全新的Ubuntu 22.04 LTS服务器主机名设为vulhub-platform。3.1 宿主机系统级优化在安装任何服务前先对宿主机进行基础优化这能避免很多后期奇怪的问题。# 更新系统并安装常用工具 sudo apt update sudo apt upgrade -y sudo apt install -y curl wget git vim net-tools htop # 调整系统参数防止Docker容器过多导致“无法打开更多文件”的错误 echo fs.file-max 6553560 | sudo tee -a /etc/sysctl.conf echo * soft nofile 65535 | sudo tee -a /etc/security/limits.conf echo * hard nofile 65535 | sudo tee -a /etc/security/limits.conf echo session required pam_limits.so | sudo tee -a /etc/pam.d/common-session sudo sysctl -p注意ulimit设置对于运行像Elasticsearch这类在Kali上可能出问题的漏洞环境至关重要。很多Docker容器内部会继承宿主机的限制。3.2 Docker与Docker Compose Plugin安装遵循Vulhub的推荐我们使用官方脚本安装Docker。这里有个小技巧使用国内镜像加速安装过程。# 使用阿里云镜像站下载安装脚本速度更快 curl -fsSL https://get.docker.com -o get-docker.sh # 或者直接使用国内镜像 # curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun sudo sh get-docker.sh # 将当前用户加入docker组避免每次都要sudo sudo usermod -aG docker $USER newgrp docker # 刷新组权限或退出重新登录 # 验证安装 docker --version现代Docker20.10.0以上版本已经内置了Compose Plugin我们不需要单独安装docker-compose命令行工具。验证方式docker compose version如果输出类似Docker Compose version v2.24.0说明一切就绪。3.3 配置Docker镜像加速与存储驱动为了后续快速拉取漏洞环境镜像必须配置镜像加速器。这里以阿里云容器镜像服务为例需要注册阿里云账号获取专属加速器地址。sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [https://your-own-mirror.mirror.aliyuncs.com], log-driver: json-file, log-opts: { max-size: 100m, max-file: 3 }, storage-driver: overlay2 } EOF将https://your-own-mirror.mirror.aliyuncs.com替换为你从阿里云控制台获取的真实地址。log-driver配置防止容器日志撑爆磁盘storage-driver使用性能更好的overlay2。# 重启Docker服务使配置生效 sudo systemctl daemon-reload sudo systemctl restart docker sudo systemctl enable docker3.4 部署Nginx作为反向代理网关我们将使用Nginx作为统一入口根据访问路径将请求分发到不同的漏洞环境容器。# 安装Nginx sudo apt install -y nginx # 创建平台专用的Nginx配置目录 sudo mkdir -p /etc/nginx/vulhub-platform接下来创建主配置文件/etc/nginx/vulhub-platform/vulhub-proxy.conf。这个配置的核心思路是使用map指令和proxy_pass。# /etc/nginx/vulhub-platform/vulhub-proxy.conf # 定义一个映射将访问路径前缀映射到对应的容器服务名和端口 map $request_uri $backend { default localhost:8080; # 默认页或未匹配时 ~^/cve-2017-5638(/|$) vulhub_struts2_s2-045:8080; ~^/cve-2014-6271(/|$) vulhub_bash_shellshock:80; ~^/cve-2017-7494(/|$) vulhub_samba_cve-2017-7494:139; # 后续每新增一个环境就在这里添加一行映射 } server { listen 80; server_name vulhub-platform.internal.company.com; # 替换为你的内网域名或IP location / { # 如果路径匹配到映射则代理到对应的容器 if ($backend) { proxy_pass http://$backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } # 如果没有匹配访问根路径则展示一个静态索引页 root /var/www/vulhub-index; index index.html; try_files $uri $uri/ 404; } }这里有个关键点vulhub_struts2_s2-045:8080中的vulhub_struts2_s2-045是我们在Docker Compose文件中为服务定义的名字8080是该服务容器内部暴露的端口。Nginx必须能通过这个服务名解析到容器的IP这要求Nginx容器和漏洞环境容器在同一个Docker网络中。我们将在后面创建这个网络。然后在Nginx的主配置/etc/nginx/nginx.conf的http块内包含我们的自定义配置http { ... include /etc/nginx/vulhub-platform/*.conf; }最后创建索引页目录和文件sudo mkdir -p /var/www/vulhub-index sudo tee /var/www/vulhub-index/index.html -EOF !DOCTYPE html html headtitle企业漏洞测试平台/title/head body h1漏洞环境列表/h1 ul lia href/cve-2017-5638CVE-2017-5638 - Apache Struts2 S2-045/a/li lia href/cve-2014-6271CVE-2014-6271 - Bash Shellshock/a/li !-- 后续动态生成或手动添加 -- /ul /body /html EOF sudo nginx -t # 测试配置 sudo systemctl reload nginx4. Vulhub环境集成与平台化改造现在基础服务已经就绪我们要把Vulhub本身“请”进来并把它改造成适合平台化运行的样子。4.1 获取与组织Vulhub代码我们不建议直接在平台服务器上git clone因为这样会包含完整的git历史体积大且更新麻烦。更好的方式是定期下载归档的发布版本或者使用git clone --depth 1只拉取最新代码。# 在平台数据目录下操作 cd /opt sudo git clone --depth 1 https://github.com/vulhub/vulhub.git sudo chown -R $USER:$USER vulhub/ # 更改属主方便操作此时/opt/vulhub目录下是按漏洞分类的无数个子目录。我们需要为平台运行建立一个“工作区”。mkdir -p /opt/vulhub-platform/environments cd /opt/vulhub-platform我的策略是不为每个漏洞环境单独维护一份docker-compose.yml而是通过符号链接symlink指向Vulhub原目录。这样做的好处是当Vulhub官方更新时我们只需要更新源目录所有链接自动生效。# 示例将Struts2 S2-045环境链接到平台工作区 ln -s /opt/vulhub/struts2/s2-045 /opt/vulhub-platform/environments/cve-2017-5638这样我们在/opt/vulhub-platform/environments下管理的就是一个个清晰的、以CVE编号或漏洞名称命名的目录每个目录都链接着真实的Vulhub配置。4.2 创建统一的Docker网络为了让所有漏洞环境容器和Nginx能互相通信我们需要创建一个自定义的Docker网络。docker network create vulhub-platform-net这个网络名字vulhub-platform-net需要与前面Nginx配置中proxy_pass使用的网络名对应。但注意Nginx配置里写的是服务名Docker Compose会自动在它所属的网络中将服务名解析为容器的IP。因此我们需要确保每个漏洞环境的docker-compose.yml文件都指定使用这个网络。4.3 改造Vulhub的docker-compose.yml这是最关键的一步。Vulhub原生的docker-compose.yml是为单次、独立运行设计的。我们需要对它进行平台化改造主要涉及三点网络、容器命名、资源限制。以/opt/vulhub/struts2/s2-045/docker-compose.yml为例原始内容可能很简单version: 2 services: web: image: vulhub/struts2:2.3.32-s2-045 ports: - 8080:8080我们需要将其改造为version: 3.8 # 使用较新的版本以支持更多特性 services: vulhub_struts2_s2-045: # 服务名改为全局唯一且具有描述性的名字 image: vulhub/struts2:2.3.32-s2-045 container_name: platform_struts2_s2_045_${INSTANCE_ID:-default} # 容器名加入实例ID支持多实例 networks: - vulhub-platform-net # 加入我们创建的统一网络 # ports: # 注释掉端口映射我们不直接暴露宿主机端口 # - 8080:8080 expose: - 8080 # 只在Docker网络内部暴露端口 deploy: # 使用deploy限制资源Compose v3语法 resources: limits: cpus: 1 # 限制最多使用1个CPU核心 memory: 512M # 限制最多使用512MB内存 restart: no # 漏洞环境通常不需要自动重启 labels: - vulhub.platform.environmenttrue - vulhub.cveCVE-2017-5638 networks: vulhub-platform-net: external: true # 使用外部已创建的网络改造要点解析服务名改为vulhub_struts2_s2-045与Nginx配置中的$backend映射严格对应。这是服务发现的关键。网络加入vulhub-platform-net并声明为external。这确保了所有环境在同一个“局域网”内。端口将ports映射改为expose。expose只向Docker网络内的其他容器公开端口而不绑定到宿主机端口更安全也避免了端口冲突。资源限制使用deploy.resources.limits为容器设置CPU和内存上限。这是企业级平台防止单个环境耗尽资源、影响其他环境或宿主机稳定的必备措施。标签添加labels便于后期用Docker命令过滤和管理所有平台创建的环境。我们需要为每一个计划集成到平台的漏洞环境都做这样的改造。可以编写一个脚本来自动化这个过程。4.4 编写环境管理脚本手动进入每个目录执行docker compose up -d太低效。我们需要一个中心化的管理脚本。创建/opt/vulhub-platform/manage.sh#!/bin/bash # 企业级Vulhub平台管理脚本 ENV_ROOT/opt/vulhub-platform/environments NETWORKvulhub-platform-net case $1 in start) ENV_NAME$2 if [ -z $ENV_NAME ]; then echo Usage: $0 start environment-name exit 1 fi ENV_PATH$ENV_ROOT/$ENV_NAME if [ ! -d $ENV_PATH ]; then echo 环境目录不存在: $ENV_PATH exit 1 fi cd $ENV_PATH # 注入实例ID例如时间戳用于支持同一环境多实例 export INSTANCE_ID$(date %s) docker compose up -d echo 环境 [$ENV_NAME] 启动成功实例ID: $INSTANCE_ID ;; stop) ENV_NAME$2 if [ -z $ENV_NAME ]; then echo Usage: $0 stop environment-name exit 1 fi ENV_PATH$ENV_ROOT/$ENV_NAME if [ ! -d $ENV_PATH ]; then echo 环境目录不存在: $ENV_PATH exit 1 fi cd $ENV_PATH docker compose down -v echo 环境 [$ENV_NAME] 已停止并清理 ;; list) echo 已集成的漏洞环境: for env in $(ls -1 $ENV_ROOT); do if [ -f $ENV_ROOT/$env/docker-compose.yml ]; then echo - $env fi done echo echo 正在运行的环境容器: docker ps --filter labelvulhub.platform.environmenttrue --format table {{.Names}}\t{{.Status}}\t{{.Ports}} ;; status) ENV_NAME$2 if [ -z $ENV_NAME ]; then docker ps -a --filter labelvulhub.platform.environmenttrue else docker ps -a --filter labelvulhub.cve$ENV_NAME fi ;; update) # 更新Vulhub源 cd /opt/vulhub git pull origin master echo Vulhub源码更新完成。请注意检查现有环境的docker-compose.yml是否需要同步更新。 ;; *) echo 企业级Vulhub平台管理工具 echo 用法: $0 {start|stop|list|status|update} [环境名] exit 1 ;; esac给脚本执行权限chmod x /opt/vulhub-platform/manage.sh。现在你可以通过./manage.sh list查看环境通过./manage.sh start cve-2017-5638一键启动环境。5. 平台运维、监控与安全加固平台搭建起来只是第一步让它稳定、安全、易用地运行起来才是真正的挑战。5.1 资源监控与告警无监控不运维。我们需要知道平台的整体资源消耗和每个漏洞环境的运行状态。一个轻量级的方案是使用cAdvisor容器监控 Prometheus指标存储 Grafana可视化。# 使用Docker Compose部署监控栈 cd /opt/vulhub-platform mkdir -p monitoring cd monitoring创建docker-compose-monitor.yml:version: 3.8 services: cadvisor: image: gcr.io/cadvisor/cadvisor:latest container_name: cadvisor privileged: true devices: - /dev/kmsg:/dev/kmsg volumes: - /:/rootfs:ro - /var/run:/var/run:ro - /sys:/sys:ro - /var/lib/docker/:/var/lib/docker:ro ports: - 8081:8080 networks: - monitor-net restart: unless-stopped prometheus: image: prom/prometheus:latest container_name: prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - prometheus_data:/prometheus command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.path/prometheus - --web.console.libraries/etc/prometheus/console_libraries - --web.console.templates/etc/prometheus/consoles - --storage.tsdb.retention.time200h - --web.enable-lifecycle ports: - 9090:9090 networks: - monitor-net restart: unless-stopped grafana: image: grafana/grafana:latest container_name: grafana volumes: - grafana_data:/var/lib/grafana environment: - GF_SECURITY_ADMIN_PASSWORDadmin123 # 请修改 ports: - 3000:3000 networks: - monitor-net restart: unless-stopped networks: monitor-net: name: monitor-net volumes: prometheus_data: grafana_data:创建Prometheus配置文件prometheus.yml:global: scrape_interval: 15s scrape_configs: - job_name: cadvisor static_configs: - targets: [cadvisor:8080] - job_name: node static_configs: - targets: [your-host-ip:9100] # 需要额外安装node-exporter启动监控栈docker compose -f docker-compose-monitor.yml up -d。访问http://your-server-ip:3000登录Grafana初始账号admin/你设置的密码添加Prometheus数据源地址填http://prometheus:9090然后导入cAdvisor相关的Dashboard如ID193即可看到容器级别的CPU、内存、网络、磁盘监控图表。5.2 日志集中收集Docker容器的日志默认在/var/lib/docker/containers/下分散且不易查看。我们可以配置Docker的日志驱动为json-file并设置大小前面已做同时使用docker logs命令查看。对于平台化运维可以进一步使用docker-compose logs -f [service-name]来查看特定环境的日志。更高级的方案是集成ELK或Loki但对于初期平台一个简单的日志轮转和归档脚本已经足够。在/etc/logrotate.d/docker-vulhub中配置/var/lib/docker/containers/*/*.log { daily rotate 7 compress delaycompress missingok copytruncate }5.3 安全加固措施漏洞测试平台本身必须安全不能成为新的攻击入口。网络隔离我们已经使用了自定义的Docker网络。此外应在宿主机防火墙如UFW中只允许特定IP段如公司内网访问平台的80端口Nginx和监控端口如3000, 9090。sudo ufw allow from 10.0.0.0/8 to any port 80 proto tcp sudo ufw allow from 10.0.0.0/8 to any port 3000 proto tcp sudo ufw --force enable容器安全非Root用户运行在改造docker-compose.yml时尽可能在镜像支持的情况下通过user:指令指定非root用户运行容器进程。只读根文件系统对于大多数漏洞环境容器内部不需要写入。可以添加read_only: true来增强安全性。限制能力使用cap_drop:丢弃所有不必要的Linux能力如ALL然后按需添加。例如一个Web应用通常不需要SYS_ADMIN能力。镜像安全定期扫描平台使用的漏洞镜像是否有新的安全漏洞。可以使用trivy或docker scout等工具。# 示例使用Trivy扫描镜像 docker pull vulhub/struts2:2.3.32-s2-045 trivy image vulhub/struts2:2.3.32-s2-045访问控制基础的Nginx索引页没有任何权限控制。在生产环境至少应该配置HTTP Basic认证或者集成公司的单点登录SSO。可以在Nginx配置的location /块中添加auth_basic Vulhub Platform; auth_basic_user_file /etc/nginx/.htpasswd;使用htpasswd命令创建用户密码文件。6. 典型问题排查与实战技巧在实际运营中你会遇到各种各样的问题。这里记录几个最常见的问题和我的解决思路。6.1 环境启动失败镜像拉取超时或错误这是最常见的问题尤其在国内网络环境下。现象docker compose up -d时卡在Pulling或报错net/http: TLS handshake timeout。排查首先docker pull单独拉取镜像确认是否是网络问题。解决确认/etc/docker/daemon.json中的镜像加速器配置正确且生效sudo systemctl restart docker。对于某些特别大的镜像可以尝试在夜间网络空闲时拉取。如果加速器也不行考虑在海外VPS上拉取镜像然后导出为tar文件再导入到平台服务器# 在海外机器 docker pull vulhub/xxx:tag docker save vulhub/xxx:tag -o xxx.tar # 将xxx.tar传输到平台服务器 # 在平台服务器 docker load -i xxx.tar6.2 容器启动后服务不可访问现象docker compose up -d成功但通过Nginx访问返回502 Bad Gateway或连接超时。排查步骤检查容器状态docker ps查看对应容器是否处于Up状态。如果是Exited用docker logs container_id查看启动日志。检查容器内服务进入容器内部检查服务是否真的在监听端口。docker exec -it container_name sh然后netstat -tlnp或ps aux。检查网络连通性在Nginx容器内如果Nginx也容器化或在宿主机上使用docker network inspect vulhub-platform-net查看容器IP然后尝试curl http://容器IP:内部端口。检查Nginx配置确认Nginx配置中的proxy_pass地址服务名和端口与docker-compose.yml中的services名称和expose端口完全一致。服务名不能包含下划线以外的特殊字符且需在同一个网络。检查防火墙确保宿主机防火墙和Docker自身的防火墙规则如果有没有阻断容器间通信。6.3 平台性能突然下降现象平台响应变慢甚至影响宿主机。排查快速定位问题容器使用docker stats命令实时查看所有容器的CPU、内存占用。一眼就能看出哪个容器是“资源黑洞”。检查监控查看Grafana Dashboard确认是CPU、内存还是磁盘IO瓶颈。常见原因与解决某个漏洞环境被恶意循环攻击在测试时如果利用脚本写错了可能变成对平台自身的DoS攻击。通过docker logs查看异常请求并临时docker pause该容器。磁盘空间不足Docker的日志、镜像、容器层会占用大量空间。定期清理docker system prune -a -f谨慎使用会清理未使用的镜像、容器、网络。更安全的是只清理日志find /var/lib/docker/containers/ -name \*.log\ -size 100M -delete。内存泄漏某些老旧的漏洞应用可能存在内存泄漏。为容器设置更严格的内存限制mem_limit并在达到限制后自动重启在docker-compose.yml中配置restart: on-failure。6.4 如何管理多个并发的相同环境有时培训或演练需要多个学员同时操作同一个漏洞但又不希望互相干扰。解决方案利用我们脚本中的INSTANCE_ID变量和Docker Compose的项目名-p参数功能。操作启动环境时指定不同的项目名它们会创建独立的容器组但共享相同的镜像和配置。cd /opt/vulhub-platform/environments/cve-2017-5638 export INSTANCE_IDteam_a docker compose -p vulhub_struts2_team_a up -d export INSTANCE_IDteam_b docker compose -p vulhub_struts2_team_b up -d此时会启动两组容器服务名会带上前缀例如vulhub_struts2_team_a_vulhub_struts2_s2-045_1。你需要在Nginx配置中为team_a和team_b配置不同的访问路径和反向代理规则。这虽然增加了配置复杂性但实现了真正的多租户隔离。搭建企业级漏洞测试平台技术实现只是骨架真正的血肉是围绕它建立的流程和规范。比如规定所有新的漏洞环境在集成前必须经过资源评估和安全扫描建立定期更新机制同步Vulhub官方的最新漏洞环境编写详细的使用手册和培训材料。这个平台的价值会随着使用它的次数和人数呈指数级增长。它从一个小工具逐渐演变为企业安全能力的一部分让安全测试从一种“手艺”变成一种可重复、可衡量的“工艺”。
![华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
![华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
