说实话我第一次接触 Wazuh 的时候心里想的是“又一个开源的 SIEM 平台装完就完事了”。结果从下载安装包到 dashboard 上看到 agent 状态变绿整整折腾了两个晚上。网上关于 Wazuh 的教程不算少但大多停留在“执行这条命令、点那个按钮”的程度一旦中间报错你根本不知道错在哪、怎么定位、怎么恢复。这篇文章把我实际部署 Wazuh 4.x 全过程中踩过的坑、排过的错、查过的日志和最终跑通的配置全部整理出来如果你正准备在自己服务器或虚拟机上装一套 Wazuh照着这份指南走能省下大量试错时间。Wazuh 不是一个单体的安全软件它是一套分布式安全监控平台核心由 Wazuh indexer、Wazuh server 和 Wazuh dashboard 三个组件组成另外还有部署在业务主机上的 wazuh-agent。它能做入侵检测、漏洞管理、日志分析、文件完整性监控、合规性检查等等适合需要统一做主机安全监控的团队也适合想学习 SIEM 架构的个人。文章以 Ubuntu 22.04 上部署 all-in-one 单机版为主线把所有关键环节的坑位都标出来。1. 内容整体设计与思路拆解1.1 Wazuh 到底是哪几个组件在协作在动手安装之前先把架构搞清楚这会直接影响你后面排查问题的思路。Wazuh 4.x 的体系不算复杂但每个组件各司其职缺一个都跑不起来Wazuh indexer基于 OpenSearch 的分布式搜索引擎集群负责存储和索引 agent 上报的安全事件与告警。你可以把它理解成整个系统的大脑的记忆区所有查询、聚合、检索都靠它。Wazuh server包含 wazuh-manager 和 wazuh-analysisd 等核心守护进程负责接收 agent 数据、运行规则引擎、触发告警并把结果写入 indexer。这是整个系统的决策中枢。Wazuh dashboard基于 OpenSearch Dashboards 的 Web 界面供安全人员做可视化分析、规则管理和系统配置。相当于给大脑配了一个可视化的操作面板。Wazuh agent部署在被监控主机上的客户端程序负责采集主机日志、文件变更、系统信息等并发送给 server。Agent 本身不存储数据数据全量上传给管理器。我这次选择的是 all-in-one 单机模式三个服务全部装在同一台 Ubuntu 22.04 主机上。官方对这种部署方式的叫法是“单节点快速启动”适用于测试环境、个人实验室或者小团队试用。生产环境建议把 indexer、server、dashboard 拆开部署不然单台机器压力会非常大尤其是日志量上来之后OpenSearch 的内存和磁盘消耗非常可观。1.2 为什么我选 Ubuntu 22.04 而不是其他发行版官方对 Wazuh 的安装支持覆盖了 Red Hat、CentOS、Ubuntu、Debian、Windows 等主流系统但我个人强烈建议新手使用 Ubuntu 22.04 LTS 作为服务器系统。原因有三个第一Ubuntu 22.04 的 OpenSearch 兼容性测试做得最完整。Wazuh 4.x 的 indexer 对系统库版本有隐性依赖在某些 CentOS 7 老旧环境上会出现 GLIBC 版本不足的问题而在 Ubuntu 22.04 上基本不会碰到这种底层库的兼容性报错。第二安装命令简单直接。Ubuntu 使用 apt 包管理器Wazuh 官方仓库对它支持得最好安装脚本不用额外处理依赖链。CentOS 上还要考虑防火墙管理工具、SELinux 的影响这些都会干扰初次部署的排错过程。第三社区排错案例最多。你如果在 Google 搜索 Wazuh 的 bug 和报错信息八成以上的解决方案都是基于 Ubuntu 环境的遇到问题更容易找到参考。如果手头只有 CentOS 或者 Debian也不是不能装但建议先用 Ubuntu 22.04 跑通流程再迁移到生产系统上。2. 安装前必须要做的环境准备2.1 内存、CPU、磁盘到底要给多少Wazuh 官方在快速启动文档里写的最低要求是 4 核 CPU、8 GB 内存、50 GB 磁盘这个配置在真实环境里也就勉强能跑起来任何一个 agent 开始大量上报数据内存可能直接被打满。我实际测试下来单机 all-in-one 加 3 到 5 台 agent建议至少给 8 核 CPU、16 GB 内存、100 GB 磁盘。这样即使 dashboard 打开仪表盘时触发大量聚合查询系统也还留有余量。在安装之前可以用下面三条命令快速检查服务器资源nproc free -h df -h如果内存不足 8 GB我建议先别急着装。Wazuh 安装脚本会因为 OpenSearch 启动失败而中断而你排查半天最后发现只是内存不够非常浪费精力。2.2 主机名解析和 hosts 文件的坑这是一个很多人忽略的细节。Wazuh 安装脚本会检查主机名、IP 地址、DNS 解析是否正常如果在安装过程中出现“hostname was NOT valid”或者“unknown host”之类的报错多半是 /etc/hosts 里主机名映射没写对。我建议在安装前直接把 hosts 文件配置好。假设我的服务器 IP 是 192.168.1.100主机名是 wazuh-server那么需要执行hostnamectl set-hostname wazuh-server echo 192.168.1.100 wazuh-server /etc/hosts然后重新登录终端用hostname和ping wazuh-server验证能否解析通。这一步看似简单但能避免安装脚本在证书生成阶段因为主机名解析失败而卡住。Wazuh 的证书生成会绑主机名和 IP如果解析混乱证书和 IP 对不上即使安装成功dashboard 里的 agent 状态也会一直显示断开。2.3 系统依赖和默认端口规划Wazuh 用到了大量端口安装前最好确认没有冲突55000/tcpWazuh server 接收 agent 连接1514/tcpagent 事件通道默认是 UDP/TCP 混合1515/tcpagent 注册服务443/tcpdashboard 和 API9200/tcpindexer 的 REST API默认不对外网开放在 Ubuntu 22.04 上如果系统自带了 nginx 或者 Apache需要先将 443 端口释放否则 dashboard 起不来。依赖工具方面安装脚本会自动处理大部分但建议先把 curl、vim、gnupg 装上apt update apt install -y curl vim gnupg apt-transport-https3. 全流程实操从下载安装包到 dashboard 显示 agent 上线3.1 获取官方安装助手并生成应答配置Wazuh 从 4.2 版本开始提供了统一的安装助手脚本 wazuh-install.sh它把 indexer、server、dashboard 的安装打包到了一个流程里。第一步不需要直接执行安装而是先下载助手并生成配置文件。curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh chmod x wazuh-install.sh sudo ./wazuh-install.sh --generate-config-files这一步会生成一个wazuh-install-files.tar.gz压缩包里面包含了所有组件初始化和彼此通信需要的证书与密码。注意运行这条命令时必须使用 root 或者通过 sudo 执行并且系统时间要准确因为证书生成对时间敏感机器时间偏差会导致后续 HTTPS 握手失败。生成的压缩包建议复制到一个安全目录保存后面重新安装 agent、扩展节点都需要用到里面的证书文件和密码。3.2 单节点一键安装的正确姿势配置文件生成之后执行全量安装sudo ./wazuh-install.sh --install这个命令会自动完成 indexer 的集群初始化、server 和 dashboard 的安装配置整个过程大约需要 15 到 30 分钟取决于网络状况和机器性能。我实际跑的时候在中国大陆网络环境下频繁卡在下载包的阶段解决办法是把默认软件源替换为阿里云或者清华的镜像源再重新执行安装脚本。安装脚本结束时终端会输出一段黄色的提示信息里面写明了 dashboard 的访问地址、管理员用户名和自动生成的初始密码格式类似这样INFO: --- Summary --- INFO: You can access the web interface https://server-ip User: admin Password: xxxxxxxx务必把这串密码保存下来后面登录 dashboard 的 Web 界面会用到。如果不小心关了终端密码在/etc/wazuh-dashboard/下的配置备份中也有记录。提示安装助手生成的密码是弱密码登录 dashboard 后建议第一时间修改。修改 API 密码时需要注意dashboard 和 indexer 的用户信息会同步存储改完需要重启 wazuh-dashboard 服务才能生效。3.3 安装完成后验证三个服务状态安装脚本提示成功之后不要急着登录 Web 界面先把三个核心服务的状态都检查一遍systemctl status wazuh-indexer systemctl status wazuh-manager systemctl status wazuh-dashboard正常状态下三者都应该显示 active (running)。如果 wazuh-indexer 没有起来可以查看它的日志journalctl -u wazuh-indexer -n 100常见的失败原因包括内存不足导致 OpenSearch 无法启动、vm.max_map_count参数太小、数据目录权限不对等。一次性把这些基础状态确认好后面才不容易出现“web 能开但没有任何数据”的诡异问题。接着验证 indexer 的 API 是否正常响应curl -k -u admin:your-password https://localhost:9200如果返回一段包含 cluster_name 和 tagline 的 JSON 内容说明 indexer 工作是正常的。这一步很关键因为 dashboard 本质上是在查询 indexer如果 indexer 没起来dashboard 页面上所有数据区域都会转圈报错。3.4 登录 dashboard 做基本初始化设置打开浏览器访问https://server-ip因为证书是自签名的浏览器一定会给出不安全提示选择继续访问即可。使用安装输出的 admin 账号密码登录后第一件事是进入管理界面确认 indexer 的健康状态。正常情况在 Dashboard 首页能看到 CPU 使用率、文件完整性监控等预置面板的数据。如果首页显示“No data”或者索引不存在的提示最常见的原因是 indexer 索引模板没有正确初始化可以访问https://server-ip/app/management查看索引管理确认有没有名为wazuh-alerts-*的索引创建出来。4. 部署 wazuh-agent从 Linux 到 Windows 的完整实录4.1 在 Linux 目标主机上安装并注册 agentWazuh 的核心价值在于 agent 的覆盖范围所以我建议装好服务端之后立刻部署一台 agent 验证全链路。以另一台 Ubuntu 22.04 主机为例先添加 Wazuh 仓库并安装 agent 包curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import chmod 644 /usr/share/keyrings/wazuh.gpg echo deb [signed-by/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main | tee -a /etc/apt/sources.list.d/wazuh.list apt update apt install -y wazuh-agent安装完成后需要把 agent 指向刚才部署好的 Wazuh server。编辑 agent 的配置文件/var/ossec/etc/ossec.conf找到clientserver字段把 IP 修改为 server 的地址client server address192.168.1.100/address port1514/port /server /client然后注册 agent 并启动服务/var/ossec/bin/agent-auth -m 192.168.1.100 -A my-linux-agent systemctl restart wazuh-agent注册过程会要求在 server 端手动添加 agent 或者开启自动注册。如果你没有预先在 server 端初始化 agent 名称注册时会提示认证失败。最简单的方式是在 server 端先显式添加 agent/var/ossec/bin/manage_agents选择添加 agent、输入名称和 IP随后把生成的密钥复制到 agent 端执行/var/ossec/bin/manage_agents导入密钥重启 agent。这套手动注册流程虽然繁琐但能避免自动注册带来的一些权限和证书问题新手阶段建议走这条路。4.2 Windows agent 安装与防火墙设置Windows 上安装 agent 相对直观下载 MSI 安装包后双击运行在安装界面填入 Wazuh server 的 IP 和 agent 名称即可。但有一个坑经常被忽略Windows 第一次启动 wazuh-agent 服务时如果系统开启了防火墙但没有放行 agent 到 server 的 1514 端口出站规则agent 状态会一直显示 disconnected。另外 Windows agent 服务默认是手动启动安装完成后需要手动在服务管理器里把 Wazuh 服务设为“自动”然后启动服务。打开服务管理器win r 输入 services.msc找到 Wazuh 服务右键属性将启动类型改为“自动”。4.3 agent 状态一直是 active 但不出数据的排查顺序最让人崩溃的一种情况是web 界面显示 agent 已经 active但点进去一个事件都看不到。我的排查顺序固定如下第一确认 agent 到 server 的网络连通性telnet 192.168.1.100 1514第二确认 agent 的ossec.conf里没有残留的默认地址。很多情况下安装包默认配置写的是自己主机的 IP导致数据发到了自己身上。第三查看 server 端有没有收到 agent 的注册消息/var/ossec/bin/agent_control -l第四查看 indexer 里有没有生成告警索引curl -k -u admin:password https://localhost:9200/_cat/indices/*wazuh*一般按这个顺序排查80% 的问题都能定位到原因剩下的就是 agent 进程异常重启即可解决。5. 高频踩坑问题与解决速查表安装和日常使用过程中我记录了一批高频问题按照“现象-排查-解决”整理成一张速查表方便你直接对照。问题现象排查方向解决方案安装脚本卡在Installing wazuh-indexer长时间不动查看 journalctl 日志常见为网络下载或 vm.max_map_count 不足调整 vim /etc/sysctl.conf设置vm.max_map_count262144执行sysctl -pdashboard 页面提示Kibana server is not ready yetwazuh-dashboard 服务崩溃或 indexer 连接失败查看/var/log/wazuh-dashboard/wazuh-dashboard.log确认 indexer 的 URL 和证书路径是否正确agent 注册失败日志报Error receiving request注册端口 1515 没放行或管理器的ossec-authd未启动防火墙放行 TCP 1515 端口执行systemctl restart wazuh-manager重启注册服务服务器内存充足但 OpenSearch 启动失败检查/var/log/wazuh-indexer/下的 cluster 日志常为 JVM 堆内存配置过大编辑/etc/wazuh-indexer/jvm.options把-Xms和-Xmx调整为可用内存的一半以内agent 状态 active 但无数据排查 1514 端口连通性、配置文件 agent 名称是否匹配、索引是否创建按 4.3 节的顺序逐项检查dashboard 首页加载很慢浏览器到 443 端口的网络问题或 dashboard 内存不足增大服务器的可用内存或者将 dashboard 静置几分钟等待缓存生成重启服务器后所有服务没有自动启动服务没设开机自启分别执行systemctl enable wazuh-indexer wazuh-manager wazuh-dashboard5.1 JVM 堆内存配置不当导致 indexer 反复崩溃这个坑我印象最深。首次安装时我用了 8 GB 内存的虚拟机OpenSearch 启动不到三分钟就自动退出日志里写的是OutOfMemoryError。原因是安装脚本生成的jvm.options默认把堆内存设成了 4 GB而系统总内存才 8 GB加上系统本身和其他进程根本余不出足够的可用内存。调整方案是打开/etc/wazuh-indexer/jvm.options把-Xms和-Xmx调低到系统内存的一半以内比如-Xms2g -Xmx2g修改后重启服务systemctl daemon-reload systemctl restart wazuh-indexer内存配置不是一个无脑拉高就好的参数。设太高系统崩设太低 OpenSearch 频繁 GC 导致查询超时。一个实用经验是先把堆内存设为总内存的 25%观察一天如果告警查询的平均响应时间在 200 毫秒以内再逐步上调。5.2 Elasticsearch/OpenSearch 的max virtual memory areas报错在 Ubuntu 上安装 OpenSearch 时有一个内核参数经常让我们这些从 Elasticsearch 时代过来的人头疼vm.max_map_count。默认值 65530 看上去挺大但 OpenSearch 在启动和运行期间会创建大量内存映射区域一旦耗尽就会报错max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]解决方式很简单修改/etc/sysctl.confvm.max_map_count262144执行sysctl -p让配置立即生效。这个参数修改后不需要重启机器但必须确保在 wazuh-indexer 启动之前已经设置好否则 OpenSearch 会直接启动失败。5.3 证书不匹配导致的certificate verify failedWazuh 组件间的通信全部用 TLS 加密。安装助手在生成证书时会把当前机器的主机名和 IP 写进证书的 SAN 字段如果你的服务器后来改了 IP或者你用了反代把 dashboard 映射到域名就会出现证书不匹配的报错。最稳妥的解决方案是重新生成证书。把/etc/wazuh-indexer/certs/、/etc/wazuh-dashboard/certs/、/var/ossec/etc/下的旧证书备份后删除然后回到最开始用安装助手的--generate-config-files重新生成配置压缩包再依次把证书复制到对应目录并重启服务。如果只是临时想绕过错误查看页面可以在浏览器里点击高级-继续访问但 agent 和 server 之间的通信无法绕过必须保证证书匹配否则 agent 会一直显示 disconnected。5.4 密码修改后组件间认证失败Wazuh 在安装时会给所有内部组件设置统一的初始密码存储在wazuh-install-files.tar.gz的wazuh-passwords.txt文件里。如果用户通过 dashboard 的 API 界面修改了 Elasticsearch 用户密码但没同步修改 dashboard 配置文件里的opensearch.password就会出现 dashborad 能登录但数据加载不出来的状况。具体修改路径是/etc/wazuh-dashboard/opensearch_dashboards.yml里的opensearch.password字段改完需要重启wazuh-dashboard。同理如果修改了 API 用户的密码还需要在 dashboard 的“Stack Management → 用户”中更新对应的凭据。6. 安装完成后给新手的进阶建议6.1 从自带规则模板开始不要急着自定义规则Wazuh 自带了上千条安全规则基本上覆盖了常见的暴力破解、恶意软件特征、异常登录等场景。新手装完后建议先在“Security events”模块观察一段时间真实数据对规则命中情况有直观感知后再根据业务需求调整规则级别或者写自定义规则。直接一上来就写自定义规则的人后期很容易把告警刷爆最重要的事件反而被淹没。6.2 配置 SCA 基线检查和漏洞扫描Wazuh 的价值不只在于日志分析。在 agent 配置文件里sca模块默认是开启的它会按预置的安全基线检查 Linux 系统的账号、权限、网络、内核参数等配置。安装完 agent 后可以在 dashboard 的“Configuration Assessment”模块查看基线扫描结果很多不合规项其实就对应着系统加固需要做的工作。漏洞检测模块vulnerability-detector也是明星功能。默认可能没开启需要在 server 端/var/ossec/etc/ossec.conf打开开关并按需配置操作系统 CVE 数据库的下载源。第一次扫描会因为要拉取完整漏洞库而比较慢但完成后能在 dashboard 里直观看到每台主机的漏洞列表和严重级别。6.3 磁盘告警一定要一开始就配Wazuh 的告警数据会无限增长索引默认按天轮转。如果索引生命周期策略没配好磁盘总有一天会写满而磁盘满造成的故障比安全事件本身还难处理。我建议在一开始就配置好磁盘用量监控和索引定期清理策略在 dashboard 的 Indexer Management 里设置 ILM 策略例如保留 30 天的数据超过后自动删除旧索引。写在最后的一点心里话Wazuh 这套东西真正难的不是安装而是理解它的运行逻辑。安装脚本只要网络好、资源足、时间准基本不会再出大问题真正折磨人的是 agent 注册失败、证书不匹配、索引没有生成这些细枝末节的东西。我前后在虚拟机里完整重装了四次才彻底摸清每一步的依赖关系也正因为这样才敢把这份踩坑指南按“报错现象 → 排查过程 → 解决方案”的格式整理出来希望它对你是一次性跑通的助力而不是又一个让你熬夜的教程。最后再分享一个小技巧Wazuh 的日志目录/var/log/wazuh-indexer/、/var/log/wazuh-dashboard/和/var/ossec/logs/里存了大量详细的运行日志遇到问题不要盲改配置先看日志。日志里行号和时间戳会直接告诉你服务在哪个阶段失败绝大多数问题都不是配置写错而是环境差异导致的。装完这套系统之后不妨在测试 agent 上故意触发几次 SSH 暴力破解模拟你看完告警链路就会明白之前踩的坑都是值得的。