SOC Stack

在 Proxmox 宿主机上执行一条命令，即可在大约 30 分钟内构建一个完整的、自托管的 Security Operations Center 实验室。

SOC Stack 是一个一条命令安装器，能够在单个 Proxmox 宿主机上快速搭建完整的开源 Security Operations Center：Wazuh、TheHive + Cortex、MISP、Zeek + Suricata、仪表板以及一系列 MCP 服务器，所有这些都能相互连接。你需要一个逼真的 SOC 来进行训练、测试检测或作为 homelab 运行，但是手动组装六个工具并对它们进行集成会耗费数天时间。它与一堆针对单个工具的指南不同，它将整个技术栈视为一个声明式、幂等且对智能体友好的部署：每个工具都是一个自包含的 LXC 组件，跨组件集成会自动连接，并且整个运行过程是非交互式的，并带有 JSON 输出，因此 AI agent 可以通过 SSH 登录并一次性完成部署。 **网站：** [lidless.dev/soc-stack](https://lidless.dev/soc-stack) ## 它的功能 SOC Stack 是一个适用于 homelab 和安全培训的自托管 SOC 实验室构建器。在 Proxmox VE 宿主机上运行一条命令，大约 30 分钟后你就会拥有一个可用的 Security Operations Center： - **Wazuh** 用于 SIEM / XDR（告警、FIM、漏洞检测、agent 管理） - **TheHive + Cortex** 用于案例管理和 SOAR（分析器、响应器、observable 丰富） - **MISP** 用于威胁情报（IOC 共享、feeds、关联） - **Zeek + Suricata** 用于网络安全监控和入侵检测（NSM + IDS/IPS） - 位于 nginx 后方的**自定义仪表板**（Bro Hunter + Playbook Forge） - **9 个 MCP 服务器**，使得 AI agent 可以通过单个 MCP 配置查询 Wazuh、TheHive、Cortex、MISP、Zeek、Suricata、MITRE ATT&CK、Rapid7 和 Sophos 每个工具都在其专用且非特权的 LXC 中运行。编排器处理 VMID 分配、网络设置、幂等性、密钥生成以及跨组件集成连接。默认情况下，整个运行过程是非交互式的，并输出结构化的 JSON，因此个人或 agent 都可以按需复现相同的实验室。 关键词：SOC 实验室、security operations center、Proxmox homelab、Wazuh SIEM、TheHive、Cortex SOAR、MISP 威胁情报、Suricata IDS、Zeek NSM、蓝队训练、检测工程、自托管安全、安全工具的 MCP 服务器。 ## 快速开始 **完整技术栈**（所有组件，采用合理的默认设置）： ``` curl -sSL https://raw.githubusercontent.com/solomonneas/soc-stack/main/install.sh | sudo bash ``` 当在本地 TTY 下以 `sudo bash install.sh` 运行时，如果你没有传递 `--components` 或 `--manifest`，安装程序将打开组件选择器。通过管道传输的、CI 的以及由 agent 驱动的安装将保持非交互式，并默认采用完整技术栈。 **自定义子集：** ``` curl -sSL https://raw.githubusercontent.com/solomonneas/soc-stack/main/install.sh | sudo bash -s -- \ --components wazuh,thehive-cortex,misp \ --preset standard \ --bridge vmbr0 --storage local-lvm ``` **由 agent 驱动**（完全非交互式，结构化输出）： ``` curl -sSL https://raw.githubusercontent.com/solomonneas/soc-stack/main/install.sh | sudo bash -s -- \ --components all \ --preset minimal \ --bridge vmbr0 --storage local-lvm --ip-mode dhcp \ --json-out /root/soc-stack.json \ --mcp-config-out /root/mcp-clients.json ``` 想在运行前先了解一番？克隆仓库并在本地执行相同的编排器；其行为是完全相同的： ``` git clone https://github.com/solomonneas/soc-stack.git cd soc-stack sudo bash install.sh --components all --dry-run # validate + plan, deploy nothing ``` 安装后： - `/root/soc-stack.json` 列出了每个组件及其 LXC VMID、IP、端口、endpoint、警告和密钥文件路径。默认情况下，原始密码和 API token 会被脱敏；仅当自动化工作流明确需要它们时，才传递 `--include-secrets-json`。 - `/root/mcp-clients.json` 是一个可以直接粘贴的 `mcpServers` 配置块，适用于 Claude Desktop、OpenClaw 或任何 MCP 客户端。它包含 bearer token，并且仅限 root 写入。 - `/var/lib/soc-stack/state/` 包含用于幂等重新运行的各组件状态文件。 - `/var/lib/soc-stack/secrets/` 包含每个生成的凭证（权限模式 0600，仅限 root 访问），以供审计恢复使用。 使用 `--force` 重新运行相同的命令以重新部署已完成的组件，或者使用 `--components ` 将单个组件添加到现有的安装中。 ## 组件 | 组件 | 服务 | LXC 预设 (minimal) | 端口 | |---|---|---|---| | **wazuh** | Wazuh Manager, Indexer, Dashboard | 2 vCPU, 2 GB RAM, 30 GB | 443, 1514, 1515, 55000 | | **thehive-cortex** | TheHive 5.4, Cortex 3.1.8, Elasticsearch 7.17, Cassandra 4.1 | 2 vCPU, 4 GB RAM, 30 GB | 9000, 9001 | | **misp** | MISP, MariaDB 10.11, Redis 7, misp-modules | 1 vCPU, 2 GB RAM, 20 GB | 443 | | **zeek-suricata** | Zeek (NSM), Suricata (IDS/IPS) | 1 vCPU, 2 GB RAM, 20 GB | 47760 | | **dashboards** | Bro Hunter + Playbook Forge 位于 nginx 后方 | 1 vCPU, 1 GB RAM, 10 GB | 80, 5174, 5177 | | **mcp** | 9 个 MCP 服务器 (wazuh, thehive, cortex, misp, zeek, suricata, mitre, rapid7, sophos) 通过 `mcp-proxy` 封装为 SSE | 1 vCPU, 1 GB RAM, 10 GB | 3001-3009 | 每个组件都在其专用的 LXC 中运行。组件可以独立部署，也可以一起部署。编排器处理 VMID 分配、网络设置、幂等性以及跨组件集成连接。 ## 跨组件集成 在所有组件部署完毕后自动配置： - **Wazuh -> TheHive**：级别 8 及以上的 Wazuh 告警通过自定义 Python 集成 (`/var/ossec/integrations/custom-thehive.py`) 作为警报转发至 TheHive。 - **TheHive <-> Cortex**：TheHive 的 Cortex 连接器通过组织范围内的 API key 指向本地 Cortex。 - **MISP -> Suricata**：每小时一次的 cron 任务从 MISP 的 `restSearch` endpoint 拉取 Snort/Suricata 规则到 Suricata 的 update.d 中。 - **Zeek -> Wazuh**：Wazuh agent 在 zeek-suricata LXC 中运行，并将 conn.log、dns.log、http.log、ssl.log、notice.log 转发给 Wazuh manager。 - **MCP 服务器 <- 所有同级组件**：每个 MCP 服务器的环境文件都填入了来自同级组件状态的、与其对应工具的 URL + API key。 ## 完成安装后的样子 `/root/soc-stack.json` 是记录已部署内容的真实数据源。在隐藏密钥的情况下，一次完整技术栈运行会报告每个组件、其 LXC、其 endpoint 以及任何警告（下方的 IP 和 token 是来自 [RFC 5737](https://datatracker.ietf.org/doc/html/rfc5737) 文档范围的占位符值）： ``` { "version": "1.0.0", "preset": "minimal", "status": "deployed", "components": [ { "component": "wazuh", "status": "deployed", "vmid": 9001, "ip": "192.0.2.11", "endpoints": { "dashboard": "https://192.0.2.11:443", "api": "https://192.0.2.11:55000" }, "credentials": { "user": "admin", "password": "REDACTED" } }, { "component": "mcp", "status": "deployed", "vmid": 9006, "ip": "192.0.2.16", "endpoints": { "wazuh_sse": "http://127.0.0.1:3001/sse", "thehive_sse": "http://127.0.0.1:3002/sse" } } ], "integrations": [ { "from": "wazuh", "to": "thehive", "status": "wired" }, { "from": "misp", "to": "suricata", "status": "wired" } ] } ``` 确切的 JSON 结果 schema 记录在 [`docs/design/specs/2026-05-15-soc-stack-unification-design.md`](docs/design/specs/2026-05-15-soc-stack-unification-design.md) 中。 ## 对 Agent 友好的契约 旨在让 AI agent 能够 SSH 登录到 Proxmox 宿主机并一次性部署好 SOC。完整的 agent 接口面： - 在 `curl | sudo bash` 下 **Stdin 是关闭的**；安装程序会自动检测到这一点并启用 `--non-interactive` 模式。每个提示符都会变成一个 flag，每个默认值都会变成一个答案。 - **退出代码** 是稳定的：0 = 成功，1 = 预检（糟糕的宿主机），2 = 验证（错误的 flag），3 = 组件失败，4 = 集成失败，5 = 混合状态。 - **JSON 结果 schema** 记录在 [`docs/design/specs/2026-05-15-soc-stack-unification-design.md`](docs/design/specs/2026-05-15-soc-stack-unification-design.md) 中。 - **幂等性**：如果所有内容都已经部署完毕（状态为 `status: "deployed"`），使用相同的 flag 重新运行会在几秒钟内退出。`--force` 会触发重新部署。 - **Manifest 模式**：无需使用几十个 flag，编写一个 JSON manifest 并传递 `--manifest ` 即可。在此基础上应用的 CLI flag 会覆盖单个 manifest 字段。 ## Flag 参考 ``` --components LIST CSV of components or "all" (default: all) --preset NAME minimal | standard | production (default: standard) --bridge NAME Proxmox bridge (default: vmbr0) --storage NAME Storage pool (default: auto-detect) --ip-mode MODE dhcp or static (default: dhcp) --ip-range CIDR Required if --ip-mode=static (e.g., 198.51.100.10/24) --vlan TAG Optional VLAN tag --vmid-start N First VMID to allocate (default: next free) --manifest PATH JSON manifest (alternative to flags) --state-dir PATH State directory (default: /var/lib/soc-stack) --json-out PATH Result JSON path (default: /root/soc-stack.json) --mcp-config-out PATH MCP client config (default: /root/mcp-clients.json) --log-file PATH Install log (default: /var/log/soc-stack-install.log) --dry-run Validate + plan only, no deploy --force Redeploy components already marked deployed --no-integrate Skip cross-component wiring phase --non-interactive Hard-fail on prompts (auto when stdin is not a TTY) --include-secrets-json Include raw credentials in result JSON (default: redacted) --mcp-bind-host HOST MCP SSE bind host (default: 127.0.0.1; use 0.0.0.0 to expose) --version Print version and exit ``` ## 仓库结构 ``` soc-stack/ ├── install.sh # repo-root wrapper for curl|bash ├── scripts/ │ ├── install.sh # orchestrator (~430 lines) │ ├── lib/ # 8 shared bash modules (bats-tested) │ │ ├── logging.sh │ │ ├── secrets.sh │ │ ├── json-out.sh │ │ ├── idempotency.sh │ │ ├── network.sh │ │ ├── manifest.sh │ │ ├── preflight.sh │ │ └── lxc.sh │ └── components/ │ ├── wazuh/ # manifest.jsonc + 5 scripts per component │ ├── thehive-cortex/ │ ├── misp/ │ ├── zeek-suricata/ │ ├── dashboards/ │ └── mcp/ # 9 MCP servers + mcp-proxy SSE bridge ├── tests/ │ ├── unit/ # 105 bats tests, mocked Proxmox binaries │ └── integration/ # per-component + cross-component assertions ├── docs/ │ ├── design/specs/ # design spec (result JSON schema lives here) │ ├── gotchas.md │ ├── adding-a-component.md # component contract walk-through │ └── architecture/ ├── playbooks/ # incident response playbooks ├── cases/ # case study evidence └── mcp-servers/ └── README.md # docs for the 9 bundled MCP servers ``` ## 工作原理 每个组件都是 `scripts/components//` 下的一个自包含文件夹，具有固定的接口： | 文件 | 运行位置 | 用途 | |---|---|---| | `manifest.jsonc` | (声明式) | 预设、端口、依赖、提供项 | | `lxc-spec.sh` | Proxmox 宿主机 | 根据预设输出 `pct create` flag | | `deploy.sh` | LXC 内部 | 幂等安装器；写入状态 JSON | | `verify.sh` | LXC 内部 | 健康检查；如果正常则退出码为 0 | | `integrate.sh` | Proxmox 宿主机 | 将此组件与同级组件连接（读取同级状态） | | `destroy.sh` | Proxmox 宿主机 | 销毁 LXC + 状态 | 编排器 (`scripts/install.sh`) 仅通过此接口与组件进行通信。添加新组件只需放入一个新文件夹；无需更改任何其他内容。 `/var/lib/soc-stack/state/.json` 中的状态文件是实现幂等性的真实数据源。重新运行 `install.sh` 会检查每个组件的状态，并跳过任何已部署的组件（除非使用 `--force`）。发生故障时，状态文件会记录 `status: "failed"` 和一个 `error` 字符串；编排器会继续处理剩余的独立组件，并报告混合状态退出码 5。 ## 前置条件 - Proxmox VE 7.x 或 8.x 或 9.x 宿主机 - Proxmox 宿主机上的 Root 访问权限 - 一个网桥（默认：`vmbr0`）和一个存储池（默认：自动检测，回退至 `local-lvm`） - 允许安装器下载内容的外出 HTTPS 连接（Docker、Wazuh 安装器、MCP 服务器仓库等） - 在 `--preset minimal` 设置下，完整技术栈需要约 12 GB 的可用内存和约 150 GB 的可用磁盘空间 如果缺少 `jq`、`curl`、`wget` 和 `openssl`，安装程序会自动安装它们。 ## 运维操作 **为单个组件重新运行：** ``` sudo bash install.sh --components misp --force ``` **重新运行集成阶段（在修复了某个同级组件之后）：** ``` sudo bash install.sh --components all ``` 已经部署的组件会被幂等性检查跳过，因此直接重新运行会直接进入跨组件连接阶段。 **验证而不进行部署：** ``` sudo bash install.sh --components all --dry-run ``` **移除单个组件：** ``` sudo bash scripts/components/misp/destroy.sh ``` 这会停止并销毁该组件的 LXC 并移除其状态文件。其他组件会继续运行；如果希望同级组件断开与它的连接，请在之后重新运行安装程序。 **卸载所有内容：** ``` for comp in mcp dashboards zeek-suricata misp thehive-cortex wazuh; do sudo bash scripts/components/${comp}/destroy.sh done sudo rm -rf /var/lib/soc-stack /root/soc-stack.json /root/mcp-clients.json ``` 最后的 `rm` 会移除状态、生成的密钥和输出的 JSON；如果你希望以后恢复凭证，请跳过它。 **升级：** ``` curl -sSL https://raw.githubusercontent.com/solomonneas/soc-stack/main/install.sh | sudo bash ``` 从较新的检出中重新运行安装器是升级路径：已经部署的组件会被原样保留，新组件会进行部署，并且集成会重新连接。要获取某个组件的新版本，请将其销毁并使用 `--components ` 重新运行。安装器从不会原地自动更新正在运行的组件。 ## 为什么不选择其他方案？ - **为什么不手动安装每个工具？** 你可以这么做，而且 Wazuh、TheHive、MISP 和 Suricata 的官方文档都很好。但是六次安装加上它们之间的集成（告警转发、分析器连接、IOC feeds、日志传送）是一个需要多天的项目，而且在你下次重建时就会崩溃。SOC Stack 将所有这些变成了一个可复现的命令。 - **为什么不使用单一的 All-in-One SIEM 虚拟机（SecurityOnion、Wazuh OVA 等）？** 那些都非常出色且是专门构建的。SOC Stack 的不同之处是有意为之：每个工具都位于其自己的 LXC 中，你可以独立地进行扩展、快照或销毁；这些组件是真正的上游项目（而不是 fork），并且跨工具集成是明确且可检查的，而不是在某个设备中的。 - **为什么不使用 Ansible 或 Terraform？** 没有什么能阻止你，配置管理的重写是合理的未来方向。当前的设计倾向于plain、可审计、你可以从头到尾阅读的 bash，以及一条允许 agent 在宿主机上无需额外工具即可驱动的 `curl | sudo bash` 路径。状态文件而非状态后端驱动幂等性。 - **为什么不直接在 Docker / Kubernetes 上运行？** 有几个组件已经在其 LXC 内部使用了 Docker Compose。Proxmox LXC 层为每个工具提供了隔离、专属的 IP 以及容器级别的快照/回滚，这与 homelab SOC 的实际运作方式是一致的。 ## soc-stack 不适用的场景 - **不是一个经过强化的生产级 SOC。** 它是一个实验室和培训工具。它假定处于一个受信任的 Proxmox 宿主机和一个受信任的内部网桥环境下。在没有防火墙、VLAN 和 TLS 终止作为前端的情况下，不要将组件 IP 暴露给不受信任的网络。完整的威胁模型请参见 [SECURITY.md](SECURITY.md)。 - **不是一个托管或托管服务。** 没有 SaaS，没有遥测，也没有回传。一切都在你控制的硬件上运行。 - **不是上游工具的 fork 或重新打包。** 它在固定的版本下从真实的来源部署 Wazuh、TheHive、Cortex、MISP、Zeek 和 Suricata；它不会修改它们。 - **不是一个自动更新器。** 安装器固定了版本，并且从不会静默地原地升级正在运行的组件；更新会在你的计划安排下进行。 - **不是多宿主机的。** 它以单个 Proxmox 宿主机为目标。目前多节点不在范围之内。 ## 添加新组件 有关组件契约的详细说明，请参见 [docs/adding-a-component.md](docs/adding-a-component.md)；有关完整设计，请参见 [docs/design/specs/2026-05-15-soc-stack-unification-design.md](docs/design/specs/2026-05-15-soc-stack-unification-design.md)。 ## 安全性 默认凭证会在部署时轮换和验证，密钥仅限 root 访问，默认情况下结果 JSON 是脱敏的，除非你另有说明，否则 MCP 服务器将绑定到 localhost。完整的威胁模型，即哪些部分是强化的、哪些是经过深思熟虑而接受的，都位于 [SECURITY.md](SECURITY.md) 中。发现了漏洞？请在此仓库上使用 GitHub 的私密漏洞报告功能。 ## 许可证 [MIT](LICENSE)。版权所有 (c) 2026 Solomon Neas。

标签：Burp项目解析, Homelab, Metaprompt, NIDS, Proxmox, 安全运营, 容器化, 应用安全, 扫描框架, 搜索引擎查询, 版权保护, 特权提升, 自动化部署, 逆向工具