mandal-suman/blue-team-lab
GitHub: mandal-suman/blue-team-lab
一个完全隔离的双段虚拟网络防御安全实验室，用于端到端的恶意软件引爆、遥测工程和检测规则开发。
Stars: 0 | Forks: 0
# 蓝队实验室
## 实验室摘要 本仓库作为一个严格隔离的防御性网络安全引爆实验室的工程蓝图和运营记录。为了促进端到端的安全运营，该基础设施实施了严格的 Layer-2 和 Layer-3 网络隔离。这将活跃的恶意软件执行限制在一个确定的爆炸半径内，同时维护了一个经过加密安全的异步遥测 pipeline，并接入本地化的 Elastic SIEM。 该项目旨在解决端点安全分析中的“黑盒”问题。通过从头开始构建摄取 pipeline、路由约束和分析引擎，操作人员可以绝对透彻地理解原始 kernel 遥测如何转化为可操作的 SIEM 检测。它既是检测工程师的功能测试场地，也是深层系统架构解决方案的文档化记录。 ## 构建内容 本项目实现了一个完全隔离的恶意软件引爆和检测工程环境，该环境基于 VMware Workstation、OPNsense、Ubuntu Server、Windows 10 和 Elastic Stack 构建。 **已实现的功能包括：** - 双段虚拟网络架构 - 基于 OPNsense 的流量分割 - TLS 加密的 Elastic Stack 部署 - Logstash Beats 摄取 pipeline - Winlogbeat 端点遥测转发 - Sysmon 遥测收集与富化 - 基于 ECS 规范化的事件存储 - Kibana 调查工作流 - 基于 KQL 的检测工程 - 对齐 MITRE ATT&CK 的验证测试 该环境旨在提供从攻击执行到检测生成的端到端可见性，同时维持严格的遏制边界。 ## 实验室存在的原因 许多安全实验室只专注于部署工具。 本项目侧重于理解整个遥测生命周期： 攻击执行 → 遥测生成 → 日志收集 → 数据传输 → 数据规范化 → 检测开发 → 威胁狩猎 每一个组件都经过了刻意的部署、配置、破坏、重建、验证和记录，以培养运营级别的理解，而不仅仅是流程上的熟练度。 ## 实验室目标 * **恶意软件引爆：** 在高度受控、严格隔离的网段中执行恶意 payload，以观察执行链，同时避免 hypervisor 的交叉污染。 * **遥测工程：** 配置和优化 kernel 级别的端点传感器，以捕获高保真度的执行上下文，避开标准操作系统的日志记录限制。 * **SIEM 工程：** 部署和管理零浪费、解耦的 Elastic Stack 基础设施，处理日志摄取、数据规范化和索引。 * **检测工程：** 将原始遥测数据转化为结构化、高信噪比的告警，从而明确识别对抗性行为。 * **威胁狩猎：** 交互式查询历史数据，以发现潜在的持久化机制和二级 payload 指标。 * **ATT&CK 映射：** 严格对照 MITRE ATT&CK 框架对齐所有生成的遥测数据和构建的检测，以实现标准化的战术分析。 ## 架构概述 该实验室构建在 Type-2 Hypervisor 基础之上，完全通过虚拟化的 packet filter 进行路由，以实施隔离。 * **VMware Workstation：** 作为 hypervisor 层，提供本地化的虚拟交换机结构（`VMnet2` 和 `VMnet3`）。 * **OPNsense（核心网关）：** 作为中央路由和防火墙引擎，明确控制主机、摄取平面和攻击平面之间的流量。 * **Ubuntu 26.04 LTS（SIEM 节点）：** 托管 Docker 容器化的 Elastic Stack，绑定到具有静态地址的摄取平面，以保证 pipeline 的稳定性。 * **Windows 10 Pro（受害机）：** 双宿主引爆目标。它通过攻击接口接收攻击，并通过防御接口将 Ring-0 遥测传输出去。 * **Kali Linux（攻击机）：** 对抗性模拟节点，严格隔离在攻击平面上，以防止横向移动回流到遥测或主机基础设施中。 ## 网络拓扑 ``` flowchart TD classDef attack fill:#3b0000,stroke:#ff4444,stroke-width:2px,color:#fff; classDef ingest fill:#00263b,stroke:#00aaff,stroke-width:2px,color:#fff; classDef infra fill:#1c1c1c,stroke:#888888,stroke-width:2px,color:#fff; classDef gateway fill:#4a2500,stroke:#ff8c00,stroke-width:2px,color:#fff; Internet(((Internet))):::infra subgraph Physical["Physical Infrastructure"] Host[Windows 11 Host]:::infra VMware[VMware Workstation Pro]:::infra end Internet <--> Host Host <--> VMware subgraph Virtual["Virtual Network Architecture"] OPN{{OPNsense Gateway
WAN + LAN + OPT1}}:::gateway subgraph VMNET3["VMnet3 - Attack Plane (192.168.60.0/24)"] Kali[Kali Linux
192.168.60.20]:::attack VictimAtk[Windows Victim NIC-2
192.168.60.10]:::attack end subgraph VMNET2["VMnet2 - Ingestion Plane (192.168.50.0/24)"] VictimDef[Windows Victim NIC-1
192.168.50.10]:::ingest SIEM[Ubuntu Server 26.04
Elastic Stack
192.168.50.50]:::ingest end end VMware <--> OPN OPN <--> Kali OPN <--> VictimAtk OPN <--> VictimDef OPN <--> SIEM Kali == "Exploit / Lateral Movement" ==> VictimAtk %% Internal SIEM / Pipeline Flow Overlaid VictimDef -. "Sysmon Logs" .-> Winlogbeat([Winlogbeat]):::ingest Winlogbeat -. "Beats TLS 5044" .-> Logstash([Logstash]):::ingest Logstash -. "ECS Events" .-> Elasticsearch[(Elasticsearch)]:::ingest Elasticsearch -. "Queries" .-> Kibana([Kibana]):::ingest Kibana -. "Detection Rules" .-> Alerts>Alerts]:::attack ``` ## 遥测流向 ``` flowchart LR classDef attack fill:#3b0000,stroke:#ff4444,stroke-width:2px,color:#fff; classDef windows fill:#003366,stroke:#0088cc,stroke-width:2px,color:#fff; classDef sensor fill:#004d40,stroke:#00bfa5,stroke-width:2px,color:#fff; classDef siem fill:#00263b,stroke:#00aaff,stroke-width:2px,color:#fff; classDef alert fill:#5c0000,stroke:#ff0000,stroke-width:2px,color:#fff; subgraph Adversary ["Attack Simulation"] Attack((Kali Linux)):::attack end subgraph Endpoint ["Victim Endpoint (Windows 10)"] Victim[OS Execution Context]:::windows Sysmon[[Sysmon Driver]]:::sensor EventLog[[Windows Event Log]]:::sensor Winlogbeat([Winlogbeat + Disk Queue]):::sensor end subgraph SIEM_Pipeline ["Elastic SIEM Pipeline"] Logstash([Logstash Node
TLS 5044]):::siem Elastic[(Elasticsearch Cluster)]:::siem Kibana([Kibana Interface]):::siem end subgraph SOC ["Detection & Response"] Detection{Detection Rules}:::alert Alert((Alert Generation)):::alert end Attack == "Malicious Payloads" ==> Victim Victim -- "Kernel Telemetry" --> Sysmon Victim -- "OS Telemetry" --> EventLog Sysmon -- "Event ID 1, 3, etc." --> Winlogbeat EventLog -- "Security/System Logs" --> Winlogbeat Winlogbeat == "Asynchronous Forwarding" ==> Logstash Logstash -- "Data Normalization / ECS" --> Elastic Elastic -- "KQL Search" --> Kibana Kibana -. "Continuous Evaluation" .-> Detection Detection == "Rule Triggered" ==> Alert ``` ## 技术栈 | 层级 | 技术 | 版本 | 用途 | | --- | --- | --- | --- | | **Hypervisor** | VMware Workstation | 17.x Pro | 硬件虚拟化和虚拟交换机结构配置。 | | **网关 / 防火墙** | OPNsense | 24.1 | Layer-3/Layer-4 边界执行和爆炸半径遏制。 | | **摄取 OS** | Ubuntu Server LTS | 26.04 | 用于执行 Docker daemon 的稳定、无头的 Linux 环境。 | | **目标 OS** | Windows 10 Pro | 22H2 | 主要引爆目标和 Windows 子系统遥测源。 | | **攻击 OS** | Kali Linux | 2024.x | 用于对抗性模拟和 payload 投递的执行节点。 | | **分析引擎** | Elasticsearch | 9.4.1 | 通过 REST API 进行分布式搜索、存储和数据查询。 | | **可视化** | Kibana | 9.4.1 | 用于数据探索、执行 KQL 查询和仪表盘的 Web 界面。 | | **摄取 Pipeline** | Logstash | 9.4.1 | 服务端数据处理、ECS 规范化和 SSL 终止。 | | **Agent 管理** | Fleet Server | 9.4.1 | 为未来集成 Elastic Agent 提供集中化管理。 | | **端点转发器** | Winlogbeat | 9.4.1 | 具有异步磁盘缓冲功能的轻量级 Windows 事件转发器。 | | **Kernel 传感器** | Sysmon | 15.x | 系统监控器，为进程和网络活动提供高级事件追踪。 | ## 已验证能力 | 能力 | 状态 | |------------|---------| | VMware 网络隔离 | 已验证 | | OPNsense 路由和防火墙 | 已验证 | | Docker 化的 Elastic 部署 | 已验证 | | TLS 加密的 Beats 摄取 | 已验证 | | Winlogbeat 遥测收集 | 已验证 | | Sysmon 事件收集 | 已验证 | | ECS 数据规范化 | 已验证 | | Kibana 调查工作流 | 已验证 | | KQL 检测开发 | 已验证 | | ATT&CK 技术验证 | 已验证 | ## 平台预览 ### Elastic Security 概览 TODO: 截图 ### Kibana 仪表盘 TODO: 截图 ### Sysmon 遥测 TODO: 截图 ### 检测规则 TODO: 截图 ## 架构原则 ### 隔离优先 攻击基础设施绝对不能与分析基础设施直接通信。 ### 检测之前先看遥测 检测质量受制于遥测质量。 ### 显式路由 所有流量路径均通过 OPNsense 明确定义。 ### 版本对齐 Elastic Stack 和遥测 agent 保持版本对齐，以防止 schema 漂移。 ### 故障记录 故障被视为工程资产，并记录其根本原因分析和修复程序。 ## 核心工程决策 * **选择 VMware Workstation 而非 WSL2：** 初始迭代尝试了 WSL2 镜像网络配置。由于无法解决的主机级 kernel 端口冲突（例如，主机 `svchost.exe` 锁定端口 9200）以及在执行严格的 Layer-2 隔离方面的限制，该方案被放弃。VMware 允许对子网进行绝对严格的分离。 * **选择 OPNsense 作为核心路由：** 采用它是为了防止动态的 hypervisor 路由变量。它提供自上而下的、显式的爆炸半径控制，确保在受害机能够与 SIEM 通信的同时，攻击机在摄取基础设施中保持完全的黑洞状态。 * **选择 Elastic Stack 进行分析：** 选择它是由于其行业标准查询语言 (KQL)、高度灵活的 Elastic Common Schema (ECS) 和强大的 Detection Engine，这与现代安全运营中心 (SOC) 运营和 MITRE ATT&CK 映射完美契合。 * **选择 Sysmon 进行遥测：** 标准的 Windows 事件日志缺乏高级检测所需的深层执行上下文。集成 Sysmon 是为了捕获 Ring-0 进程创建树、内存注入和确定性的进程到网络 callback 映射。 ## 实验室能力 * **恶意软件引爆：** 在受控状态下安全执行活跃的二进制文件和脚本。 * **遥测收集：** 将端点数据端到端路由到集中式数据湖。 * **Sysmon 监控：** 深入观察 kernel callback 和进程创建。 * **检测开发：** 迭代创建逻辑规则以捕获特定的恶意技术。 * **威胁狩猎：** 主动查询原始数据流以验证假设。 * **KQL 开发：** Kibana 查询语言在数据提取中的实际应用。 * **Sigma 开发：** 针对 Elastic 后端的后端无关检测规则编译。 * **ATT&CK 映射：** 将原始数据与已知的对手攻击剧本结合进行上下文分析。 * **安全事件分析：** 将不同的事件关联成一个紧密的事件时间线。 ## 异步运行状态（资源优化） 此架构设计为按顺序执行。为了绕过硬件限制（例如 16GB RAM 限制），实验室在三个独立且隔离的阶段中运行。遥测 pipeline 利用 `queue.disk` 缓冲来保证状态转换之间数据的零丢失。 **状态 1：引爆与遏制** * **活跃节点：** OPNsense、Windows 10（受害机）、Kali Linux。 * **离线节点：** Ubuntu 26.04 (SIEM)。 * **目标：** 执行 payload。Winlogbeat 将所有 ECS 遥测数据本地缓冲到受害机的物理磁盘上。 **状态 2：摄取与同步** * **活跃节点：** OPNsense、Windows 10（受害机）、Ubuntu 26.04 (SIEM)。 * **离线节点：** Kali Linux。 * **目标：** 遥测清空。受害机与 Logstash 建立 TLS 会话，并将物理磁盘队列排空至 Elasticsearch 中。 **状态 3：检测工程与分析** * **活跃节点：** OPNsense、Ubuntu 26.04 (SIEM)。 * **离线节点：** Windows 10（受害机）、Kali Linux。 * **目标：** KQL 开发、威胁狩猎和通过 Kibana UI 进行验证。占用最低资源足迹。 ## 当前状态 | 组件 | 状态 | |------------|---------| | 网络隔离 | 运行中 | | OPNsense 路由 | 运行中 | | Docker 基础设施 | 运行中 | | Elasticsearch | 运行中 | | Kibana | 运行中 | | Logstash | 运行中 | | Winlogbeat | 运行中 | | Sysmon | 运行中 | | TLS Pipeline | 运行中 | | 检测工程 | 开发中 | | 威胁狩猎工作流 | 开发中 | | Zeek 集成 | 计划中 | | Suricata 集成 | 计划中 | ## 仓库结构 ``` blue-team-lab/ ├── README.md ├── LICENSE ├── .gitignore ├── configs/ | ├── network/ | │ ├── kali-static-binding.sh | │ ├── opnsense-pf-rulesets.md | │ └── ubuntu-00-installer-config.yaml | ├── siem/ | │ ├── .env.example | │ ├── beats-input.conf | │ ├── docker-compose.setup.yml | │ ├── docker-compose.yml | │ └── logstash-pipeline.conf | └── telemetry/ | ├── sysmonconfig.xml | └── winlogbeat.yml ├── docs/ │ ├── 00-prerequisites.md │ ├── 01-network-architecture-segmentation.md │ ├── 02-siem-infrastructure-deployment.md │ ├── 03-endpoint-telemetry-engineering.md │ └── 04-validation-detection-engineering.md └── scripts/ ├── host_network_override.ps1 ├── start_elastic.sh └── teardown_elastic.sh ``` ## 配置参考 ### 网络 - [Ubuntu Netplan](configs/network/ubuntu-00-installer-config.yaml) - [OPNsense 规则](configs/network/opnsense-pf-rulesets.md) ### SIEM - [docker-compose.yml](configs/siem/docker-compose.yml) - [docker-compose.yml](configs/siem/docker-compose.setup.yml) - [logstash-pipeline.conf](configs/siem/logstash-pipeline.conf) - [.env.example](configs/siem/.env.example) ### 遥测 - [winlogbeat.yml](configs/telemetry/winlogbeat.yml) - [sysmonconfig.xml](configs/telemetry/sysmonconfig.xml) ## 构建阶段 实验室通过四个主要的工程阶段进行部署。每个阶段都建立了后续阶段所需的基础能力。 ### 基础 — 前置条件 在开始部署之前，将验证所有必需的软件、操作系统、安装媒体和平台依赖项。 关键交付物： * 硬件验证 * VMware Workstation 安装 * 获取 OPNsense * 获取 Ubuntu Server * 获取 Windows 10 * 获取 Kali Linux * Elastic Stack 制品验证 文档： * `docs/00-prerequisites.md` ### 第一阶段 — 网络架构与隔离 此阶段建立隔离的网络架构，将攻击流量与遥测基础设施分离开来。 关键交付物： * VMnet2 摄取平面 * VMnet3 攻击平面 * OPNsense 部署 * 防火墙策略执行 * 静态网络配置 * 路由验证 * 网段间连通性测试 文档： * `docs/01-network-architecture-segmentation.md` ### 第二阶段 — SIEM 基础设施部署 此阶段部署负责收集、存储和可视化遥测数据的集中式分析平台。 关键交付物： * Ubuntu Server 准备 * Docker 安装 * TLS 证书生成 * Elasticsearch 部署 * Kibana 部署 * Logstash 部署 * 平台验证 文档： * `docs/02-siem-infrastructure-deployment.md` ### 第三阶段 — 端点遥测工程 此阶段将 Windows 端点连接到分析平台，并启用高保真遥测收集。 关键交付物： * Sysmon 安装 * Sysmon 配置 * Winlogbeat 部署 * TLS 连通性验证 * 索引创建 * Kibana Data Views * 遥测验证 文档： * `docs/03-endpoint-telemetry-engineering.md` ### 第四阶段 — 验证与检测工程 此阶段通过受控的攻击模拟和检测开发来验证遥测可见性。 关键交付物： * 攻击模拟 * 遥测验证 * KQL 开发 * 检测规则创建 * ATT&CK 映射 * 告警验证 文档： * `docs/04-validation-detection-engineering.md` ## 检测工程示例 **本地账户创建** * **MITRE 技术：** T1136.001 (Persistence) * **KQL 查询：** `event.code: "4720" and winlog.event_data.TargetUserName: *` **服务安装** * **MITRE 技术：** T1543.003 (Privilege Escalation / Persistence) * **KQL 查询：** `event.code: "7045" and winlog.event_data.ServiceName: *` **PowerShell 脚本执行** * **MITRE 技术：** T1059.001 (Execution) * **KQL 查询：** `event.code: "4104"` ## 工程挑战与解决方案 * **WSL2 端口冲突：** * *根本原因：* Windows 主机服务锁定了 SIEM 所需的关键摄取端口。 * *解决方案：* 弃用 WSL2；迁移到 VMware Type-2 hypervisor 以实现绝对的硬件抽象。 * **Hypervisor Kernel 死锁：** * *根本原因：* Windows 网络位置感知 (NLA) 和相同的接口指标导致了路由循环和 `vmnet.sys` 驱动程序故障。 * *解决方案：* 执行 PowerShell 覆盖命令，强制将 Interface Metric 设为 10，并显式禁用摄取适配器上的 NLA 过滤。 * **物理到虚拟的 MAC 对齐反转：** * *根本原因：* VMware PCI 枚举将 FreeBSD 的 `em1` 和 `em2` 接口交叉接线错了。 * *解决方案：* 在 OPNsense 控制台中手动反转接口分配，以恢复 Layer-2 的完整性。 * **摄取 Pipeline 中的 TLS SAN 不匹配：** * *根本原因：* Logstash 为 loopback 生成了证书，但 Winlogbeat 需要针对 LAN 网关 IP 进行验证。 * *解决方案：* 注入 `ssl.verification_mode: certificate` 以强制进行 CA 验证，同时绕过显式的主机名限制。 * **Logstash 编译悖论：** * *根本原因：* 在严格的 9.4.1 环境中使用传统的 8.x 语法，同时声明单向 TLS 约束。 * *解决方案：* 去除相互矛盾的参数，并使用 `ssl_client_authentication => "none"`。 * **易失性内存导致的遥测破坏：** * *根本原因：* 默认的 Beats 配置会在目标 SIEM 离线时丢弃本地队列。 * *解决方案：* 设计了异步磁盘缓冲 pipeline（`queue.disk: 1GB`），以在端点上缓冲 ECS 事件，直到 SIEM 恢复。 ## 关键经验 **培养的技术技能** - Hypervisor 网络和虚拟交换机设计 - OPNsense packet filter 和隔离 - 基于 Docker 的 Elastic Stack 部署 - Winlogbeat 和 Sysmon 集成 - TLS 加密的遥测 pipeline - ECS 规范化和 KQL 开发 - 检测工程和 ATT&CK 映射 **总结的工程教训** - 遥测质量直接影响检测质量。 - 大多数 SIEM 部署失败源于网络、TLS 或 schema 不匹配，而不是分析平台本身。 - Elastic 组件之间严格的版本对齐可显著减少摄取和映射问题。 - 当分析基础设施不可用时，端点侧缓冲变得至关重要。 - 在构建安全的引爆环境时，网络隔离比恶意软件的复杂程度更重要。 - 了解故障状态比盲目遵循部署说明更有价值。 ## 当前限制 - 单节点 Elastic 部署 - 无端点防御能力 - 无内存取证集成 - 无自动化恶意软件沙箱 - 无网络数据包捕获平台 - 无威胁情报富化 - 无集中式案例管理系统 这些限制是刻意的，代表了未来的扩展机会。 ## 未来增强计划 * **Elastic Agent 和 Fleet 集成：** 从传统的 Beats 过渡到统一的 agent 管理。 * **Zeek / Suricata NSM：** 在 OPNsense 核心部署网络安全监控 (NSM)，进行深度 L7 数据包检测。 * **Atomic Red Team：** 自动化执行本地化的 MITRE ATT&CK 技术。 * **Sigma 自动化：** 创建 CI/CD pipeline 以将 YAML 逻辑动态编译为 Elastic 规则。 * **威胁情报集成：** 摄取外部 MISP 数据源，以关联文件哈希和域名。 * **恶意软件分析扩展：** 通过在端点上集成 YARA 来整合动态内存扫描。 ## 安全提示 本仓库严格来说是一个结构化记录。所有基础设施状态均已做脱敏处理。这些配置中没有发布任何活跃的凭据、私人加密密钥或敏感的主机数据。强烈建议复制此架构的操作人员通过提供的 `.env` 模板生成自己的证书颁发机构 (CA) 和应用程序密码。 ## 许可证 该项目基于 MIT 许可证授权 - 有关详细信息，请参阅 ```/LICENSE``` 文件。 ## 作者 [Suman Mandal](https://linkedin.com/in/mandal-suman) 网络安全专业学生，专注于： - 检测工程 - SIEM 工程 - Linux 系统 - 数字取证 - 安全运营 - 防御性安全研究 本仓库记录了从零开始构建实用的检测工程环境过程中的工程决策、部署过程、故障、故障排除方法论和运营经验教训。
    
**一个基于 VMware、OPNsense、Elastic Stack、Sysmon 和 Winlogbeat 构建的严格隔离的恶意软件引爆、遥测工程和检测开发实验室。** 旨在研究完整的防御性安全生命周期：
攻击模拟 → 遥测收集 → 日志摄取 → 检测工程 → 威胁狩猎
    
**一个基于 VMware、OPNsense、Elastic Stack、Sysmon 和 Winlogbeat 构建的严格隔离的恶意软件引爆、遥测工程和检测开发实验室。** 旨在研究完整的防御性安全生命周期：
攻击模拟 → 遥测收集 → 日志摄取 → 检测工程 → 威胁狩猎
## 实验室摘要 本仓库作为一个严格隔离的防御性网络安全引爆实验室的工程蓝图和运营记录。为了促进端到端的安全运营，该基础设施实施了严格的 Layer-2 和 Layer-3 网络隔离。这将活跃的恶意软件执行限制在一个确定的爆炸半径内，同时维护了一个经过加密安全的异步遥测 pipeline，并接入本地化的 Elastic SIEM。 该项目旨在解决端点安全分析中的“黑盒”问题。通过从头开始构建摄取 pipeline、路由约束和分析引擎，操作人员可以绝对透彻地理解原始 kernel 遥测如何转化为可操作的 SIEM 检测。它既是检测工程师的功能测试场地，也是深层系统架构解决方案的文档化记录。 ## 构建内容 本项目实现了一个完全隔离的恶意软件引爆和检测工程环境，该环境基于 VMware Workstation、OPNsense、Ubuntu Server、Windows 10 和 Elastic Stack 构建。 **已实现的功能包括：** - 双段虚拟网络架构 - 基于 OPNsense 的流量分割 - TLS 加密的 Elastic Stack 部署 - Logstash Beats 摄取 pipeline - Winlogbeat 端点遥测转发 - Sysmon 遥测收集与富化 - 基于 ECS 规范化的事件存储 - Kibana 调查工作流 - 基于 KQL 的检测工程 - 对齐 MITRE ATT&CK 的验证测试 该环境旨在提供从攻击执行到检测生成的端到端可见性，同时维持严格的遏制边界。 ## 实验室存在的原因 许多安全实验室只专注于部署工具。 本项目侧重于理解整个遥测生命周期： 攻击执行 → 遥测生成 → 日志收集 → 数据传输 → 数据规范化 → 检测开发 → 威胁狩猎 每一个组件都经过了刻意的部署、配置、破坏、重建、验证和记录，以培养运营级别的理解，而不仅仅是流程上的熟练度。 ## 实验室目标 * **恶意软件引爆：** 在高度受控、严格隔离的网段中执行恶意 payload，以观察执行链，同时避免 hypervisor 的交叉污染。 * **遥测工程：** 配置和优化 kernel 级别的端点传感器，以捕获高保真度的执行上下文，避开标准操作系统的日志记录限制。 * **SIEM 工程：** 部署和管理零浪费、解耦的 Elastic Stack 基础设施，处理日志摄取、数据规范化和索引。 * **检测工程：** 将原始遥测数据转化为结构化、高信噪比的告警，从而明确识别对抗性行为。 * **威胁狩猎：** 交互式查询历史数据，以发现潜在的持久化机制和二级 payload 指标。 * **ATT&CK 映射：** 严格对照 MITRE ATT&CK 框架对齐所有生成的遥测数据和构建的检测，以实现标准化的战术分析。 ## 架构概述 该实验室构建在 Type-2 Hypervisor 基础之上，完全通过虚拟化的 packet filter 进行路由，以实施隔离。 * **VMware Workstation：** 作为 hypervisor 层，提供本地化的虚拟交换机结构（`VMnet2` 和 `VMnet3`）。 * **OPNsense（核心网关）：** 作为中央路由和防火墙引擎，明确控制主机、摄取平面和攻击平面之间的流量。 * **Ubuntu 26.04 LTS（SIEM 节点）：** 托管 Docker 容器化的 Elastic Stack，绑定到具有静态地址的摄取平面，以保证 pipeline 的稳定性。 * **Windows 10 Pro（受害机）：** 双宿主引爆目标。它通过攻击接口接收攻击，并通过防御接口将 Ring-0 遥测传输出去。 * **Kali Linux（攻击机）：** 对抗性模拟节点，严格隔离在攻击平面上，以防止横向移动回流到遥测或主机基础设施中。 ## 网络拓扑 ``` flowchart TD classDef attack fill:#3b0000,stroke:#ff4444,stroke-width:2px,color:#fff; classDef ingest fill:#00263b,stroke:#00aaff,stroke-width:2px,color:#fff; classDef infra fill:#1c1c1c,stroke:#888888,stroke-width:2px,color:#fff; classDef gateway fill:#4a2500,stroke:#ff8c00,stroke-width:2px,color:#fff; Internet(((Internet))):::infra subgraph Physical["Physical Infrastructure"] Host[Windows 11 Host]:::infra VMware[VMware Workstation Pro]:::infra end Internet <--> Host Host <--> VMware subgraph Virtual["Virtual Network Architecture"] OPN{{OPNsense Gateway
WAN + LAN + OPT1}}:::gateway subgraph VMNET3["VMnet3 - Attack Plane (192.168.60.0/24)"] Kali[Kali Linux
192.168.60.20]:::attack VictimAtk[Windows Victim NIC-2
192.168.60.10]:::attack end subgraph VMNET2["VMnet2 - Ingestion Plane (192.168.50.0/24)"] VictimDef[Windows Victim NIC-1
192.168.50.10]:::ingest SIEM[Ubuntu Server 26.04
Elastic Stack
192.168.50.50]:::ingest end end VMware <--> OPN OPN <--> Kali OPN <--> VictimAtk OPN <--> VictimDef OPN <--> SIEM Kali == "Exploit / Lateral Movement" ==> VictimAtk %% Internal SIEM / Pipeline Flow Overlaid VictimDef -. "Sysmon Logs" .-> Winlogbeat([Winlogbeat]):::ingest Winlogbeat -. "Beats TLS 5044" .-> Logstash([Logstash]):::ingest Logstash -. "ECS Events" .-> Elasticsearch[(Elasticsearch)]:::ingest Elasticsearch -. "Queries" .-> Kibana([Kibana]):::ingest Kibana -. "Detection Rules" .-> Alerts>Alerts]:::attack ``` ## 遥测流向 ``` flowchart LR classDef attack fill:#3b0000,stroke:#ff4444,stroke-width:2px,color:#fff; classDef windows fill:#003366,stroke:#0088cc,stroke-width:2px,color:#fff; classDef sensor fill:#004d40,stroke:#00bfa5,stroke-width:2px,color:#fff; classDef siem fill:#00263b,stroke:#00aaff,stroke-width:2px,color:#fff; classDef alert fill:#5c0000,stroke:#ff0000,stroke-width:2px,color:#fff; subgraph Adversary ["Attack Simulation"] Attack((Kali Linux)):::attack end subgraph Endpoint ["Victim Endpoint (Windows 10)"] Victim[OS Execution Context]:::windows Sysmon[[Sysmon Driver]]:::sensor EventLog[[Windows Event Log]]:::sensor Winlogbeat([Winlogbeat + Disk Queue]):::sensor end subgraph SIEM_Pipeline ["Elastic SIEM Pipeline"] Logstash([Logstash Node
TLS 5044]):::siem Elastic[(Elasticsearch Cluster)]:::siem Kibana([Kibana Interface]):::siem end subgraph SOC ["Detection & Response"] Detection{Detection Rules}:::alert Alert((Alert Generation)):::alert end Attack == "Malicious Payloads" ==> Victim Victim -- "Kernel Telemetry" --> Sysmon Victim -- "OS Telemetry" --> EventLog Sysmon -- "Event ID 1, 3, etc." --> Winlogbeat EventLog -- "Security/System Logs" --> Winlogbeat Winlogbeat == "Asynchronous Forwarding" ==> Logstash Logstash -- "Data Normalization / ECS" --> Elastic Elastic -- "KQL Search" --> Kibana Kibana -. "Continuous Evaluation" .-> Detection Detection == "Rule Triggered" ==> Alert ``` ## 技术栈 | 层级 | 技术 | 版本 | 用途 | | --- | --- | --- | --- | | **Hypervisor** | VMware Workstation | 17.x Pro | 硬件虚拟化和虚拟交换机结构配置。 | | **网关 / 防火墙** | OPNsense | 24.1 | Layer-3/Layer-4 边界执行和爆炸半径遏制。 | | **摄取 OS** | Ubuntu Server LTS | 26.04 | 用于执行 Docker daemon 的稳定、无头的 Linux 环境。 | | **目标 OS** | Windows 10 Pro | 22H2 | 主要引爆目标和 Windows 子系统遥测源。 | | **攻击 OS** | Kali Linux | 2024.x | 用于对抗性模拟和 payload 投递的执行节点。 | | **分析引擎** | Elasticsearch | 9.4.1 | 通过 REST API 进行分布式搜索、存储和数据查询。 | | **可视化** | Kibana | 9.4.1 | 用于数据探索、执行 KQL 查询和仪表盘的 Web 界面。 | | **摄取 Pipeline** | Logstash | 9.4.1 | 服务端数据处理、ECS 规范化和 SSL 终止。 | | **Agent 管理** | Fleet Server | 9.4.1 | 为未来集成 Elastic Agent 提供集中化管理。 | | **端点转发器** | Winlogbeat | 9.4.1 | 具有异步磁盘缓冲功能的轻量级 Windows 事件转发器。 | | **Kernel 传感器** | Sysmon | 15.x | 系统监控器，为进程和网络活动提供高级事件追踪。 | ## 已验证能力 | 能力 | 状态 | |------------|---------| | VMware 网络隔离 | 已验证 | | OPNsense 路由和防火墙 | 已验证 | | Docker 化的 Elastic 部署 | 已验证 | | TLS 加密的 Beats 摄取 | 已验证 | | Winlogbeat 遥测收集 | 已验证 | | Sysmon 事件收集 | 已验证 | | ECS 数据规范化 | 已验证 | | Kibana 调查工作流 | 已验证 | | KQL 检测开发 | 已验证 | | ATT&CK 技术验证 | 已验证 | ## 平台预览 ### Elastic Security 概览 TODO: 截图 ### Kibana 仪表盘 TODO: 截图 ### Sysmon 遥测 TODO: 截图 ### 检测规则 TODO: 截图 ## 架构原则 ### 隔离优先 攻击基础设施绝对不能与分析基础设施直接通信。 ### 检测之前先看遥测 检测质量受制于遥测质量。 ### 显式路由 所有流量路径均通过 OPNsense 明确定义。 ### 版本对齐 Elastic Stack 和遥测 agent 保持版本对齐，以防止 schema 漂移。 ### 故障记录 故障被视为工程资产，并记录其根本原因分析和修复程序。 ## 核心工程决策 * **选择 VMware Workstation 而非 WSL2：** 初始迭代尝试了 WSL2 镜像网络配置。由于无法解决的主机级 kernel 端口冲突（例如，主机 `svchost.exe` 锁定端口 9200）以及在执行严格的 Layer-2 隔离方面的限制，该方案被放弃。VMware 允许对子网进行绝对严格的分离。 * **选择 OPNsense 作为核心路由：** 采用它是为了防止动态的 hypervisor 路由变量。它提供自上而下的、显式的爆炸半径控制，确保在受害机能够与 SIEM 通信的同时，攻击机在摄取基础设施中保持完全的黑洞状态。 * **选择 Elastic Stack 进行分析：** 选择它是由于其行业标准查询语言 (KQL)、高度灵活的 Elastic Common Schema (ECS) 和强大的 Detection Engine，这与现代安全运营中心 (SOC) 运营和 MITRE ATT&CK 映射完美契合。 * **选择 Sysmon 进行遥测：** 标准的 Windows 事件日志缺乏高级检测所需的深层执行上下文。集成 Sysmon 是为了捕获 Ring-0 进程创建树、内存注入和确定性的进程到网络 callback 映射。 ## 实验室能力 * **恶意软件引爆：** 在受控状态下安全执行活跃的二进制文件和脚本。 * **遥测收集：** 将端点数据端到端路由到集中式数据湖。 * **Sysmon 监控：** 深入观察 kernel callback 和进程创建。 * **检测开发：** 迭代创建逻辑规则以捕获特定的恶意技术。 * **威胁狩猎：** 主动查询原始数据流以验证假设。 * **KQL 开发：** Kibana 查询语言在数据提取中的实际应用。 * **Sigma 开发：** 针对 Elastic 后端的后端无关检测规则编译。 * **ATT&CK 映射：** 将原始数据与已知的对手攻击剧本结合进行上下文分析。 * **安全事件分析：** 将不同的事件关联成一个紧密的事件时间线。 ## 异步运行状态（资源优化） 此架构设计为按顺序执行。为了绕过硬件限制（例如 16GB RAM 限制），实验室在三个独立且隔离的阶段中运行。遥测 pipeline 利用 `queue.disk` 缓冲来保证状态转换之间数据的零丢失。 **状态 1：引爆与遏制** * **活跃节点：** OPNsense、Windows 10（受害机）、Kali Linux。 * **离线节点：** Ubuntu 26.04 (SIEM)。 * **目标：** 执行 payload。Winlogbeat 将所有 ECS 遥测数据本地缓冲到受害机的物理磁盘上。 **状态 2：摄取与同步** * **活跃节点：** OPNsense、Windows 10（受害机）、Ubuntu 26.04 (SIEM)。 * **离线节点：** Kali Linux。 * **目标：** 遥测清空。受害机与 Logstash 建立 TLS 会话，并将物理磁盘队列排空至 Elasticsearch 中。 **状态 3：检测工程与分析** * **活跃节点：** OPNsense、Ubuntu 26.04 (SIEM)。 * **离线节点：** Windows 10（受害机）、Kali Linux。 * **目标：** KQL 开发、威胁狩猎和通过 Kibana UI 进行验证。占用最低资源足迹。 ## 当前状态 | 组件 | 状态 | |------------|---------| | 网络隔离 | 运行中 | | OPNsense 路由 | 运行中 | | Docker 基础设施 | 运行中 | | Elasticsearch | 运行中 | | Kibana | 运行中 | | Logstash | 运行中 | | Winlogbeat | 运行中 | | Sysmon | 运行中 | | TLS Pipeline | 运行中 | | 检测工程 | 开发中 | | 威胁狩猎工作流 | 开发中 | | Zeek 集成 | 计划中 | | Suricata 集成 | 计划中 | ## 仓库结构 ``` blue-team-lab/ ├── README.md ├── LICENSE ├── .gitignore ├── configs/ | ├── network/ | │ ├── kali-static-binding.sh | │ ├── opnsense-pf-rulesets.md | │ └── ubuntu-00-installer-config.yaml | ├── siem/ | │ ├── .env.example | │ ├── beats-input.conf | │ ├── docker-compose.setup.yml | │ ├── docker-compose.yml | │ └── logstash-pipeline.conf | └── telemetry/ | ├── sysmonconfig.xml | └── winlogbeat.yml ├── docs/ │ ├── 00-prerequisites.md │ ├── 01-network-architecture-segmentation.md │ ├── 02-siem-infrastructure-deployment.md │ ├── 03-endpoint-telemetry-engineering.md │ └── 04-validation-detection-engineering.md └── scripts/ ├── host_network_override.ps1 ├── start_elastic.sh └── teardown_elastic.sh ``` ## 配置参考 ### 网络 - [Ubuntu Netplan](configs/network/ubuntu-00-installer-config.yaml) - [OPNsense 规则](configs/network/opnsense-pf-rulesets.md) ### SIEM - [docker-compose.yml](configs/siem/docker-compose.yml) - [docker-compose.yml](configs/siem/docker-compose.setup.yml) - [logstash-pipeline.conf](configs/siem/logstash-pipeline.conf) - [.env.example](configs/siem/.env.example) ### 遥测 - [winlogbeat.yml](configs/telemetry/winlogbeat.yml) - [sysmonconfig.xml](configs/telemetry/sysmonconfig.xml) ## 构建阶段 实验室通过四个主要的工程阶段进行部署。每个阶段都建立了后续阶段所需的基础能力。 ### 基础 — 前置条件 在开始部署之前，将验证所有必需的软件、操作系统、安装媒体和平台依赖项。 关键交付物： * 硬件验证 * VMware Workstation 安装 * 获取 OPNsense * 获取 Ubuntu Server * 获取 Windows 10 * 获取 Kali Linux * Elastic Stack 制品验证 文档： * `docs/00-prerequisites.md` ### 第一阶段 — 网络架构与隔离 此阶段建立隔离的网络架构，将攻击流量与遥测基础设施分离开来。 关键交付物： * VMnet2 摄取平面 * VMnet3 攻击平面 * OPNsense 部署 * 防火墙策略执行 * 静态网络配置 * 路由验证 * 网段间连通性测试 文档： * `docs/01-network-architecture-segmentation.md` ### 第二阶段 — SIEM 基础设施部署 此阶段部署负责收集、存储和可视化遥测数据的集中式分析平台。 关键交付物： * Ubuntu Server 准备 * Docker 安装 * TLS 证书生成 * Elasticsearch 部署 * Kibana 部署 * Logstash 部署 * 平台验证 文档： * `docs/02-siem-infrastructure-deployment.md` ### 第三阶段 — 端点遥测工程 此阶段将 Windows 端点连接到分析平台，并启用高保真遥测收集。 关键交付物： * Sysmon 安装 * Sysmon 配置 * Winlogbeat 部署 * TLS 连通性验证 * 索引创建 * Kibana Data Views * 遥测验证 文档： * `docs/03-endpoint-telemetry-engineering.md` ### 第四阶段 — 验证与检测工程 此阶段通过受控的攻击模拟和检测开发来验证遥测可见性。 关键交付物： * 攻击模拟 * 遥测验证 * KQL 开发 * 检测规则创建 * ATT&CK 映射 * 告警验证 文档： * `docs/04-validation-detection-engineering.md` ## 检测工程示例 **本地账户创建** * **MITRE 技术：** T1136.001 (Persistence) * **KQL 查询：** `event.code: "4720" and winlog.event_data.TargetUserName: *` **服务安装** * **MITRE 技术：** T1543.003 (Privilege Escalation / Persistence) * **KQL 查询：** `event.code: "7045" and winlog.event_data.ServiceName: *` **PowerShell 脚本执行** * **MITRE 技术：** T1059.001 (Execution) * **KQL 查询：** `event.code: "4104"` ## 工程挑战与解决方案 * **WSL2 端口冲突：** * *根本原因：* Windows 主机服务锁定了 SIEM 所需的关键摄取端口。 * *解决方案：* 弃用 WSL2；迁移到 VMware Type-2 hypervisor 以实现绝对的硬件抽象。 * **Hypervisor Kernel 死锁：** * *根本原因：* Windows 网络位置感知 (NLA) 和相同的接口指标导致了路由循环和 `vmnet.sys` 驱动程序故障。 * *解决方案：* 执行 PowerShell 覆盖命令，强制将 Interface Metric 设为 10，并显式禁用摄取适配器上的 NLA 过滤。 * **物理到虚拟的 MAC 对齐反转：** * *根本原因：* VMware PCI 枚举将 FreeBSD 的 `em1` 和 `em2` 接口交叉接线错了。 * *解决方案：* 在 OPNsense 控制台中手动反转接口分配，以恢复 Layer-2 的完整性。 * **摄取 Pipeline 中的 TLS SAN 不匹配：** * *根本原因：* Logstash 为 loopback 生成了证书，但 Winlogbeat 需要针对 LAN 网关 IP 进行验证。 * *解决方案：* 注入 `ssl.verification_mode: certificate` 以强制进行 CA 验证，同时绕过显式的主机名限制。 * **Logstash 编译悖论：** * *根本原因：* 在严格的 9.4.1 环境中使用传统的 8.x 语法，同时声明单向 TLS 约束。 * *解决方案：* 去除相互矛盾的参数，并使用 `ssl_client_authentication => "none"`。 * **易失性内存导致的遥测破坏：** * *根本原因：* 默认的 Beats 配置会在目标 SIEM 离线时丢弃本地队列。 * *解决方案：* 设计了异步磁盘缓冲 pipeline（`queue.disk: 1GB`），以在端点上缓冲 ECS 事件，直到 SIEM 恢复。 ## 关键经验 **培养的技术技能** - Hypervisor 网络和虚拟交换机设计 - OPNsense packet filter 和隔离 - 基于 Docker 的 Elastic Stack 部署 - Winlogbeat 和 Sysmon 集成 - TLS 加密的遥测 pipeline - ECS 规范化和 KQL 开发 - 检测工程和 ATT&CK 映射 **总结的工程教训** - 遥测质量直接影响检测质量。 - 大多数 SIEM 部署失败源于网络、TLS 或 schema 不匹配，而不是分析平台本身。 - Elastic 组件之间严格的版本对齐可显著减少摄取和映射问题。 - 当分析基础设施不可用时，端点侧缓冲变得至关重要。 - 在构建安全的引爆环境时，网络隔离比恶意软件的复杂程度更重要。 - 了解故障状态比盲目遵循部署说明更有价值。 ## 当前限制 - 单节点 Elastic 部署 - 无端点防御能力 - 无内存取证集成 - 无自动化恶意软件沙箱 - 无网络数据包捕获平台 - 无威胁情报富化 - 无集中式案例管理系统 这些限制是刻意的，代表了未来的扩展机会。 ## 未来增强计划 * **Elastic Agent 和 Fleet 集成：** 从传统的 Beats 过渡到统一的 agent 管理。 * **Zeek / Suricata NSM：** 在 OPNsense 核心部署网络安全监控 (NSM)，进行深度 L7 数据包检测。 * **Atomic Red Team：** 自动化执行本地化的 MITRE ATT&CK 技术。 * **Sigma 自动化：** 创建 CI/CD pipeline 以将 YAML 逻辑动态编译为 Elastic 规则。 * **威胁情报集成：** 摄取外部 MISP 数据源，以关联文件哈希和域名。 * **恶意软件分析扩展：** 通过在端点上集成 YARA 来整合动态内存扫描。 ## 安全提示 本仓库严格来说是一个结构化记录。所有基础设施状态均已做脱敏处理。这些配置中没有发布任何活跃的凭据、私人加密密钥或敏感的主机数据。强烈建议复制此架构的操作人员通过提供的 `.env` 模板生成自己的证书颁发机构 (CA) 和应用程序密码。 ## 许可证 该项目基于 MIT 许可证授权 - 有关详细信息，请参阅 ```/LICENSE``` 文件。 ## 作者 [Suman Mandal](https://linkedin.com/in/mandal-suman) 网络安全专业学生，专注于： - 检测工程 - SIEM 工程 - Linux 系统 - 数字取证 - 安全运营 - 防御性安全研究 本仓库记录了从零开始构建实用的检测工程环境过程中的工程决策、部署过程、故障、故障排除方法论和运营经验教训。
标签：DAST, Docker Compose, Elastic SIEM, MIT许可证, OPNsense, 内容过滤, 安全实验室, 恶意软件分析, 版权保护, 越狱测试