sanctum-sec/soc-day3-scout
GitHub: sanctum-sec/soc-day3-scout
一个面向SOC场景的轻量级威胁情报聚合与查询平台，从多个公开源自动摄取IOC并提供即时信誉查询和事件广播能力。
Stars: 0 | Forks: 0
# 团队 2 — 侦察兵：威胁情报聚合器
**您的 Lightsail：** `wic02.sanctumsec.com` (63.179.14.154)
**您的 GitHub 仓库：** `https://github.com/sanctum-sec/soc-day3-scout`
**请先阅读：** [`sanctum-sec/soc-protocol`](https://github.com/sanctum-sec/soc-protocol) — 这是您必须遵守的约定。
## 1. 您的任务
您是 SOC 的**智库**。您从公共互联网中提取网络威胁情报，对其进行清洗并使其可查询，以便其他团队能在数秒内得到*“这是否有害？”*的答案。
到今天结束时，您将拥有：
- 对 3 个以上免费公开的威胁情报源（URLhaus、ThreatFox、Firehol、Spamhaus、Tor exit list）进行定期拉取
- 带有信誉评分、标签和时间戳的本地 SQLite IOC（IP、域名、哈希、URL）数据库
- 供其他团队查询的 Query API，如：`GET /ioc/bad-ips`，`GET /enrich?ip=…`
- 将高信誉度 IOC 以 SOC Protocol 的 `ioc` 事件形式广播给分析师和猎人的推送器
- 可以查看您的智库内容、已提取的数据以及谁在调用*您的* API 的管理员控制台
陷阱团队指望您将攻击者标记为已知有害。分析师指望您对警报进行评分。猎人指望您在评估异常时提供上下文。您是所有人的第二意见。
## 2. 在真实 SOC 中的定位
摘自 MITRE 表 1《11 Strategies of a World-Class SOC》：
- **网络威胁情报收集、处理与融合** — 您需要完成这三项工作。
- **网络威胁情报分析与生产** — 标签化、评分、趋势分析。
- **网络威胁情报共享与分发** — 您向同级工具发布数据。
这是每个成熟的 SOC 迟早都会构建的功能。今天，您将在八小时内构建一个最小可行版本。
## 3. 访问权限与已安装环境
```
ssh ubuntu@wic02.sanctumsec.com
# 密码/пароль: 参见 https://wic-krakow.sanctumsec.com/wic-access-ghosttrace (Basic Auth: wic / stepup-krakow-2026)
```
已安装：`git`、Python 3.10 + pip、Node.js LTS、`claude`、`codex`、AWS CLI 以及用于 `s3://wic-krakow-2026` 的凭证。
出站互联网访问不受限制 — 您可以自由拉取情报源。
## 4. 数据流
### 4.1 您的产出（输出）
两种输出形式：
**(a) 按需查询 API** — 其他团队主动向您请求：
| Endpoint | 调用者 | 返回内容 |
| --------------------------------------------- | ------------------- | ------------------------------------------------------------ |
| `GET /ioc/bad-ips?since=` | **陷阱** (polling) | 带有评分和标签的已知恶意 IP 的 JSON 列表 |
| `GET /enrich?ip=1.2.3.4` | 任何人 | 单个 IP 的信誉记录（或 404） |
| `GET /enrich?domain=example.com` | 任何人 | 单个域名的信誉记录 |
| `GET /enrich?hash=` | 任何人 | 单个文件哈希的信誉记录 |
| `GET /health` | 所有人 | `{"status":"ok","tool":"scout"}` |
**(b) 推送事件** — 您将 `ioc` 事件 POST 到：
| 目标 | Endpoint | 何时触发 |
| ----------- | ------------------------------------------- | ----------------------------------------------------------------- |
| **分析师** | `http://wic03.sanctumsec.com:8000/ingest` | 只要新提取的 IOC 信誉度 ≥ 70 |
| **猎人** | `http://wic04.sanctumsec.com:8000/context` | 相同的触发条件 — 猎人使用此进行校准 |
### 4.2 您的输入（消费）
**(a) 外部威胁情报源**（免费，公开 — 初始数据集无需密钥）：
| 来源 | 获取内容 | 方式 |
| ------------------------------------------------------------------------------------------- | ------------------------------------------- | -------------------------------------- |
| [URLhaus](https://urlhaus.abuse.ch/downloads/) | 恶意 URL | 通过 HTTPS 获取 CSV，每 5 分钟更新一次 |
| [ThreatFox](https://threatfox.abuse.ch/export/) | 标记有恶意软件家族的 IOC | 通过 HTTPS 获取 JSON |
| [Firehol Level 1](https://iplists.firehol.org/?ipset=firehol_level1) | 已知恶意 IP | 纯文本列表 |
| [Spamhaus DROP](https://www.spamhaus.org/drop/drop.txt) | 垃圾邮件发送者网络 | 纯文本列表 |
| [Tor exit list](https://check.torproject.org/torbulkexitlist) | 当前 Tor 出口节点 | 纯文本列表 |
作为加分项，获取免费的 API 密钥（注册只需 2 分钟）：
- [AbuseIPDB](https://www.abuseipdb.com/register) — 每天免费检查 1000 次
- [AlienVault OTX](https://otx.alienvault.com/) — 免费，宽松的速率限制
**(b) 同级可观察数据**（告诉您“我看到了这个”的团队）：
| 发送方 | Endpoint | 发送内容 |
| ----------- | --------------------- | ---------------------------------------- |
| **陷阱** | `POST /observe` | 攻击蜜罐的新 IP |
| **猎人** | `POST /observe` | 猎人认为可疑的 IP/域名/哈希 |
您将它们录入，使用您拥有的数据进行富化，如果信誉评分超过阈值，就广播 `ioc` 事件。
### 4.3 您发出的 IOC 事件示例
```
{
"schema_version": "1.0",
"event_id": "",
"event_type": "ioc",
"timestamp": "2026-04-23T09:16:00Z",
"producer": "scout",
"severity": "high",
"observables": {
"source_ip": "203.0.113.42"
},
"data": {
"ioc_type": "ipv4",
"reputation_score": 92,
"first_seen": "2025-12-01T00:00:00Z",
"last_seen": "2026-04-22T22:00:00Z",
"tags": ["brute-force", "scanner", "tor-exit"],
"sources": ["firehol", "tor-exit-list"],
"confidence": "high"
}
}
```
## 5. 架构 — 您要构建的三个部分
### 5.1 情报引擎（提取 + 标准化）
每 15 分钟运行一次的调度器：
1. 拉取每个配置的情报源（HTTPS GET — 大多数是纯文本或 CSV）
2. 解析格式（每个情报源对应一个解析器）
3. 标准化为通用的 IOC 记录：`{ioc_value, ioc_type, source, first_seen, last_seen, tags, raw}`
4. 在本地 SQLite 中执行 Upsert（更新 `last_seen`，合并 `tags`，重新计算 `reputation_score`）
5. 检测到新的高信誉 IOC 并将其放入广播队列
### 5.2 查询 API
运行在端口 **8000** 的 FastAPI 服务器，包含 4.1(a) 中的端点。底层只是读取 SQLite。如果需要，可以添加缓存。
### 5.3 广播器
一个小型后台任务，耗尽广播队列并使用 SOC Protocol 信封将 `ioc` 事件 POST 给分析师和猎人。
### 5.4 管理页面（端口 8001）
**运营状况：**
- 情报源状态：每个源最后一次成功拉取的时间，录入的记录数量
- 数据库中的 IOC 总数，按类型（IP / 域名 / 哈希 / URL）细分
- 入站请求统计：哪些同级在访问 `/enrich` 和 `/ioc/bad-ips`，频率如何
- 广播队列深度
**安全状况：**
- 失败的身份验证
- 触发速率限制
- 因 Schema 验证在 `/observe` 上被拒绝的请求
- 查询了您所没有内容的同级（可能值得拉取的潜在有趣数据）
## 6. 推荐技术栈（非强制）
| 组件 | 推荐 | 原因 |
| -------------- | ------------------------------------------------ | ------------------------------------------------------------------------ |
| 语言 | **Python 3.10** | requests、pandas、sqlite3 — 几乎都是标准库 |
| HTTP | **FastAPI** + Uvicorn | 与所有团队一致 |
| 调度器 | **APScheduler** 或小型 asyncio 循环 | 情报源每 15 分钟一次；不需要 Celery |
| 存储 | **SQLite**，每种 IOC 类型一张表 | 单个文件，在 `ioc_value` 上建立索引 |
| HTTP 客户端 | **httpx**（支持 async）或 **requests** | 取决于您是否想要异步 |
| 管理 UI | FastAPI + Jinja + HTMX | 同上 |
## 7. 安全基础设施 — 毫不妥协
最低要求：
- [ ] `/observe` 和任何写入端点上的 Bearer token（读取端点保持开放 — 这是设计意图 — 但需带有速率限制）
- [ ] `/observe` 上的 Pydantic 验证
- [ ] 所有公共端点上的速率限制（每个 IP 200 次/分钟 — 对于查询 API 来说是合理的）
- [ ] 管理界面上的 HTTP Basic 身份验证
- [ ] **情报源白名单** — 仅从硬编码列表中的主机名拉取数据。这可以防止在发生 SSRF 时潜在的枢纽攻击。
- [ ] **默认不信任来自 `/observe` 的数据作为 IOC** — 将其标记为 `community_submitted`，在提升至高信誉之前需要第二个来源的确认
- [ ] 仅追加的安全日志
请求 Claude：
```
Add a feed-source allowlist module. When fetching, check the hostname against
a hardcoded set: urlhaus.abuse.ch, threatfox.abuse.ch, iplists.firehol.org,
www.spamhaus.org, check.torproject.org. Reject anything else with a clear
error in the security log.
```
## 8. 管理页面规范
URL：`http://wic02.sanctumsec.com:8001/admin` — HTTP Basic 登录。
**运营状况：**
- 情报源状态表：名称，最后一次获取时间，状态，记录数量增量
- IOC 总数：4 环图细分（IP / 域名 / 哈希 / URL）
- 今日查询最多的 10 个 IOC（同级最感兴趣的内容）
- 广播队列深度和错误
**安全状况：**
- 最近 50 次失败的身份验证
- 触发的速率限制
- 被 Schema 拒绝的 `/observe` 有效载荷
- 对未知 IOC 的查询（可能很有趣；可能是针对您的侦察）
## 9. 您的一天 — 与 Claude 的各个阶段
### 阶段 0 — 启动 (9:15–10:00)
与导师的共同会议。确定角色。
### 阶段 1 — 脚手架 (10:00–10:45)
```
Start a FastAPI project in ~/app. Create:
- main.py with /health and the read endpoints GET /ioc/bad-ips, GET /enrich.
They can return empty lists / 404 for now.
- /observe POST endpoint protected by bearer token validating the event envelope.
- schemas/envelope.py — shared Pydantic model.
- storage/db.py — SQLite connection + schema for ioc table (ioc_value TEXT PRIMARY KEY,
ioc_type TEXT, source TEXT, first_seen TEXT, last_seen TEXT, tags TEXT JSON,
reputation_score INTEGER).
- systemd unit to run uvicorn on port 8000.
- requirements.txt with fastapi, uvicorn, pydantic, httpx, apscheduler, slowapi.
```
提交，推送。部署。测试 `curl /health`。`/ioc/bad-ips` 的桩代码返回 `[]`。
### 阶段 2 — 情报摄取 (10:45–12:30)
```
Create ~/app/feeds/ with one parser module per source:
- firehol.py: fetches https://iplists.firehol.org/files/firehol_level1.netset,
parses out /32 IPs, returns list of (ip, "firehol_level1") tuples.
- spamhaus.py: fetches https://www.spamhaus.org/drop/drop.txt, skips ; comments,
extracts CIDR + description.
- tor.py: fetches https://check.torproject.org/torbulkexitlist, returns list of IPs.
- urlhaus.py: fetches https://urlhaus.abuse.ch/downloads/csv_recent/, parses CSV,
returns list of URLs + their malware tags.
- threatfox.py: fetches https://threatfox-api.abuse.ch/export/json/recent/,
returns list of IOCs with their types.
Then create ~/app/feeds/scheduler.py that runs all of these every 15 minutes,
upserts results into the sqlite ioc table, and recalculates reputation_score:
- In firehol/tor/spamhaus: 70
- In urlhaus: 85
- In threatfox: 85
- Appearing in 2+ sources: boost by 10
- Appearing in 3+ sources: boost by 15 (cap at 100)
Tag each ioc with all source names.
```
本地测试。首次运行应填入大约 300,000 条 Firehol 记录 + 来自其他每个来源的一些内容。
### 阶段 3 — 查询 API + 广播器 (12:30–14:30)
（包含午餐 — 去吃饭，别空着肚子写代码。）
实现：
```
Fill in GET /ioc/bad-ips — query all IPs with reputation_score >= 70, return a
JSON list of objects {ip, score, tags, last_seen}. Support ?since=
to only return IOCs whose last_seen is newer than that.
Fill in GET /enrich — accepts ?ip= or ?domain= or ?hash=. Returns the full
ioc record if found, else 404.
Fill in POST /observe — accepts an event envelope. Extract the observable
(source_ip / domain / hash), upsert into ioc table with source="community",
reputation_score=40 (low-confidence), tag=["community_submitted"].
If the same ioc already exists from another source, bump last_seen.
Create ~/app/broadcaster.py — runs every 30s. Queries ioc table for records
where reputation_score >= 70 AND last_seen > 30 seconds ago AND NOT already_broadcast.
For each, construct an "ioc" event envelope and POST to:
- http://wic03.sanctumsec.com:8000/ingest
- http://wic04.sanctumsec.com:8000/context
Mark as broadcast. If POST fails, log to security.log and retry next tick.
```
### 阶段 4 — 管理页面 + 加固 (14:30–16:30)
```
Create ~/app/admin/ on port 8001 with HTTP Basic auth, HTMX auto-refresh every 10s.
- "Operational" tab: feed health table (query a feed_runs table you also need to
create), IOC totals per type, top-10 queried IOCs today (from a query_log table),
broadcast queue depth.
- "Security" tab: last 50 entries from security.log parsed as JSON lines.
Also add rate limiting to the public endpoints: 200 req/min per source IP.
```
### 阶段 5 — 集成 + 演示准备 (16:30–17:30)
- 检查陷阱的轮询是否成功访问了 `/ioc/bad-ips`（在管理界面中查看入站请求）
- 确保您每分钟至少向分析师和猎人广播一个 `ioc` 事件
- 向 `/observe` 发送一个合成的可观察数据 — 必须端到端通过
- 编写 pytest：身份验证、Schema、enrich 查找
## 10. 如何在 3-5 人之间分配工作
如果您有 **3** 人：
| 角色 | 负责内容 |
| ------------------- | ---------------------------------------- |
| 情报源工程师 | 情报源解析器、调度器、存储 Schema |
| API + 广播器 | FastAPI 路由、广播器、信封 |
| 管理 + 部署 | 端口 8001 上的控制台、systemd、Actions |
如果您有 **4** 人：
| 角色 | 负责内容 |
| -------------------- | ---------------------------------------- |
| 情报源工程师 | 情报源解析器 + 调度器 |
| 存储 + API | SQLite Schema + 所有查询端点 |
| 广播器 | 推送事件 + 重试 |
| 管理 + 安全 | 控制台、身份验证、速率限制、日志 |
如果您有 **5** 人：
将“情报源工程师”拆分为“情报源-A”（Firehol、Spamhaus、Tor — 简单的文本格式）和“情报源-B”（URLhaus、ThreatFox — CSV/JSON）。
## 11. “先出 Mock” 检查清单
在 11:00 之前：
- [ ] `GET /health` 正常工作
- [ ] `GET /ioc/bad-ips` 返回一个包含 5 个虚假恶意 IP 的硬编码列表（以便陷阱团队可以据此进行开发）
- [ ] `GET /enrich?ip=198.51.100.` 返回一个虚假的 IOC 记录
- [ ] 带有 Bearer 的 `POST /observe` 接受一个虚假信封并返回 202
这样，在您的真实情报源数据流入之前，陷阱和猎人就可以开始集成。
## 12. 完成标准
**最低要求：**
- [ ] 成功以 15 分钟的节奏拉取三个情报源
- [ ] SQLite 中填入了 ≥ 100 个真实的 IOC
- [ ] `GET /ioc/bad-ips` 返回真实数据
- [ ] `GET /enrich` 对所有三种 IOC 类型都有效
- [ ] `POST /observe` 接收并保存社区提交的内容
- [ ] 广播器向分析师和猎人发送 `ioc` 事件
- [ ] 端口 8001 上包含两个标签页的管理界面
- [ ] systemd + GitHub Actions 部署
**加分项：**
- [ ] 5 个活跃的情报源（添加了 URLhaus + ThreatFox）
- [ ] 集成带有 API 密钥的 AbuseIPDB，用于在 `/enrich` 上进行实时查询
- [ ] IOC “衰减” — 降低 > 30 天未被看到的 IOC 的评分
- [ ] 按同级的审计日志：谁询问了哪些 IOC
- [ ] 带有源 IP 地理定位的非常小的世界地图
## 13. 进阶目标（如果您进度超前）
- 类似 MISP 的 TAXII 源，以便外部平台可以使用您的智库
- 关联分析：“该 IP 在过去一小时内在同级提交中出现了 4 次” → 自动提高置信度
- 富化流水线：对于每个新的 IOC，自动执行 WHOIS 和地理定位，并将其附加到记录中
- 将每日快照存入 `s3://wic-krakow-2026/public/scout/snapshots/`
祝狩猎愉快。
## 第 3 天的贯穿目标（AI-CTI 主题）
除了上述特定于团队的可交付成果之外，**第 3 天议程中的以下三个主题（模块 4-6）必须在您的工具、管理页面或学习产物中得到显著体现。** Claude Code — 这正是让您能在一天内完成这一切的关键 — 请善用它。
### 目标 1 — AI 增强的 CTI
在您的工具*内部*使用 Claude（或任何 LLM）自动化 CTI 周期的至少一个步骤：提取、分类、关联或富化威胁情报。这是模块 4 的实际应用。
### 目标 2 — TTP 和 AI 驱动的攻击模式
在将行为映射到 MITRE ATT&CK 时，还要识别 AI 驱动的攻击者会以不同方式生成的 TTP：LLM 生成的网络钓鱼、自动化的 OSINT 驱动侦察、机器生成的多态载荷、以异常时间间隔进行的脚本化信标通信。请在您的检测、假设、IOC 标签或操作手册中反映这一点。
### 目标 3 — AI 社会工程学（攻击*与*防御）
真正的攻击者现在正在使用 AI 来扩大网络钓鱼、声音克隆、冒充的规模。您的工具必须至少触及这一点一次：捕获一个 SE 产物、对其进行标记、对其发出警报、对其进行富化 — 或者至少记录下来，面对 AI 驱动的 SE 尝试时，您的工具将*如何*反应。
### 每个目标如何落实到您的具体工作中
- **AI 增强的 CTI：** 通过 Claude 处理每个录入的 IOC，并附带类似这样的提示：*“对于此 IOC（IP / 域名 / 哈希），用一句话描述最可能的战术和技术（MITRE ATT&CK）。”* 将 LLM 描述保存为 `data.llm_tag`；在 `/enrich` 响应中显示它。
- **TTP / AI 攻击模式：** 在拉取 URLhaus / ThreatFox 时，为引用了 `phishing-kit`、`generated-phishing` 或被情报源标记为自动化的活动的记录添加标签过滤器。公开一个专门列出这些内容的 endpoint `/ioc/ai-campaigns`。
- **AI 社会工程学：** 包含至少一个与 AI 生成的网络钓鱼域名相关的情报源。`ThreatFox` 已经对此进行了标记；在控制台的单独面板中显示它们。
标签：ESC4, Firehol, IOC数据库, IP 地址批量处理, Lambda架构, Lightsail, OSINT, REST API, SanctumSec, SOC协议, Spamhaus, SQLite, Team 2 Scout, ThreatFox, Tor出口节点, URLhaus, Web服务, WIC 2026, 信誉评分, 后端开发, 威胁情报, 威胁情报源, 威胁情报聚合器, 安全仪表板, 安全运营中心, 实时处理, 开发者工具, 恶意IP, 恶意URL, 恶意域名, 恶意软件哈希, 情报共享, 网络信息收集, 网络安全, 网络映射, 运行时操纵, 逆向工具, 隐私保护