12vethamithran/NOCTRA-AI-Autonomous-SOC-Platform

# NOCTRA AI — 自主 SOC 平台 **NOCTRA AI** 是一个开源的、基于浏览器的安全运营中心（SOC），由 Google Gemini AI 驱动。它接收原始日志文件（CSV、JSON、syslog、EVTX、Windows Event、Apache、logfmt），运行涵盖完整 MITRE ATT&CK 杀伤链的 **43 条检测规则**，外加 **XGBoost ML 检测器**和行为异常引擎（UEBA），使用可解释的 AI 概率对每个警报进行评分，**在重复警报到达分析员手中之前将其折叠合并**，将威胁映射到 MITRE 技术，并生成取证 PDF 报告 —— 所有这些都不会在磁盘上存储任何字节。一个 **5 阶段的 ML 自我升级 pipeline** 不断从真实语料数据中重新训练阈值和字段别名。专为需要企业级威胁检测但不希望花费企业级部署时间的 SOC 分析员、蓝队和网络安全学习者而构建。 **无存储 · 跨越 MITRE ATT&CK 的 43 条规则 · XGBoost ML 检测器 · 自我升级引擎 · 可解释 AI · 附带证据的警报 · 自动去重 · L1/L2 双模式 · Docker 化** [](https://noctra-ai-autonomous-soc-platform.vercel.app) [](https://noctra-ai-autonomous-soc-platform.vercel.app) [](https://noctra-ai-autonomous-soc-platform.onrender.com/health) [](https://www.docker.com) [](LICENSE) ## 实时演示 **[noctra-ai-autonomous-soc-platform.vercel.app](https://noctra-ai-autonomous-soc-platform.vercel.app)** 无需注册。放入一个日志文件或点击 **“运行演示场景”** 即可查看一个合成的多阶段攻击。 ## 目录 1. [什么是 SOC？](#1-what-is-a-soc-for-non-cyber-readers) 2. [NOCTRA 的功能](#2-what-noctra-does-in-one-paragraph) 3. [为什么选择 NOCTRA 而不是普通 SOC 工具](#3-why-noctra-vs-a-normal-soc-tool) 4. [检测 pipeline](#4-the-detection-pipeline) 5. [检测规则内部解析（实战示例）](#5-inside-a-detection-rule-worked-example) 6. [警报解剖](#6-anatomy-of-an-alert) 7. [43 条规则目录一览](#7-the-43-rule-catalogue-at-a-glance) 8. [AI 的集成位置](#8-where-ai-is-integrated-7-places) - [8b. XGBoost ML 模型深度解析](#8b-xgboost-ml-detection-model--deep-dive) - [8c. 自我升级 pipeline 端到端解析](#8c-ml-self-upgrade-pipeline--how-it-works-end-to-end) 9. [AI 攻击评分的计算方式](#9-how-the-ai-attack-score-is-calculated) 10. [降噪：NOCTRA 如何阻止警报洪流](#10-noise-reduction-how-noctra-stops-alert-floods) 11. [操作演示：日志文件 → PDF 报告](#11-walkthrough-log-file--pdf-report) 12. [架构](#12-architecture) 13. [部署](#13-deployment) 14. [本地开发](#14-local-development) 15. [术语表](#15-glossary-for-newcomers) 16. [常见问题](#16-faq) ## 1. 什么是 SOC？（面向非网安从业者） **SOC**（安全运营中心）是企业内部负责监控网络上所有活动的团队和软件 —— 包括登录尝试、文件传输、DNS 查询、应用错误等 —— 并试图找出看起来像**攻击者**而非正常用户的活动。 | 级别 | 角色 | 典型问题 | |------|------|------------------| | **L1 — 分诊分析员** | 第一响应人。决定警报是真实的（TP）还是无效的（FP）。 | *"这事值得叫醒别人吗？"* | | **L2 — 威胁分析员** | 深度调查员。重建攻击者的行动路线。 | *"他们触碰了什么，又是怎么进来的？"* | ## 2. NOCTRA 的功能，用一段话概括 NOCTRA AI 是一个基于浏览器的 SOC，它接收原始日志文件（CSV / JSON / syslog / Web 访问日志 / EVTX / Windows Event / Apache / logfmt），运行 **涵盖暴力破解 → 横向移动 → 数据泄露 → 云身份滥用 → EDR 文件投放的 43 条检测规则 + XGBoost ML 检测器 + 行为异常引擎（UEBA） + AI 分类器**，**折叠重复项，使得一个逻辑事件 = 一个警报**，并为分析员提供一个**带有结构化证据和 AI 推理依据的已排序警报队列**。在后台，一个 **5 阶段的自我升级 pipeline**（语料分析 → 规则合成 → 解析器提取 → 模型重训）根据标记的语料数据不断改进阈值、字段别名和 ML 模型 —— 可在夜间自动触发或通过 `POST /admin/retrain` 按需触发。分析员点击浏览，AI 给出裁定建议并解释其推理过程，平台自动将相关警报关联成 **映射到 MITRE 的攻击链**，最后只需一键即可生成 **PDF 事件报告**。没有任何数据被存储在磁盘上 —— 所有数据都保留在 RAM 中，并在会话结束时被擦除。 ## 3. 为什么选择 NOCTRA 而不是普通 SOC 工具 | | 传统 SOC 技术栈 | **NOCTRA AI** | |---|---|---| | **部署** | 需数天至数周 —— 需配置集群、许可证、接入 pipeline | **浏览器标签页即开即用。免安装。** | | **单次调查成本** | 按接入的 GB 数收费 ($$) | **每次会话免费** | | **AI 评分** | 通常是黑盒式的“风险评分” | **0–100 的 TP 概率，并附带产生该分数的实际信号** | | **为什么是这个分数？** | 极少展示 | **点击任意分数 → 显示加权信号列表** | | **MITRE ATT&CK 映射** | 附加组件 / 付费模块 | **内置。** 每条规则都映射到具体的技术 + 战术 | | **攻击链关联** | 需自定义 SPL / KQL 查询 | **自动化。** 将相关警报拼接成杀伤链叙事 | | **L1 与 L2 的区分** | 所有人使用相同的 UI | **两种专为不同层级构建的视角** | | **行为分析 (UEBA)** | 通常作为单独产品出售 | **内置。** 具备基于每用户和每 IP 基线的 σ 偏差检测 | | **存储 / 合规性** | 磁盘上需 PB 级存储 | **零字节存储。** 会话数据存活于 RAM 中，结束时即清除 | **权衡：** NOCTRA 是专为*单次会话处理单个日志文件*而设计的 —— 它不是完整的企业级 SIEM。最适合用于：事件响应、学习 SOC 分析员角色、演示、蓝队演练、入侵后分诊。 ## 4. 检测 pipeline ### 4a. 单次会话的 10 阶段 pipeline ``` flowchart LR A[01
Ingest] --> B[02
Normalize] B --> C[03
Detect] C --> D[04
ML Scan] D --> E[05
Score] E --> F[06
Enrich] F --> G[07
Chain] G --> X[08
Dedup] X --> H[09
Triage] H --> I[10
Report] classDef stage fill:#1c1c20,stroke:#e11d48,color:#fff class A,B,C,D,E,F,G,X,H,I stage ``` | # | 阶段 | 处理内容 | |---|-------|-------------| | 01 | **接入** | 自动检测格式（CSV/TSV、JSON/JSONL、Apache、syslog、Windows Event、logfmt）—— 同时参考来自 `parser_hints.json`（通过语料学习得到）的格式检测信号。任何未知的日志都会回退到通用行解析器，因此接入过程永远不会失败。 | | 02 | **标准化** | 将列标准化为统一的 schema：`timestamp, source_ip, dest_ip, dest_host, user, event_type, status, port, bytes`。**95+ 个字段别名**（40 个内置 + 55 个从 `parser_hints.json` 学习得到）涵盖了 camelCase 的云环境变体。嵌套的 JSON 会被展平，因此规则可以读取 Suricata payload 中的 `alert_signature_id` 等字段。 | | 03 | **检测** | 运行 **43 条确定性规则**（R001–R043）+ UEBA IsolationForest + 跨事件关联。规则按攻击者上下文（IP、用户、设备）对事件进行分组 —— 一次逻辑攻击 = 一个警报，而不是每个数据包产生一个。阈值支持从 `rule_config.json` 热重载（无需重启）。 | | 04 | **ML 扫描** | **XGBoost ML 检测器** (`ml_detector.py`) 使用 519 维特征向量（500 个 TF-IDF + 12 个手工设计 + 7 个格式 one-hots）对每一行进行评分。未被确定性规则捕获且置信度 ≥ 70% 的行将发出额外的 `ML-*` 警报。 | | 05 | **评分** | AI 为每个警报分配 0–1 的 TP 概率，并附带结构化的推理依据 + SHAP 特征归因。如果 Gemini 不可用，则运行启发式兜底策略。 | | 06 | **富化** | IP 信誉（AbuseIPDB / VirusTotal）、地理位置、ASN、哈希 → MITRE 技术。采用懒加载 —— 仅在分析员打开警报时调用。 | | 07 | **串并** | 将相关警报分组为攻击链。例如：登录失败激增 → 登录成功 → 权限提升 → 数据泄露 = 一个完整的杀伤链叙事。 | | 08 | **去重** | **安全网。** 使用 `(rule_id, source_ip, user, dest_ip)` 键合并跨规则和重复上传的相同警报。累加 `event_count`，并记录最早的的时间戳、最高严重程度以及在 `extra` 中展示的 `rolled_up_count`。 | | 09 | **分诊** | 带有侧边栏、playbook、AI 建议、键盘导航的 L1 队列。 | | 10 | **报告** | 生成 L1 交接班报告或 L2 取证档案 PDF。 | ### 4b. 后台 ML 自我升级周期 独立的 5 阶段 pipeline 在每天夜间（UTC 03:00）运行，或通过 `POST /admin/retrain` 按需运行： ``` flowchart LR P1[Phase 1
corpus_analyser] --> P2[Phase 2
rule_synthesiser] P2 --> P3[Phase 3
parser_pattern_extractor] P3 --> P4[Phase 4
train_model] P4 -->|hot-reload| E[(Engine)] classDef ph fill:#1c1c20,stroke:#3b82f6,color:#fff class P1,P2,P3,P4 ph ``` | 阶段 | 脚本 | 输出 | |-------|--------|--------| | 1 | `corpus_analyser.py` | `rule_insights.json` — 每条规则经 F1 优化的阈值 + 具有区分度的二元语法 | | 2 | `rule_synthesiser.py` | 修补 `rule_config.json` — 仅应用能使 F1 提升 ≥ 0.02 的更改 | | 3 | `parser_pattern_extractor.py` | `parser_hints.json` — 从语料中学习到的字段别名 + 格式检测信号 | | 4 | `train_model.py` | `models/ml_detector.pkl` — 重新训练的 XGBoost 打包文件（包含 `tfidf` + `clf` 键） | 轮询进度：`GET /admin/retrain`。所有管理端点都需要 `Authorization: Bearer `。 ## 5. 检测规则内部解析（实战示例） 每一条 NOCTRA 规则都遵循相同的三步结构：**过滤 → 聚合 → 发出**。以下是 R001 — “凭据暴力破解”： ``` filter events where status == FAILED and source_ip is set group by source_ip + 60-second sliding window threshold ≥ 5 failed logins in the same window emit ONE alert per (source_ip, window) severity = HIGH mitre_technique = T1110 evidence = list of the log indices that triggered it ``` 为什么这种结构很重要： - **逐行触发警报的循环**（反模式：为每次失败的登录发出一个警报）是 SOC 工具产生警报洪流的原因。NOCTRA 绝不会写 `for row in failed_logins:` 这样的迭代 —— 它总是先进行分组。 - **滑动时间窗口**排除了巧合。6 个月内 5 次登录失败不是暴力破解；60 秒内 5 次才是。 - **证据索引**让 UI 能够直接跳转到触发警报的原始日志行 —— 告别“相信我”式的黑盒。 想要编写自己的规则？可以使用应用内的 **Rule Builder**，或者将 YAML 规则放入 DSL 中 —— 采用相同的过滤/分组/阈值模型，无需编写 Python。 ## 6. 警报解剖 `POST /ingest` 返回的每个警报都是一个具有以下结构的 JSON 对象： ``` { "alert_id": "a-7f3c12", "rule_id": "R001", "rule_name": "Credential Brute Force", "severity": "HIGH", "tp_probability": 0.92, "description": "8 failed logins from 203.0.113.66 in a 60-second window — credential compromise: SUCCEEDED", "timestamp": "2026-05-25T02:31:14Z", "source_ip": "203.0.113.66", "user": "jdoe", "event_count": 8, "mitre_technique": "T1110", "mitre_tactic": "Credential Access", "related_log_indices": [12, 13, 15, 17, 19, 21, 22, 24], "extra": { "window_seconds": 60, "succeeded_after": true, "rolled_up_count": 1 }, "ai_rationale": "Burst of failed logins followed by success from same IP is a classic brute-force pattern.", "shap_features": [ {"feature": "failed_login_count", "contribution": 0.41}, {"feature": "success_after_failures", "contribution": 0.28}, {"feature": "source_ip_reputation", "contribution": 0.13} ] } ``` | 字段 | 告知分析员的内容 | |-------|---------------------------| | `tp_probability` | “这有多大可能是真实的？” —— 0–1，由启发式算法和 Gemini 综合得出。 | | `event_count` | 有多少原始日志事件被折叠进了这一个警报中。 | | `related_log_indices` | 触发此规则的源日志的具体行 —— 在 UI 中点击即可跳转。 | | `mitre_technique` / `mitre_tactic` | 使用业界标准的 ATT&CK 词汇描述的攻击者行为。 | | `extra.rolled_up_count` | 如果 > 1，说明此警报是 N 个几乎完全相同的警报合并而来（去重阶段）。 | | `shap_features` | AI 用于对此警报进行评分的主要信号。消除“黑盒疑虑。 | | `ai_rationale` | 针对此特定警报量身定制的一句话英文解释。 | ## 7. 43 条规则目录一览 | 家族 | 规则 ID | 示例 | MITRE 战术 | |--------|----------|----------|--------------| | **凭据与身份** | R001, R006, R007, R010, R013, R015, R016, R020, R033 | 暴力破解、非工作时间登录、新增管理员账户、多服务攻击、LSASS 转储、明文凭据、账户锁定风暴、RDP 暴力破解、Kerberoasting | Credential Access | | **权限提升** | R003 | 时间窗口内 普通用户 → 管理员 | Privilege Escalation | | **横向移动与侦察** | R002, R004, R008, R022 | 端口扫描、多主机认证、Web fuzzing 404 爆发、不可能的移动 | Discovery, Lateral Movement | | **数据泄露与 C2** | R005, R014, R021, R026, R027 | 大量出站传输、DNS 隧道、C2 信标、端口碰撞、内部扫描 | Exfiltration, Command & Control | | **Web 与应用攻击** | R024, R025, R043 | SQL 注入、Web shell / 侦察 UA、IDOR 枚举（顺序 ID 访问） | Initial Access, Discovery | | **端点与 EDR** | R011, R012, R017, R018, R019, R023, R031, R032 | 可疑的 PowerShell、进程注入、可疑的持久化、事件日志被清除、安全工具篡改、勒索软件文件写入、伪装、脚本释放 EXE | Execution, Defense Evasion, Impact | | **邮件与网络钓鱼** | R028, R029 | 可疑的邮件认证失败、带有危险附件的网络钓鱼 | Initial Access | | **云身份（AWS / Entra / M365）** | R030, R034, R035, R036, R037, R038, R039, R040, R042 | 授予云管理员权限、控制台 root 登录、CloudTrail 篡改、OAuth 同意授权、无 MFA 的 AWS API 调用、S3 异常体量、SharePoint 大量下载、云环境侦察 | Persistence, Defense Evasion, Collection | | **地理与行为异常** | R041 | 来自意外国家的登录（可通过 `rule_config.json` 配置基线） | Initial Access | | **行为分析 (UEBA)** | `UEBA-*` | IsolationForest 针对每用户/ IP 偏离基线的 σ 偏差 | 多种 | | **ML 检测器** | `ML-*` | XGBoost 模型捕获 regex 规则遗漏的攻击 —— 519 维特征向量，≥ 70% 置信度阈值 | 多种 | ## 8. AI 的集成位置（7 个地方） | # | 位置 | AI 的作用 | 不可用时的兜底方案 | |---|-------|------------------|------------------------| | 1 | **检测** | IsolationForest UEBA 模型对每个用户/IP 偏离基线的程度进行评分 | 确定性阈值规则 | | 2 | **ML 扫描** | XGBoost 分类器（基于 68k 标记记录训练）捕获规则 regex 遗漏的攻击模式 —— 519 个特征，≥ 70% 阈值 | 规则引擎覆盖大部分检测 | | 3 | **评分** | Gemini 分类器返回每个警报的 0–1 TP 概率 + 推理依据 | 10 信号启发式评分器 | | 4 | **分诊** | AI 生成针对特定警报的 TP/FP 原因 + 量身定制的响应 playbook | 静态原因库 | | 5 | **调查** | 自主 agent 产出裁定建议、关键发现、推理步骤 | 人工调查选项卡 | | 6 | **串并** | LLM 撰写通俗易懂的杀伤链叙事报告 | 结构化串并摘要 | | 7 | **自我升级** | 5 阶段 pipeline（语料分析 → 规则合成 → 解析器提取 → 重新训练）每晚自动调整阈值并重新训练 XGBoost | 引擎基于最后已知的好配置运行 | ## 8b. XGBoost ML 检测模型 — 深度解析 ML 检测器（`backend/engine/ml_detector.py`）是第二个独立的检测阶段，在所有 43 条确定性规则运行**之后**执行。它用于捕获 regex 无法表达的攻击模式。 ### 训练数据 | 属性 | 数值 | |-----------|-------| | 标记记录总数 | **68,655** | | 覆盖日志格式 | syslog, JSON, WAF, CSV, Zeek, EVTX, 通用格式 | | 标签分布 | 攻击 / 良性样本均衡分布 | | 训练脚本 | `noctra_training_data/train_model.py` | | 模型输出 | `backend/models/ml_detector.pkl`（包含 `tfidf` + `clf` 键） | ### 特征工程（519 个特征） | 分组 | 数量 | 描述 | |-------|------:|-------------| | TF-IDF 文本特征 | 500 | 来自原始日志行（前 1000 个字符）的前 500 个 n-grams | | 手工设计的特征 | 12 | 行长度、数字占比、特殊字符占比、IP 计数、`has_error`、`has_privesc`、`has_exfil`、`has_injection`、`has_user`、`has_timestamp`、大写字母比例、空格比例 | | 格式 one-hots | 7 | `syslog`, `json`, `waf`, `csv`, `zeek`, `evtx`, `generic` | ### 评分与严重程度映射 | 置信度 | 严重程度 | 含义 | |------------|----------|---------| | ≥ 92% | `CRITICAL` | 高度确定的攻击模式 | | ≥ 80% | `HIGH` | 强烈的攻击信号 | | ≥ 70% | `MEDIUM` | 可能是攻击 —— 值得审查 | | < 70% | *(不触发)* | 低于阈值 —— 被抑制 | ML 警报携带格式为 `ML-Rxxx` 的规则 ID（例如 `ML-R001`），并在 `alert.extra` 中包含 `ml_confidence` 和 `raw_snippet`。它们**仅**针对未被确定性规则覆盖的行发出 —— 因此 ML 层增加了信号而不会产生重复。 ### MITRE 推断 ML 检测器使用按优先级排序的 regex 信号从原始行中推断战术/技术（凭据失败 → 注入 → 权限提升 → 阻止/拒绝操作 → 云事件 → 数据泄露 → PowerShell → 侦察）。默认兜底：`Command and Control / T1071`。 ## 8c. ML 自我升级 pipeline — 端到端工作原理 ``` POST /admin/retrain │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ retrain_orchestrator.py │ │ │ │ Phase 1 → corpus_analyser.py │ │ • Reads 68k records from normalized/training_corpus.ndjson │ │ • Grid-searches threshold params (min_failures, min_ports…) │ │ to maximise per-rule F1 │ │ • Mines discriminative bigrams per rule (lift ≥ 30.0) │ │ • Outputs: rule_insights.json │ │ │ │ Phase 2 → rule_synthesiser.py │ │ • Reads rule_insights.json │ │ • Only applies threshold changes where ΔF1 ≥ 0.02 │ │ • Guards against generic words as IoC patterns │ │ • Patches rule_config.json + writes synthesis_report.json │ │ │ │ Phase 3 → parser_pattern_extractor.py │ │ • Mines field aliases per format (logfmt, json, csv…) │ │ • Generates format-detection signals (≥ 85% format purity) │ │ • Outputs: backend/engine/parser_hints.json │ │ │ │ Phase 4 → train_model.py │ │ • Rebuilds TF-IDF + XGBoost pipeline on full corpus │ │ • Saves backend/models/ml_detector.pkl │ │ │ │ Hot-reload → engine picks up new config + model on next call │ └─────────────────────────────────────────────────────────────────┘ ``` **安全保障：** - 最低 F1 提升门槛（`MIN_F1_IMPROVEMENT = 0.02`） —— 防止由于嘈杂的语料导致性能倒退 - 通用词黑名单可防止将常见 token（"failed"、"password"、"scan"、"type"）作为 IoC 模式注入 - 最小提升阈值（`MIN_LIFT_PATTERN = 30.0`） —— 仅添加在攻击中比在良性样本中可能性高出 30 倍的模式 - 拒绝并发重新训练 —— 可通过 `GET /admin/retrain` 轮询状态 - 每个脚本都有 600 秒的超时限制，以防止 pipeline 挂起 **监控：** ``` # 触发重新训练 curl -X POST https://your-backend/admin/retrain \ -H "Authorization: Bearer $ADMIN_SECRET" # 轮询进度 curl https://your-backend/admin/retrain \ -H "Authorization: Bearer $ADMIN_SECRET" # → {"running": true, "phase": "corpus_analyser", "progress_pct": 25, ...} ``` ## 9. AI 攻击评分的计算方式 每个警报都会获得一个 **0–100 的 TP 概率**。 | 信号 | 权重 | |--------|-------:| | 严重程度 = `CRITICAL` | +25 | | 严重程度 = `HIGH` | +15 | | 匹配确定性规则 | +10 | | UEBA 基线偏差 (>2σ) | +18 | | 命中跨事件关联 | +12 | | 链接了 ≥ 2 个 MITRE 技术 | +15 | | 映射了单个 MITRE 技术 | +5 | | IsolationForest 异常得分 > 0.6 | +10 | | 同一警报上关联了 ≥ 5 个事件 | +8 | 这些分数会被累加，截取至 0–100 的范围内，然后与 Gemini 分类器进行混合加权（在可用时，权重为 70% AI / 30% 启发式）。 | 得分 | 级别 | |------:|------| | ≥ 75% | **高置信度 TP** | | 45–74% | **可能的 TP** | | < 45% | **低置信度** | ## 10. 降噪：NOCTRA 如何阻止警报洪流 SOC 分析员忽视其工具的第一大原因是**警报疲劳** —— 当一次逻辑上的攻击产生了 100 个警报，而真实信号被淹没在重复项中时。NOCTRA 在四个层面上解决了这个问题： ### 第 1 层 — 规则先聚合再发出 每个规则根据攻击上下文（`source_ip`、`user`、`device`、`sender`）对其匹配的事件进行分组，并发出**每组一个警报**，而不是每行一个。投放了 200 个文件的勒索软件运行过程 = **1** 个警报，其中包含 `event_count: 200` 以及 `extra` 中的文件名样本。 ### 第 2 层 — 滑动时间窗口 基于数量的规则（R001 暴力破解、R002 端口扫描、R008 模糊测试）要求阈值**在狭窄的时间窗口内**（60 秒、30 秒、5 分钟）被触发。一周内分散出现的 20 个 HTTP 404 是正常的浏览噪音；五分钟内的 20 个则是模糊测试。这一项检查就消灭了绝大多数“日志文件跨越 7 天”的误报。 ### 第 3 层 — 全 pipeline 的去重扫描 在所有规则运行完毕后，接入 pipeline 会进行最后一次扫描。任何共享 `(rule_id, source_ip, user, dest_ip)` 的警报都会被合并到最早生成的警报中 —— 保留更高的严重程度、更高的置信度，并记录 `rolled_up_count`，以便 UI 可以显示“抑制了 5 个重复项”。这能捕获到单规则聚合遗漏的任何内容，并防止同一活动的重复上传导致警报累积。 ### 第 4 层 — 解析器的稳健性确保规则能够真正触发 “警报过多”的另一半原因是“因为字段被错误解析而导致的错误警报”。NOCTRA 的解析器： - 当状态列存在但为空时，会重新运行状态启发式算法（这是一种常见的 CSV 怪癖，即 `keep_default_na=False` 会使空单元格看起来像是被填充了）。 - 为每个规范名称携带 **95+ 个字段别名**（40 个内置 + 55 个从 `parser_hints.json` 学习得到）—— `sourceIPAddress`、`source_ip`、`srcip`、`ClientIp`、`remote_addr`、`caller_ip_address`、`initiatedBy.user.ipAddress`、`hostname`、`destination` 等等，全都会被折叠归入对应的规范字段。 - 将嵌套的 JSON 展平，因此 Suricata 的 `alert.signature.id` 和 AWS 的 `userIdentity.arn` 最终都会变成规则可以读取的扁平列。 - 将每个空字符串/`"none"`/`"null"` 字符串标准化为 Python 的 `None`，以便 `.notna()` 检查在各种云 schema 中表现一致。 **最终效果：** 真实的攻击会触发预期的少数几个截然不同的警报。干净的日志不会触发任何警报。重复上传不会导致警报成倍增加。 ## 11. 操作演示：日志文件 → PDF 报告 ``` sequenceDiagram autonumber actor A as Analyst participant UI as Browser (NOCTRA UI) participant API as FastAPI Backend participant AI as Gemini AI A->>UI: Drop log file on Upload page UI->>API: POST /ingest API-->>UI: Session ready — ranked alerts A->>UI: Open Triage queue A->>UI: Click alert → drawer opens UI->>API: GET /verdict-assist A->>UI: Confirm TP / Dismiss FP A->>UI: Click "Run AI Agent" UI->>API: POST /agent-investigate API->>AI: Multi-step reasoning AI-->>API: Verdict + findings A->>UI: Export Report UI-->>A: PDF incident dossier ``` ## 12. 架构 ``` flowchart TB subgraph Browser["Browser (Vite + React 18)"] L[Landing] & U[Upload] & T[Triage] & I[Investigation] & H[Hunt] & Rb[Rule Builder] & D[Dashboard] end subgraph Backend["FastAPI Backend (Python 3.11)"] R[Routers] & E[Detection Engine] & S[Session Store] & AIS[AI Service] & TIS[Threat Intel] end subgraph External["External APIs"] G[Google Gemini] & AB[AbuseIPDB] & VT[VirusTotal] end Browser <-->|REST / JSON| R R --> E & S & AIS & TIS AIS --> G TIS --> AB & VT ``` ## 13. 部署 | 层级 | 平台 | URL | |-------|----------|-----| | **前端** | Vercel | [noctra-ai-autonomous-soc-platform.vercel.app](https://noctra-ai-autonomous-soc-platform.vercel.app) | | **后端** | Render | `https://noctra-ai-autonomous-soc-platform.onrender.com` | ### Vercel — 前端 | 设置 | 值 | |---------|-------| | 根目录 | `frontend` | | 构建命令 | `npm run build` | | 输出目录 | `dist` | | 安装命令 | `npm install` | **环境变量：** | 键 | 值|-----|-------| | `VITE_API_URL` | 你的 Render 后端 URL | ### Render — 后端 | 设置 | 值 | |---------|-------| | 根目录 | `backend` | | 运行时 | Python 3 | | 构建命令 | `pip install -r requirements.txt` | | 启动命令 | `uvicorn main:app --host 0.0.0.0 --port $PORT` | **环境变量：** | 键 | 描述 | |-----|-------------| | `GEMINI_API_KEY` | Google AI Studio 密钥 | | `ABUSEIPDB_API_KEY` | AbuseIPDB 密钥 | | `VIRUSTOTAL_API_KEY` | VirusTotal 密钥 | | `CORS_ORIGIN` | 你的 Vercel 前端 URL | | `SESSION_TTL_MINUTES` | `30` | | `MAX_UPLOAD_MB` | `25` | | `ADMIN_SECRET` | 用于 `POST /admin/retrain` 的 Bearer token（可选 —— 留空则禁用身份验证） | | `RETRAIN_SCHEDULE_HOUR_UTC` | 用于夜间重训的 UTC 小时时间（默认为 `3`） | ## 14. 本地开发 ### 方案 A — Docker（推荐） ``` # 复制并填入你的 API keys cp backend/.env.example backend/.env # 启动两个服务 docker compose up --build ``` 前端：[http://localhost:3000](http://localhost:3000) · 后端：[http://localhost:8000](http://localhost:8000) ### 方案 B — 手动设置 有关完整的手动设置说明，请参阅 [SETUP.txt](SETUP.txt)。 ``` # Backend cd backend python -m venv venv && source venv/bin/activate # Windows: venv\Scripts\activate pip install -r requirements.txt cp .env.example .env uvicorn main:app --reload --port 8000 # Frontend (新 terminal) cd frontend npm install npm run dev ``` 打开 [http://localhost:5173](http://localhost:5173)。 ### 方案 C — 自托管生产环境 ``` cp .env.example .env.prod # 使用真实的 API keys 和 URLs 填入 .env.prod docker compose --env-file .env.prod -f docker-compose.prod.yml up -d ``` ## 15. 新手术语表 | 术语 | 含义 | |------|---------| | **警报** | 平台标记“这看起来很可疑”。是一个聚合后的事件，而不是单个日志行。 | | **TP / FP** | 真阳性（真实的攻击）/ 假阳性（噪音）。 | | **分诊** | 快速将警报分类为 TP 还是 FP。 | | **MITRE ATT&CK** | 业界权威的攻击者技术目录。每一条 NOCTRA 规则都会映射到其中一项。 | | **技术 vs 战术** | *战术*是攻击者的目标（如“Credential Access”）；*技术*是他们实现目标的手法（如“T1110 – Brute Force”）。 | | **UEBA** | 用户与实体行为分析 —— 使用 IsolationForest 标记偏离基线的行为。 | | **攻击链** | 一系列相关的警报，共同描述了一个完整的攻击故事（例如 暴力破解 → 提权 → 泄露）。 | | **杀伤链** | 描述攻击阶段的概念模型：侦察 → 武器化 → 投递 → 利用 → 安装 → C2 → 目标行动。 | | **IOC** | 入侵指标 —— 在攻击中出现的 IP、域名、哈希或用户。 | | **SHAP** | 一种解释哪些特征最影响了 ML 模型评分的技术。 | | **XGBoost** | ML 检测器使用的梯度提升树集成模型。68k 条训练记录，519 个特征（500 个 TF-IDF + 12 个手工设计 + 7 个格式 one-hots），≥70% 的置信度阈值。 | | **TF-IDF** | 词频-逆文档频率 —— 将原始日志文本转换为数值向量。前 500 个 n-grams 构成了 96% 的 ML 特征向量。 | | **自我升级 pipeline** | 5 阶段的后台任务（corpus_analyser → rule_synthesiser → parser_pattern_extractor → train_model），可根据标记的日志数据自动调整检测规则。在夜间运行或通过 `POST /admin/retrain` 按需运行。 | | **L1 / L2** | Tier-1（分诊与响应）/ Tier-2（追踪与关联）。 | | **滑动窗口** | 随着事件移动的时间范围 —— “在任何 60 秒的跨度内出现 5 次登录失败”，而不是“在固定的过去一分钟内”。 | | **聚合** | 将许多匹配的事件折叠成一个带有计数的警报，而不是每个事件生成一个警报。 | | **去重 / 折叠** | 全 pipeline 范围内的扫描，合并共享了规则 + 攻击者 + 目标的警报。阻止警报洪流。 | | **证据** | 触发规则的确切日志行索引 —— 让分析员可以亲自核实，而不仅仅是盲目信任。 | | **字段别名** | 许多日志源对同一事物使用不同的命名（`source_ip` vs `sourceIPAddress` vs `client_ip`）。别名将它们统一折叠为一个规范名称。 | | **无存储** | 任何数据都不会持久化到磁盘。会话仅存在于服务器 RAM 中，空闲 30 分钟后将被擦除。 | ## 16. 常见问题 **问：NOCTRA 会取代 Splunk / Sentinel 吗？** 不会。NOCTRA 适用于单次会话处理单个日志文件 —— 如事件响应、学习、演示、入侵后分诊。持续的企业级监控请使用完整的 SIEM。 **问：AI 会将我的原始日志发送给 Google 吗？** 不会。只有警报摘要包（规则名称、MITRE 标签、时间戳）会被发送给 Gemini。原始日志行保留在你的后端 RAM 中。 **问：如果 Gemini 宕机了或者我没有 API 密钥怎么办？** 一切仍会正常运作。平台会自动回退到 10 信号的确定性评分器。 **问：“无存储”是如何强制执行的？** 会话存在于进程内存的 Python 字典中。清理任务会在 30 分钟不活动后将其驱逐。没有数据库，没有磁盘写入。 **问：我可以添加自己的规则吗？** 可以 —— Rule Builder 自带四个模板。你可以组合多条件过滤器、分配严重程度、映射 MITRE 技术，并针对当前活动会话进行测试触发。 **问：我上传了两次相同的日志，得到了两次相同的警报。这是一个 bug 吗？** 不是 —— 每次上传都会创建一个独立的会话。在单个会话内，NOCTRA 会积极地进行去重（上文的第 3 层）。而在不同会话之间，历史记录被有意隔离，以确保演示和调查之间不会互相干扰。 **问：某条规则没有在我预期会触发的日志上触发。我该检查什么？** 依次检查这三点：(1) 解析器是否正确映射了你的列名？打开会话详情页 —— 如果 `source_ip` 显示为空行，说明你的日志使用了尚未被设置别名的名称。(2) 规则的阈值/时间窗口是否真的匹配？基于体量的规则需要突发量出现在其时间窗口内。(3) 是否被去重扫描合并到了另一个警报中？查看相邻警报上的 `extra.rolled_up_count > 1`。 **问：为什么是“43 条规则”？以后还会增加吗？** 43 是目前覆盖 MITRE ATT&CK 矩阵的规则总数，包含了从凭据获取到云持久化、EDR 检测以及 IDOR 枚举（R001–R043）的各项内容。ML 自我升级 pipeline (`POST /admin/retrain`) 可以从语料数据中合成新的规则候选。手动添加一条规则只需在 [`engine/rules.py`](backend/engine/rules.py) 中编写单个函数。 **问：NOCTRA 是如何区分“聚合”和“抑制”的？** 聚合发生在一条规则*内部*（将匹配同一规则的多行组合在一起）。去重发生在 pipeline 末端、跨越所有规则进行（合并指向同一攻击者+目标的警报）。两者都会保留 `event_count`，因此什么都不会“丢失” —— 去掉的仅仅是单行日志带来的噪音。 **问：目前实际支持哪些日志格式？** CSV / TSV（支持任意分隔符，表头大小写混用亦可）、JSON / JSONL / NDJSON（自动展平嵌套对象）、Apache combined / common、syslog（RFC 3164 + 5424）、Windows Event Log 文本导出、logfmt 键=值对、通用的自由文本（按行记录事件）。特定云端支持：AWS CloudTrail JSON、Entra Sign-In + Audit 日志、M365 Unified Audit、Defender for Endpoint 导出、Suricata EVE JSON。

_{NOCTRA AI · 自主 SOC · v4.0 · 43 条规则 · XGBoost ML 检测器 · 自我升级引擎 · 自动去重 · 天生无存储 · MIT License}

标签：AMSI绕过, Cloudflare, MITRE ATT&CK, SOC平台, UEBA, XGBoost, 威胁检测, 安全运营, 扫描框架, 请求拦截, 逆向工具