Wazuh 这个开源安全监控平台我第一次装的时候差点被劝退。它在功能上整合了主机入侵检测、日志分析、文件完整性监控、漏洞检测和 SIEM 事件关联几乎一家伙把安全运维的日常需求都覆盖了。但真正折磨人的地方是它的安装过程自签证书、组件通信、索引存储、Web 仪表板每一环都藏着意想不到的“小脾气”。前阵子我在测试环境又从零部署了一遍 Wazuh 4.x把之前散落的坑系统整理了一遍这次写下来希望能让准备入坑的朋友少走点弯路。Wazuh 到底解决什么问题往小了说你可以用它实时盯住服务器上的可疑登录、关键文件改动、恶意进程和漏洞扫描结果往大了说它能把分散在各机器上的安全日志统一收拢、建立告警规则、形成可视化报表。这篇内容围绕 Wazuh 服务器端和 agent 端的安装踩坑展开用的是最常见的单机 All-in-One 部署方式适合刚接触 Wazuh 的运维同学、想在测试环境快速跑起来的人以及正在被各种依赖错误和连接问题折磨的技术同行。1. 安装前先把架构搞清楚Wazuh 这几个组件都是干什么的1.1 核心组件的关系很多人一上来就执行安装脚本装了一半发现卡住然后开始乱试最后又重装系统。这不是技术问题而是没搞明白 Wazuh 的组件关系。Wazuh 4.x 主要由三个服务端组件和一个客户端 agent 组成。Wazuh manager 是核心引擎负责接收 agent 上报的数据执行规则分析、告警、主动响应等任务。它内部其实是一组守护进程比如处理日志采集的 wazuh-analysisd、负责远程连接收数据的 wazuh-remoted、管理 agent 注册的 wazuh-authd、以及执行命令的 wazuh-execd。凡是 agent 跟服务器之间的通信、策略下发、事件分析都是 manager 的工作。Wazuh indexer 是数据存储和检索引擎基于 OpenSearch 改造而来老版本里叫 Wazuh Elasticsearch。它的作用就是把 manager 生成的告警和事件数据索引化让 Dashboard 能够快速搜索和展示。这个组件也是最吃内存、最吃磁盘的角色很多安装失败都发生在它身上。Wazuh dashboard 是用户操作的 Web 界面基于 OpenSearch Dashboards 改造提供安全事件查询、规则配置、agent 管理、系统状态监控等功能。装好之后用户打开浏览器访问 HTTPS 地址看到的管理后台就是它。Wazuh agent 是部署在受监控主机上的轻量客户端负责采集系统日志、配置审计、文件完整性、命令执行结果等信息并通过加密通道发送给 manager。Linux、Windows、macOS、FreeBSD、Solaris 等系统都有对应版本。数据流向大致是这样的agent 收集数据 → 发送到 manager默认监听 1514/TCP 或 UDP→ manager 经过规则引擎分析后生成 alert 事件 → 写入本地 alerts.json → 由 Filebeat 转发到 indexer默认 9200/TCP→ 索引后供 dashboard 查询。理解这条链路后面排查问题就会很轻松。1.2 部署模式怎么选Wazuh 官方提供几种部署方式All-in-One 单机部署、分布式多节点部署、以及容器化部署。我这次用得多的是 All-in-One也就是把 manager、indexer、dashboard 三件套都装在同一台服务器上适合测试环境、小型环境或者作为学习平台。官方提供的 wazuh-install.sh 脚本默认就是帮你把这几个组件全部配置好包括自签证书、Filebeat 配置、初始账号密码都可以自动生成。生产环境如果规模大了建议把 indexer 独立拆出去甚至可以组成三节点集群manager 和 dashboard 也分层部署。不过这种部署方式需要手动生成证书、手动配置集群发现、手动调堆内存复杂度不是普通新手能短时间驾驭的。所以我的建议很直接如果你是第一次接触 Wazuh或者只是在内部测试先用单机 All-in-One 跑通等真正理解了数据链路再考虑分布式拆分。不要一上来就追求复杂架构那会让排错难度翻好几倍。还有一种方式是直接拉 Docker 镜像跑确实能缩短部署时间但容器内的日志持久化、证书挂载、端口映射反而是另一套排错逻辑。Windows 下很多人想用 Hyper-V 或者 WSL 跑实际体验并不好Wazuh 官方对 Docker 的定位是快速体验长期稳定运行我仍然推荐原生 Linux 部署。2. 服务器端安装以及我踩过的那些坑2.1 环境准备阶段的三个细节我把环境准备放在最前面是因为这一步漏掉任何一个后面都可能出现“看上去没问题装完却不工作”的情况。第一是系统版本。Wazuh 官方支持的 Linux 发行版包括 CentOS、RHEL、Rocky Linux、AlmaLinux、Ubuntu、Debian 等。我自己在 CentOS 7 和 Rocky Linux 9 上都试过能跑通。需要注意的是 CentOS 7 比较老可能需要额外处理 Python、依赖库的问题如果你有条件直接用 Ubuntu 22.04 或 Rocky Linux 9 更省事。32 位系统不用想Wazuh 只支持 64 位。第二是资源规划。单机 All-in-One 的最低配置官方写的是 4GB 内存、2 核 CPU但这只是“能启动”的级别。实际使用中如果 indexer 还在写入数据dashboard 又有人在查询4GB 内存会显得非常紧张时不时就发生 OOM。我建议至少给 4 核 8GB 内存磁盘 20GB 空闲空间起步。另外agent 和 indexer 的数据日志都在增长磁盘太小会产生一连串连锁故障。第三是内核参数和系统限制。OpenSearch 对虚拟内存映射数量有硬性要求执行下面的命令检查并调整sysctl -w vm.max_map_count262144 echo vm.max_map_count262144 /etc/sysctl.conf sysctl -p文件描述符限制也容易被忽略。如果这个值太小Wazuh 组件长期运行时会出现文件句柄耗尽服务状态看起来是 active但日志里全是报错。可以在/etc/security/limits.conf里加上* soft nofile 65535 * hard nofile 65535修改完后重新登录 shell 生效。系统时间同样重要证书和 TLS 握手对时间同步非常敏感时间差太多的话agent 注册时会出现“certificate verify failed”或者“clock skew”错误。可以先跑一下timedatectl set-ntp true并确认时区是你期望的时区。2.2 用安装脚本部署的完整步骤Wazuh 4.x 官方推荐用安装脚本进行 All-in-One 部署。下面以 4.7 版本为例流程大致如下# 1. 切换到 root脚本需要管理员权限 sudo su - # 2. 下载安装脚本 curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh.sha256 # 3. 校验完整性 sha256sum wazuh-install.sh cat wazuh-install.sh.sha256sha256 比对无误后先只生成配置文件不执行安装。这一步的官方理由是它会生成集群所需的证书和密码信息你可以提前检查bash wazuh-install.sh --generate-config-files执行后会在同级目录生成wazuh-install-files.tar里面包含了所有证书文件和初始密码。之后正式安装bash wazuh-install.sh --install脚本会依次安装 wazuh-indexer、wazuh-manager、wazuh-dashboard并进行配置和启动。整个安装过程比较长因为要下载大量 RPM/DEB 包和 Java 运行时。安装结束后屏幕会打印一个admin用户的随机密码以及 dashboard 的登录地址请立刻复制保存后面登录要用。安装期间如果网速不好不建议反复中断重来因为脚本不是幂等的中断后残留的配置可能导致下一次安装出现冲突。更稳的做法是在安装前确认你访问官方软件源的速度正常必要时给服务器配置好可用的 DNS。安装过程中如果想看进度可以同时在另一个终端里跟踪日志tail -f /var/log/wazuh-install.log日志文件里会有每一步是否成功的记录出错时通常能看到比较明显的错误关键字比如ERROR:,FAILED,no-space-left等。2.3 服务器端安装中最常见的三类异常我在多台机器上安装遇到最多的问题首先是磁盘空间。安装到 wazuh-indexer 时RPM 包非常大它依赖的 OpenSearch 下载包动辄几百 MB加上索引初始化和日志如果/var所在分区只剩几个 G很容易在解压阶段报No space left on device。这个问题的处理方法很简单安装前用df -h /var确认剩余空间最少留出 10GB最好是 20GB 以上。其次是内存不足导致的进程被 OOM Killer 杀掉。现象是安装完成后 dashboard 和 indexer 服务活了一会儿随后systemctl status显示 active但一刷页面就报连接失败。查看系统日志dmesg -T | tail -50能看到killed process (java)之类的记录。临时手段是增加 swap比如fallocate -l 4G /swapfile chmod 600 /swapfile mkswap /swapfile swapon /swapfile echo /swapfile none swap sw 0 0 /etc/fstab但要记住swap 能改善临时表现为真正要跑生产还是老老实实加内存。还有一个坑是网络源问题。国内网络环境下访问 Wazuh 官方软件源偶尔会特别慢导致脚本在Install Wazuh indexer环节一直卡住。这个问题的处理方式不是换源而是先确保服务器能正常访问外网如果确实下载不稳定可以把 packages 下载任务拆开先手动下载需要的 rpm/deb 包再让脚本安装。不过手动改源也不会简单到哪里去我更推荐的做法是选择网络状况较好的时间段执行安装不要让脚本长时间挂着不管。3. agent 部署和连接问题排查3.1 安装 agent 之前先确认这三个问题很多人在服务器端装好后兴冲冲去装 agent装完一看状态是 never connected 或者 disconnected就开始怀疑配置。其实 agent 安装前有几个问题必须先问自己。第一个问题agent 所在的机器能不能访问到 manager 的 1514 端口和 1515 端口1514 是数据上报端口1515 是 agent 注册端口。如果 manager 和 agent 之间隔了防火墙、安全组、或者 TSD 网络策略必须先放行。用最简单的命令验证telnet manager_ip 1515如果网络不同这个端口测试是过不去的那连接问题就跟 agent 配置本身无关先修网络。第二个问题使用的是什么注册方式Wazuh 支持 agent 自动注册默认在 manager 上会开放 1515/UDP? 实际上是 authd 监听 1515/TCPagent 安装时设置WAZUH_AGENT_NAME和WAZUH_MANAGER变量即可完成注册。如果使用代理或手动安装需要在/var/ossec/etc/ossec.conf里修改 manager 地址。Windows agent 在安装时会把环境变量转成配置项安装后想改地址就要去C:\Program Files (x86)\ossec-agent\ossec.conf修改clientserveraddress这一节。第三个问题agent 的 hostname 是否唯一如果多个 agent 取了相同的名称manager 侧会出现客户端 key 冲突一个 agent 把另一个挤下线。为了避免这个问题我建议 agent 名称就用主机名加用途后缀比如web01-nginx、db01-mysql。3.2 agent 装完连不上按这个顺序查我在实际使用中agent 连不上 manager 的排查路径基本是固定的。先看 agent 端日志Linux 上默认位置是/var/ossec/logs/ossec.logWindows 上在安装目录的logs目录。日志里最典型的错误是ERROR: Error receiving response from manager或WARNING: Invalid response from auth server说明注册阶段就没走通。然后确认 manager 的认证进程有没有在跑systemctl status wazuh-manager ss -lntp | grep -E 1514|1515如果监听端口没问题再用tcpdump抓包确认能不能收到 agent 的请求tcpdump -i any port 1515 -nn如果抓不到包说明 agent 到 manager 的网络路径有问题检查防火墙和安全组。如果抓到了包但 agent 仍然注册失败大概率是证书或时间问题。生产环境里不少老机器时间不准agent 和 manager 之间的 TLS 证书验证会失败。把系统时间同步好再重启 agent。还有一种常见情况是安装 agent 时把 manager IP 写错了之后修改了配置文件但没有完全重启 agent。在 Linux 上重启 agent 的正确做法是systemctl restart wazuh-agent不要只执行/var/ossec/bin/ossec-control start因为它可能没有重新读取配置。Windows 上则是通过服务管理器重启Wazuh服务并确认环境变量已生效。3.3 active 状态反复跃迁通常是这几个原因agent 成功注册后dashboard 上会显示 active。如果看到 agent 的状态时而 active、时而 disconnected说明连接不稳定不要先怀疑 Wazuh bug优先检查下面几个点。第一是 agent 和 manager 之间的网络质量特别是跨网段或者经过隧道时丢包会导致连接中断。可以用ping manager_ip和iperf3测试长期稳定性如果丢包率高需要从路由、MTU、带宽占用这几个方向排查。第二是 manager 的并发连接数限制或文件描述符限制。当受管主机特别多时默认配置会出现资源瓶颈。可以调整 manager 的/var/ossec/etc/ossec.conf中remote部分的逐项设置比如max_concurrency_sessions然后再重启 wazuh-manager。不过单机测试环境一般不会触及这个瓶颈更多是低配服务器接待不了太多 agent。第三是 agent key 老化或者重复注册。当 agent 被 dashboard 删除但机器上 agent 进程还在继续上报会出现认证不一致。这种情况下最好的办法是在 dashboard 里重新添加 agent并重新执行 agent 注册命令必要时先停 agent删掉本地的client.keys再重新注册。4. 装完之后的验证、排错和经验沉淀4.1 上线前要做的健康检查安装成功不等于运行成功。我通常会在正式接入 agent 之前把下面这些检查动作全部做一遍。先看组件服务状态systemctl status wazuh-manager wazuh-indexer wazuh-dashboard三个服务都显示 active (running) 后再验证 indexer 的集群健康状态。在服务器本机执行curl -k -u admin:密码 https://localhost:9200/_cluster/health?pretty如果status是green或yellow都是正常red就说明索引有分片异常需要结合/var/log/wazuh-indexer/wazuh-indexer.log继续查。这里要注意admin 密码就是安装脚本生成的初始密码如果忘记可以通过重置密码脚本处理。然后验证 manager 的 API 是否正常curl -k -u admin:密码 https://localhost:55000/security/users?pretty如果有成功响应说明 API 服务正常。最后打开浏览器访问https://服务器IP用 admin 登录 dashboard进入后看左下角的 agent 数量是否能显示出来。还没接入 agent 时不要急着说部署失败。先在 manager 上手动制造一条测试事件验证整条链路echo Wazuh test alert /var/log/test-alert.log然后配置一个临时监控规则或者直接用 Wazuh 默认规则。更简单的方法是通过 dashboard 的“模块 → 安全事件”页面看看是否能定期收到日志。如果 dashboard 始终没有任何数据优先查看/var/ossec/logs/alerts/alerts.json里有没有写入。如果这里没有数据说明问题出在 agent 或采集端如果这里有数据但 dashboard 看不到问题就出在 Filebeat 或 indexer 上。4.2 常见问题速查表下面这张表是我自己在多次安装和排障中整理出来的高频问题挺实用建议收藏。现象可能原因处理建议浏览器无法访问 dashboardwazuh-dashboard 未启动端口被占用证书错误用systemctl status wazuh-dashboard查看使用ss -lntp | grep 443检查端口清理浏览器缓存或用无痕窗口访问登录后安全事件模块空白Filebeat 未正确发送数据索引模板缺失执行filebeat test output查看输出端连接确认/etc/filebeat/filebeat.yml中主机指向 indexer 地址进入 Stack Management 检查索引模板是否存在agent 显示 never connectedagent 注册流程未完成网络不通查看 agent 端 ossec.log确认 1515 端口能 telnet 通重新执行注册命令agent 间歇性 disconnected网络抖动manager 并发限制key 冲突检查网络丢包查看 manager 日志删除冗余 agent 后重新注册索引器集群状态 red磁盘满分片分配失败节点配置错误清理磁盘空间检查索引分片状态查看 indexer 日志里的具体异常安装脚本卡在下载阶段网络源不稳定磁盘空间不足确认/var空间足够稍后重试优先在网络稳定时段安装重启后服务起不来内存不足文件句柄耗尽配置路径不对用dmesg -T查看 OOM检查 limits.conf确认加载的配置文件和实际目录一致除了表格外我觉得最值得记录的一点是不要过度依赖 dashboard 上显示的状态。Wazuh 是一个链路式系统上层显示 active 不代表数据一定正确入库一定要训练自己从日志出发的排查思路。比如 agent 状态是 active但 dashboard 没有数据那就要按“agent → manager → filebeat → indexer → dashboard”的顺序逐层看日志而不是直接怀疑 dashboard 坏了。4.3 从踩坑到稳定运行的几点优化安装完成后如果要让 Wazuh 长期稳定运行有几个优化点是跑不掉的。第一调整 indexer 的 JVM 堆内存。默认安装脚本会配置得相对保守在低配服务器上反而不够用。我习惯手动修改/etc/wazuh-indexer/jvm.options里的-Xms和-Xmx一般设为物理内存的一半但不能超过 32G。修改后重启 wazuh-indexersystemctl restart wazuh-indexer如果机器只有 4G 内存建议把堆内存设为 1-2G给系统和其他组件留出余量。这个参数不是越大越好堆内存过大会导致 GC 暂停反而影响稳定性。第二给索引数据配置生命周期管理。Wazuh 的告警数据会不断写入 indexer时间久了磁盘会被索引撑爆。官方推荐给索引设置 ILMIndex Lifecycle Management策略或者直接用索引抹除脚本定期清理 90 天前的数据。我自己写了一个简单的 cron 任务每天凌晨清理 90 天以上的告警索引保证磁盘占用可控。第三备份关键配置。Wazuh 的配置分散在几个地方manager 在/var/ossec/etcindexer 在/etc/wazuh-indexerdashboard 在/etc/wazuh-dashboardFilebeat 在/etc/filebeat。升级或者改动前把这几目录打包备份出问题可以快速回滚。证书目录尤其要备份因为重装时还需要它们一旦丢失所有 agent 都要重新注册。第四监控 Wazuh 自身的服务状态。我见过太多人只监控业务系统反而忽略了安全平台本身。建议把 wazuh-manager、wazuh-indexer、wazuh-dashboard 的服务状态以及磁盘使用率、内存使用率都纳入监控告警。Wazuh 本身也有“agent 失联告警”和“服务状态告警”能力可以在 dashboard 里配好通知这样即使平台自己出现问题也能第一时间收到消息。5. 升级和维护当中容易忽略的雷区5.1 先搞清楚升级顺序Wazuh 的版本升级不是点一下按钮就完事。从 4.x 的老版本升到新版本顺序应该是先升级 indexer再升级 manager 和 dashboard最后升级 agent。如果先动了 manager旧版本 agent 可能会因为协议变化导致无法连接如果先升级 dashboard它可能连不上旧版 indexer。实际动手前务必把所有配置都备份好尤其是自定义规则、解码器、配置文件然后去官方升级文档确认当前版本到目标版本的迁移路径。我踩过最深的坑是升级过程中服务正常但 indexer 的映射模板没有自动更新旧索引数据无法被 dashboard 正常加载。这种情况通常不是升级失败而是没有清理旧索引模板或者没有重建索引模式。解决办法是在 dashboard 的 Index Patterns 里刷新索引模式或者手动删除旧的wazuh-*索引模式后重新创建。5.2 agent 大批量升级的方法如果你管理几十台机器一台台进终端执行升级命令会累到怀疑人生。Wazuh 支持通过 dashboard 的“Agent Upgrade”功能批量下发升级任务也可以提前把 agent 安装包放到本地 HTTP 服务器配合 Ansible、Salt 或自研脚本批量推送。批量升级前要特别注意版本跨度比如从 4.2 直接跨到 4.7某些配置可能不兼容建议在测试 agent 上先跑通再分批次升级。升级过程中 agent 的状态可能会短暂变为 disconncted这是正常现象。等待 agent 重新连接后确认版本号已更新、规则集已同步、以及本地日志采集没有丢失太多数据。如果升级后 agent 持续无法连接优先对比升级前后的 ossec.conf 配置看看是不是新版本改了默认值或者新增了属性。5.3 维护当中的一个体会Wazuh 这类开源安全平台刚装完的那一周最容易出问题后面反而会越来越稳定。原因很简单第一周你能把网络、证书、配置、资源这些问题全暴露出来解决完了剩下的就是日常入库和告警优化。我个人的体会是安装踩坑不要怕关键是每次踩坑后要把日志和排查路径记录下来。比如你改了什么参数、重启了什么服务、日志里出现了哪些关键字写成自己的排错手册。这比任何官方文档都管用因为官方文档是静态的而你的环境是动态的。最后再分享一个小技巧如果 dashboard 页面可用但告警数据偏少先别急着怀疑安全事件没有发生可能是 agent 的采集范围不够。默认 Wazuh agent 只采集系统日志、审计日志和文件完整性信息很多业务日志需要你手动配置 localfile 或者应用级日志采集规则。把需要的日志文件路径加入 agent 的 ossec.conf 的localfile模块再重启 agent很快你就能在 dashboard 上看到新的事件流。这个操作我做过很多次是让 Wazuh 从“能用”变成“好用”的关键一步。