cerberus8484/Nexora-Control-Plane

## 目录 [它是什么？](#was-ist-es) · [面向谁？](#für-wen) · [目前已实现的功能](#was-es-heute-kann) · [截图](#screenshots) · [架构](#architektur) · [快速开始](#quickstart-lokal--dev) · [当前状态](#aktueller-stand) · [安全模型](#security-modell) · [集成](#integrationen) · [案例研究](#case-studies--drei-probleme-aus-dem-echten-betrieb) · [路线图](#roadmap) · [许可证](#lizenz) ## 它是什么？ **DE:** 一款适用于 Tier 1–3 的自托管 SOC 平台 — 包含 Incident 工单、Threat Hunting （17 个预置且映射至 MITRE 的 Hunt）、配备 Human-Approval 的 KI-Triage-Agent 以及一个实时遥测运维看板。它是在真实的实验环境中**基于真实运营构建**的， 而非基于 Fixtures：具备 Event Forwarding 的 Windows-AD、Wazuh-SIEM、OPNsense，以及每个 Endpoint 上的 Sysmon。**无虚假数据** — 屏幕上的每一个图表、每一个 Alert、每一个 Verdict 均来自真实的 Pipeline (ADR-009)。 **EN:** A self-hosted SOC platform — incident tickets, MITRE-mapped threat hunting, an AI triage agent with human approval, and a live telemetry ops board. Built and operated against a real lab, not against fixtures. No mock data anywhere. **它刻意*不*包含的部分：** 它不是 SIEM、EDR 或 Log-Collector 的替代品 — Nexora 旨在消费并对它们的数据进行关联。它也不进行自动的威胁清除。 ## 面向谁？ - **SOC Analyst (Tier 1–3)**，希望将重复的 Triage 常规工作移交给一个可验证的 KI-Copilot，从而腾出更多时间进行 Tier-3 工作（Hunting、Detection Engineering）。 - **饱受 Alert 噪音困扰的 Wazuh 团队**，正在寻找一个用于 生成工单、评估 FP 以及关联 Evidence 的 Companion。 - **小型 SOC、内部 IT 安全部门、MSP/MSSP**，希望运营一个 无强制云端要求的自托管 Workbench。 ## 使命 Nexora SOC 是一个 KI 驱动的 SOC 编排平台，旨在辅助 Analyst 进行 Security Alert 的 Triage、评估和记录。该平台将 Tickets、Evidence、Threat Intel、Hunt Findings 以及基于 KI 的建议结合在一起，形成 一个可追溯的 Workflow。 目标是在不放弃控制权或责任的前提下，减少 Tier-1 和 Tier-2 的常规工作负荷。 KI 能够识别模式、准备决策、 提出下一步建议，并能在明确规定的 Policy 下支持低风险的 Workflow。 关键操作仍将保持 Human-in-the-loop、基于角色的强制审批， 并且完全可审计。 由此，Nexora SOC 为 Tier-3 工作创造了更多空间：Threat Hunting、Detection Engineering、复杂 Incidents、Use-Case 开发以及 Detection 质量的持续改进。 ## 为什么会有这个项目 由一名正向 SIEM-Engineering 转型的 SOC-Analyst 构建 — 旨在回答 一个简单的问题：*如果今天可以重新构建这套工具，它会是什么样子？* 三个核心原则贯穿始终： 1. **无虚假数据** (ADR-009)。没有真实数据源的区域会如实显示 空白状态。如果 Dashboard 显示有 9,000 个 forwarded Events，那它就确实是 9,000 个。 2. **Evidence 决定 — 人类批准。** KI 提出建议 (`pending → approve/reject`)，并可在明确定义的、 基于角色的 Policy 下支持低风险的 Workflow；关键操作仍需强制审批、 可审计且可回滚。一个确定性的 Evidence-Floor 可以防止 较弱的模型将真实的发现错误地压制为 False Positive。 3. **可证明而非口头声称。** 全面实施 TDD（145 个 Suite，约 2273 个 Backend 测试）， 每条 Pipeline 均经过端到端的实时验证 — 从投放 EICAR 到生成 Ticket。 ## 目前已实现的功能 | 领域 | 功能描述 | |---|---| | **Incident-Tickets** | 生命周期（State/Status 模型，ADR-007），连续的 `INC` 编号，全文搜索，Audit-History，通过 IoCs 进行交叉引用 | | **Analysis-Deck** | SOC-Workbench：Queue、Evidence（Chain of Custody、SHA-256）、Threat-Intel-Enrichment（VirusTotal/AbuseIPDB）、来自 Indexer 的 Event-Timeline | | **Threat Hunting** | 17 个预置的一键式 Hunt（LSASS-Access、Kerberoasting、AS-REP-Roasting、Shadow-Copy-Deletion、WMI-Persistence 等），全部映射至 MITRE-ATT&CK；配备 Allowlist + Approval-Gate 的 Safe-Command-Console | | **KI-Triage-Agent** | 本地 LLM（Ollama，无强制云端要求）分析 Alert-Evidence-Bundle；Human-Approval-Workflow；Evidence-Floor 会确定性地覆盖过于温和的模型 Verdict | | **实时遥测** | 运维看板展示来自 Wazuh-Indexer 的真实时间序列：SIEM-Events、Firewall-Blocks、通过 WEF 获取的 AD-Logons、Defender 发现、每个 VLAN 的 Events | | **FP-Management** | 四眼原则 Workflow：Analyst 提交受限范围内的 Exception，Engineer 负责执行 — XML 预览，Kill-Switch，无自动重启 | | **Detection Engineering** | 100+ 自定义 Wazuh 规则（Sysmon FileCreate/Registry/Pipe/DNS，AD/Kerberos 4720/4728/4740/1102/4719/5136）— 已针对真实的 DC-Events 进行实时验证 | | **集成** | Inbound：Wazuh/QRadar/Splunk（Webhook + HMAC，Offense-Dedup） · Outbound：ServiceNow/OTRS · 配备 ReDoS 防护的 YARA 扫描引擎 | | **平台** | Auth/RBAC（admin > engineer > analyst > viewer），Append-only 的 Audit-Log（DSGVO：仅记录字段名，不记录值），Postgres + Repository-Pattern | ## 截图 | 视图 | 预览 | |---|---| | **Analysis Deck** — SOC-Workbench、Queue + Tabs | | | **KI-Analyse** — Triage-Verdict + Evidence-Floor | | | **Threat Hunts** — 一键式目录，MITRE 映射 | | | **Evidence Center** — Chain of Custody、SHA-256 | | | **KI Settings** — Provider/Modell/Fallback/Test | | | **Wazuh Dashboard** — 实时遥测、VLAN 区域 | | ## 架构 ``` Lab (Quellen) Nexora SOC (dieses Repo) ┌──────────────────────────────┐ ┌──────────────────────────────────────┐ │ DC01 ──WEF──▶ WEC01 │ │ web (nginx, TLS) ── React 18 + TS │ │ Clients (Sysmon, Defender) │ │ │ /api │ │ OPNsense (filterlog) │──▶───│ api (Node/Express) │ │ Linux-Hosts (ClamAV, FIM) │Wazuh │ Auth · RBAC · Audit · Tickets · │ │ ▼ │Webhook Hunts · KI-Agent · Telemetrie │ │ Wazuh Manager + Indexer ◀────┼──────│ │ Repository-Pattern │ │ (11 Agents, VT-Lookup) │ Query│ postgres │ └──────────────────────────────┘ └──────────────────────────────────────┘ ``` - **Backend:** Node.js + Express + PostgreSQL — Repository-Pattern（测试/开发环境使用 InMemory，在 `DB_ENABLED=true` 时使用 Postgres），为每个集成提供 Adapter 层 - **Frontend:** React 18 + TypeScript + Vite，使用 Vitest 测试纯逻辑模块 - **Deployment:** Docker Multi-Stage，nginx-TLS，One-Shot-Release-Script ## 快速开始（本地 / 开发） 前提条件：Node.js 20+。在没有 Postgres 的情况下，Backend 将运行于 InMemory-Repositories。 ``` # 1) Backend cd backend && npm install npm run dev # http://localhost:3000 (InMemory, ohne DB) npm test # 2) Frontend（第二个 Terminal） cd frontend && npm install npm run dev # http://localhost:5173 (Proxy /api → :3000) npm test # 3) 通过 ENV bootstrap Admin 的 Dev-Modus ADMIN_EMAIL=admin@example.com ADMIN_PASSWORD=ChangeMe123 npm --prefix backend run dev ``` 启用持久化：设置 `DB_ENABLED=true` + 连接数据（`backend/.env.example`）。 **生产环境 / Proxmox：** 完整指南见 [`deploy/README.md`](deploy/README.md)。 ## 当前状态 **实验室实时状态** 位于 nexora.local (10.0.10.75) — P0–P19a 已实现，KI-Agent 已在本地 Ollama 上投入生产（Cloud-Provider 为可选启用）。 - **Backend:** 145 个测试套件 / 约 2273 个测试通过 (Jest)。 - **Frontend:** 70 个测试套件 / 约 766 个测试通过 (Vitest)，`tsc` 0 / `eslint` 0 个错误。 - **待办 / 计划中：** PDF-Report-Generator、MFA/TOTP & SSO、Wazuh Health Center、 Endpoint Companion Agent、E2E (Playwright) — 详见路线图。 权威的详细状态：[`docs/00-overview/feature-status.md`](docs/00-overview/feature-status.md) · 阶段计划：[`ROADMAP.md`](ROADMAP.md)。 ## 安全模型 - **Auth:** 仅限 Cookie (httpOnly)，**`sessionStorage` 中不使用 JWT**（XSS 加固）； Bearer/PAT 保留给 API 客户端使用。针对 Cookie-Sessions 启用 **CSRF Double-Submit**。 - **RBAC:** admin > engineer > analyst > viewer — 在服务器端强制执行。 - **Audit-Log:** append-only，符合 DSGVO 规范的记录（仅限字段名，不含具体值）， 在涉及个人信息处进行 IP 哈希处理。 - **默认关闭的加固项：** 密码 Policy/过期/历史、Session/非活动超时、 账户锁定、多重 Session 限制、强制 TLS、IP-Allowlist — 均可 在服务器端强制开启，未经管理员激活不会改变运行形态 (ADR-017/019)。 - **输入加固:** HMAC 签名的 Webhook、在每个系统边界进行 Joi 验证、 YARA 引擎中的 ReDoS 防护、使用 `textContent` 替代 `innerHTML`。 请**不要**通过公开的 Issues 报告漏洞，请按照 [`SECURITY.md`](SECURITY.md) 进行报告（Responsible Disclosure）。 ## 集成 | 方向 | 源 / 目标 | 机制 | |---|---|---| | **Inbound** | Wazuh · QRadar · Splunk | Webhook + HMAC，Offense-Dedup → Ticket | | **Inbound** | 电子邮件（Phishing 接收） | Webhook (HMAC) 为主 · 计划支持 IMAP-Poller | | **Outbound** | ServiceNow · OTRS | Adapter 层（Ticket 同步） | | **Enrichment** | VirusTotal · AbuseIPDB | 在 Analysis-Deck 中进行 Threat-Intel 查询 | | **引擎** | YARA | 带有 ReDoS 防护的扫描引擎 | 每个集成均位于 **Adapter 层**之后 — 禁止对域进行直接的外部访问 （硬性规则，详见 CONTRIBUTING.md）。 ## 案例研究 — 真实运营中的三个问题 ### 1 · “为什么我的 Domain Controller 不提供 Events？” 尽管 WEF Pipeline 在运行，但 Dashboard 显示 DC-Logons 为 0。存在根本原因， 这只能通过实时取证发现： - **DC 上的“Event Log Readers”组为空** — WEF Forwarder (NETWORK SERVICE) 根本没有权限读取 Security 日志。只有 PowerShell-Events 能够穿透，这掩盖了问题。 - **Kerberos 基础规则被设置为 Level 0**，因此它永远不会进入 Alerts 索引 — Events 虽然到达了，但处于不可见状态。 同一设置中的额外陷阱：Source-Initiated Subscription 的默认 SDDL (`A;;GA;;;DC` = “Domain Computers”) **排除了 Domain Controller** — DC 并非其成员。修复：补充 `(A;;GA;;;ED)`。 ### 2 · EICAR → 不到一分钟生成 Ticket — 以及为什么 KI 需要先学习 Pipeline 的端到端证明：客户端上的 EICAR 文件 → FIM（实时） → Wazuh → VirusTotal 集成（60+ 引擎） → Alert → Webhook → 带有完整 Evidence-Bundle 的 Ticket。 尽管如此，KI-Agent 仍将其评估为“false_positive 0.2”。在经历两个轮班的诊断后发现：**(1) 代码缺口** — Alert-Normalizer 根本没有提取 VirusTotal 字段，这个最强信号从未出现在 Prompt 中。**(2) 模型太弱** — 即使 Prompt 中包含 VT，3B 模型仍给出了错误的 Verdict。 解决方案：一个**确定性的 Evidence-Floor**（VT ≥ 5 malicious ⇒ 至少为 `confirmed_incident`，Confidence ≥ 0.9），它会覆盖模型的判断，并将 此次覆盖作为证据记录在案。从此以后，命中的 VT 再也无法悄无声息地 作为 False Positive 混过去 — 且与模型无关。 ### 3 · 永远无法触发的 Detection 规则 Brute-Force / Kerberos 规则依赖于经典的 **eventlog** 基础规则 (18xxx) — 而这些规则对于 `windows_eventchannel`-Events (WEF/Sysmon) **永远不会触发**。 迁移到正确的 60xxx 基础，使用 `same_field` 而非 `same_source_ip`（因为 eventchannel-Decoder 不提供 `srcip`），并且排除了机器账户 (`$`) 以防范 Kerberoasting-FPs。验证并非通过 logtest（因为它对 stdin 的解码是 错误的 — 已知的 Bug），而是针对**真实的 DC-Events**：升级规则 “将成员添加至特权组”在真实环境中以 Level 13 触发 (T1098)。 ## 路线图 阶段计划 0–9 及实时状态见 [`ROADMAP.md`](ROADMAP.md)。简而言之：稳定性 + UI/UX 产品化 + Enterprise-Security 已取得重大进展；尚未完成的主要是 Reports/PDF、MFA/SSO、Wazuh Health Center、Endpoint Companion Agent 以及 产品化工作（截图、Demo、发布 `v0.1.0-pilot`）。Nexora 是且永远是 开源的。 关于每次发布的变化详情，请参见 [`CHANGELOG.md`](CHANGELOG.md)。 ## 工程标准 - **TDD:** 测试先行 — 145 个 Backend 套件 / 约 2273 个测试 (Jest)， 70 个 Frontend 套件 / 约 766 个测试 (Vitest)，逻辑被严格实现为纯模块。 - **架构决策** 记录为 ADR：[`docs/adr/decisions.md`](docs/adr/decisions.md)。 - **开发日志** 记录了包含陷阱在内的每一次会话：[`docs/dev-journal.md`](docs/dev-journal.md)。 - **参与贡献：** [`CONTRIBUTING.md`](CONTRIBUTING.md) · 用户指南 [`docs/02-user-guide/user-guide.html`](docs/02-user-guide/user-guide.html) · 开发者指南 [`docs/04-developer-guide/developer-guide.html`](docs/04-developer-guide/developer-guide.html)。 ## 许可证 Apache License 2.0 — 详见 [`LICENSE`](LICENSE) 和 [`NOTICE`](NOTICE)。 本项目是且永远是开源的。

标签：AI风险缓解, GNU通用公共许可证, MITM代理, Node.js, PostgreSQL, React, SOC编排, Syscalls, 安全运营, 扫描框架, 测试用例, 自定义脚本, 请求拦截