概要设计文档
This commit is contained in:
parent
59e1c21181
commit
f713e45945
@ -1,2 +1,6 @@
|
||||
# mine_ctf
|
||||
|
||||
## Docs
|
||||
|
||||
- [CTF Platform Plan](docs/ctf-platform-plan.md)
|
||||
|
||||
|
||||
474
docs/ctf-platform-plan.md
Normal file
474
docs/ctf-platform-plan.md
Normal file
@ -0,0 +1,474 @@
|
||||
# 学 / 练 / 考一体化 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`
|
||||
- 业务层自研
|
||||
- 一期先做“练 + 考”
|
||||
- 二期再补“学”
|
||||
- 题库从第一天起就按“同题多场景复用”设计
|
||||
|
||||
这条路线综合了建设速度、长期扩展性和容器题支撑能力，整体风险最低。
|
||||
Loading…
x
Reference in New Issue
Block a user