Wazuh这套开源安全监控平台功能确实能打SIEM、入侵检测、日志审计、合规检查一把梭但你要是从零开始自己装一遍我敢说你大概率会在前三个小时里想砸键盘。别问我怎么知道的——我第一次布 Wazuh 的时候从拿到官方文档到三个组件全部正常运行断断续续折腾了差不多两个整天。而且最气人的是装完回头看基本都是些很小的问题证书权限不对、内核参数没改、hosts 没写、防火墙悄悄挡了个端口有的甚至就是拼写错误。这篇文章就是把我在 Wazuh 安装这条路上踩过的坑、反复排查的细节和最终跑通的方法按阶段全部分享出来。如果你准备在自己服务器或者虚拟机里部署 Wazuh这套实操笔记应该能帮你把安装周期从两天压缩到两小时。1. 装 Wazuh 之前先把这些底子打好1.1 版本选择和操作系统兼容性别到时候三个组件版本对不上Wazuh 4.x 之后官方把架构拆成了三大件Wazuh Indexer存储和检索数据底层是 OpenSearch、Wazuh Manager负责 agent 管理、日志分析、告警生成和 Wazuh Dashboard可视化界面底层是 OpenSearch Dashboards。看起来是三件套但它们的版本必须严格匹配。比如 4.8 系列的 Indexer 配 4.8 的 Managerfilebeat 也要用 4.8 的模板dashboard 同样要 4.8。你如果贪图省事直接用系统里的 OpenSearch 旧版本混搭大概率会在启动阶段因为字段模板不兼容报一堆解析错误。操作系统方面官方支持 RHEL 系和 Debian 系的主流版本比如 CentOS 7/8、Rocky Linux、Ubuntu 20.04/22.04、Debian 11 等。我的建议是新部署直接用 Rocky Linux 8 或者 Ubuntu 22.04 LTS别再用 CentOS 7 了。Wazuh 4.8 以后的组件在 CentOS 7 上依赖系统 glibc 版本有些前端库和服务跑起来会诡异报错排查半天才发现是系统太老。我自己测试环境分别装过 CentOS 7.9、Rocky 8.6、Ubuntu 20.04综合体验最省心的是 Rocky 8。还有一个容易踩的坑如果你机器上已经装了独立的 Elasticsearch、OpenSearch 或者有服务占了 9200、9300 端口务必先停掉或者卸载否则 Indexer 启动时端口冲突日志里会一直报Address already in use。Wazuh Indexer 用的就是 OpenSearch它和系统里已有的 OpenSearch 实例会抢资源不能用“双开”的思路。1.2 资源评估内存不够一切白搭官方给的 All-in-One 最低要求是 4GB 内存、2 核 CPU但我说实话这个配置只够“能启动”完全谈不上“能用”。Wazuh Indexer 底层是 OpenSearch本身 JVM 堆内存就要占 2G 到 4G再叠加 Dashboard 的 Node 进程、Manager 的分析引擎4G 内存跑起来动不动就 OOM最明显的表现就是服务进程还在但 Web 界面卡死或者 agent 的日志发过来就丢过几分钟 Indexer 就挂一次。如果你想在自己电脑上用虚拟机做测试建议至少分配 6G 到 8G 内存。硬盘方面SSD 是刚需。Indexer 的数据目录默认在/var/lib/wazuh-indexer即使只接入一台测试主机几天下来告警事件也有几百 MB 到几个 GB机械硬盘跑 OpenSearch 的读写延迟会让你怀疑人生。另外安装包本身解压后占用不小给/var分区至少留 30G 空间比较稳妥。内存不足的另一个隐患是 swap 问题。Wazuh Indexer 默认配置里会开启bootstrap.memory_lock: true也就是要求锁住内存禁用 swap。这样做的好处是避免 GC 性能抖动但前提是你的系统要允许进程锁定足够大的内存。如果/etc/security/limits.conf里的 memlock 没放开Indexer 启动时就会报memory locking requested for opensearch process but memory is not locked然后整个服务就在启动失败和重启循环里反复横跳。1.3 系统初始化三件套主机名、sysctl 和防火墙部署 Wazuh 之前先把系统底子收拾干净。第一件事是主机名。Wazuh Indexer 的集群发现机制会用到 hostname 解析主机名最好只用字母、数字和短横线千万别带下划线不然 OpenSearch 在解析节点名时可能报非法字符。同时/etc/hosts里一定要有本机 IP 和主机名的对应关系不然启动时network.host解析不到地址服务直接起不来。第二件事是改内核参数。最重要的一项就是vm.max_map_countOpenSearch 要求这个值不能低于 262144而大部分 Linux 系统默认只有 65530。不修改的话Indexer 启动日志里会明确提示max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]。修改命令如下需要切换到 root 用户执行sysctl -w vm.max_map_count262144 echo vm.max_map_count262144 /etc/sysctl.conf sysctl -p顺带把vm.swappiness调低一些改为 1 或者 10减少系统对 swap 的依赖。这个操作在内存小的机器上尤其管用。然后检查一下ulimit -l的值如果 memlock 是 64KB在/etc/security/limits.conf里给运行用户放开限制wazuh-indexer soft memlock unlimited wazuh-indexer hard memlock unlimited改完重启一下系统或者重新登录终端生效。第三件事是防火墙和 SELinux。如果你用的是 CentOS/Rocky 这类默认开启 SELinux 的系统不想深入了解规则的话测试环境直接setenforce 0是最省事的方案但重启后会失效需要同时修改/etc/selinux/config永久关闭。生产环境不建议这么干但可以针对 9200、443、1514、1515、55000 这几个端口放行 SELinux 上下文不过那一套规则配下来容易出错所以我个人装机阶段都是先关掉跑通了再慢慢收紧。2. 安装方式选型和安装过程拆解2.1 官方安装脚本能把人坑哭的“黑盒”Wazuh 官方网站提供了一键安装脚本帮助文档看起来特别美好下载一个脚本敲几条命令就自动生成证书、装好所有组件、配置好服务。实际跑起来坑点非常密集。官方 All-in-One 安装脚本实际执行过程是这样拆分的curl -sO https://packages.wazuh.com/4.8/wazuh-install.sh bash wazuh-install.sh --generate-config-files bash wazuh-install.sh --wazuh-indexer node-1 bash wazuh-install.sh --start-cluster bash wazuh-install.sh --wazuh-server wazuh-1 bash wazuh-install.sh --wazuh-dashboard dashboard很多第一次接触的人以为执行一条bash wazuh-install.sh --all-in-one就完事了但官方脚本实际还是分阶段执行的。最大的坑是--generate-config-files这一步它会在当前目录生成一个wazuh-install-files.tar.gz压缩包里面包含所有节点需要的证书和配置文件。如果你在中途因为断网、超时等原因中断了脚本压缩包没生成就直接执行--wazuh-indexer node-1脚本会报找不到wazuh-install-files.tar.gz而且由于证书还没生成后面所有组件都会卡在证书校验上。我的建议是一开始就把四步拆开来执行一步一步看输出。每跑完一步确认服务起来了再跑下一步。脚本执行完会在终端输出一大段内容里面有 Dashboard 的访问地址、管理员账号和密码还有用于 agent 登记的密码。这段输出别随手关掉我就是因为没保存后来要从日志里翻半天。如果真忘了可以用官方工具重置bash /usr/share/wazuh-indexer/bin/wazuh-passwords-tool -a这个工具会把所有内置账号的密码重置然后重新打印出来前提是 Indexer 服务必须已经正常启动。2.2 手动安装三件套厘清组件依赖关系如果你不想被脚本黑盒支配可以选择手动安装。但手动安装对逻辑要求更高你必须清楚三个组件的依赖关系。我的建议顺序是Indexer → Manager → Filebeat → Dashboard理由很简单Indexer 是数据存储层它最先启动为后面的组件提供写入和查询接口Manager 是数据生产层agent 的数据、告警都汇总到它这里但它需要 filebeat 帮它把数据推到 IndexerFilebeat 是数据管道安装 Manager 之后、Dashboard 之前配好Dashboard 是展示层它需要连接 Indexer 读取数据最后装最合理。手动安装时系统里需要先配好 Wazuh 的软件源。以 Debian/Ubuntu 系为例curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | apt-key add - echo deb https://packages.wazuh.com/4.x/apt/ stable main | tee /etc/apt/sources.list.d/wazuh.list apt-get updateRHEL 系的做法稍有不同要把 GPG key 导入到 rpm 的 keyring然后新建一个 repo 文件。第一次配源容易犯的错误是版本号写错比如官方文档给你的可能是4.x通用源而不是固定4.8版本。用4.x的写法后面apt-get update不会报错但实际拉取的软件包版本可能比你预期的要高或低和手头其他组件版本不好对齐。建议直接写死大版本号比如4.8这样全链路版本一致避免给后面的排障留坑。2.3 Filebeat 配置数据管道能不能通全看它Manager 和 Indexer 都起来之后Filebeat 是很多人忽略的一环。它的作用是把 Wazuh Manager 产生的告警和事件数据转发给 Indexer。如果你跳过 Filebeat或者配错了 Filebeat 的输出地址Dashboard 的界面能正常打开但“安全事件”和“总览”页面永远只有零条数据甚至会出现告警产生但数据检索不到的问题。Filebeat 的配置文件在/etc/filebeat/filebeat.yml需要检查的关键项是这几段output.elasticsearch: hosts: [https://indexer-ip:9200] protocol: https username: admin password: admin-password ssl: certificate_authorities: - /etc/filebeat/certs/root-ca.pem很多人会把hosts写成 manager 自己的地址这就错了。Filebeat 的职责是把数据往 Indexer 送你要写的是 Indexer 的 IP192.168.x.x和端口9200。另外Filebeat 也要有自己的证书目录路径在/etc/filebeat/certs/里面至少要有root-ca.pem、filebeat.pem、filebeat-key.pem。如果你发现 Filebeat 启动日志里出现x509: certificate signed by unknown authority之类的报错十有八九是 CA 证书路径写错或者根本没把根证书拷到这个目录。把证书分发到 Filebeat 目录后记得重启服务再观察日志。3. 证书、配置和端口安装期的三座大山3.1 证书生成和分发属主权限一定要看清楚Wazuh 所有组件之间的通信都走 TLS所以证书贯穿整个安装过程。官方脚本的--generate-config-files会在压缩包里放好 6 到 8 个证书文件手动安装时也可以用官方证书工具生成bash /usr/share/wazuh-indexer/bin/wazuh-cert-tool.sh -A生成完以后要把对应的证书分别拷贝到各个组件的 certs 目录下。这里最容易被忽略的是属主和权限问题。Indexer 的证书目录是/etc/wazuh-indexer/certs/文件属主必须是wazuh-indexer:wazuh-indexerManager 的是/etc/wazuh-manager/certs/属主是wazuh-manager:wazuh-managerDashboard 和 Filebeat 同理。如果你用 root 用户 scp 过去之后没改属主服务进程会因为读不了私钥直接启动失败。修改命令通用写法是chown -R wazuh-indexer:wazuh-indexer /etc/wazuh-indexer/certs/ chmod 500 /etc/wazuh-indexer/certs/ chmod 400 /etc/wazuh-indexer/certs/*.pem权限建议统一压到 400 或 600。还有一个新手极易踩的坑Dashboard 连接的 Indexer 如果用的是自签 CA那么 root CA 文件必须和最初生成证书的那个完全一致。如果你在一次测试中分两批生成过证书第二批证书的 CA 和第一批对不上Dashboard 请求 Indexer 时会报 SSL 握手失败日志里会看到OpenSearch Dashboards has not been configured to trust the OpenSearch backend之类的提示。解决办法只有一个所有组件必须使用同一套 root CA。这也是为什么官方脚本把证书打包成一个 tar.gz 文件的原因——它就是强迫你所有节点使用同一套凭证。3.2 opensearch.yml 和 jvm.options改错一个参数就起不来Indexer 的配置文件是/etc/wazuh-indexer/opensearch.yml。单机部署时下面这几个参数是必须写对的network.host: 0.0.0.0 discovery.type: single-node bootstrap.memory_lock: true plugins.security.disabled: falsenetwork.host如果只写127.0.0.1其他组件就访问不到它写0.0.0.0表示监听所有网卡最省事。discovery.type: single-node对单机部署很关键不写的话它默认走集群发现流程会一直找其他节点启动过程可能卡住十五分钟。有一点要注意plugins.security.disabled千万不要改成true。有人图省事关掉安全模块想着测试环境无所谓结果 Wazuh Dashboard 和 Filebeat 连接时全部因为鉴权失败而弹错而且你在界面上完全看不到具体是哪一步出了问题。JVM 堆内存配置在/etc/wazuh-indexer/jvm.options里面的-Xms和-Xmx要显式设置。官方默认值是 1G全流程部署后最好调整到物理内存的一半但不能超过 32G。我这里踩过一个坑在 16G 内存的机器上把堆调成了 12G结果 Indexer 一直起不来日志提示 mmap 失败最后发现是系统max_map_count不够而且内存锁配置也没匹配。建议先用 4G 堆跑起来后续根据写入量再调整不要一上来就贪大。3.3 Dashboard 配置文件核对清单照着抄Dashboard 的配置文件是/etc/wazuh-dashboard/opensearch_dashboards.yml。安装完成后最小改动建议如下server.host: 0.0.0.0 server.port: 443 opensearch.hosts: [https://indexer-ip:9200] opensearch.ssl.verificationMode: certificate i18n.locale: zh-CNserver.host如果不写在0.0.0.0你用浏览器访问虚拟机的 IP 时就会直接拒绝连接。opensearch.hosts必须写 Indexer 的访问地址协议是 https。verificationMode这里有讲究默认是full它不光校验 CA还会校验证书里的 IP 或域名和你访问的地址是否一致。如果你在生成证书时只写了 hostname没写 IP那么用 IP 访问时校验就会失败。测试环境把它改成certificate可以跳过主机名校验只验证 CA能少踩很多坑。还有一个容易被忽略的点Dashboard 自身的 HTTPS 证书由插件管理证书文件路径默认在/etc/wazuh-dashboard/certs/下如果你修改了配置文件里的权限或者目录路径记得同步把所有.pem文件的属主改成wazuh-dashboard:wazuh-dashboard权限 400。不然服务启动时会报EACCES或者permission denied。我自己就在这段卡了半小时最后发现只是证书文件属主是 rootdashboard 进程没有读取权限。4. Agent 端安装与接入最后一步也不让人省心4.1 Agent 部署前必须确认的三项关键信息Wazuh 部署的最后一步是安装 agent代理端这里同样有一堆细节。Linux 上安装 agent 之前先确认三件事Manager 的 IP 地址、agent 的注册密码、agent 的名称。Manager IP 没什么好说的注册密码可以通过安装 dashboard 输出的那段文字里找到也可以在 Manager 上执行cat /var/ossec/etc/authd.pass这个密码只在 agent 首次注册时需要注册成功以后会在/var/ossec/etc/client.keys里生成一条记录后续认证走的是证书和密钥密码就不再起作用了。agent 名称建议起得有意义一些比如webserver-01、db-server-02因为在 Dashboard 的 agent 列表里显示的就是这个名字方便后续管理。如果你起了一堆test1、test2到后来根本分不清哪台是哪台。安装 agent 时官方给的命令通常是一行脚本里面带有环境变量安装完成后要确认/var/ossec/etc/ossec.conf里的address是否指向正确的 Manager IP。有些时候脚本执行完配置文件里的地址还是默认的MANAGER_IP需要手动改然后重启 agent 服务systemctl enable wazuh-agent systemctl start wazuh-agent4.2 Agent 状态不是 Active三种“卡住”现象逐一排查发现 agent 装完后状态一直不对先看 Dashboard agent 列表里的状态总共就是三种Active、Disconnected、Unverified。先说Unverified这个状态说明 agent 从来没成功向 Manager 注册过。排查顺序是第一检查/var/ossec/etc/client.keys文件是否存在第二确认 1515 端口是否通的第三确认注册密码是否输入正确。如果端口通、密码对但 client.keys 一直不生成去 Manager 上执行journalctl -u wazuh-manager -f看有没有报Unable to register之类的错误定位到原因后再处理。Disconnected状态表示 agent 曾经注册成功但是当前连接中断。最常见的三个原因是Manager 防火墙没放行 1514 端口、agent 和 Manager 之间的网络不通、agent 服务意外停止了。这个时候优先从 agent 端看日志Linux 上执行journalctl -u wazuh-agent -f tail -f /var/ossec/logs/ossec.log看日志里是ERROR还是WARNING。如果看到频繁重连但失败多半是网络问题用telnet manager-ip 1514或者nc -vz manager-ip 1514验证一下端口连通性。在这之后时间不同步也是一个隐藏杀器。agent 和 Manager 的系统时间差得太多认证握手时会因为时间戳越界失败Dashboard 上表现出忽连忽断的诡异状态。所以所有参与部署的机器第一件事就是配好 chrony 或 ntpd让时间保持一致。Windows 平台的 agent 问题通常集中在安装包的权限和杀毒软件拦截上。安装 Wazuh agent 的 msiexec 命令里可以一次性指定 Manager 地址和注册密码但 Windows 防火墙默认会拦 Skynet老版本叫法或 wazuh-agent 进程的入站连接需要手动添加允许规则。另外公司内的杀毒软件有时会把 agent 的写日志行为当成异常导致 agent 服务反复被 kill这种情况下最有效的思路是先在防病毒白名单里放行 Wazuh 相关目录和服务。4.3 端口放行清单一次性避免“排查半天发现是防火墙”防火墙的问题放在最后说是因为它太基础反而容易被忽略。Agent 和 Manager 通信过程中涉及三个端口服务端口协议用途Agent 事件传输1514TCPagent 向 Manager 发送日志和事件Agent 注册1515TCPagent 首次注册和密钥分发Wazuh API55000TCPDashboard 调用 Manager 的 APIIndexer API9200TCP各组件读写数据、认证接口Dashboard443TCP浏览器访问 Web 界面如果你用的是 firewalld可以这样快速放行firewall-cmd --permanent --add-port1514/tcp firewall-cmd --permanent --add-port1515/tcp firewall-cmd --permanent --add-port55000/tcp firewall-cmd --permanent --add-port9200/tcp firewall-cmd --permanent --add-port443/tcp firewall-cmd --reload从 agent 到 Manager 至少放行 1514 和 1515从 Dashboard 到 Indexer 要放行 9200从浏览器到 Dashboard 要放行 443从 Dashboard 到 Manager 要放行 55000。还有一点如果组件之间是跨网段的你还要排查云厂商的安全组规则Wazuh 报错里有时不会给你明确提示这种基础网络问题排查起来最费时间。我自己就多次在本地防火墙放行之后忘了云平台安全组也有入站规则排查了很久。5. 安装期高频报错速查表与实操建议5.1 高频报错速查表报错现象可能原因快速排查方法vm.max_map_count is too low内核参数没改执行sysctl -w vm.max_map_count262144memory locking requested ... but memory is not lockedmemlock 限制未放开修改/etc/security/limits.conf并重启Address already in use9200 或 443 端口被占ss -lntp | grep 9200定位进程x509: certificate signed by unknown authorityCA 证书不一致或路径错误检查 root-ca.pem 是否部署到各组件 certs 目录Wazuh Indexer 启动后反复重启JVM 堆内存设置过高或max_map_count不足查看/var/log/wazuh-indexer/*.logDashboard 无法连接 Indexeropensearch.hosts写错或证书不匹配检查opensearch_dashboards.yml里的 hostsAgent 状态为 Unverified1515 端口不通或注册密码错查看 Manager 日志检查 authd.passDashboard 页面有数据但事件不显示Filebeat 输出地址错误或证书缺失检查/etc/filebeat/filebeat.yml事件时间差 8 小时系统时区未统一timedatectl set-timezone Asia/Shanghai5.2 一套我实测能跑通的 All-in-One 快速部署清单如果你想要一个比较顺滑的部署流程可以照我这个清单来操作每完成一步确认一下再走下一步准备一台 Rocky Linux 8 或 Ubuntu 22.04 的虚拟机分配 8G 内存2 核以上硬盘 50G。设置干净的主机名编辑/etc/hosts回填本机 IP 和主机名。执行sysctl -w vm.max_map_count262144并写入配置文件永久生效。关闭 SELinuxRHEL 系或临时放行端口确保没有防火墙挡路。下载wazuh-install.sh分步执行先生成配置文件再装 Indexer。确认systemctl status wazuh-indexer为 active 后再开始装 Manager。配置 Filebeat替换/etc/filebeat/filebeat.yml里的 hosts 为 Indexer IP重启服务确认日志无报错。最后装 Dashboard配置opensearch_dashboards.yml确认 Web 界面能打开。用浏览器访问https://dashboard-ip用安装输出里的账号密码登录先在“总览”页面确认数据不为空。再安装第一台 agent看状态是否变 Active。这套流程走下来大部分人的安装都能在半天内结束。5.3 最后几条血泪经验先说说我在一次环境里踩过的链式故障那台机器内存只有 4G但我把 Indexer 的 JVM 堆调成了 3G然后 Dashboard 就反复 OOM每次拉起 Dashboard 都把系统内存吃满Manager 也跟着遭殃agent 事件全部积压。最后我把堆调回 2G同时加了 2G 的 swap 才勉强稳住。所以Wazuh 的组件不是分配的资源越多越好要综合考虑整台机器的内存余量。另外所有服务日志的位置一定要记熟它们是排查问题的第一任老师Indexer 日志/var/log/wazuh-indexer/Manager 日志/var/log/wazuh-manager/Dashboard 日志/var/log/wazuh-dashboard/Filebeat 日志/var/log/filebeat/遇到安装异常的时候先systemctl status 服务名看服务状态再用journalctl -u 服务名 -f看实时日志最后去对应日志目录翻详细错误。不要一上来就怀疑官网文档写错了99% 的问题都出在环境差异上而不是软件本身的 bug。根据我自己的经验还有一个小技巧值得分享装组件前先打好虚拟机快照每成功装完一个组件打一个快照。这样如果你在后面的步骤里把配置改坏了直接回滚到上一个快照重来比反复清包卸载要快多了。Wazuh 的卸载残留也很讨厌重装时如果没清干净旧证书和旧配置后面会一直受到旧证书干扰。我自己就吃过这个亏后来干脆养成了“先快照后动手”的习惯整个安装过程的试错成本一下就降下来了。