CTF平台搭建

CTF平台不是台搭买台服务器、装个Docker就完事的台搭东西。真正动手搭过的台搭人都知道，坑全在后头。台搭

我去年给学校战队搭过一个内部训练平台，台搭用的台搭开源框架CTFd。装起来确实快，台搭十分钟跑起来，台搭但等实际用上，台搭问题一个接一个冒出来——题目上传后图片不显示，台搭动态flag生成延迟，台搭最离谱的台搭是有一次比赛进行到一半，数据库连接池爆了，台搭整场直接白给。台搭

先说选型。台搭CTFd是PHP写的，轻量，插件多，适合入门。但你要是想搞点复杂的，比如AWD攻防模式，或者想自定义积分算法，那它就不太够用了。我后来换成了基于Django的CTFd的替代品——CTFd-Whale，它把动态容器管理做得更干净，每个题目能独立起一个Docker实例，选手解题时互相隔离，不会出现一个人把环境搞崩、其他人跟着遭殃的情况。

但动态容器这东西，爽是爽，资源开销直接翻倍。一台4核8G的服务器，跑十个动态题目就有点喘了。我见过有人用Kubernetes来编排，那确实是生产级方案，但对学生团队来说，维护成本太高了。我的建议是：先想清楚你要服务多少人。五十人以内，单机加Docker Compose足够；几百人同时在线，那得考虑负载均衡和Redis缓存。

题目本身才是平台的核心，而不是平台。你平台再炫，题目烂，选手照样骂娘。我搭平台时最花时间的部分不是写代码，是出题。一道好的Web题，得有真实的漏洞环境，还得防着选手直接拿扫描器梭哈。后来我学聪明了，用docker-compose把每个题目环境隔离，再给每个容器设单独的flag，选手解出来一个，只能得那一道题的分，没法串。

别忘了日志。平台跑起来后，日志是你唯一的眼睛。谁在什么时间提交了什么flag，IP是多少，提交频率是否异常——这些全得靠日志分析。有一次我发现某个IP在五分钟内提交了三十多次错误flag，明显是在爆破。我直接把他IP封了，然后写了条规则：同一IP每分钟提交超过十次，自动触发验证码。

最后说点实在的：别一上来就追求功能齐全。你先搭个能跑的，放三道题，找几个朋友来测。测完你会发现，真正要改的不是功能，是细节——比如题目描述里的图片加载不出来，比如提交flag时大小写没统一，比如倒计时显示的是服务器时间而不是北京时间。这些小事看着不起眼，但在比赛现场，任何一个都能让选手心态爆炸。

平台这东西，永远没有“搭完”的时候。你每办一次比赛，就会冒出新需求。所以架构上留好扩展点，插件化设计，比什么都重要。我现在那个平台，已经迭代了三个大版本，最初那版CTFd早被换掉了，但数据结构没动过——因为一开始我就把用户、题目、比赛、提交记录分成了独立的模块。

搭平台就是个不断填坑的过程。你填的坑越多，下一场比赛就越稳。反正我现在看到“平台稳定运行”这六个字，心里第一反应不是欣慰，是怀疑——肯定还有哪个坑没填上。