hokytawio/CloudFlare-Threat-Landscape-Monitor

Radar PT — 威胁态势仪表板 面向葡萄牙的威胁情报仪表板，在 [Cloudflare Radar API](https://developers.cloudflare.com/radar/) 的基础上构建（在 AI 的辅助下）。实时 显示针对葡萄牙的 DDoS 攻击（layer 3/4 和 layer 7）、来源国家/地区、 IPv6 采用率、自动化流量（bot）百分比，以及 Cloudflare 报告的流量 异常。 - 项目初衷 我构建此项目作为我向 SOC/Blue Team 分析师转型的一部分——目标不仅是“拥有一个漂亮的仪表板”，而是练习我当前 工作中每天使用的技能（关联安全数据、设计检测、思考监控 系统的可靠性），并将其应用于我所在公司的封闭 环境之外，结合真实的公开威胁情报 API。 - 架构 ``` ┌─────────────┐ ┌──────────────────┐ ┌────────────────────┐ │ Browser │──HTTP──▶│ Backend FastAPI │──HTTP──▶│ Cloudflare Radar │ │ React/Vite │◀────────│ (proxy + cache) │◀────────│ API │ └─────────────┘ └──────────────────┘ └────────────────────┘ ``` 前端从不直接与 Cloudflare 通信。所有请求 都经过自建的 backend，它会： - 将 API token 保存在浏览器无法访问的位置； - 在内存中进行缓存（TTL 为 60 秒），以免耗尽 Radar API 的速率限制 或重复不必要的调用； - 在将错误返回给客户端之前对其进行标准化（参见安全章节）。 ``` backend/ FastAPI — chama a Radar API com o token e faz cache └── app/ ├── main.py entrypoint + CORS ├── config.py settings via .env (pydantic-settings) ├── radar_client.py cliente HTTP + cache TTL └── routers/radar.py endpoints consumidos pelo frontend frontend/ React + Vite + Tailwind + Recharts └── src/ ├── App.jsx fetch de dados + parsing defensivo do JSON ├── api.js wrapper de chamadas ao backend └── components/ ├── Header.jsx relógio + indicador live/erro ├── RadarSweep.jsx elemento assinatura: radar giratório com os │ países de origem dos ataques como "blips" ├── AttacksTimeline.jsx layer3 vs layer7 ao longo do tempo ├── StatCard.jsx └── AnomaliesFeed.jsx ``` - 技术栈 **Backend:** Python, FastAPI, httpx (async), pydantic-settings **Frontend:** React 18, Vite, Tailwind CSS, Recharts **数据源:** Cloudflare Radar API v4（endpoint 包括 `attacks/layer3`、 `attacks/layer7`、`http/summary/*`、`annotations`） - 解决的技术挑战 代码审查中发现的实际问题： 1. 异常 endpoint 需要强制的时间范围** `/radar/annotations` endpoint 返回 `400 Bad Request` 并带有提示 `"You must send either range or start & end dates"`。最初的请求并未 包含 `dateRange`。修复方法：在 backend 中添加缺失的参数。 单凭这一点并不算严重——但它揭示了第二个问题： 2. 单个 endpoint 失败会导致整个仪表板崩溃** 前端使用 `Promise.all()` 并行请求 6 个 endpoint。 只要**一个** promise 失败，`Promise.all` 就会拒绝，这意味着其他 5 个图表——本来已经有有效数据——仅仅因为异常 endpoint 就会卡在 错误状态。使用 `Promise.allSettled()` 修复：每个 widget 独立处理其自己的结果， 并且只有在**所有**请求都失败时，仪表板才会显示错误。这 与任何生产环境监控面板所期望的**优雅降级**是相同的原则——SIEM 不会因为特定的 数据源宕机而致盲。 3. 速率限制 / 环境配置** backend 中 60 秒的缓存 TTL 专门用于避免在开发期间耗尽 Radar API 的速率限制，因为前端 每 5 分钟自动重新查询一次数据，并且在每次手动刷新页面时也会查询。 安全考量！ 我将其视为内部包含有效凭证的任何服务来处理，即使 这是一个本地项目： | 风险 | 状态 | |---|---| | token 暴露在浏览器端 | 已缓解——token 仅存在于 backend | | token 被提交到 git | 已缓解——`.gitignore` 排除了 `backend/.env` | | 通过错误消息泄露内部细节 | 已缓解——upstream 错误仅保留在服务器日志中；客户端 接收通用错误消息 | | 通过 API 数据进行 XSS | 默认已缓解——React 默认会对文本进行转义；未使用 `dangerouslySetInnerHTML` | | 某个 endpoint 宕机导致一切崩溃 | 已缓解——`Promise.allSettled` + 按 widget 实现 优雅降级 | | backend 未经认证暴露 | **未缓解**——设计为在 `localhost` 运行。如果公开暴露，任何人都可以调用 `/api/*` 并耗尽 token 配额（open proxy）。前端需要加入 专属认证 | | 自身 endpoint 无速率限制 | **未缓解**——60 秒的缓存有所帮助，但并不能防止对 backend 的直接 滥用 | | token 权限范围 | 取决于始终使用“Radar”模板（read-only），绝对不要使用具有 zone/DNS 访问权限的 token | 如果你想在本地测试，请遵循以下教程： #1. 获取 Cloudflare Radar token 1. https://dash.cloudflare.com/profile/api-tokens 2. **Create Token** → 模板 **"Radar"**（或带有 `Account > Radar > Read` 的自定义配置） 3. 保存 token——它只会显示一次 4. Backend ``` cd backend python -m venv venv venv\Scripts\activate # Windows (PowerShell: venv\Scripts\Activate.ps1) # source venv/bin/activate # macOS/Linux pip install -r requirements.txt copy .env.example .env # macOS/Linux: cp .env.example .env # 编辑 .env 并粘贴 CLOUDFLARE_API_TOKEN uvicorn app.main:app --reload --port 8000 ``` 在 http://localhost:8000/health 确认 3. Frontend ``` cd frontend npm install npm run dev ``` 打开 http://localhost:5173 理想化者？ Octávio Garcia，在 Claudinho（AKA CLAUDE AI）的协助下完成！ Cybersecurity - SOC - Blue Team analyst.

标签：自定义脚本, 运行时操纵, 逆向工具