mine_ctf/docs/ctf-platform-plan.md

学 / 练 / 考一体化 CTF 平台规划文档

1. 文档目的

本文档用于规划一套基于现有开源项目二次开发的 CTF 平台，目标是支持：

• 学：课程化学习、知识点引导、实验闯关
• 练：日常刷题、专题训练、战队训练、靶场实操
• 考：正式考试、分班分组、限时考核、成绩导出

规划重点不是“从零重写一个 CTF 平台”，而是“基于成熟开源项目快速搭建可持续演进的平台”。

2. 建设目标

2.1 总目标

建设一套统一账号、统一题库、统一成绩、统一运维的 CTF 平台，让同一批题目可以在不同场景下复用：

• 在学习场景中作为带引导的实验题
• 在训练场景中作为刷题题或战队训练题
• 在考试场景中作为正式考核题

2.2 业务目标

• 降低办赛、带队训练、组织考核的重复配置成本
• 让题库从“赛事型资产”升级为“教学型资产”
• 让用户成长路径可追踪：学过什么、练过什么、考得怎样
• 让平台可以支持学校、培训营、企业内训三类典型场景

2.3 非目标

首期不建议把范围做得过大，以下内容建议暂不作为一期硬目标：

• 完整 LMS 能力（长视频直播、作业批改、论坛社区）
• 远程 AI 监考
• 全量攻防演练平台
• 完整 OJ / 编程题平台

3. 现有开源项目选型判断

3.1 结论先行

推荐路线：

• 以 GZCTF 作为题目运行与比赛引擎
• 以自研“门户层 / 教学层 / 考试层”补齐学练考一体化能力
• 课程编排、模块化学习路径可借鉴 pwn.college dojo 的组织方式
• CTFd 适合作为备选方案，尤其适合 Python 团队或轻量活动场景

3.2 选型对比

项目	更适合做什么	优势	短板	结论
GZCTF	比赛引擎、容器题运行、动态环境	原生支持 Docker / K8s、动态容器、动态 Flag、动态分值、分组与写作收集，偏实战赛事	学习路径、课程编排、考试流程管理仍需补齐；二开需考虑其授权与品牌要求	作为底座优先
CTFd	轻量比赛平台、插件式扩展、主题定制	社区成熟、插件和主题机制完善、动态分值 / Hint / Unlock 链路成熟	容器题与隔离环境能力通常要依赖插件或外围系统，自带“学练考一体”能力不足	作为备选
pwn.college dojo	学习编排与课程组织参考	课程 / 模块 / 挑战的组织模型清晰，适合“学”的层面借鉴	系统复杂，直接作为底座成本较高	作为设计参考，不建议直接做底座

3.3 为什么更推荐 GZCTF

对于“学、练、考一体”平台，最难的往往不是前台页面，而是下面这些底层能力：

• 容器题的生命周期管理
• 动态 Flag 和题目隔离
• 并发下的稳定性
• 比赛中的监控、日志、排行榜
• 后续向靶场 / 实验环境扩展的空间

GZCTF 在这些方面更贴近目标平台的核心诉求。如果后面考试和训练都需要大量 Web / Pwn / Misc 实验环境，GZCTF 更容易成为长期底座。

3.4 选型注意事项

• GZCTF 的官方资料显示其核心基于 AGPLv3，同时存在受限组件与商标要求，二开前要先确认对外部署方式、代码开放义务、品牌展示要求。
• CTFd 为 Apache-2.0，更宽松，但平台核心能力更偏“赛事壳子 + 插件扩展”。
• 如果团队主力是 Python，且一期重点是“题库管理 + 课程引导 + 轻考试”，CTFd 可更快起步。
• 如果团队需要中长期支撑容器题、实训、校赛、结课考核，GZCTF 更值得投入。

4. 产品定位与场景设计

4.1 平台定位

目标平台不是单纯办赛平台，而是“安全实训操作系统”，至少覆盖三类场景：

1. 课程学习
2. 日常训练
3. 正式考核

4.2 三大模式定义

学

面向初学者与课程学习过程，强调引导和路径：

• 按方向组织课程：Web、Pwn、Crypto、Reverse、Misc、AWD 基础等
• 按模块组织知识点：基础、进阶、专题、综合
• 每个模块绑定题目、附件、题解、讲义、视频或外链资料
• 支持前置依赖与解锁规则
• 支持练习记录、学习进度、掌握度统计

练

面向平时训练和战队培养，强调自由度和强反馈：

• 公开练习场
• 专题训练营
• 限时训练赛
• 班级 / 战队内部排行榜
• 靶机或容器环境一键启动、重置、续期

考

面向正式考试和结业考核，强调过程可控与结果可审计：

• 题单 / 试卷编排
• 限时开放、迟到策略、交卷策略
• 分班 / 分组 / 分考场
• 随机抽题或 A/B 卷
• 成绩冻结、申诉复核、成绩导出
• 操作日志、提交记录、异常行为审计

4.3 统一设计原则

同一题目应当只维护一份“主数据”，在不同场景下用不同策略发布：

• 学习模式：可见提示、可见知识点、可见题解、可多次重置
• 训练模式：弱提示、开放时间长、强调排行榜与环境可用性
• 考试模式：严格限制提示、限制可见性、强调审计与防泄题

5. 核心能力规划

5.1 统一账号与组织体系

• 用户账号
• 班级 / 训练营 / 战队 / 学院组织
• 角色权限：学生、教练、讲师、命题人、管理员、考务
• 单点登录预留：学校统一认证、企业 AD / OAuth

5.2 统一题库

每道题建议维护以下元数据：

• 题目名称、方向、难度、标签
• 题目类型：附件题、静态容器题、动态容器题
• 知识点、前置知识、学习目标
• 场景属性：可学习、可训练、可考试
• 预计用时、建议人群、题解开放策略
• 附件、容器镜像、Flag 策略、环境依赖
• 风险等级：是否容易泄题、是否需独立环境、是否适合考试

5.3 学习中心

• 课程树 / 模块树
• 学习路径解锁
• 讲义 / 视频 / 外链资料挂载
• 分步提示与题解控制
• 学习进度、完成率、掌握度看板

5.4 训练中心

• 自由刷题
• 专题闯关
• 周赛 / 月赛 / 内部选拔赛
• 战队协作模式
• 环境重置、限时续期、实例回收

5.5 考试中心

• 题库抽题
• 固定题单组卷
• 分班分卷
• 防串题策略
• 审计日志与导出
• 成绩单、班级统计、知识点维度分析

5.6 内容运营与运维中心

• 题目导入导出
• 镜像构建与发布
• 附件管理
• 公告、通知、活动配置
• 平台监控、容器监控、告警
• 比赛 / 考试结束后的归档与复盘

6. 推荐总体架构

6.1 架构原则

• 核心运行能力复用开源项目
• 业务编排能力自研
• 题目主数据与运行实例分离
• 平台门户与比赛内核解耦

6.2 分层架构

flowchart LR
    A[统一门户 Frontend] --> B[业务中台 API]
    B --> C[学习服务]
    B --> D[训练服务]
    B --> E[考试服务]
    B --> F[用户与组织服务]
    C --> G[统一题库服务]
    D --> G
    E --> G
    D --> H[GZCTF 比赛/环境引擎]
    E --> H
    G --> H
    B --> I[统计分析服务]
    H --> J[(PostgreSQL/Redis/Object Storage)]
    B --> J
    H --> K[Docker / K8s]

6.3 模块拆分建议

建议拆成两大域：

A. 平台业务域

• 门户前端
• 账号与组织
• 课程与学习路径
• 训练计划
• 考试编排
• 数据分析

B. 题目运行域

• 比赛 / 练习实例
• 动态容器
• Flag 校验
• 排行榜
• 提交记录
• 环境监控

这样做的好处是：以后即使底层引擎从 GZCTF 调整为别的方案，平台层仍可保留。

7. 一期建议范围（MVP）

7.1 一期目标

先验证“统一题库 + 训练 + 考试”能跑通，再补“课程化学习”。

原因：

• 训练和考试更接近 GZCTF / CTFd 的现有能力，落地更快
• 学习中心需要更多内容运营和教学设计，见效略慢
• 先把题库、环境、权限、成绩这些硬骨头打通，后续扩展最稳

7.2 一期功能清单

• 统一登录
• 统一题库主数据
• 题目与 GZCTF 实例映射
• 公开练习场
• 限时训练赛
• 基础考试模式
• 成绩导出
• 基础统计报表
• 题目发布审批流

7.3 一期不做或弱化

• 视频课程
• 复杂学习画像
• AI 助教
• 高级反作弊
• 多校区多租户强隔离

8. 二期建议范围

二期再把“学”补齐，形成真正的一体化闭环：

• 课程中心
• 模块化知识图谱
• 学习路径解锁
• 分步提示与题解策略
• 教师面板
• 班级画像
• 训练推荐
• 题目质量分析

9. 三期建议范围

• 多租户 / 多院系隔离
• SSO 与组织同步
• 高级防作弊策略
• 题目工厂与 CI/CD
• 自动化镜像体检
• 资源预算与弹性扩缩容
• 区域化部署与灾备

10. 技术实现建议

10.1 底座策略

推荐采用“外包内核”思路：

• GZCTF 负责比赛、容器、Flag、提交、排行等运行时能力
• 自研业务服务负责课程、训练编排、考试编排、组织、报表

不要一开始就深改 GZCTF 核心代码，优先采用：

• API 集成
• 主题定制
• 外挂服务
• 数据同步

只有在 API 明显不够时，再考虑有边界地修改底层项目。

10.2 题目内容流水线

建议从一开始就建立题目标准化流程：

1. 题目源码和附件放在 Git 仓库
2. 容器题通过 CI 构建镜像
3. 题目元数据同步到统一题库
4. 题目按场景发布到学习 / 训练 / 考试
5. 结束后回收环境并归档数据

10.3 部署建议

按阶段划分：

• 本地开发：Docker Compose
• 测试环境：Docker + 单节点 K3s
• 生产环境：K8s + PostgreSQL + Redis + MinIO + 监控告警

如果目标规模在校内 100 到 300 人，初期可以从 Docker 起步。 如果目标是长期平台、公开赛事或多班并发考试，尽早上 K8s 更稳。

10.4 数据与审计建议

至少要保留以下数据：

• 用户学习记录
• 提交记录
• 题目 solve / fail 数据
• 环境启动与销毁日志
• 成绩变更日志
• 考试过程日志

这些数据决定了后续是否能做：

• 成绩复核
• 异常行为分析
• 题目难度校准
• 学习推荐

11. 关键风险与应对

11.1 授权与合规风险

风险：

• 直接二开 GZCTF 可能涉及 AGPL、受限组件、商标展示要求

应对：

• 在立项阶段先做开源合规审查
• 能用 API / 插件方式扩展，就先不深 Fork
• 对外发布前准备版权说明、源码开放策略和品牌说明

11.2 泄题与场景污染风险

风险：

• 同一题同时用于学习、训练、考试，容易泄题

应对：

• 题目增加场景标签与发布策略
• 题解、Hint、附件按模式隔离
• 考试题优先使用变体题或同知识点不同载体题

11.3 容器资源与并发风险

风险：

• Web / Pwn 动态环境消耗大，考试高峰容易打满机器

应对：

• 题目按资源等级分层
• 预热热点镜像
• 配置实例回收策略
• 提前做压测和限流

11.4 内容生产瓶颈

风险：

• 平台搭好了，但课程和题库跟不上

应对：

• 优先做 1 到 2 个方向的精品专题
• 建立题目模板和审核标准
• 把命题、讲义、题解形成统一生产规范

12. 建议里程碑

M0：2 周

• 完成开源选型确认
• 梳理授权与合规边界
• 跑通 GZCTF 本地 PoC
• 明确统一题库的数据模型

M1：4 到 6 周

• 完成统一登录
• 完成题库后台
• 完成练习场 MVP
• 打通题目发布与实例启动

M2：4 到 6 周

• 完成训练赛模式
• 完成基础考试模式
• 完成成绩导出和基础报表

M3：4 到 8 周

• 完成课程中心
• 完成学习路径与进度跟踪
• 完成教师 / 教练视角看板

M4：持续演进

• 多租户
• SSO
• 监控告警完善
• 自动化题目流水线
• 更完整的数据分析

13. 当前建议的落地路径

最务实的落地方案是：

1. 先把 GZCTF + 统一题库后台 + 练习/考试编排 做出来
2. 用最小成本跑通一个真实场景，例如“校队训练营 + 结课考核”
3. 通过一期积累用户、题目、流程数据
4. 再把课程学习、知识图谱、推荐系统慢慢补上

这样做比“一开始就做一个特别全的平台”更稳，也更容易真正上线。

14. 下一步建议

如果按这个方向继续推进，建议下一份文档直接进入下面三选一：

1. 一期 PRD：把 MVP 功能拆成页面、角色、流程、字段
2. 技术架构设计：把服务划分、数据流、部署拓扑画出来
3. 题库模型设计：把课程、题目、训练、考试之间的数据关系先定死

15. 参考项目与资料

• GZCTF 官方文档：https://gzctf.gzti.me/
• GZCTF GitHub：https://github.com/GZTimeWalker/GZCTF
• CTFd 官方文档：https://docs.ctfd.io/
• CTFd GitHub：https://github.com/CTFd/CTFd
• pwn.college dojo：https://github.com/pwncollege/dojo
• pwn.college example-dojo：https://github.com/pwncollege/example-dojo

16. 本文档的推荐决策

如果现在就要拍板，我的建议是：

• 底座选 GZCTF
• 业务层自研
• 一期先做“练 + 考”
• 二期再补“学”
• 题库从第一天起就按“同题多场景复用”设计

这条路线综合了建设速度、长期扩展性和容器题支撑能力，整体风险最低。