rani27-bipo/siem-soar-n8n

# 🛡️ SOC 自动化平台 — 使用 n8n 的 SIEM/SOAR        ## 架构 ``` graph TD A[Logs entrants : Auth / Firewall / Email] -->|POST sécurisé| B[GW-007 — API Gateway] B -->|Auth token + Rate Limit + Circuit Breaker| C[SIEM-001 — Détecteur Brute Force FSM] C -->|Alerte FSM q3/q4 déclenchée| D[ORCH-000 — Dispatcher] D -->|Déduplication 15min + Corrélation APT 1h| E{Type d'incident} E -->|brute_force| F[SOAR-002 — Réponse BF] E -->|phishing| G[SOAR-003 — Réponse Phishing] F --> H[VirusTotal + AbuseIPDB] G --> H H --> I[WhatsApp L1 + OTP 6 chiffres] I -->|BF-OUI-XXXXXX| J{Décision analyste} J -->|OUI| K[SIM-004 — Blocage IP Firewall] J -->|NON| L[Escalade SOC L2] D --> M[TIMEOUT-008 — SLA Monitor toutes les 15min] M -->|SLA breached| L D --> N[REPORT-005 — Dashboard MTTD/MTTR] style B fill:#1f6feb,color:#fff style D fill:#e8710a,color:#fff style H fill:#d93025,color:#fff style I fill:#1a7f37,color:#fff ``` ## 功能 | ID | Workflow | 角色 | 技术要点 | |----|----------|------|-------------------| | `SIEM-001` | BruteForce Detector | FSM 检测 q0→q4 | 有限状态机，阈值 5 次失败 / 10 分钟，PostgreSQL 持久化 | | `SOAR-002` | BruteForce Response | 自动化响应 + OTP | VirusTotal, AbuseIPDB，指数退避重试，Supabase Edge OTP | | `SOAR-003` | Phishing Response | 隔离、清除邮件、AV 扫描 | 3 个并行操作，分析师 OTP，L2 升级 | | `ORCH-000` | Incident Dispatcher | 去重 + APT 关联分析 | PostgreSQL 缓存 15分钟去重，1小时关联，playbook 路由 | | `GW-007` | API Gateway | 认证 + 限流 | Token 认证，每 IP 100 req/min，熔断器 | | `RELAY-010` | Twilio HMAC Validator | 防 SMS 欺骗 | 对每个 callback 验证 Twilio HMAC-SHA1 签名 | | `RESP-006` | Response Dispatcher | 分析师 SMS 路由 | 解析格式 `BF-OUI-123456`，路由至正确的 playbook | | `REPORT-005` | Metrics Dashboard | 实时 SOC KPI | MTTD, MTTR, SLA compliance, automation rate, security posture | | `SIM-004` | Firewall Simulator | 模拟 EDR/FW | block_ip, isolate_host, purge_emails, full_av_scan | | `TIMEOUT-008` | SLA Escalation | SLA 监控 | 每 15分钟调度，自动 WhatsApp 升级至 L2 | ## 有限状态机与状态逻辑 该项目包含**唯一一个正式的有限状态机** (SIEM-001) 和**两个生命周期 pipeline** (SOAR-002, SOAR-003)，它们复用了类似的符号 (`q1`, `q2`...)，但在数学本质上并非状态机——为了保持严谨，特此明确区分。 ### SIEM-001 — 暴力破解检测有限状态机 真正的 5 状态 FSM，持久化在数据库中（表 `fsm_sessions`），以便在 n8n 实例重启后依然存活。状态转移表 δ(状态, 事件) → 状态，固定字母表 `{auth_fail, port_scan, priv_escalation, phishing, data_exfil, timeout, resolved}`，接受状态为 `q3` 和 `q4`。  | 状态 | 严重程度 | 优先级 | 触发告警 | |------|----------|----------|------------------------| | `q0` — 待机 | INFO | P4 | 否 | | `q1` — 可疑 | LOW | P3 | 否 | | `q2` — 侦察 | MEDIUM | P2 | 否 | | `q3` — 活跃威胁 | HIGH | P1 | 是（仅一次，通过 `alertSent` 标志位） | | `q4` — 严重沦陷 | CRITICAL | P0 | 是（每发生一次新严重事件都会重置并再次触发） | 任何 `timeout` 或 `resolved` 事件都会将状态机恢复为 `q0` 并重置计数器，无论当前处于何种状态——这可以避免已解决的事件被无限期标记为活跃，并限制因偶尔输入错误引起的误报。 ### SOAR-002 / SOAR-003 — 事件生命周期（不是 FSM） 一旦 SIEM-001 传输告警，SOAR-002 和 SOAR-003 的 playbook 将推动事件经历一个**顺序状态 pipeline** (`etat_soar` 字段)。与 SIEM-001 不同，这里没有通用的状态转移表：workflow 的每个 `Code_*` 节点都会硬编码写入下一个值，而绝不会读取前一个状态来决定转移。这是生命周期跟踪，而不是状态机。  | 步骤 | 含义 | |-------|----------------| | `q1_Triage` | 事件已创建，等待富化 | | `q2_Enrichissement` | 通过 VirusTotal + AbuseIPDB 成功富化 | | `q2_Enrichissement_Partiel` | 由于 API 失败导致部分富化 | | `q4_Containment` | 收到分析师的同意决策，已执行遏制操作 | | `q5_Escalation` | SLA 超时或遏制失败 — 升级至 L2 | | `q6_Closed` | 事件已关闭（遏制成功或分析师做出拒绝决策） | ## MITRE ATT&CK 映射 | 技术 | 名称 | 战术 | Workflow | |-----------|-----|--------|----------| | `T1110.001` | Password Guessing | Credential Access | SIEM-001 + SOAR-002 | | `T1110.004` | Credential Stuffing | Credential Access | SIEM-001 + SOAR-002 | | `T1566.002` | Spearphishing Link | Initial Access | SOAR-003 | ## 数据库 — 7 个 PostgreSQL 表 | 表 | 角色 | TTL | |-------|------|-----| | `incidents` | SOC 主表 — 包含所有 MITRE, SLA, FSM, TI 字段 | 永久 | | `fsm_sessions` | 用于暴力破解检测的各 IP FSM 状态 | 不活动 2 小时后清除 | | `otp_challenges` | 由 Supabase Edge Function 生成的 WhatsApp OTP 验证码 | 5 分钟 | | `dedup_cache` | 用于避免事件重复的去重缓存 | 15 分钟 | | `correlation_cache` | 各 IP 的持久化 APT 关联缓存 | 1 小时 | | `workflow_logs` | 所有 n8n workflow 的结构化日志 | 30 天 | | `threat_intel_cache` | AbuseIPDB + VirusTotal 缓存，以限制 API 调用 | 6 小时 | 视图 `vw_soc_dashboard` 实时计算过去 24 小时的：MTTD、MTTR、SLA compliance、automation rate、maturity level 和 security posture (GREEN / AMBER / RED)。 包含部分索引、触发器、清理函数和 RLS 的完整 schema 位于 [`database/schema.sql`](database/schema.sql)。 ## 自动计算的 SOC 指标 - **MTTD** — Mean Time To Detect：从首次日志到事件创建之间的时间 - **MTTR** — Mean Time To Respond：从事件创建到其关闭之间的时间 - **SLA Compliance** — 在规定时间内解决的事件百分比 - **Automation Rate** — 无需人工干预即解决的事件百分比 - **Security Posture** — 根据针对 P0 的事件、违反 SLA 情况以及 MTTR 评估为 GREEN / AMBER / RED - **Maturity Level** — 根据平均 MTTR 评估为 ELITE / MATURE / EN PROGRESSION / INITIAL ## 技术栈 | 类别 | 技术 | |-----------|-------------| | SOAR 编排 | n8n Cloud (10 个 workflow) | | 数据库 | 通过 Supabase 使用 PostgreSQL (7 个表，RLS，部分索引) | | 分析师告警 | Twilio WhatsApp + SMS | | Threat Intelligence | VirusTotal API + AbuseIPDB | | 安全 OTP | Supabase Edge Functions (Deno, Web Crypto API) | | Dashboard | HTML / CSS / 原生 JavaScript | | 测试 | Python 3 (从 .env 安全加载，50+ 断言) | ## 项目结构 siem-soar-n8n/ ├── README.md ├── .env.example # 环境变量 — 模板 ├── .gitignore ├── workflows/ # 导出为 JSON 的 10 个 n8n workflow │ ├── GW-007_API_Gateway.json │ ├── SIEM-001_BruteForce_Detector.json │ ├── ORCH-000_Incident_Dispatcher.json │ ├── SOAR-002_BruteForce_Response.json │ ├── SOAR-003_Phishing_Response.json │ ├── RESP-006_Response_Dispatcher.json │ ├── RELAY-010_Twilio_HMAC_Validator.json │ ├── REPORT-005_Metrics_Dashboard.json │ ├── SIM-004_Firewall_Simulator.json │ └── TIMEOUT-008_SLA_Escalation.json ├── database/ │ ├── schema.sql # 完整的 Supabase schema — 在 SQL Editor 中执行 │ └── edge-functions/ │ └── generate-otp.ts # Deno Edge Function — 加密生成 OTP ├── dashboard/ │ └── soc_dashboard.html # SOC dashboard — 实时指标 ├── images/ │ ├── n8n-workflows.png │ ├── database.png │ ├── soc_dashboard.png │ ├── SOAR_002_workflow.png │ ├── fsm_siem001_automate.png │ └── soar002_incident_lifecycle.png ├── docs/ │ └── incident_response_playbook.md # 暴力破解和网络钓鱼 playbook └── test/ └── soc_test_suite.py # Python 测试套件 — 50+ 断言 ## 安装 ### 前置条件 - n8n Cloud 账户或 self-hosted Docker 实例 - Supabase 账户（免费额度即可） - 启用了 WhatsApp Sandbox 的 Twilio 账户 - AbuseIPDB API Key（免费，每天 1000 次请求） - VirusTotal API Key（免费，每天 500 次请求） - 安装了 pip 的 Python 3.8+（用于测试套件） ### 步骤 1 — Supabase 数据库 1. 在 [supabase.com](https://supabase.com) 创建一个项目 2. 进入 **SQL Editor** 并完整执行 `database/schema.sql` — 它将创建 7 个表、索引、清理函数、dashboard 视图和 RLS 3. 部署 OTP Edge Function： ``` supabase functions deploy generate-otp --project-ref TON_PROJECT_REF ``` 源文件位于 `database/edge-functions/generate-otp.ts` 4. 在 Supabase → Settings → Edge Functions → Secrets 中，添加 secret `OTP_EDGE_TOKEN`，其值为你在步骤 2 中生成的值 5. 记下你的 **Project URL** 和 **service_role key** — 你在 n8n 中会用到它们 ### 步骤 2 — 环境变量 ``` cp .env.example .env # 打开 .env 并填写每个值 ``` 使用以下命令为每个变量生成安全的 token： ``` python3 -c "import secrets; print(secrets.token_urlsafe(16))" ``` 然后在 **n8n → Settings → Variables** 中填入相同的变量。 ### 步骤 3 — 导入 n8n workflow 在 n8n → Workflows → Import from file 中，按以下精确顺序导入 JSON： SIM-004_Firewall_Simulator.json ← 基础设施 GW-007_API_Gateway.json SIEM-001_BruteForce_Detector.json ORCH-000_Incident_Dispatcher.json SOAR-002_BruteForce_Response.json SOAR-003_Phishing_Response.json RESP-006_Response_Dispatcher.json RELAY-010_Twilio_HMAC_Validator.json REPORT-005_Metrics_Dashboard.json TIMEOUT-008_SLA_Escalation.json 在导入后激活每个 workflow。 ### 步骤 4 — 模拟暴力破解攻击 此脚本从同一 IP 发送 10 次失败的认证尝试，以触发 FSM 检测： ``` for i in {1..10}; do curl -X POST https://TON_N8N_URL/webhook/siem-logs \ -H "x-soc-token: TON_SIEM_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "type": "auth_fail", "ip": "185.220.101.45", "user": "admin", "session_id": "SESS-DEMO-001" }' sleep 2 done ``` **预期结果：** 在第 5 次失败后收到 WhatsApp 告警，在 Supabase 中创建带有 VirusTotal + AbuseIPDB 富化信息的事件，向 L1 分析师发送 OTP 以供决策，验证后触发 IP 封锁。 ### 步骤 5 — 运行测试套 ``` pip install requests python-dotenv cp .env.example .env # 用你的真实值填写 .env python test/soc_test_suite.py ``` 该套件覆盖：SIEM-001、ORCH-000、SIM-004、REPORT-005、GW-007、RESP-006、SOAR-002、SOAR-003、RELAY-010、TIMEOUT-008，以及 SQL 注入 / 恶意输入。 ### 步骤 6 — Dashboard 在浏览器中打开 `dashboard/soc_dashboard.html`。在文件中配置你的 REPORT-005 endpoint URL 以显示实时指标。 ## 安全性 - 所有 workflow 之间的 token 都通过 n8n Variables 注入 — 绝不在代码中硬编码 - 通过 RELAY-010 启用 Twilio HMAC-SHA1 验证，以防止 SMS 欺骗 - OTP 使用 Web Crypto API (CSPRNG) 通过 Supabase Edge Functions 生成，以哈希形式存储，并在 5 分钟后过期 - 在所有 7 个 Supabase 表上启用 RLS (Row Level Security) — 只有 n8n 的 `service_role` 具有写权限 - `.env` 文件被 `.gitignore` 排除在版本控制之外 - API Gateway (GW-007) 实施每 IP 100 req/min 的速率限制，并对 downstream 服务启用熔断器 ## 为何采用这些架构选择 **使用 FSM 而不是简单的阈值计数器** — 传统的计数器 (`if failed_attempts > 5`) 无法区分正在进行的攻击和已结束的活动，也无法表示逐步监控的中间状态。FSM 允许显式地建模从被动观察 (q1, q2) 到活跃告警 (q3, q4) 的转变，并在认证成功时自动重置——这减少了仅仅是输错一两次密码的用户的误报。 **使用 OTP 而不是简单的按钮确认** — 简单的可点击“确认”链接容易受到网络钓鱼攻击，并且无法保证做出验证决策的确实是被分配的分析师。发送到分析师手机上、通过服务端 (Web Crypto API) 使用 CSPRNG 生成的 OTP 挑战，保证了遏制决策来自物理上持有已注册设备的人员，且 5 分钟的有效窗口限制了重放风险。 **使用 TI 缓存而不是在每个事件发生时调用 API** — VirusTotal 和 AbuseIPDB 的免费配额有限（每天 500 和 1000 次请求）。如果没有缓存，重复出现的同一攻击者 IP 会在一天内耗尽配额，从而阻碍对真正新事件的富化。6小时的缓存在数据新鲜度和配额消耗之间取得了平衡。 **使用数据库中的持久化关联而不是 n8n 内存** — n8n 的 StaticData 是易失性的，会在实例重启或重新激活 workflow 时消失。将 APT 关联存储在 `correlation_cache` 表中而不是 StaticData 中，可确保关联历史在实例重启和部署后依然存在，这对于检测持续数小时的攻击模式至关重要。 **使用状态 pipeline 而不是为 SOAR-002/003 提供第二个 FSM** — 与可能状态和转换数量足以证明使用真正的状态转移表的暴力破解检测不同，响应 playbook 的执行本质上是线性的（分诊 → 富化 → 决策 → 遏制/升级 → 关闭）。将其建模为 FSM 会增加复杂性而无任何益处：简单按顺序写入的状态字段就足够了，并且更易于调试。 ## 我学到了什么 - 设计具有明确责任分离（检测 / 编排 / 响应 / 报告）的 **SOC 事件驱动架构** - 实现**有限状态机 (FSM)** 以进行带有数据库持久化的有状态暴力破解检测，并能够识别何时顺序 pipeline 足以替代完整的 FSM - 使用 **HMAC-SHA1** 和 Bearer token 认证来保护服务间调用 - 为 SOC 分析师的关键决策构建**多因素 OTP 验证流程** - 集成 **Threat Intelligence APIs** (VirusTotal, AbuseIPDB) 并使用缓存优化配额 - 使用 **MTTD / MTTR / SLA compliance / automation rate** 指标衡量 SOC 性能 - 编写涵盖正常用例、安全拒绝和 SQL 注入的**自动化测试套件** ## ⚠️ 免责声明 出于教育目的的学术项目。`.env.example` 中的所有值均为占位符。切勿提交真实的 API key。测试中使用的 IP 均为虚构或属于文档保留范围。 ## 作者 ZOUBDANE RANYA — 网络安全专业学生 | ENSAM Casablanca 专业方向：Blue Team · SOC · 检测与事件响应 [](https://linkedin.com/in/TON_PROFIL) [](https://github.com/rani27-bipo)

标签：FTP漏洞扫描, n8n, SOAR, SOC自动化, 后端开发, 威胁情报, 安全编排, 开发者工具, 自动化响应, 逆向工具