xPablo13/OpenSOC-MSSP

# SOC-Lab-使用-Wazuh-Shuffle-Cortex-进行威胁检测与响应 一个基于 Docker 的自动化 SOC 实验室仓库。集成了 Wazuh (SIEM/XDR)、Shuffle (SOAR) 和 Cortex (CTI)。其突出特点在于具备弹性的架构，内置 TCP/DNS 代理，包含针对 Windows 的 MITRE ATT&CK 检测规则，支持误报抑制以及自动化的事件响应 Playbook。非常适合 Detection Engineering。 # 开源多租户 (MSSP) SOC 实验室架构 本仓库包含了一个旨在作为 **MSSP (Managed Security Service Provider)** 运行的实验室环境的技术文档、配置和工作流。该基础设施针对集中监控、高级检测和自动化事件响应进行了优化。 ## 1. 概述与战略目标 本项目的目标是部署一个能够以隔离方式管理多个客户（租户）的**安全运营中心 (SOC)**。该架构通过使用容器和网络分段来保证可扩展性，使安全分析师能够在一个统一的 *Open Source* 工具栈下集中处理来自不同环境的遥测数据。 ## 2. 网络拓扑与基础架构 该基础设施部署在 **VMware ESXi** 虚拟机监控程序上，在隔离网络 (**VLAN 104 - LAB4**) 中运行。通过在 DHCP 服务器中按 MAC 地址预留 IP 来确保服务的稳定性。 ### 虚拟机清单 | 主机名 | IP 地址 | 操作系统 | 主要角色 | 资源 (vCPU/RAM/HDD) | | :--- | :--- | :--- | :--- | :--- | | **SOC-SIEM-V1** | 172.18.104.17 | Ubuntu 24.04 LTS | 分析与数据库 | 2 vCPUs, 6GB RAM, 80GB | | **SOC-SOAR-V2** | 172.18.104.18 | Ubuntu 24.04 LTS | 自动化与 CTI | 2 vCPUs, 7GB RAM, 80GB | | **SOC-PROXY-V3** | 172.18.104.21 | Debian 12 | 边界与负载均衡 | 1 vCPU, 500MB RAM, 10GB | ## 3. 技术栈与数据流 (Data Pipeline) 该架构采用模块化设计，以避免单点故障 (SPOF) 并优化资源消耗。 ### A. 检测层 (SOC-SIEM-V1) 基于 **Wazuh** 和 **OpenSearch** 生态系统： * **Wazuh Manager：** 关联引擎与 MITRE ATT&CK 规则合规性检查。 * **内存优化：** 将 JVM 调整为 2GB 并设置 `vm.max_map_count=262144` 以防止 OpenSearch 崩溃。 * **自定义检测：** 在 `/var/ossec/etc/rules/local_rules.xml` 中集中管理高级检测规则。 ### B. 响应与编排层 (SOC-SOAR-V2) 基于 **Docker** 的部署，以简化工具的互联互通： * **TheHive & Cortex：** 案例管理与指标 (IOCs) 分析。 * **Docker-Cortex Bridge：** 实施 `socat` 以安全地暴露 Docker socket，允许 Cortex 执行分析器而不出现权限错误。 * **Shuffle (SOAR)：** 通过 Webhook 自动化告警工作流。 * **ChatOps 集成：** 双向 Telegram 机器人，用于关键通知（告警级别 > 11）和查询事件状态。 ### C. 边界层 (SOC-PROXY-V3) 使用 **NGINX** 作为统一入口点，以保护 SOC 核心： * **透传隧道 (第 4 层)：** 将 TCP 流量（端口 1515 和 1514）转发到 SIEM，用于 Agent 注册和接收加密遥测数据。 * **SSL 终端 (第 7 层)：** 管理内部 PKI 证书并执行 HTTPS 重定向，以安全访问管理仪表板。 ## 4. 数据流与 SOAR 编排 (事件工作流) 事件的生命周期和响应自动化充当了 SOC 的中枢神经系统，结构化为一个单向且并行的 *pipeline*，从而消除了手动的一级 (分诊) 工作。 ### 阶段 1：摄取、传输与触发 1. **边缘收集：** 安全 Agent 检测异常，并通过 TCP 端口 1514 将加密遥测数据发送到 SOC-PROXY-V1 节点。 2. **SIEM 处理：** NGINX 将流量重定向到 Wazuh Manager，后者对事件进行解码和评估，并将其物理存储在其本地文件 `alerts.json` 中。 3. **注入 SOAR：** 通过在 SIEM 节点上由 Filebeat 执行的脚本，提取关键告警并通过直接 HTTP POST 异步发送到 Shuffle 编排器的 Webhook。 ### 阶段 2：规范化与工件提取 (Python 节点) 一旦 Shuffle 接收到原始 JSON _payload_，执行过程就会分叉到并行的 Python 节点： * **清理节点：** Python 脚本净化日志，消除运行噪音，并规范化 JSON 结构，以避免编排器中出现语法错误。 * **提取节点：** 专用脚本 (`evaluador_ip`, `evaluador_hash`) 检查事件，独立提取 IPv4 地址和加密签名 (MD5/SHA256)。 ### 阶段 3：可追溯性与 CTI 富化 1. **实例化：** 使用规范化后的数据，Shuffle 调用 TheHive API 创建基础告警。 2. **Observables 注入：** 如果提取节点捕获了有效的 IOC，编排器会向 TheHive 发出第二次请求，将其作为“Observables”附加到新创建的告警中。 3. **情报分析：** Shuffle 动态调用 Cortex 分析器，对照外部数据库查询 observables 的信誉：VirusTotal (哈希和 IP)、AbuseIPDB (IP) 和 AlienVault OTX (活动与脉冲)。 ### 阶段 4：分诊、升级与通知 最后一个 Python 节点充当“法官”，摄取评分（例如，*Abuse Confidence Score* 或 VT 检出率）。 * **升级为案例：** 如果情报指标超过了定义的风险阈值，Shuffle 会自动将 TheHive 中的告警升级为结构化的“案例”。 * **ChatOps 告警：** 同时，编排器向 SOC 的 Telegram 机器人发送格式化的消息，实时通知团队已确认的威胁。 ### 阶段 5：主动响应与人机回路 流程最终通过双向 Telegram 机器人和 Wazuh 的 Active Response 模块实现威胁清除能力： * **暴力破解遏制 (IP 封锁)：** 如果检测到的攻击向量是重复的异常登录，Telegram 会部署一个交互式提示，询问分析师是否继续操作。如果分析师按下接受按钮，Shuffle 将编排直接在防火墙中自动封锁攻击者 IP 的操作。 * **恶意软件清除 (文件删除)：** 如果原始告警来自文件完整性模块 (FIM)，并且 Cortex 通过 VT 确认哈希是恶意的，SOAR 将向受影响的 Agent 下发主动响应命令，以进行二进制文件的自主删除或隔离。 ## 5. 高级用例与自主运行 该环境超越了被动关联的范畴。我们将主动响应和远程管理功能直接集成到了编排器 中，从而最大程度地减轻一级团队的操作负担。 ### 5.1. 远程管理控制台 (双向 ChatOps) 我们已经将 Telegram 的通知机器人转变为交互式命令界面。这使得分析师能够直接从他们的移动设备上查询并对基础设施进行操作，整个过程是加密的，且无需在内部网络中开放任何端口。 编排器 持续查询机器人的收件箱，智能地管理 Telegram API 的 *offsets* 以避免重复读取消息。通过处理原始请求的 Python 节点，SOC 可以响应特定的命令： * **命令 `/status`：** SOAR 向 SIEM 发起查询，并返回格式化的文本，实时显示部署在客户端的所有 Wazuh Agent 的连接状态（活动/断开）。 * **命令 `/casos`：** 调用 TheHive REST API 提取并返回一个快速报告，包含已打开事件的总数，并按严重程度进行细分。 **自动化日报：** 为了在不依赖手动仪表板的情况下保持对边界的控制，我们在 Shuffle 中配置了一个每 24 小时（例如 09:00 AM）触发一次的定时 *trigger*。 为了保证准确性并避免 API 易失性缓存导致的失败，此工作流直接针对 OpenSearch 引擎（端口 9200）启动 *Query DSL* 深度查询。它提取过去 24 小时内严重程度高于 7 的所有 Wazuh 告警以及在 TheHive 中创建的新案例，将它们打包成执行摘要，自动发送到 SOC 的 Telegram 群组。 ### 5.2. 反钓鱼引擎与邮件主动响应 我们部署了一个自动化 *workflow* 来中和针对企业电子邮件的社会工程攻击： 1. **主动监控：** SOAR 连接到企业收件箱，并自动摄取新的传入电子邮件。 2. **工件解析：** 一个专用的 Python 节点分析邮件头和正文，动态提取威胁指标（可疑的 URLs 和域名）。 3. **并发 CTI 分析：** 提取的 observables 被发送到 Cortex，后者查询外部情报 API (VirusTotal) 以评估域名的真实信誉。 4. **事件生成与缓解：** 如果情报引擎裁定该域名是恶意的，SOAR 将编排在 TheHive 中立即创建高严重性告警，附加电子邮件的元数据，并将事件置于准备就绪且集中的状态，以便分析师进行最终的缓解处理。 ### 自动化分诊证据 以下是 SOAR (Shuffle) 如何处理由 Wazuh 检测到的暴力破解告警的真实示例：提取 IP，从情报源 (CTI) 查询其信誉，并为一级分析师生成结构化案例。  ### ChatOps 与主动响应证据 (人机回路) 以下示例展示了我们的编排器与 Telegram 的双向集成。在发生关键的暴力破解攻击时，机器人会实时通知团队并部署交互式按钮。这使得分析师能够评估威胁并直接从聊天中授权在边界防火墙中自动封锁 IP，将平均响应时间 (MTTR) 缩短至几秒钟。  ### 漏洞检测仪表板证据 在此截图中，我们可以观察到 Wazuh 针对特定 Agent 生成的漏洞告警。这里展示了我们基础设施中许多可能被攻击者利用的潜在安全故障，其中许多源于未及时更新的应用程序或严重的配置错误。 

标签：Cloudflare, Cortex, Debian, Detection Engineering, DNS代理, Docker, Docker容器, FTP漏洞扫描, IP 地址批量处理, MITRE ATT&CK, MSSP, Playbook, Python 实现, Shuffle, SOAR, TCP代理, VLAN, VMware ESXi, Wazuh, Windows检测规则, 剧本, 参数枚举, 安全合规, 安全实验室, 安全服务提供商, 安全编排, 安全运营中心, 安全防御评估, 容器化部署, 攻击面发现, 网络代理, 网络分段, 网络威胁情报, 网络安全, 网络映射, 自动化响应, 虚拟化, 误报消除, 请求拦截, 负责任AI, 逆向工具, 隐私保护, 集中监控