组织一场正经的CTF比赛最让人头疼的往往不是出题而是怎么把题目安全、稳定、公平地发给选手。早几年常见的做法是给附件、给靶机IP选手连上去各玩各的听起来没什么问题但真到了几十上百人同时在线的时候场景就失控了有人把题目环境打崩所有人跟着遭殃有人拿别人解题的痕迹直接“借鉴”反作弊全靠裁判肉眼盯更有题目本身需要一个独立环境根本没法让所有人共享。动态靶机这个思路就是为了解决这些问题——每个选手、每支队伍进到的都是自己的独立容器实例flag单独生成环境互不干扰平台按需拉起、超时回收。GZCTF就是一套专门干这个事的开源竞赛平台基于Docker动态生成靶机部署起来不算复杂但里面值得讲清楚的门道不少。这篇内容我打算从部署、配置、镜像制作到运维排障完整拆一遍基于GZCTF的动态靶机环境搭建过程。适合正在筹备校内赛、训练赛的个人或小团队也适合第一次接触动态靶机、想搞清楚这套机制到底怎么运作的同学。我会把每一步为什么这么做、哪些参数会影响选手体验、哪些坑是真踩过才知道的一并写清楚。1. 先想清楚动态靶机到底是什么为什么绕不开 Docker很多人第一次接触GZCTF的时候容易把它理解成“一个能挂题的网站”。这么说也没错但动态靶机这个核心功能才是它和其他简单题库系统最本质的区别。理解了动态靶机的价值你才会知道部署时那些看似多余的组件到底在解决什么问题。1.1 传统静态附件赛的尴尬动态靶机是怎么解的传统CTF题目有两类典型形态。一类是静态题题目就是一个压缩包里面放着源码、加密流量、图片等等选手下载下来本地分析最后找到flag提交。另一类是固靶题目给一个固定IP和端口所有人都连同一个环境。静态题吃亏在环境依赖上一道带特定版本的题目选手本地跑不起来就只能干瞪眼固靶吃亏在公平性和稳定性上环境被某个人打坏了后面的人全没法做题甚至有人直接在靶机上搞破坏影响别人解题。动态靶机的思路是把题目做成镜像平台收到选手的请求后用Docker实时创建一个独立的容器实例。每个人看到的flag不一样连进去的环境也不一样提交flag也只认自己实例里的那一个。这样一来选手之间互不干扰题目环境也不会被共享弹栈的人污染裁判要做的反作弊工作一下子少了很多。Docker在这里承担的就是“批量生成隔离环境”的角色没有容器技术这套机制根本玩不起来。1.2 同类平台那么多为什么挑GZCTF来实战目前社区里开源的CTF平台并不少有的是老牌项目功能全面但界面和代码风格偏年代感有的是新出的轻量方案部署简单但动态靶机能力比较弱。GZCTF在我的实际体验里最突出的三点是第一动态靶机的产品化做得完整支持镜像、端口、资源限制、实例上限、自动销毁等配置不需要自己写一堆管理脚本第二选手端体验好启动容器、倒计时、访问URL都是自动化的不用给选手发一大段操作说明第三部署形态足够轻单机Docker加几个辅助服务就能跑起来适合小团队快速落地。更关键的是它对私有镜像仓库、对象存储、邮件服务等周边组件的支持都比较标准没有搞什么私有协议换环境迁移数据相对容易。对于想长期维护一套训练平台的组织来说这一点非常重要——今天在单机上搭好了明天想把容器调度迁到集群上底层思路也是通用的不会白学。1.3 一套GZCTF平台的完整组成远不止“一个容器”很多人以为部署GZCTF就是跑一个容器其实官方推荐的部署方式至少包含五个角色GZCTF主程序、PostgreSQL数据库、Redis缓存、Docker Registry私有镜像仓库以及节点上的Docker引擎。它们各有分工主程序负责Web界面、业务逻辑和容器编排数据库存比赛、题目、用户、提交记录Redis处理缓存和临时数据Registry用来存动态靶机的镜像选手启动容器时节点从这里拉镜像Docker引擎则是所有动态实例的真正宿主。这个架构里Registry的存在往往是最容易被新人忽略的。你可能觉得镜像直接build在服务器上给平台用就行了但GZCTF的动态靶机调度并不是“在你当前这台机器上docker run”而是通过Docker API拉起容器镜像需要有一个明确的来源地址。如果题目镜像只存在于本地没有推到Registry平台调度时会直接报“找不到镜像”。后面我在部署章节里会专门演示怎么搭Registry并正确推镜像。2. 从零部署选一台机器把 GZCTF 完整跑起来部署GZCTF本身不复杂难的是把环境一次配对。这一节我从服务器选型开始逐步带你搭一套可用的单机环境。整个过程如果你是照着做的大概半小时内能把平台跑起来。2.1 硬件和系统选型别在第一步就埋雷GZCTF主程序本身不占多少资源内存512MB到1GB就能转但动态靶机才是资源消耗的大头。你需要根据参赛人数和题目并行上限来倒推内存需求每个动态容器限制多少内存最多同时存活多少个实例两者相乘就是内存下限。比如一个容器限制256MB同时最多50个实例那就至少需要12.8GB可用内存再加上系统、平台、数据库、镜像仓库的开销推荐16GB起步。CPU方面动态靶机一般不会跑重负载但容器创建、销毁的调度操作对CPU突发有要求4核心以上比较稳妥。磁盘则是另一个容易低估的点一个基础镜像两三百MB几十个题目镜像堆起来就是几十GB再加上容器日志和数据库增长建议预留至少100GB可用空间最好用SSD。系统我用的是Debian系Ubuntu Server 22.04或Debian 12都行安装软件最省事。2.2 安装 Docker 和 Compose确认权限和工作模式GZCTF需要操作Docker来创建和管理容器这意味着主程序容器要挂载宿主机的Docker socket也就是/var/run/docker.sock。这一步省不了但也意味着主程序容器拥有宿主机的Docker控制权相当于root级别的操作能力。所以我建议只在可信的内网环境里用这套方案不要随手把平台暴露到公网。安装Docker我一般直接走官方脚本或系统包管理器。装完之后确认两件事docker version能正常输出docker compose version能看到版本号。如果系统里装的是老式docker-compose也能用但下面的配置我按新版compose插件写法来。还有一点确认当前用户能执行Docker命令或者干脆用root操作避免权限问题干扰判断。2.3 核心配置文件docker-compose.yml 完整示例实际部署时我习惯用一个专门的目录放所有配置文件比如/opt/gzctf。下面是一套我在小规模比赛中验证过可用、也保留了解释说明的compose配置。version: 3.9 services: gzctf: image: gzctf/gzctf:latest container_name: gzctf restart: always depends_on: - db - cache - registry ports: - 8080:8080 environment: - GZCTF_HTTP_PORT8080 - ConnectionStrings__PostgresHostdb;Port5432;Databasegzctf;Usernamegzctf;Passwordchange_me - ConnectionStrings__Redisredis:6379,passwordchange_me - Storage__TypeLocal - Storage__Location/app/cloud - Registry__TypeBasic - Registry__Usergzctf - Registry__Passwordchange_me - Registry__Urlhttp://registry:5000 - Email__Confirmationfalse - Account__NewSignuptrue - Smtp__Hostmail.example.com - Smtp__Port465 - Smtp__Usernamenoreplyexample.com - Smtp__Passwordchange_me volumes: - ./appsettings.json:/app/appsettings.json:ro - ./data:/app/cloud - /var/run/docker.sock:/var/run/docker.sock networks: - internal db: image: postgres:15-alpine container_name: gzctf-db restart: always environment: POSTGRES_USER: gzctf POSTGRES_PASSWORD: change_me POSTGRES_DB: gzctf volumes: - pgdata:/var/lib/postgresql/data networks: - internal cache: image: redis:7-alpine container_name: gzctf-cache restart: always command: redis-server --requirepass change_me volumes: - redisdata:/data networks: - internal registry: image: registry:2 container_name: gzctf-registry restart: always environment: REGISTRY_AUTH: htpasswd REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd REGISTRY_HTTP_SECRET: some_random_secret REGISTRY_STORAGE_DELETE_ENABLED: true volumes: - ./auth:/auth - registrydata:/var/lib/registry networks: - internal volumes: pgdata: redisdata: registrydata: networks: internal:这套配置我用了多个环境变量来控制GZCTF的行为这里有几个值得解释的点。ConnectionStrings__Postgres和ConnectionStrings__Redis是主程序连数据库和缓存的连接串注意环境变量里的双下划线在 .NET 配置系统里代表层级分隔不能漏写。Storage__TypeLocal表示附件和头像存在本地Storage__Location指定了存储目录如果要换对象存储把类型改成对应方案补上endpoint和密钥即可。Registry__TypeBasic开启镜像仓库的账号密码认证防止任何人都能往里推镜像这个在生产环境必须开。2.4 镜像仓库的密码文件必须先手工生成上面的compose引用了/auth/htpasswd这个文件但GZCTF的Registry容器不会自动创建它。你需要先创建auth目录然后用Registry官方镜像里的htpasswd工具生成账号密码。命令是这样mkdir -p /opt/gzctf/auth cd /opt/gzctf docker run --rm --entrypoint htpasswd registry:2 -Bbn gzctf your_strong_password auth/htpasswd-B表示用bcrypt算法加密密码-b表示命令行直接给密码-n表示输出到标准输出而不是写文件。生成后检查一下auth/htpasswd内容应该是一行gzctf:...的密文。这个文件里的账号密码要和compose里Registry__User、Registry__Password保持一致主程序才能用这组凭证从Registry拉取镜像。2.5 启动平台第一次访问要做什么配置都就位后在/opt/gzctf目录下执行:docker compose up -d等所有容器起来用docker compose ps看一下状态正常应该是四个服务都是running。然后浏览器访问http://服务器IP:8080。首次访问时GZCTF会引导你创建管理员账号这是平台里唯一的初始入口务必记住这个账号后面创建比赛、管理题目都靠它。进入管理后台后第一件事不是急着建比赛而是先把基础配置过一遍。重点看三块站点设置里的地址和端口是否正确注册开关和邮箱验证是否按需调整存储配置确认附件上传能正常写入最后在管理面板里确认能看到Docker节点的在线状态。Docker节点连不上后面动态靶机一道题都跑不起来所以这一步一定要确认到位。3. 动态靶机核心机制与题目配置逐项解析平台跑起来只是开始真正影响比赛质量的是题目如何配置。GZCTF的动态靶机把Docker容器调度抽象成了几个关键的配置项搞清楚每一项的实际含义你才能既不把资源耗尽也不让选手卡在环境上。3.1 题目类型怎么选Static、Dynamic 与 TestableGZCTF里的题目类型我建议先用一句话记住Static就是传统静态题不弹容器Dynamic是纯动态靶机题选手每题一个独立容器Testable则是动态靶机加静态附件的混合形态选手既下载附件分析又需要启动容器验证和获取flag。实际比赛中纯分析类的题目用Static即可比如流量包、古典密码、隐写需要真实运行环境的题比如Web漏洞利用、PWN、逆向中的交互题用Dynamic或Testable。Testable最典型的场景是附件里给出了题目源码或二进制选手本地逆向出利用方式然后到动态靶机里打一下拿flag。这种形式既能减少选手环境依赖又能保留题目分析的深度是我个人最喜欢的题型组合。3.2 动态靶机镜像的制作规范决定后面的所有体验平台本身不会帮你“出题”你得先把题目造成Docker镜像。这里面最核心的一件事镜像必须支持动态flag注入。GZCTF约定平台启动容器时会把每个实例独有的flag通过环境变量GZCTF_FLAG传给容器。如果镜像里的服务不读取这个变量就会所有人拿到同一个flag动态靶机直接失去意义。所以标准做法是镜像里放一个启动脚本启动时把环境变量里的flag写入容器内固定位置然后再把真正的服务拉起来。看一下我常用的模板FROM alpine:latest RUN apk add --no-cache python3 WORKDIR /app COPY start.sh /app/start.sh COPY server.py /app/server.py RUN chmod x /app/start.sh EXPOSE 8000 ENTRYPOINT [/app/start.sh]#!/bin/sh if [ -n $GZCTF_FLAG ]; then echo $GZCTF_FLAG /flag chmod 444 /flag fi python3 /app/server.py注意几点。写入flag后要把权限设为只读防止选手在容器里改掉flag影响其他人。容器启动脚本必须放到ENTRYPOINT而不是CMD确保环境变量注入发生在脚本执行之前。还有千万不要在Dockerfile里写死一个flag那会让所有实例都一模一样。3.3 平台侧题目参数全解析镜像准备好之后在管理后台创建动态题会看到一长串参数。很多人第一次看到这些框就懵了其实它们都有明确作用。我把关键参数整理成了表格方便对照。参数作用我的建议Image题目镜像在Registry中的完整名称必须与推送到Registry的镜像名完全一致Port Mapping容器内哪个端口对外暴露按容器实际监听端口填多端口需要仔细配置CPU Count每个容器允许使用的CPU核数一般0.2到1即可别给满Memory Limit每个容器的内存上限256MB到512MB起步PWN题适当调高Instance Limit单道题最多同时存在的容器数根据资源预算设定防止被单队刷爆Auto Destroy容器无活动多久后自动销毁推荐30到60分钟避免资源无人释放Is Trial是否允许选手重复申请新实例建议开启但配好总实例上限这里尤其要解释Instance Limit和Auto Destroy的关系。Instance Limit是这道题在全局范围内允许同时存在的实例上限注意不是每队一个是所有人加起来只能有这么多。如果队伍多、题目热门很容易就被占满后启动的选手会一直排队。Auto Destroy是无人访问多久后回收实例可以在一定程度上缓解资源压力。实操上我一般先把单题实例上限设为队伍数的三分之二然后在比赛前用几个模拟账号实测一下再按选手反馈微调。3.4 动态分值曲线怎么算别让分变成一道算术题动态靶机赛制还有一个配套机制解题人数越多这道题剩下的分越低越早解出分越高。这在一定程度上平衡了“巨人题”和“签到题”的分值差距。GZCTF里这道题的基础分、衰减系数、最低分和每道题的权重有关典型曲线会呈现“指数衰减”的趋势。不同版本对动态分值的参数命名不完全一样但原理是通的。假如某题初始分500分最低分100分前5个解出来的人分别拿500、400、320、256、205这样的递减分值第20个解出时已经贴到最低分附近。一血还会有额外的Blood Bonus加成这个是平台默认支持的。设置分值时我建议不要把衰减系数设得太狠尤其题目总数不多的小比赛分差过大会让后半程的解题彻底失去动力。3.5 网络隔离与反作弊平台是怎么做到相对公平的动态靶机的公平性并不只靠flag不同来保证网络隔离同样关键。GZCTF在调度动态容器时会为每个实例分配独立的内部网络标识队伍之间默认不能互相访问对方的容器。这样就算有人拿到了同队队友的实例地址也无法从别的队伍容器里读取数据。配合容器启动时生成的随机token选手访问自己靶机时用的是带token的URL其他人无法猜测和接管。当然这并不能完全防止选手互相交换答案比如把自己容器里的flag直接发给别人。平台层面的反作弊手段主要是IP绑定、提交频率限制、封禁账号等再往下就要靠赛制设计和人工复核了。对于小规模比赛动态靶机加独立网络已经足够挡住大多数简单作弊方式不用过度设计。4. 完整实战从 Dockerfile 到第一道动态题前面讲了一堆原理这一节我带你把一道简单的Web动态靶机题完整走一遍。从写Dockerfile开始到推到Registry再到选手端启动容器、访问、拿flag、提交大家照着这个流程走后面学会做其他类型的题就只是换个镜像而已。4.1 一道带命令注入漏洞的迷你靶机为了演示我写一个极简的Python HTTP服务它接收一个cmd参数直接拼到系统命令里执行。这个设计在真实比赛里不算出彩但用来展示动态靶机的完整链路非常合适。import os from http.server import BaseHTTPRequestHandler, HTTPServer FLAG flag_path /flag if os.path.exists(flag_path): with open(flag_path) as f: FLAG f.read().strip() class Handler(BaseHTTPRequestHandler): def do_GET(self): if self.path.startswith(/cmd): cmd self.path.split(, 1)[1] if in self.path else id result os.popen(cmd).read() self.send_response(200) self.end_headers() self.wfile.write(result.encode()) else: self.send_response(200) self.end_headers() self.wfile.write(bhello ctfer) def log_message(self, fmt, *args): pass HTTPServer((0.0.0.0, 8000), Handler).serve_forever()这个服务读取/flag文件但并没有直接暴露它选手需要利用命令注入绕过限制才能拿到flag。Dockerfile可以用前面给的那个Alpine模板把Python代码拷贝进去暴露8000端口。这里刻意选了Alpine加Python的标准库不用Flask镜像体积能控制在100MB上下动态靶机拉起会快很多。4.2 构建镜像并推到私有 Registry镜像构建好之后接下来是把镜像推到Registry里。假设平台compose里Registry的地址是registry:5000而镜像名字必须让平台能用同样的逻辑访问到。实际操作中因为Docker客户端和Registry容器都在同一个宿主机上推镜像时可以用宿主机上的映射端口或直接访问容器网络。我建议在构建时就把镜像tag成完整Registry地址的格式docker build -t localhost:5000/web/cmd-exec:1.0 . docker push localhost:5000/web/cmd-exec:1.0推成功后用docker pull localhost:5000/web/cmd-exec:1.0验证一下能否正常拉取。这里要用到2.4节里生成的Registry账号密码Docker会提示登录。如果登录失败先检查auth/htpasswd文件内容和compose里的Registry__Password是否一致这是自建Registry最常见的坑。4.3 在管理后台创建题目并走通全流程镜像推好以后回到GZCTF管理后台创建一个题目。题目类型选Dynamic镜像名填localhost:5000/web/cmd-exec:1.0。但这里有个细节平台主程序解析镜像名时可能不会自动补全Registry地址你要么在平台里配置Registry地址后镜像名直接用仓库内路径加标签的完整格式要么提前在测试环境确认平台能正确解析。我的习惯是在配置里把Registry__Url设置为可访问的Registry地址镜像名就填完整的registry地址/项目名/镜像名:标签避免歧义。端口配置填8000内存限制给256MB实例上限按队伍数预估。保存后用选手身份进入比赛点击“启动实例”等待几秒钟平台会返回一个访问URL。浏览器打开这个URL访问/cmd?cmdcat /flag就能看到自己这个实例独有的flag。复制提交分数立刻到账。整个链路走通你的动态靶机环境就算真正能用了。5. 运维实录比赛中最容易踩的坑与排查方法就算部署顺利比赛进行中也一定会冒出各种状况。下面这些坑我基本都踩过有的是比赛现场临时救火才解决掉的。我把常见问题和排查思路整理成一张速查表再分别展开说。现象可能原因排查思路容器一直Pending或创建失败镜像不存在、资源不足、Docker socket权限问题看平台日志和docker ps -a确认容器状态选手访问不了靶机URL端口配置错误、反代未传递WebSocket/头部对比容器内端口与平台配置flag不一致或提交失败镜像没读GZCTF_FLAG、直接内置了固定flag检查启动脚本和Dockerfile高并发下平台响应慢内存不足、容器数量超预算查看内存占用临时调低实例上限比赛后迁移数据丢失只备份了数据库没备份Registry和对象存储必须同时备份三类数据5.1 动态容器一直创建失败问题到底出在哪只要动态靶机起不来比赛就基本没法进行所以这是优先级最高的问题。第一步先看GZCTF主程序日志一般会给出失败原因比如“image not found”或“no space left on device”。如果是镜像找不到回Registry页面确认镜像是否真的推成功了镜像名是否和题目配置一字不差。如果是磁盘满了清理无用的镜像和日志扩容磁盘。还有一个隐蔽问题如果你给GZCTF主程序挂载的Docker socket路径不对它根本连不上Docker所有容器都会卡在待创建状态。5.2 选手连不上靶机端口和反代这里最容易绕晕直连模式下GZCTF会给每个实例暴露宿主机的随机端口选手访问http://服务器IP:随机端口/token。如果你在服务器前面还有一层Nginx或Caddy反向代理事情就变得复杂起来。你得保证动态容器的那一段端口范围也被代理转发而且需要把原始Host和协议头正确传给后端。很多人只配了平台主程序的站点代理忘了靶机端口范围结果比赛一开始页面能打开、容器能启动就是访问URL死活连不通。配置反代时还需要留意HTTP和HTTPS协议不一致的问题。平台页面是HTTPS动态靶机访问URL如果还是HTTP浏览器会直接拦截混合内容选手一脸懵。这类问题排查起来不难但要在赛前就让几个模拟账号实际走一遍全流程别等到比赛已经开始才暴露。5.3 flag不一致或者拿不到镜像规范一旦出错全盘皆输flag相关的问题十有八九出在镜像启动脚本上。常见三种情况脚本压根没读取GZCTF_FLAG环境变量所有实例共用一个写死在镜像里的flag脚本把flag写进/flag了但应用读的不是这个位置以及脚本执行顺序不对应用启动之后flag才生成。排查时手动run一个容器用-e GZCTF_FLAGtest_flag方式跑起来进去看看flag文件是否存在、内容是否等于传入的环境变量基本就能定位问题。我强烈建议在出题阶段就做这个手动验证别等题目上线了再试。5.4 并发一高平台就卡资源预算必须提前算动态靶机的资源消耗不是线性的。平时没人启动容器平台闲得很比赛开赛前30分钟所有人同时点启动瞬间可能创建上百个容器这时候CPU、内存、磁盘IO一起飙升。我在一次实验中没控制好某道题设了很大内存限制结果50个实例直接把16G内存吃满平台和数据库一起卡死比赛被迫中断了十来分钟。经验教训是赛前一定要做并发压测至少用模拟账号同时启动十几个容器观察资源占用。动态题的实例上限宁可保守一点也不要一次给太宽容器满了选手可以排队等待平台崩了那是所有人一起等着。另外可以给Docker配置日志文件上限防止某个容器的stdout把磁盘打满。5.5 比赛数据备份与快速迁移守住平台的三样家底比赛结束以后数据备份和迁移同样重要。GZCTF的数据分布在三个地方PostgreSQL数据库里的用户、比赛、题目、提交记录对象存储或本地目录里的附件和头像Registry里的所有题目镜像。只备份其中一个都不够任何一块缺失恢复出来的平台都是残废的。我的备份习惯是停掉容器后直接备份整个项目目录的data、auth再用pg_dump导出数据库Registry的数据用volume备份或直接打包/var/lib/registry。恢复时先按同样的compose启动空平台再把备份导回去重启容器即可。这个过程最好选在比赛后马上演练一次真到要迁移服务器的时候才不会手忙脚乱。最后再分享一点个人习惯无论规模多大的比赛正式开赛前24小时我一定会做一次全链路模拟——用一个普通选手账号走一遍注册、开容器、做题、交flag的完整流程顺便检查服务器负载。动态靶机的坑大多不是出现在配置文档里而是出现在并发瞬间和版本差异里。先把这套流程跑顺了比赛时你才有底气坐在那里喝茶而不是蹲在服务器前看日志。
组织一场正经的CTF比赛最让人头疼的往往不是出题而是怎么把题目安全、稳定、公平地发给选手。早几年常见的做法是给附件、给靶机IP选手连上去各玩各的听起来没什么问题但真到了几十上百人同时在线的时候场景就失控了有人把题目环境打崩所有人跟着遭殃有人拿别人解题的痕迹直接“借鉴”反作弊全靠裁判肉眼盯更有题目本身需要一个独立环境根本没法让所有人共享。动态靶机这个思路就是为了解决这些问题——每个选手、每支队伍进到的都是自己的独立容器实例flag单独生成环境互不干扰平台按需拉起、超时回收。GZCTF就是一套专门干这个事的开源竞赛平台基于Docker动态生成靶机部署起来不算复杂但里面值得讲清楚的门道不少。这篇内容我打算从部署、配置、镜像制作到运维排障完整拆一遍基于GZCTF的动态靶机环境搭建过程。适合正在筹备校内赛、训练赛的个人或小团队也适合第一次接触动态靶机、想搞清楚这套机制到底怎么运作的同学。我会把每一步为什么这么做、哪些参数会影响选手体验、哪些坑是真踩过才知道的一并写清楚。1. 先想清楚动态靶机到底是什么为什么绕不开 Docker很多人第一次接触GZCTF的时候容易把它理解成“一个能挂题的网站”。这么说也没错但动态靶机这个核心功能才是它和其他简单题库系统最本质的区别。理解了动态靶机的价值你才会知道部署时那些看似多余的组件到底在解决什么问题。1.1 传统静态附件赛的尴尬动态靶机是怎么解的传统CTF题目有两类典型形态。一类是静态题题目就是一个压缩包里面放着源码、加密流量、图片等等选手下载下来本地分析最后找到flag提交。另一类是固靶题目给一个固定IP和端口所有人都连同一个环境。静态题吃亏在环境依赖上一道带特定版本的题目选手本地跑不起来就只能干瞪眼固靶吃亏在公平性和稳定性上环境被某个人打坏了后面的人全没法做题甚至有人直接在靶机上搞破坏影响别人解题。动态靶机的思路是把题目做成镜像平台收到选手的请求后用Docker实时创建一个独立的容器实例。每个人看到的flag不一样连进去的环境也不一样提交flag也只认自己实例里的那一个。这样一来选手之间互不干扰题目环境也不会被共享弹栈的人污染裁判要做的反作弊工作一下子少了很多。Docker在这里承担的就是“批量生成隔离环境”的角色没有容器技术这套机制根本玩不起来。1.2 同类平台那么多为什么挑GZCTF来实战目前社区里开源的CTF平台并不少有的是老牌项目功能全面但界面和代码风格偏年代感有的是新出的轻量方案部署简单但动态靶机能力比较弱。GZCTF在我的实际体验里最突出的三点是第一动态靶机的产品化做得完整支持镜像、端口、资源限制、实例上限、自动销毁等配置不需要自己写一堆管理脚本第二选手端体验好启动容器、倒计时、访问URL都是自动化的不用给选手发一大段操作说明第三部署形态足够轻单机Docker加几个辅助服务就能跑起来适合小团队快速落地。更关键的是它对私有镜像仓库、对象存储、邮件服务等周边组件的支持都比较标准没有搞什么私有协议换环境迁移数据相对容易。对于想长期维护一套训练平台的组织来说这一点非常重要——今天在单机上搭好了明天想把容器调度迁到集群上底层思路也是通用的不会白学。1.3 一套GZCTF平台的完整组成远不止“一个容器”很多人以为部署GZCTF就是跑一个容器其实官方推荐的部署方式至少包含五个角色GZCTF主程序、PostgreSQL数据库、Redis缓存、Docker Registry私有镜像仓库以及节点上的Docker引擎。它们各有分工主程序负责Web界面、业务逻辑和容器编排数据库存比赛、题目、用户、提交记录Redis处理缓存和临时数据Registry用来存动态靶机的镜像选手启动容器时节点从这里拉镜像Docker引擎则是所有动态实例的真正宿主。这个架构里Registry的存在往往是最容易被新人忽略的。你可能觉得镜像直接build在服务器上给平台用就行了但GZCTF的动态靶机调度并不是“在你当前这台机器上docker run”而是通过Docker API拉起容器镜像需要有一个明确的来源地址。如果题目镜像只存在于本地没有推到Registry平台调度时会直接报“找不到镜像”。后面我在部署章节里会专门演示怎么搭Registry并正确推镜像。2. 从零部署选一台机器把 GZCTF 完整跑起来部署GZCTF本身不复杂难的是把环境一次配对。这一节我从服务器选型开始逐步带你搭一套可用的单机环境。整个过程如果你是照着做的大概半小时内能把平台跑起来。2.1 硬件和系统选型别在第一步就埋雷GZCTF主程序本身不占多少资源内存512MB到1GB就能转但动态靶机才是资源消耗的大头。你需要根据参赛人数和题目并行上限来倒推内存需求每个动态容器限制多少内存最多同时存活多少个实例两者相乘就是内存下限。比如一个容器限制256MB同时最多50个实例那就至少需要12.8GB可用内存再加上系统、平台、数据库、镜像仓库的开销推荐16GB起步。CPU方面动态靶机一般不会跑重负载但容器创建、销毁的调度操作对CPU突发有要求4核心以上比较稳妥。磁盘则是另一个容易低估的点一个基础镜像两三百MB几十个题目镜像堆起来就是几十GB再加上容器日志和数据库增长建议预留至少100GB可用空间最好用SSD。系统我用的是Debian系Ubuntu Server 22.04或Debian 12都行安装软件最省事。2.2 安装 Docker 和 Compose确认权限和工作模式GZCTF需要操作Docker来创建和管理容器这意味着主程序容器要挂载宿主机的Docker socket也就是/var/run/docker.sock。这一步省不了但也意味着主程序容器拥有宿主机的Docker控制权相当于root级别的操作能力。所以我建议只在可信的内网环境里用这套方案不要随手把平台暴露到公网。安装Docker我一般直接走官方脚本或系统包管理器。装完之后确认两件事docker version能正常输出docker compose version能看到版本号。如果系统里装的是老式docker-compose也能用但下面的配置我按新版compose插件写法来。还有一点确认当前用户能执行Docker命令或者干脆用root操作避免权限问题干扰判断。2.3 核心配置文件docker-compose.yml 完整示例实际部署时我习惯用一个专门的目录放所有配置文件比如/opt/gzctf。下面是一套我在小规模比赛中验证过可用、也保留了解释说明的compose配置。version: 3.9 services: gzctf: image: gzctf/gzctf:latest container_name: gzctf restart: always depends_on: - db - cache - registry ports: - 8080:8080 environment: - GZCTF_HTTP_PORT8080 - ConnectionStrings__PostgresHostdb;Port5432;Databasegzctf;Usernamegzctf;Passwordchange_me - ConnectionStrings__Redisredis:6379,passwordchange_me - Storage__TypeLocal - Storage__Location/app/cloud - Registry__TypeBasic - Registry__Usergzctf - Registry__Passwordchange_me - Registry__Urlhttp://registry:5000 - Email__Confirmationfalse - Account__NewSignuptrue - Smtp__Hostmail.example.com - Smtp__Port465 - Smtp__Usernamenoreplyexample.com - Smtp__Passwordchange_me volumes: - ./appsettings.json:/app/appsettings.json:ro - ./data:/app/cloud - /var/run/docker.sock:/var/run/docker.sock networks: - internal db: image: postgres:15-alpine container_name: gzctf-db restart: always environment: POSTGRES_USER: gzctf POSTGRES_PASSWORD: change_me POSTGRES_DB: gzctf volumes: - pgdata:/var/lib/postgresql/data networks: - internal cache: image: redis:7-alpine container_name: gzctf-cache restart: always command: redis-server --requirepass change_me volumes: - redisdata:/data networks: - internal registry: image: registry:2 container_name: gzctf-registry restart: always environment: REGISTRY_AUTH: htpasswd REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd REGISTRY_HTTP_SECRET: some_random_secret REGISTRY_STORAGE_DELETE_ENABLED: true volumes: - ./auth:/auth - registrydata:/var/lib/registry networks: - internal volumes: pgdata: redisdata: registrydata: networks: internal:这套配置我用了多个环境变量来控制GZCTF的行为这里有几个值得解释的点。ConnectionStrings__Postgres和ConnectionStrings__Redis是主程序连数据库和缓存的连接串注意环境变量里的双下划线在 .NET 配置系统里代表层级分隔不能漏写。Storage__TypeLocal表示附件和头像存在本地Storage__Location指定了存储目录如果要换对象存储把类型改成对应方案补上endpoint和密钥即可。Registry__TypeBasic开启镜像仓库的账号密码认证防止任何人都能往里推镜像这个在生产环境必须开。2.4 镜像仓库的密码文件必须先手工生成上面的compose引用了/auth/htpasswd这个文件但GZCTF的Registry容器不会自动创建它。你需要先创建auth目录然后用Registry官方镜像里的htpasswd工具生成账号密码。命令是这样mkdir -p /opt/gzctf/auth cd /opt/gzctf docker run --rm --entrypoint htpasswd registry:2 -Bbn gzctf your_strong_password auth/htpasswd-B表示用bcrypt算法加密密码-b表示命令行直接给密码-n表示输出到标准输出而不是写文件。生成后检查一下auth/htpasswd内容应该是一行gzctf:...的密文。这个文件里的账号密码要和compose里Registry__User、Registry__Password保持一致主程序才能用这组凭证从Registry拉取镜像。2.5 启动平台第一次访问要做什么配置都就位后在/opt/gzctf目录下执行:docker compose up -d等所有容器起来用docker compose ps看一下状态正常应该是四个服务都是running。然后浏览器访问http://服务器IP:8080。首次访问时GZCTF会引导你创建管理员账号这是平台里唯一的初始入口务必记住这个账号后面创建比赛、管理题目都靠它。进入管理后台后第一件事不是急着建比赛而是先把基础配置过一遍。重点看三块站点设置里的地址和端口是否正确注册开关和邮箱验证是否按需调整存储配置确认附件上传能正常写入最后在管理面板里确认能看到Docker节点的在线状态。Docker节点连不上后面动态靶机一道题都跑不起来所以这一步一定要确认到位。3. 动态靶机核心机制与题目配置逐项解析平台跑起来只是开始真正影响比赛质量的是题目如何配置。GZCTF的动态靶机把Docker容器调度抽象成了几个关键的配置项搞清楚每一项的实际含义你才能既不把资源耗尽也不让选手卡在环境上。3.1 题目类型怎么选Static、Dynamic 与 TestableGZCTF里的题目类型我建议先用一句话记住Static就是传统静态题不弹容器Dynamic是纯动态靶机题选手每题一个独立容器Testable则是动态靶机加静态附件的混合形态选手既下载附件分析又需要启动容器验证和获取flag。实际比赛中纯分析类的题目用Static即可比如流量包、古典密码、隐写需要真实运行环境的题比如Web漏洞利用、PWN、逆向中的交互题用Dynamic或Testable。Testable最典型的场景是附件里给出了题目源码或二进制选手本地逆向出利用方式然后到动态靶机里打一下拿flag。这种形式既能减少选手环境依赖又能保留题目分析的深度是我个人最喜欢的题型组合。3.2 动态靶机镜像的制作规范决定后面的所有体验平台本身不会帮你“出题”你得先把题目造成Docker镜像。这里面最核心的一件事镜像必须支持动态flag注入。GZCTF约定平台启动容器时会把每个实例独有的flag通过环境变量GZCTF_FLAG传给容器。如果镜像里的服务不读取这个变量就会所有人拿到同一个flag动态靶机直接失去意义。所以标准做法是镜像里放一个启动脚本启动时把环境变量里的flag写入容器内固定位置然后再把真正的服务拉起来。看一下我常用的模板FROM alpine:latest RUN apk add --no-cache python3 WORKDIR /app COPY start.sh /app/start.sh COPY server.py /app/server.py RUN chmod x /app/start.sh EXPOSE 8000 ENTRYPOINT [/app/start.sh]#!/bin/sh if [ -n $GZCTF_FLAG ]; then echo $GZCTF_FLAG /flag chmod 444 /flag fi python3 /app/server.py注意几点。写入flag后要把权限设为只读防止选手在容器里改掉flag影响其他人。容器启动脚本必须放到ENTRYPOINT而不是CMD确保环境变量注入发生在脚本执行之前。还有千万不要在Dockerfile里写死一个flag那会让所有实例都一模一样。3.3 平台侧题目参数全解析镜像准备好之后在管理后台创建动态题会看到一长串参数。很多人第一次看到这些框就懵了其实它们都有明确作用。我把关键参数整理成了表格方便对照。参数作用我的建议Image题目镜像在Registry中的完整名称必须与推送到Registry的镜像名完全一致Port Mapping容器内哪个端口对外暴露按容器实际监听端口填多端口需要仔细配置CPU Count每个容器允许使用的CPU核数一般0.2到1即可别给满Memory Limit每个容器的内存上限256MB到512MB起步PWN题适当调高Instance Limit单道题最多同时存在的容器数根据资源预算设定防止被单队刷爆Auto Destroy容器无活动多久后自动销毁推荐30到60分钟避免资源无人释放Is Trial是否允许选手重复申请新实例建议开启但配好总实例上限这里尤其要解释Instance Limit和Auto Destroy的关系。Instance Limit是这道题在全局范围内允许同时存在的实例上限注意不是每队一个是所有人加起来只能有这么多。如果队伍多、题目热门很容易就被占满后启动的选手会一直排队。Auto Destroy是无人访问多久后回收实例可以在一定程度上缓解资源压力。实操上我一般先把单题实例上限设为队伍数的三分之二然后在比赛前用几个模拟账号实测一下再按选手反馈微调。3.4 动态分值曲线怎么算别让分变成一道算术题动态靶机赛制还有一个配套机制解题人数越多这道题剩下的分越低越早解出分越高。这在一定程度上平衡了“巨人题”和“签到题”的分值差距。GZCTF里这道题的基础分、衰减系数、最低分和每道题的权重有关典型曲线会呈现“指数衰减”的趋势。不同版本对动态分值的参数命名不完全一样但原理是通的。假如某题初始分500分最低分100分前5个解出来的人分别拿500、400、320、256、205这样的递减分值第20个解出时已经贴到最低分附近。一血还会有额外的Blood Bonus加成这个是平台默认支持的。设置分值时我建议不要把衰减系数设得太狠尤其题目总数不多的小比赛分差过大会让后半程的解题彻底失去动力。3.5 网络隔离与反作弊平台是怎么做到相对公平的动态靶机的公平性并不只靠flag不同来保证网络隔离同样关键。GZCTF在调度动态容器时会为每个实例分配独立的内部网络标识队伍之间默认不能互相访问对方的容器。这样就算有人拿到了同队队友的实例地址也无法从别的队伍容器里读取数据。配合容器启动时生成的随机token选手访问自己靶机时用的是带token的URL其他人无法猜测和接管。当然这并不能完全防止选手互相交换答案比如把自己容器里的flag直接发给别人。平台层面的反作弊手段主要是IP绑定、提交频率限制、封禁账号等再往下就要靠赛制设计和人工复核了。对于小规模比赛动态靶机加独立网络已经足够挡住大多数简单作弊方式不用过度设计。4. 完整实战从 Dockerfile 到第一道动态题前面讲了一堆原理这一节我带你把一道简单的Web动态靶机题完整走一遍。从写Dockerfile开始到推到Registry再到选手端启动容器、访问、拿flag、提交大家照着这个流程走后面学会做其他类型的题就只是换个镜像而已。4.1 一道带命令注入漏洞的迷你靶机为了演示我写一个极简的Python HTTP服务它接收一个cmd参数直接拼到系统命令里执行。这个设计在真实比赛里不算出彩但用来展示动态靶机的完整链路非常合适。import os from http.server import BaseHTTPRequestHandler, HTTPServer FLAG flag_path /flag if os.path.exists(flag_path): with open(flag_path) as f: FLAG f.read().strip() class Handler(BaseHTTPRequestHandler): def do_GET(self): if self.path.startswith(/cmd): cmd self.path.split(, 1)[1] if in self.path else id result os.popen(cmd).read() self.send_response(200) self.end_headers() self.wfile.write(result.encode()) else: self.send_response(200) self.end_headers() self.wfile.write(bhello ctfer) def log_message(self, fmt, *args): pass HTTPServer((0.0.0.0, 8000), Handler).serve_forever()这个服务读取/flag文件但并没有直接暴露它选手需要利用命令注入绕过限制才能拿到flag。Dockerfile可以用前面给的那个Alpine模板把Python代码拷贝进去暴露8000端口。这里刻意选了Alpine加Python的标准库不用Flask镜像体积能控制在100MB上下动态靶机拉起会快很多。4.2 构建镜像并推到私有 Registry镜像构建好之后接下来是把镜像推到Registry里。假设平台compose里Registry的地址是registry:5000而镜像名字必须让平台能用同样的逻辑访问到。实际操作中因为Docker客户端和Registry容器都在同一个宿主机上推镜像时可以用宿主机上的映射端口或直接访问容器网络。我建议在构建时就把镜像tag成完整Registry地址的格式docker build -t localhost:5000/web/cmd-exec:1.0 . docker push localhost:5000/web/cmd-exec:1.0推成功后用docker pull localhost:5000/web/cmd-exec:1.0验证一下能否正常拉取。这里要用到2.4节里生成的Registry账号密码Docker会提示登录。如果登录失败先检查auth/htpasswd文件内容和compose里的Registry__Password是否一致这是自建Registry最常见的坑。4.3 在管理后台创建题目并走通全流程镜像推好以后回到GZCTF管理后台创建一个题目。题目类型选Dynamic镜像名填localhost:5000/web/cmd-exec:1.0。但这里有个细节平台主程序解析镜像名时可能不会自动补全Registry地址你要么在平台里配置Registry地址后镜像名直接用仓库内路径加标签的完整格式要么提前在测试环境确认平台能正确解析。我的习惯是在配置里把Registry__Url设置为可访问的Registry地址镜像名就填完整的registry地址/项目名/镜像名:标签避免歧义。端口配置填8000内存限制给256MB实例上限按队伍数预估。保存后用选手身份进入比赛点击“启动实例”等待几秒钟平台会返回一个访问URL。浏览器打开这个URL访问/cmd?cmdcat /flag就能看到自己这个实例独有的flag。复制提交分数立刻到账。整个链路走通你的动态靶机环境就算真正能用了。5. 运维实录比赛中最容易踩的坑与排查方法就算部署顺利比赛进行中也一定会冒出各种状况。下面这些坑我基本都踩过有的是比赛现场临时救火才解决掉的。我把常见问题和排查思路整理成一张速查表再分别展开说。现象可能原因排查思路容器一直Pending或创建失败镜像不存在、资源不足、Docker socket权限问题看平台日志和docker ps -a确认容器状态选手访问不了靶机URL端口配置错误、反代未传递WebSocket/头部对比容器内端口与平台配置flag不一致或提交失败镜像没读GZCTF_FLAG、直接内置了固定flag检查启动脚本和Dockerfile高并发下平台响应慢内存不足、容器数量超预算查看内存占用临时调低实例上限比赛后迁移数据丢失只备份了数据库没备份Registry和对象存储必须同时备份三类数据5.1 动态容器一直创建失败问题到底出在哪只要动态靶机起不来比赛就基本没法进行所以这是优先级最高的问题。第一步先看GZCTF主程序日志一般会给出失败原因比如“image not found”或“no space left on device”。如果是镜像找不到回Registry页面确认镜像是否真的推成功了镜像名是否和题目配置一字不差。如果是磁盘满了清理无用的镜像和日志扩容磁盘。还有一个隐蔽问题如果你给GZCTF主程序挂载的Docker socket路径不对它根本连不上Docker所有容器都会卡在待创建状态。5.2 选手连不上靶机端口和反代这里最容易绕晕直连模式下GZCTF会给每个实例暴露宿主机的随机端口选手访问http://服务器IP:随机端口/token。如果你在服务器前面还有一层Nginx或Caddy反向代理事情就变得复杂起来。你得保证动态容器的那一段端口范围也被代理转发而且需要把原始Host和协议头正确传给后端。很多人只配了平台主程序的站点代理忘了靶机端口范围结果比赛一开始页面能打开、容器能启动就是访问URL死活连不通。配置反代时还需要留意HTTP和HTTPS协议不一致的问题。平台页面是HTTPS动态靶机访问URL如果还是HTTP浏览器会直接拦截混合内容选手一脸懵。这类问题排查起来不难但要在赛前就让几个模拟账号实际走一遍全流程别等到比赛已经开始才暴露。5.3 flag不一致或者拿不到镜像规范一旦出错全盘皆输flag相关的问题十有八九出在镜像启动脚本上。常见三种情况脚本压根没读取GZCTF_FLAG环境变量所有实例共用一个写死在镜像里的flag脚本把flag写进/flag了但应用读的不是这个位置以及脚本执行顺序不对应用启动之后flag才生成。排查时手动run一个容器用-e GZCTF_FLAGtest_flag方式跑起来进去看看flag文件是否存在、内容是否等于传入的环境变量基本就能定位问题。我强烈建议在出题阶段就做这个手动验证别等题目上线了再试。5.4 并发一高平台就卡资源预算必须提前算动态靶机的资源消耗不是线性的。平时没人启动容器平台闲得很比赛开赛前30分钟所有人同时点启动瞬间可能创建上百个容器这时候CPU、内存、磁盘IO一起飙升。我在一次实验中没控制好某道题设了很大内存限制结果50个实例直接把16G内存吃满平台和数据库一起卡死比赛被迫中断了十来分钟。经验教训是赛前一定要做并发压测至少用模拟账号同时启动十几个容器观察资源占用。动态题的实例上限宁可保守一点也不要一次给太宽容器满了选手可以排队等待平台崩了那是所有人一起等着。另外可以给Docker配置日志文件上限防止某个容器的stdout把磁盘打满。5.5 比赛数据备份与快速迁移守住平台的三样家底比赛结束以后数据备份和迁移同样重要。GZCTF的数据分布在三个地方PostgreSQL数据库里的用户、比赛、题目、提交记录对象存储或本地目录里的附件和头像Registry里的所有题目镜像。只备份其中一个都不够任何一块缺失恢复出来的平台都是残废的。我的备份习惯是停掉容器后直接备份整个项目目录的data、auth再用pg_dump导出数据库Registry的数据用volume备份或直接打包/var/lib/registry。恢复时先按同样的compose启动空平台再把备份导回去重启容器即可。这个过程最好选在比赛后马上演练一次真到要迁移服务器的时候才不会手忙脚乱。最后再分享一点个人习惯无论规模多大的比赛正式开赛前24小时我一定会做一次全链路模拟——用一个普通选手账号走一遍注册、开容器、做题、交flag的完整流程顺便检查服务器负载。动态靶机的坑大多不是出现在配置文档里而是出现在并发瞬间和版本差异里。先把这套流程跑顺了比赛时你才有底气坐在那里喝茶而不是蹲在服务器前看日志。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
