ctf比赛环境搭建

上个月我帮学校社团搭了一套CTF训练平台，赛环折腾了整整两个通宵。境搭建最坑的赛环不是写题目，而是境搭建环境本身——选手连不上服务器、容器启动超时、赛环flag被提前爆破。境搭建这些破事比解题还让人头大。赛环

先说最基础的境搭建架构。别一上来就搞Kubernetes，赛环那玩意儿对五人小社团就是境搭建灾难。我推荐Docker Compose起步，赛环单台4核8G的境搭建云服务器足够跑20个并发容器。每个题目一个独立容器，赛环用docker-compose定义端口映射和资源限制。境搭建比如一道web题，赛环就映射一个随机端口到容器内的80端口，同时挂载一个只读的flag文件进去。

关键点是镜像隔离。我见过有人图省事，所有题目共用一个基础镜像，结果选手拿到shell后直接docker exec进了别人的容器。正确做法是每个题目构建独立镜像，哪怕只是改个环境变量。写Dockerfile时记得把flag放进环境变量而不是写死在代码里，这样即使代码泄露也不会直接暴露flag。

动态flag这块有个坑。如果所有选手共享同一个flag，第一个提交的人就能毁掉整场比赛。我后来改用每道题每个选手一个独立flag，通过一个简单的API服务动态注入。选手访问题目时，平台根据其token生成专属flag写入容器。实现起来不复杂，写个几十行的Flask应用就够，但能避免99%的作弊纠纷。

网络策略别忽略。默认桥接网络会让所有容器互通，选手拿下A题容器后就能横向扫描B题。我习惯把每道题的容器划到独立的docker network里，同时禁止容器访问宿主机以外的网段。iptables规则写几条就够，但能挡住大多数脚本小子的试探。

checker机制是另一个容易被忽略的环节。光有题目不行，你得知道选手是否真的解出来了。最简单的做法是让flag格式固定为flag{ ...}，平台定期扫描容器日志或文件系统来确认flag是否被读取。进阶一点，可以写个健康检查脚本，每五分钟探测一次容器状态，如果发现容器被提权或者被破坏就自动重启。

资源限制必须写死。内存限制512M，CPU限制0.5核，超了就杀容器。不然有人写个死循环就能拖垮整个平台。我见过最离谱的一次，某个选手跑了个fork炸弹，直接把宿主机的OOM killer触发，连带其他题目的容器全挂了。

最后说下平台选择。CTFd是社区最常用的开源平台，安装方便，插件也多。但它的动态容器功能要配第三方插件，我折腾了半天才跑通。如果你只是线下赛用，其实可以更暴力——直接写个简单的web页面，选手提交flag后手动核对。反正线下赛就几十号人，效率低点也无所谓。

哦对了，备份这事千万别偷懒。比赛前把整个docker目录打包存一份，包括所有镜像和容器配置。去年有场比赛服务器被选手搞崩了，主办方没有备份，题目全丢了，最后只能临时改题。那种尴尬场面，经历过一次就再也不敢不备份了。

环境搭完，别忘了自己先当选手跑一遍流程。从注册账号到提交flag，每个环节都亲手试一次。我上次就是没测重置密码功能，结果比赛当天有人忘记密码，后台又没配邮件服务，只能手动改数据库。小细节，大麻烦。