malathi-cyber-sketch/wazuh-sysmon-siem-home-lab

# Wazuh + Sysmon SIEM 家庭实验室          我搭建的一个小型 SIEM 环境，目的是真正在实践中理解“端点监控”的含义，而不是纸上谈兵。Wazuh manager 在 Kali 上通过 Docker 运行，一台 Windows 10 机器作为被监控的端点，Sysmon 为其提供详细的遥测数据，然后我攻击自己的机器，看看这套系统是否真的能捕捉到什么。 简短的回答是：确实捕捉到了。详细的说明在下面。 ## 为什么做这个 每一个 SOC 分析师的招聘启事都把“SIEM 经验”列为要求，而每一门课程都只是教你阅读别人已经生成的告警。我想自己构建这条 pipeline —— 安装它、破坏它、修复它、攻击它，然后阅读我自己的告警 —— 这样我才能真正理解仪表板背后发生了什么，而不是仅仅认得那个 UI 界面。 我选择使用 Docker 部署 Wazuh manager，而不是裸机安装程序，主要是因为我觉得这样启动得更快。确实如此，但也并非完全如此 —— 下文会详细说明。 ## 实验室包含什么 - **Wazuh Manager** —— Kali Linux，通过 `docker-compose` 部署，Wazuh 4.7.5 - **Windows 10 端点** —— Wazuh Agent 4.7.5 + Sysmon 15.21 (SwiftOnSecurity config) - **攻击机** —— 同一台 Kali 机器，用于针对 Windows 目标进行 Hydra 暴力破解尝试和 Nmap 扫描 ``` [Kali - Wazuh Manager (Docker)] <---- monitors ----> [Windows 10 - Agent + Sysmon] | └── also used to attack the Windows box (Hydra, Nmap) ``` 所有设备都位于 `192.168.100.0/24` 的仅主机 (host-only) 网络上。Manager 地址为 `.3`，Windows 目标地址为 `.4`。 ## 阶段 1 — 让网络互通 **工具：** `ipconfig`, `ping` 在完全接触 Wazuh 之前，我只是检查了一下这两台机器是否真的能互相通信。这很基础，但跳过这一步正是导致你之后调试错误方向的原因。 ``` C:\Windows\system32>ping 192.168.100.3 Reply from 192.168.100.3: bytes=32 time<1ms TTL=64 ``` 发送了 4 个数据包，0% 丢失。很好，继续下一步。   ## 阶段 2 — 使用 Docker 搭建 Wazuh Manager **工具：** Docker, `docker-compose` 我拉取了官方的 `wazuh-docker` 单节点仓库并直接运行。 ``` cd wazuh-docker/single-node docker-compose up -d docker ps ``` 创建了 17 个卷，在不到一秒的时间内启动了 3 个容器 —— indexer、manager 和 dashboard。 ``` single-node-wazuh.indexer-1 Up single-node-wazuh.manager-1 Up single-node-wazuh.dashboard-1 Up ```  说实话，与我对之前手动安装的记忆相比，这部分感觉太容易了。这种感觉并没有持续太久。 *（旁注 —— 我之前也曾在 Kali 上直接尝试过手动运行 `wazuh-install.sh -a` 的方式，因为 Kali 并不在 Wazuh 官方支持的操作系统列表中。必须加上 `--ignore-check` 运行才能跳过操作系统检查，实际上它顺利完成安装了。不过我还是保留了 Docker 版本作为主要的环境设置，因为当我弄坏某些东西时，它更容易推倒重建。）*  ## 阶段 3 — 打开仪表板 **工具：** 浏览器, Wazuh Dashboard 使用安装脚本在最后输出的管理员凭据登录 `https://192.168.100.3`。第一次查看仪表板：代理摘要显示“无结果”，一条黄色的横幅告诉我还没有添加任何代理。这很合理 —— 我确实还没添加。 这就是在截图中看起来令人印象深刻，但如果没有任何实际的端点汇报数据，它实际上毫无意义的部分。我想指出这一点，因为很多“SIEM 实验室”的教程写到这就停了，好像这就是终点线。但这其实只是起跑线。  ## 阶段 4 — 注册 Windows 10 代理 **工具：** `manage_agents` (Wazuh 内置的 CLI，在 manager 容器内运行) 这就是 Docker 让事情变得稍微有点烦人的地方 —— 代理管理工具不是图形界面的，你必须在正在运行的容器内执行它。 ``` (A)dd an agent (A) Please provide the following: * A name for the new agent: windows10 * The IP Address of the new agent: 192.168.100.4 Confirm adding it? (y/n): y Agent added with ID 001. ```   然后提取该代理 ID 的密钥： ``` (E)xtract key for an agent Provide the ID of the agent to extract the key: 001 Agent key information for '001' is: MDAxIHdpbmRvd3MxMCAxOTIuMTY4LjEwMC40IGY4Y... ```  将该密钥粘贴到 Windows 端的 Wazuh Agent 应用程序中，点击保存，点击启动。状态随即变为 **Running**。 ``` Agent: windows10 (001) - 192.168.100.4 Status: Running ```  也从 manager 端进行了验证： ``` docker exec -it single-node-wazuh.manager-1 /var/ossec/bin/agent_control -l ``` ``` ID: 001, Name: windows10, IP: 192.168.100.4, Active ``` 代理已上线。但这并不意味着它已经派上用场了 —— 一个基础的代理会汇报系统信息，但我想要的是真正的进程级遥测数据，这就意味着需要 Sysmon。 ## 阶段 5 — 安装 Sysmon **工具：** Sysinternals Sysmon + SwiftOnSecurity 的社区 config Sysmon 记录进程创建、网络连接和文件活动的细节远比默认的 Windows 事件日志详细得多。但它需要一个 config 文件才能真正发挥作用 —— 默认的 config 几乎不记录任何内容。 ``` C:\Users\admin\Downloads\Sysmon>Sysmon64.exe -accepteula -i sysmonconfig-export.xml ``` 一个小麻烦：解压后下载的文件变成了 `Sysmon.exe`, `Sysmon64.exe`, 和 `Sysmon64a.exe` —— 我最初在还没有 `cd` 进入正确文件夹的情况下尝试运行 `Sysmon64.exe`，并收到了“未识别”的错误。新手的错误，在我检查了 `dir` 之后大约十秒钟就修复了。  验证它确实已经安装并启动： ``` wevtutil qe Microsoft-Windows-Sysmon/Operational /c:5 /f:text ``` ``` Event ID: 16 — Sysmon config state changed Configuration: C:\Users\admin\Downloads\sysmonconfig-export.xml Event ID: 4 — Sysmon service state changed: Started ``` Config 已加载，服务正在运行，哈希值已确认。很好。   ## 阶段 6 — 让 Wazuh 真正读取 Sysmon 日志 **工具：** `ossec.conf` (Wazuh 代理 config) 这一步很容易被忽略，然后你就会纳闷为什么仪表板里什么都没显示。Wazuh 代理默认并不知道要转发 Sysmon 的事件日志 —— 你必须明确告诉它。 将此代码块添加到 `C:\Program Files (x86)\ossec-agent\ossec.conf` 中： ``` Microsoft-Windows-Sysmon/Operational eventchannel ``` 重启了服务： ``` net stop WazuhSvc net start WazuhSvc ``` 也是在这个时候，我遇到了整个项目中比较令人困惑的 bug 之一 —— 重启后代理立即显示为已断开连接，并且 Sysmon 事件根本没有在仪表板中显示（`rule.groups: sysmon` → 未找到结果）。我花了一些时间检查服务状态、事件日志，并再次检查了 config 文件，之后干脆把所有东西又重启了一遍。它自己就恢复了。我至今没有一个干净利落的解释 —— 我最好的猜测是，服务在 config 重新加载后需要一点时间向 manager 重新注册，但我没有深入挖掘去证实这一点。   ## 阶段 7 — 真正攻击目标 **工具：** Hydra, Nmap 是时候看看这一切是否真的捕捉到了什么。 **使用 Hydra 进行暴力破解尝试 (RDP 和 SSH)：** ``` hydra -l Administrator -P passwords.txt rdp://192.168.100.4 [ERROR] freerdp: The connection failed to establish. [ERROR] all children were disabled due too many connection errors 0 of 1 target completed, 0 valid password found ``` ``` hydra -l Administrator -P passwords.txt ssh://192.168.100.4 [ERROR] could not connect to ssh://192.168.100.4:22 - Timeout connecting ``` 两者都彻底失败了 —— RDP 没有按照 Hydra 需要的方式接受连接，SSH 甚至都没有开放。这不是我开始时预期的结果，但这是一个真实的结果：该目标确实不存在针对这些特定攻击路径的漏洞。我将此保留在文档中，而不是悄悄删除它，因为一次失败的攻击仍然是一个真实的发现。 **Nmap 全端口扫描：** ``` nmap 192.168.100.4 -p- ``` 这个起作用了并生成了真实的遥测数据 —— 扫描交互产生的进程创建和文件活动几乎立刻显示在了 Sysmon 中。 我也直接在 Windows 机器上运行了一些本地活动 —— PowerShell 脚本文件创建、命令提示符使用、文件投放 —— 以产生更真实的“攻击者在机器上”的行为，而不仅仅是依赖基于网络的攻击。   ## 阶段 8 — 读取结果 **工具：** Wazuh Dashboard → Security Events 这才是真正的回报。将事件过滤范围缩小到 `agent.name: windows10`，看着告警不断涌入。 反复出现的模式，一次又一次地显示： ``` Rule 92201 (Level 9): powershell.exe created a new scripting file under Windows Temp or User data folder MITRE: T1105 (Ingress Tool Transfer), T1059 (Command and Scripting Interpreter) Tactic: Command and Control, Execution ``` 还有一个很引人注目的 —— Level 15，这是我这段时间看到的最高严重级别： ``` Rule 92213 (Level 15): Executable file dropped in folder commonly used by malware MITRE: T1105 Tactic: Command and Control ``` 还在较低的严重级别捕获了发现活动 (T1087)，这与 Nmap 扫描相符。    出于好奇而非计划，我也针对 CIS Microsoft Windows 10 Benchmark 运行了内置的 SCA (Security Configuration Assessment) 扫描： ``` Policy: CIS Microsoft Windows 10 Enterprise Benchmark v1.12.0 Passed: 121 Failed: 270 Score: 30% ``` 30% 的成绩很难看，但这是一个没有经过任何加固的原生 Windows 10 虚拟机，所以老实说这大概是我预料之中的。如果非要说的话，这也是一个很好的论据，说明了为什么基线加固很重要 —— 这台机器几乎无法通过真实审计会运行的每一项配置检查。 ## 我遇到的问题以及实际上是如何解决的 我没有把它们整理得比实际情况更整洁 —— 这大概是我遇到它们时的顺序。 | 问题 | 到底发生了什么 | 我是如何解决的 | |---|---|---| | `docker-compose up` 给出了关于 `version` 属性已过时的警告 | 较新版本的 Docker Compose 不再需要 yml 中的 `version:` 字段 | 忽略了它 —— 表面上的警告，反正容器都正常启动了 | | `NET START WazuhSvc` 提示“服务名称无效” | 代理 MSI 第一次没有干净地安装 | 重新安装了 MSI，然后在尝试启动它之前使用 `sc query WazuhSvc` 确认了该服务存在 | | 尝试运行 `Sysmon64.exe` 并得到“未识别”的提示 | 实际上并没有在我解压 zip 文件的文件夹中 | 显然，先 `cd` 进入正确的文件夹 —— 但值得一提，因为这是你在疲惫时会浪费十分钟的那种错误 | | Sysmon 事件完全没有显示在 Wazuh 中 | `ossec.conf` 中没有包含告诉代理去读取 Sysmon 事件通道的 `` 块 | 手动添加了 eventchannel 块，重启了代理服务 | | 配置重启后代理立即显示断开连接，并且日志文件夹看起来是空的 | 不完全确定 —— 可能是服务在重新加载后需要时间重新注册 | 再次重启了服务，检查 `agent_control -l` 直到它再次显示 Active | | Hydra 无法暴力破解 RDP 或 SSH | RDP 连接在协议级别未能完成，目标上甚至没有开放 SSH 端口 | 没有“修复”这个问题 —— 这是一个准确的结果。将其记录为一个发现，而不是强行使用不同的攻击来获得一个更完美的故事| Kali 不在 Wazuh 手动安装程序支持的操作系统列表中 | Wazuh 的安装脚本会对照固定列表进行检查 (RHEL, CentOS, Ubuntu, Amazon Linux) | 在手动尝试时加上了 `--ignore-check` 运行；最终无论如何还是坚持以 Docker 部署作为主要方式 | | 仪表板中的报告页面显示“无报告” | Wazuh 仅基于保存的仪表板/报告定义生成 PDF 报告 —— 当时还没有报告定义 | 需要先保存仪表板视图并创建报告定义；因为没有深入探究，因为这并不是检测目标的核心 | ## 我从中学到了什么 Docker 让 manager 的部署变得更快，但并没有让整个项目变得更容易 —— 它只是把摩擦转移到了其他地方。我不再与包安装程序作斗争，而是开始与容器 exec 命令作斗争，并弄清楚哪些 config 存在于容器内，哪些存在于宿主机上。这两种方式都不“简单”，它们只是在不同的地方存在困难。这可能是整个过程中最坦率的收获。 另一件让我印象深刻的事情是：让代理显示为“Active”并不等于获得了有用的遥测数据。“管道已连接”和“管道正在传输任何值得阅读的内容”之间存在真正的差距，而这个差距正是大多数教程一笔带过的 `ossec.conf` 步骤。 ## 仓库结构 ``` wazuh-sysmon-home-lab/ ├── README.md └── screenshots/ ├── docker_wazuh.png ├── dashboard.png ├── installing_wazuh.png ├── agent_adding.png ├── added_agent.png ├── key.png ├── use_main.png ├── waw.png ├── windows_2.png ├── ruuning.png ├── sysmon.png ├── sysmon_files.png ├── sysmon_running_successfully.png ├── sysmon_results.png ├── events.png ├── events_sysmon.png ├── attacks.png ├── kali_talk.png └── windows_can_talk.png ``` ## 关于我 我是 Malathi (Enola) —— 正在努力进入 SOC 分析师岗位，此前有过为期 6 个月的网络安全实习经验，涵盖 IDS/防火墙操作、VAPT 和 SOC 运营。这个实验室是我试图缩小“我学过 SIEM 概念”和“我实际上运行过、破坏过并修复过它”之间差距的尝试。我仍在学习中 —— 如果有任何我弄错了或者可以处理得更干净的地方，很乐意听取您的反馈。 [LinkedIn](https://linkedin.com/in/malathi-mittapalli-enola-b73208413) · [GitHub](https://github.com/malathi-cyber-sketch)

标签：CTI, Docker, Wazuh, 安全实验环境, 安全防御评估, 插件系统, 端点监控, 请求拦截