Wazuh 部署架构

服务端装在哪：Linux VM，没有第二种答案

部署 Wazuh 第一个要决定的问题，也是唯一没有争议的问题：Server 装在 Linux 虚拟机（Ubuntu）上。

不要装在 Windows Server 上，也不装在宿主机上：

位置	结论
Windows Server	官方优先支持 Linux；Windows 上部署复杂、不稳定，后期升级容易出问题
宿主机	宿主机一关，全部监控同时消失——这是拿业务连续性换部署省事
Linux VM	官方推荐形态，隔离、快照、可迁移

宿主机当服务器是典型的「实验环境思维」——在个人电脑上搭起来验证一下没问题，一旦当成生产架构，重启、断电、更新任何一件事都会连带全部安全监控下线。服务一律进 VM，这件事没有例外。

一台 VM 里跑齐三个组件：

Wazuh Manager      接收 Agent 上报，规则引擎，告警
Wazuh Indexer      事件存储与索引（基于 OpenSearch）
Wazuh Dashboard    可视化与检索界面

为什么不用单独装 Kibana

历史上 Wazuh 用 ELK（Elasticsearch + Kibana）做存储和展示，所以很多教程还在教「Wazuh + Kibana」的组合。现在这套已经内置了：

• 存储用 OpenSearch（Wazuh 自带的 Indexer）
• 展示用 Wazuh Dashboard（基于 OpenSearch Dashboards）

技术上你仍然可以自己装一套 Kibana 对接，但没有理由这么做：多一套组件就多一个升级要对齐的版本、多一个故障点、多一份备份。用自带的，够用且省心。

Windows Server 跑在虚拟机里的资源要求

域控（以及后续服务）跑 VM 是完全 OK 的，甚至更推荐——快照意味着域控配错了可以回滚，隔离意味着测试和生产不互相污染。底线配置：

• CPU：不低于 2 核
• 内存：8GB 起步（域控 + 后续服务的余量）

低于这条线不一定会立刻报错，但会出现各种「说不清的慢」——组策略应用超时、登录卡顿、索引构建迟缓——排查这些症状的时间，远超当初省下的硬件钱。

日志统一进 Wazuh

Sysmon、Windows 安全日志、PowerShell 日志——全部进 Wazuh，一套管道。

不需要：

• 单独为 Sysmon 建一套收集
• 单独收 Windows 事件日志
• 再对一套转发规则

分散管道的代价不是「多几个配置」，而是关联分析时永远在对不齐的时间线上做拼接。统一管道 + 统一时区 + 统一保留策略，才可能回答「10:12:30 哪个账号登录、10:12:33 执行了什么命令、10:12:20 往外发了什么数据」这种跨源问题。

Agent 侧随域策略下发安装，配置纳入版本管理；Server 侧的规则从「高价值规则」起步，别一次全开（规则与降噪见建设路线最后一部分）。

容量与保留

Sysmon 全量开启后日志量上涨很快，两个数字先记下来：

• 本机保留 24 小时足够应急——出事时查最近一天的细节，更早的走中心端。
• 中心端按月归档，并按月做容量评估：磁盘告警阈值设在 70%，别等写满了才发现。

日志平台的价值在「出事之后能重建过程」，而重建的前提是那时候数据还在。保留策略不是磁盘管理问题，是取证能力问题。