# 学 / 练 / 考一体化 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 分层架构 ```mermaid 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` - 业务层自研 - 一期先做“练 + 考” - 二期再补“学” - 题库从第一天起就按“同题多场景复用”设计 这条路线综合了建设速度、长期扩展性和容器题支撑能力，整体风险最低。