s-baiaman/wazuh-siem-lab

GitHub: s-baiaman/wazuh-siem-lab

一个基于 Wazuh 4.14 的家庭 SOC 实验室项目,演示跨平台端点威胁检测、自定义检测规则编写及自动化事件响应的完整流程。

Stars: 0 | Forks: 0

# 家庭 SOC 实验室 — Wazuh SIEM 多 Agent 监控与自动化响应 一个从零开始搭建的实战型安全运营中心 (SOC) 实验室,使用 **Wazuh 4.14**(开源 SIEM/XDR)。本项目演示了跨 Linux 和 Windows 端点的端到端威胁检测、自定义检测工程以及自动化事件响应。 ## 目录 - [概述](#overview) - [架构](#architecture) - [展示技能](#skills-demonstrated) - [实验室设置](#lab-setup) - [检测场景](#detection-scenarios) - [1. SSH 暴力破解 (Linux)](#1-ssh-brute-force-linux) - [2. 文件完整性监控 (Linux)](#2-file-integrity-monitoring-linux) - [3. 自定义检测规则](#3-custom-detection-rule) - [4. Windows 登录失败检测](#4-windows-failed-logon-detection) - [5. 自动化主动响应](#5-automated-active-response) - [MITRE ATT&CK 覆盖范围](#mitre-attck-coverage) - [故障排除笔记](#troubleshooting-notes) - [关键要点](#key-takeaways) ## 概述 该实验室的目标是构建一个功能齐全的微型 SOC,并使用它来检测、分析和自动响应模拟攻击。重点不仅仅是安装工具,而是**理解检测 pipeline**(原始日志 -> 解码器 -> 规则 -> 警报)、在字段级别阅读警报、编写自定义检测逻辑以及配置自动化响应。 **本实验室涵盖的内容:** - 以 all-in-one 配置部署完整的 Wazuh 技术栈(Indexer、Server、Dashboard) - 通过 Wazuh agent 接入 Windows 端点(多 agent 架构) - 模拟真实攻击技术并分析生成的警报 - 编写带有严重级别升级的自定义检测规则 - 配置 Active Response 以自动阻止攻击者 IP - 将检测结果映射到 MITRE ATT&CK 框架 ## 架构 ``` Host-only network (192.168.56.0/24) ┌────────────────────────┐ ┌────────────────────────┐ │ WIN10-VICTIM │ │ SIEM-LAB (Ubuntu) │ │ 192.168.56.102 │ agent → server │ 192.168.56.101 │ │ │─────────────────────>│ │ │ Wazuh Agent (001) │ events / logs │ Wazuh Server (000) │ │ Windows Event Logs │ │ Wazuh Indexer │ │ │ │ Wazuh Dashboard │ └────────────────────────┘ └────────────────────────┘ ▲ │ HTTPS :443 ┌──────┴────────┐ │ Host browser │ │ (analyst) │ └───────────────┘ Data flow: Agents collect logs → Server decodes and applies detection rules → matched events become alerts → → Indexer stores them → Dashboard visualizes them for the analyst. ``` | 组件 | 角色 | |-----------|------| | Wazuh Agent | 从端点收集日志和安全事件 | | Wazuh Server | 解码日志、应用规则、生成警报、运行 Active Response | | Wazuh Indexer | 存储并索引警报(基于 OpenSearch) | | Wazuh Dashboard | 用于调查和可视化的 Web 界面 | ## 展示技能 - **SIEM 管理** — 完整的 Wazuh 部署和配置 - **日志分析与警报分类** — 在字段级别阅读警报(解码器、提取的字段、严重级别) - **检测工程** — 使用 `if_sid` 继承和严重级别调整编写自定义规则 - **多平台监控** — Linux 和 Windows 端点 - **事件响应自动化** — 使用基于防火墙阻止的 Active Response - **MITRE ATT&CK 映射** — 将检测结果与对手技术对齐 - **故障排除** — 在真实条件下诊断磁盘、网络和服务问题 ## 实验室设置 **环境** - Wazuh server:Ubuntu 24.04 虚拟机(4 GB 内存,60 GB 磁盘),all-in-one 安装 - 端点:Windows 10 虚拟机,已安装 Wazuh agent - 网络:VirtualBox NAT(互联网)+ Host-only 适配器(`192.168.56.0/24`),用于隔离的 server↔agent↔分析师通信 **服务器安装:** ``` curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh && sudo bash ./wazuh-install.sh -a ``` 通过主机浏览器访问 `https://192.168.56.101` 上的 Dashboard,从而让资源有限的虚拟机免于运行浏览器。 ## 检测场景 ### 1. SSH 暴力破解 (Linux) **模拟攻击:** 使用不存在的用户对服务器进行反复的 SSH 登录失败尝试。 ``` for i in {1..10}; do sshpass -p 'qwertyiop123' ssh -o StrictHostKeyChecking=no hacker@192.168.56.101; done ``` **检测:** Wazuh 根据频率关联了各个失败尝试,并触发了 **rule 5712**(*"sshd: brute force trying to get access to the system"*),级别为 **level 10**。单次尝试在 level 5 触发;一旦达到频率阈值(8 个事件),就会触发升级到 level 10 —— 这展示了事件关联,而不仅仅是单行匹配。 **警报内部信息(来自解码后的事件):** - `decoder.name: sshd` → 从原始日志中提取了 `data.srcip` 和 `data.srcuser` - `rule.frequency: 8` → 所需的关联事件数 - `rule.mitre.id: T1110` (Brute Force) ### 2. 文件完整性监控 (Linux) **设置:** 在一个包含类似凭据配置的受保护目录上配置了实时 FIM。 ``` /etc/critical-files ``` **模拟攻击:** 修改、创建和删除受监控目录中的文件。 **检测:** Wazuh 对每个操作触发了不同的规则 —— **added** (554)、**modified** (550)、**deleted** (553)。`modified` 警报通过加密方式证明了篡改: ``` File '/etc/critical-files/config.conf' modified Mode: realtime Size changed from '27' to '35' Old md5sum was: 'cd9a6939531b5ac177577271a0a59138' New md5sum is: 'd6ce9370c7593e4c4062ef96cabc2ab1' ``` 映射到 **T1565.001** (Stored Data Manipulation)。前后的哈希值比较是核心机制 —— 文件更改无法逃避加密哈希的检测,但可以通过伪造大小/时间戳来隐藏。 ### 3. 自定义检测规则 **目标:** 默认的 FIM 规则将 *任何* 文件更改都指定为 level 7。由于 `config.conf` 包含凭据,因此对其的任何更改都应被视为高严重级别的事件。我编写了一条自定义规则,它继承了基础 FIM 规则并提升了严重级别。 ``` 550 /etc/critical-files/config.conf CRITICAL: protected credential file (config.conf) was modified T1565.001 ``` **工作原理:** `550` 将该规则链接到现有的 FIM 检测中,而 `` 条件将其范围缩小到特定文件。这是真正的检测工程实践 —— 使用组织特定的上下文来扩展内置逻辑,而不是复制它。结果是:现在对该文件的修改会在 **level 12** 触发,并显示在 "Level 12+" 关键视图中。 ### 4. Windows 登录失败检测 **设置:** 将 Wazuh agent 部署到 Windows 10 虚拟机(agent `001`,`WIN10-VICTIM`),收集 Windows Event Logs。这建立了一个真正的多 agent 架构 —— 针对独立端点的攻击会显示在中央服务器上。 **模拟攻击:** 通过 `runas` 使用不存在的用户进行登录失败尝试。 ``` runas /user:hacker cmd ``` **检测:** Wazuh 捕获了 **Windows Event ID 4625**(登录失败)。Windows 遥测数据比单行 Linux 日志要丰富得多: - `data.win.eventdata.logonType: 2` (interactive logon) - `data.win.eventdata.targetUserName: hacker` - `data.win.eventdata.subStatus: 0xc0000064` (user does not exist) `subStatus` 代码具有分析价值 —— `0xc0000064` 表示用户名不存在(盲目猜测),而 `0xc000006a` 则表示用户名 *有效* 但密码错误(攻击者知道真实存在的账户 —— 更危险)。 ### 5. 自动化主动响应 **目标:** 从被动检测转向自动化响应 —— 自动阻止暴力破解攻击者。 ``` firewall-drop local 5712 180 ``` **测试:** 从 Windows 端点向服务器发起了 SSH 暴力破解。事件序列讲述了完整的事件经过: ``` 20:16:30–20:17:04 sshd: Attempt to login using a non-existent user (rule 5710, lvl 5) 20:17:08 sshd: brute force ... (rule 5712, lvl 10) ← trigger 20:17:10 Host Blocked by firewall-drop Active Response (rule 651) ← auto-response (~2s later) ``` **验证(三个独立的证明):** 1. **Dashboard** — 触发了 `Host Blocked by firewall-drop Active Response` 事件 2. **攻击者端** — SSH 会话在攻击中途断开,提示 `Connection timed out`,随后的 `ping` 返回了 `Request timed out` 3. **服务器端** — 自动为 `192.168.56.102` 创建了 iptables `DROP` 规则 在 180 秒超时后,Wazuh 自动解除了阻止并恢复了连接 —— 无需人工干预即可完成完整的 **检测 → 阻止 → 恢复** 循环。 ## MITRE ATT&CK 覆盖范围 该实验室在多种战术中产生了检测结果,而不是单一战术的变体: | 检测 | 技术 | 战术 | |-----------|-----------|--------| | SSH 暴力破解 | T1110 – Brute Force | Credential Access | | Windows 登录失败 | T1110 – Brute Force | Credential Access | | 文件修改 (FIM) | T1565.001 – Stored Data Manipulation | Impact | | 自定义凭据文件规则 | T1565.001 – Stored Data Manipulation | Impact | *附加内容:* Wazuh 的 Vulnerability Detection 模块自动清点了 Windows 主机上安装的软件,并将其与 CVE 数据库进行了交叉比对 —— 展示了伴随威胁检测的漏洞管理。 ## 故障排除笔记 遇到并解决的实际问题(调试也是该技能的一部分): - **安装失败 — 磁盘已满。** 初始的 25 GB 虚拟磁盘在安装 Dashboard 期间被填满(`dpkg: disk full`)。通过 `/var/log/wazuh-install.log` 进行诊断,通过扩展 VDI 并扩容分区(`growpart` + `resize2fs`)解决。最初,过期的 VirtualBox 快照阻止了调整大小(delta disk),必须先将其合并。 - **时间范围陷阱。** Dashboard 上的 "No results" 反复出现,这是由折叠的时间过滤器而不是数据缺失引起的 —— 这是一个很好的教训,即信任 pipeline 并检查查询窗口。 - **Windows 虚拟机性能。** 减少了分配的 CPU 核心(过度分配会降低调度性能)并提高了显存以稳定客户机。 ## 关键要点 - SIEM 的价值在于 **分析 pipeline**,而不是安装 —— 了解解码器如何提取字段以及规则如何按频率关联事件,是区分操作工具与理解工具的关键。 - **严重级别调整很重要。** 大多数事件都是低级别的背景噪音(level 3–5);过滤 `rule.level:>=10` 是分析师将数千条日志缩减为重要内容的方法。 - **检测工程** —— 使用特定于环境的上下文来扩展现有规则,这是一种高杠杆、低投入的方法,能让检测变得有意义。 - **自动化响应** 闭环了从检测到防御的过程,但必须仔细界定范围,以避免阻止合法访问。
标签:AMSI绕过, HTTP工具, Wazuh, x64dbg, 威胁检测, 安全实验室, 安全运营中心, 网络映射, 自动化响应