1. 为什么Wazuh最难的不是使用而是第一步安装先交代一下背景。我大概在一年前第一次接触Wazuh当时公司内部需要一个开源的安全监控平台能把服务器上的入侵检测、漏洞扫描、日志分析和文件完整性监控统一起来。调研了一圈Suricata偏流量侧OSSEC单纯做HIDS而Wazuh既有HIDS能力又带SIEM的日志分析功能还有比较完整的Web管理界面看起来是性价比最高的选择。但说真的Wazuh最大的门槛不在你后期怎么写规则、怎么配告警而是安装这一步就能劝退一大批人。我见过有人在虚拟机里折腾了整整一周最后连Dashboard的登录页都没看到也见过照着官方文档一步一步执行结果因为一个端口没放开整个安装过程全部作废。这个现象不奇怪。Wazuh不是那种一条命令装完就跑的轻量工具它的架构里包含索引器、服务器端组件、Dashboard前端和Agent端四部分任何一个环节出问题都会表现为服务起来了但连不上或者页面打不开。更麻烦的是官方文档里给出的快速安装方式虽然简化了命令但对系统资源和网络环境的要求非常硬核很多人在第一步就栽了。这篇文章我就把自己的实际安装过程、踩过的坑、排查的链路和最终采用的稳妥方案完整记录下来。无论你是第一次尝试Wazuh的初学者还是已经部署过一两次但被各种报错折磨过的运维这篇文章应该都能帮你省下不少时间。2. 部署前的环境核对这些细节没做好后面全是连环坑2.1 官方给的最低配置是所有坑的根源先直接把结论放在这里Wazuh官方文档写的最低硬件要求在真实部署场景里几乎跑不动。官方口径是2个CPU、4GB内存起步我实测下来4GB内存的虚拟机装完四组件之后系统可用内存只剩三四百MB索引器一启动就开始疯狂交换分区Dashboard页面转圈圈Agent注册后状态迟迟不显示Active。如果你的环境是虚拟机建议直接按以下配比来资源项AIO一体化安装最低建议拆分安装服务端索引器DashboardCPU4核服务端4核索引器4核Dashboard2核内存8GB实测10GB更稳服务端6GB索引器8GBDashboard2GB磁盘50GB索引器单独给100GB以上SSD系统Ubuntu 22.04 LTS / 24.04 LTS同左避免用CentOS 7这个表是我折腾了各种配置之后总结出来的舒服线。低于这个规格不是一定起不来但你会陷入装完—内存不足—服务挂掉—重启—又挂掉的循环排查起来极其痛苦。2.2 网络规划别偷懒主机名必须提前想好Wazuh安装过程中会生成自签名证书而证书里的CommonName跟你的主机名强绑定。如果你安装之后改了hostname证书校验就会失败Dashboard会报Invalid certificate之类的错误服务之间的通信也会出问题。我推荐的做法是在安装之前就定好主机名比如wazuh-server然后把它写进/etc/hosts并且保证本机的hostname和hostname -f解析结果一致。这里有个很隐蔽的细节很多人只改了/etc/hostname没有同步改/etc/hosts结果hostname -f返回的还是旧名字或者空值安装脚本在生成证书的时候就会出各种灵异问题。sudo hostnamectl set-hostname wazuh-server echo 127.0.0.1 wazuh-server | sudo tee -a /etc/hosts hostname -f确认最后一条命令输出的是wazuh-server再继续下一步。2.3 防火墙是最大的隐形杀手很多人在配置完一切之后发现Dashboard页面打不开第一反应是服务没起来各种查日志、重启服务折腾半天才发现是防火墙把端口拦了。Wazuh的端口清单比较长而且不同版本会有细微差异这里以4.7/4.8为例端口用途55000/TCPWazuh Server的RESTful API1514/TCPAgent日志接收1515/TCPAgent注册1516/TCPAgent群组管理443/TCPDashboard Web访问9300/TCP索引器节点间通信9200/TCP索引器RESTful接口仅本机必要时如果你用的是ufw直接这样放行sudo ufw allow 55000/tcp sudo ufw allow 1514/tcp sudo ufw allow 1515/tcp sudo ufw allow 1516/tcp sudo ufw allow 443/tcp sudo ufw allow 9300/tcp sudo ufw reload如果你在云服务器上部署除了系统防火墙还要去安全组里放行。这一步最容易漏掉因为很多时候你在服务器本机测试端口是通的但外部访问就是不行问题就出在安全组上。2.4 系统源和基础依赖先处理干净Wazuh的安装脚本会依赖curl、tar、openssl、python3这些基础工具以及systemd的正常工作。我遇到过一台最小化安装的Ubuntu连curl都没有安装脚本直接在下载阶段就报错。所以先跑一遍sudo apt update sudo apt upgrade -y sudo apt install -y curl tar openssl python3 python3-pip systemd另外Swap空间建议至少配4GB。虽然前面我吐槽了内存不足会触发Swap但在部署初期Swap可以避免OOM直接杀掉进程。等后面稳定运行了你可以在/etc/wazuh-indexer/jvm.options里调整堆大小。3. 两种安装路径的差异与各自的坑3.1 一体化快速安装AIO适合什么场景Wazuh官方现在推荐一体化安装All-in-One也就是一条命令把Wazuh Indexer、Wazuh Server和Wazuh Dashboard都装在同一台机器上。命令很简单curl -sO https://packages.wazuh.com/4.8/wazuh-install.sh sudo bash wazuh-install.sh --generate-config-files sudo bash wazuh-install.sh --install装完后脚本会输出一个随机生成的Dashboard密码用这个密码就能登录Web界面。如果你是在生产环境之外做测试验证或者团队规模在几台主机以内这种装法完全够用。AIO的坑在于第一对内存的要求更高因为三个组件挤在一起我实测8GB内存才能稳定运行4GB会频繁出现索引器进程被OOM第二一旦系统里已经有其他服务占用了443或9200端口安装脚本会直接卡住或者报错。我遇到一次是因为机器上提前装了一个Nginx占了443端口安装过程卡在Dashboard配置阶段排查了很长时间才发现问题。3.2 分布式拆分安装更稳妥的逻辑如果你要监控的主机数量超过50台或者对数据保留周期有较长要求建议把Wazuh Indexer和Server拆到两台机器上甚至在更大规模下把索引器单独扩展到三个节点。分布式安装的好处是各组件资源不互相争抢出问题的时候排查边界也清晰。但代价是安装配置要多好几个步骤你需要先装索引器集群再装服务端并指向索引器地址最后装Dashboard并完成证书分发。证书这块是分布式安装最容易出错的地方官方脚本生成的一套证书文件在拷贝到各节点的时候要确保路径和权限都一致否则节点间通信就起不来。3.3 我最终采用的安装方式结合自身的实际使用场景我最终用的是AIO安装加手动调整JVM参数的方式。这台机器跑的是Ubuntu 22.04给了4核8GB内存系统装在一块NVMe SSD上数据目录我单独挂了一块100GB的虚拟磁盘。安装命令执行完之后我没有立刻去登录Dashboard而是先把各服务状态检查了一遍sudo systemctl status wazuh-indexer sudo systemctl status wazuh-manager sudo systemctl status wazuh-dashboard sudo systemctl status filebeat这四个服务都必须是active (running)状态任何一个不对都别急着往下走先解决当前问题再继续。不要相信反正待会还会自动启动这种侥幸心理Wazuh启动失败经常是连环式的一个组件没起来会导致后续依赖它的组件全部异常。4. 安装过程中最常见的七个报错与处理顺序4.1 内存不足导致索引器反复崩溃这个放在第一个讲因为它是新手的头号杀手。现象是安装过程看着一切正常装完后wazuh-indexer服务一会儿就挂journalctl里出现Out of memory或者java.lang.OutOfMemoryError。根本原因是Wazuh索引器基于OpenSearch默认JVM堆内存设置是机器物理内存的50%在8GB机器上就是4GB堆加上索引进程实际运行开销整个索引器会吃掉接近7GB内存一旦机器上还有其他服务系统内存就爆了。解决办法是修改JVM堆大小sudo vi /etc/wazuh-indexer/jvm.options找到-Xms和-Xmx改成-Xms2g -Xmx2g改完之后重启sudo systemctl restart wazuh-indexer这里有个经验JVM堆大小不要把-Xms和-Xmx设置成不同值Wazuh官方推荐设成一致避免运行时堆动态扩容带来的性能波动。4.2 Dashboard页面打不开443端口没有任何响应如果你访问https://你的IP始终转圈或者提示拒绝连接先检查Dashboard服务状态如果状态正常再用ss -lntp | grep 443看端口是否真的在监听。常见原因有三个防火墙没放行、Dashboard服务根本没起来、或者服务起来但监听的地址不是所有网卡。第三个问题比较隐蔽Wazuh Dashboard默认监听地址是0.0.0.0但如果你在配置文件里改过server.host就可能导致只能本机访问。检查方式sudo grep -r server.host /etc/wazuh-dashboard/opensearch_dashboards.yml正常应该看到server.host: 0.0.0.0。如果改成了localhost或具体IP改成0.0.0.0再重启。4.3 Agent注册不上一直显示Disconnected这个问题排在第三是因为它完全没有报错但就是连不上。现象是你在另一台机器上装了Agent之后/var/ossec/etc/ossec.conf里配置的address写的是服务器的IP但Dashboard上Agent状态永远是Disconnected。排查链路是这样的先在服务器上确认1514和1515端口在监听在Agent机器上用telnet 服务器IP 1514和1515测试端口连通性如果端口不通检查防火墙和安全组如果端口通但Agent还是连不上看Agent日志/var/ossec/logs/ossec.log我遇到过一次很经典的场景防火墙全开了端口也是通的Agent日志里反复出现ERROR: Invalid signature。最后发现是Agent和Server的版本不一致Agent版本比Server新导致通信密钥校验失败。Wazuh的版本兼容性比较严格官方要求Agent和Server保持同版本。解决办法也很简单curl -s https://packages.wazuh.com/4.x/apt/ | sudo tee /etc/apt/sources.list.d/wazuh.list sudo apt update sudo apt install wazuh-agent -y或者直接用打包好的版本覆盖安装然后重启Agent服务。4.4 Filebeat数据管道连接失败Dashboard能登录但服务器管理页面的数据始终显示不出来告警也没有信息这时候大概率是Filebeat没有成功把数据推送到索引器。排查命令sudo /usr/share/filebeat/filebeat test output正常情况下会输出elasticsearch: http://127.0.0.1:9200...并显示Connection successful。如果显示连接失败检查Filebeat配置文件/etc/filebeat/filebeat.yml中的output.elasticsearch.hosts是不是指向了正确的索引器地址。还有一个容易忽略的点Filebeat和索引器之间的TLS证书校验。如果ssl.certificate_authorities指向的证书文件路径不对或者文件权限不对Filebeat会一直报TLS握手失败。把证书路径列出来检查sudo ls -l /etc/filebeat/certs/看到证书文件存在且有读权限再重启Filebeat。4.5 安装脚本卡在Installing Wazuh indexer长时间没反应这个坑我没少遇到原因多半是下载依赖包太慢或者网络到Wazuh官方仓库的连接不稳定。Wazuh的安装脚本会从packages.wazuh.com下载索引器、Dashboards、Agent等一堆软件包在网络环境不太好的时候下载到一半就卡死了。遇到这种情况不建议反复重跑安装脚本因为残留的配置和未完成的安装状态会导致二次安装报错。正确的做法是sudo bash wazuh-install.sh --uninstall先做干净卸载然后把/etc/wazuh-indexer、/etc/wazuh-dashboard、/var/lib/wazuh-indexer等残留目录手动清理掉再重新安装。另外可以尝试配置国内镜像源sudo vi /etc/apt/sources.list.d/wazuh.list把URL改成可访问的镜像地址或者直接下载deb包手动安装。我实际测试下来配置代理是最省事的方案如果没有代理就用离线安装包的方式避免反复卡下载。4.6 证书校验失败导致索引器集群无法启动分布式安装时索引器节点之间要互相信任。如果你的节点是从其他机器拷贝证书过来的很容易出现证书的CN和节点主机名不匹配的问题。报错关键字在/var/log/wazuh-indexer/wazuh-indexer.log里会看到SSLHandshakeException PKIX path building failed解决方案是重新生成证书。注意Wazuh官方脚本生成的证书是针对安装时的主机名和IP生成的所以如果你拷贝到另一台机器使用必须保证那台机器的主机名和IP与生成证书时一致。更稳妥的做法是在每台节点上分别生成证书文件而不是拷贝同一套。4.7 Dashboard登录后显示Security无法访问或者API显示红点Dashboard能进去但API连接显示异常首先要检查Wazuh Server的API服务是否正常curl -k -u wazuh-wui:wazuh-wui https://localhost:55000/如果返回401 Authorization Required说明API服务在正常工作问题出在Dashboard和Server之间的认证配置。如果连接被拒绝检查/etc/wazuh-dashboard/opensearch_dashboards.yml里的wazuh配置段的hosts是否指向了正确的Server API地址。另一个常见的原因是API用户wazuh-wui的密码变了但你不知道。Wazuh安装脚本会随机生成这个密码并写入配置如果你之前手动重置过API密码Dashboard里的配置就不会自动更新。这种时候直接去Dashboard的配置页面重新填一遍API连接信息即可。5. 服务起不来时的排查链路比重装更省事5.1 从systemd日志里找真正的关键词安装完之后遇到服务起不来的情况很多人的第一反应是去翻安装脚本的输出日志。但装完之后的运行期问题最好的入口是systemd日志。以Wazuh Manager为例sudo journalctl -u wazuh-manager --no-pager -n 100这里的输出会直接告诉你报错的关键词。我印象最深刻的一次是wazuh-manager起来之后过几秒就自己退了日志里只有一行ERROR: Unable to open file: /var/ossec/etc/ossec.conf: No such file or directory后来一查是之前手动清理时把/var/ossec目录删得太干净连配置文件一起没了。重新复制配置模板后服务就正常了。5.2 检查文件和目录权限Wazuh对权限的要求比较严格尤其是/var/ossec目录下所有文件的属主必须是wazuh:wazuh。如果你用root去修改过配置文件或者拷贝文件时没有保留属主信息服务就会出各种莫名其妙的问题。sudo chown -R wazuh:wazuh /var/ossec还有索引器的数据目录sudo chown -R wazuh-indexer:wazuh-indexer /var/lib/wazuh-indexer sudo chown -R wazuh-indexer:wazuh-indexer /var/log/wazuh-indexer一个隐藏比较深的细节是证书文件。Wazuh安装时会把OpenSearch证书放在/etc/wazuh-indexer/certs如果这些文件的权限包含了group或other的可读权限OpenSearch会在启动时报错提示私钥文件权限过大。处理方式sudo chmod 600 /etc/wazuh-indexer/certs/*.key sudo chmod 644 /etc/wazuh-indexer/certs/*.pem5.3 vm.max_map_count不达标导致索引器异常退出这是OpenSearch系产品的经典坑跟Wazuh本身无关但影响一致。安装完索引器后启动过程中可能会出现ERROR: [1] bootstrap checks failed其中一项就是max virtual memory areas vm.max_map_count [65530] is too low。解决方案sudo sysctl -w vm.max_map_count262144 echo vm.max_map_count262144 | sudo tee -a /etc/sysctl.conf改完不用重启系统重新启动索引器即可。这个问题在Docker部署方式下尤其常见因为宿主机内核参数会直接影响容器内进程。5.4 磁盘空间被日志撑爆Wazuh的日志和分析组件都很健谈尤其是索引器的工作日志和数据目录在短时间内就能吃掉几个GB。如果你部署时磁盘只给了20GB可能运行不到一周就被数据写满然后各种服务开始报磁盘空间不足的错。建议在安装完后检查一下日志轮转配置sudo cat /etc/logrotate.d/wazuh如果你的环境中没有自动清理策略可以手动清理索引数据。还可以在Dashboard的Indexer Management里配置索引生命周期策略规定数据保留天数超过的数据自动删除。6. 首次登录后必须立即做的验证和收尾工作6.1 确认四个组件都处于健康状态安装完、服务都起来之后先不要急着去配置告警规则。用下面一组命令验证系统是否真的健康# 索引器集群状态 curl -k -u admin:你的密码 https://localhost:9200/_cluster/health?pretty # 预期结果是 status 为 green 或 yellow # Filebeat 输出测试 sudo /usr/share/filebeat/filebeat test output # Wazuh Manager 服务状态 sudo systemctl status wazuh-manager sudo /var/ossec/bin/wazuh-control status这里wazuh-control status会列出Manager内部各个进程的状态正常情况应该有以下几项且都为runningwazuh-analysisdwazuh-authdwazuh-dbwazuh-execdwazuh-integratordwazuh-logcollectorwazuh-monitordwazuh-modulesdwazuh-remotedwazuh-syscheckd如果一个或多个进程没有运行优先去/var/ossec/logs/ossec.log里找原因。6.2 修改默认密码和关闭无用端口安装脚本会输出两个随机密码一个是Dashboard登录密码另一个是admin用户密码两者默认是一样的。登录进去之后建议立刻在Stack Management Users里修改密码。如果这些密码泄露给非授权人员对方就能通过API拿你所有Agent的完整信息包括文件完整性监控的结果。还有权限收紧的问题。我见到很多人的机器上9200端口是对所有IP开放的这就意味着任何人都可以直接查询你的索引数据。如果你不需要远程直接访问OpenSearch API就把9200端口限制为只能本机访问sudo ufw deny 9200/tcpDashboard既然提供了Web界面9200端口对外不开放完全不影响正常使用。6.3 第一时间安装Agent做联通测试别在零Agent的状态下就开始研究告警规则配置先把一台测试机装上Agent确认走通全链路再说。Agent安装比较简单curl -s https://packages.wazuh.com/4.x/apt/pubkey.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import echo deb [signed-by/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main | sudo tee /etc/apt/sources.list.d/wazuh.list sudo apt update sudo apt install wazuh-agent -y sudo systemctl enable wazuh-agent sudo systemctl start wazuh-agent然后编辑/var/ossec/etc/ossec.conf把address改成你服务器的IP或域名重启Agent。关键点Agent启动之后在Dashboard上要过一小段时间通常几十秒到两三分钟才会显示Online。不要刚启动就看一眼发现是Disconnected就慌给它一点时间。如果持续五分钟还是Disconnected再按第4.3节的排查链路去查。6.4 用一个小实验验证安全告警全链路我建议在验证完Agent联通性之后做一个小实验来确认整个告警链路是通的。这个实验很简单在Agent机器上创建一个临时文件然后修改它触发syscheck的文件完整性告警。echo test /root/test_wazuh.txt echo modified /root/test_wazuh.txt过几十秒Dashboard的Security events模块里应该会出现一条关于/root/test_wazuh.txt的告警事件类型是syscheck。如果能看到这条告警就说明Agent → Manager → Filebeat → Indexer → Dashboard的完整链路是健康的后面再做规则定制就放心了。7. 安装过程中的几个经验沉淀关于Wazuh安装这件事我踩的坑够多每次重装都会有新的感悟。这里把经验集中讲一下。**第一个经验是少用一条龙脚本的思路。**Wazuh提供的wazuh-install.sh确实很强大自动帮你生成配置、装好所有组件。但正因为自动化程度太高出了问题你反而很难定位是哪个环节出了错。我推荐的做法是第一次安装时用官方脚本装但每执行完一步都手动验证一下当前的状态。比如脚本生成配置文件后先检查生成的证书文件和配置文件内容是否正确再继续下一步。**第二个经验是先学会卸载再学安装。**Wazuh在部署过程中你大概率会有装废了重来的时刻。这时候如果不会干净卸载残留的配置文件和未完全清理的服务状态会导致第二次安装失败而且报错还特别莫名其妙。官方提供了一个卸载脚本sudo bash wazuh-install.sh --uninstall但如果你使用的是手动分布式部署方式卸载时需要自己清理的目录比这多得多包括/var/lib/wazuh-indexer、/etc/wazuh-dashboard、/etc/filebeat、/var/ossec以及各自的日志目录。我只想说重装之前把残留清理干净比你花两小时去排查一个由残留配置文件导致的诡异报错要划算得多。**第三个经验是关于环境一致性的执念。**Wazuh官方支持CentOS、Ubuntu、Debian以及较新版本也支持一些其他发行版但我在测试中发现同样的版本在不同发行版上的安装行为会有细微差异。比如某些老版本在CentOS 7上安装时需要手动处理OpenSSL版本的兼容问题而在Ubuntu 22.04上就是一路绿灯。如果你非要用Wazuh就优先选择官方文档中标注为强烈推荐的发行版。这不是瞧不起其他系统而是你不太想在排查安全平台本身问题之外还要花额外精力去排查操作系统层面的坑。**第四个经验是安装文档里的每一个端口都有它存在的意义别乱改。**比如那个9300端口是索引器集群内部通信用的单机部署时看起来没什么用但如果你把它从配置里删了或者防火墙没放行后面你想扩展成三节点集群的时候就会遇到各种节点之间连不上的问题。我建议在初始化部署时就按端口清单把防火墙规则配置齐全哪怕现在用不上也先把规则加上后面用的时候少一层麻烦。8. 最后再分享一个安装完成以后的优化方向装好Wazuh并跑通全链路之后很多人就认为大功告成直接把服务器扔那不管了。其实安装只是第一步如果想让平台长期稳定运行还有几件收尾工作要做。第一是索引生命周期管理。Wazuh默认会无限期保存索引数据磁盘消耗速度远比你想象得快。建议在Dashboard的Indexer Management里创建一个ISPM策略比如把监控数据保留30天到期后自动删除或归档。第二是调整Agent端的上报频率。默认的syscheck扫描间隔和日志轮询时间是按通用场景配置的你可以根据自己的需求调整比如把文件完整性检查的间隔从每小时改成每6小时减少Agent机器的资源消耗同时仍然能保持有效的监控覆盖。第三是配置告警通知。Wazuh支持把告警接入邮件、Slack、钉钉等渠道安装完成后最好第一时间把通知渠道配上否则告警只在Dashboard里显示谁会天天守着页面看呢。从我个人的经验来说Wazuh是一个功能上限很高的安全监控平台安装阶段是最枯燥也最容易劝退人的部分。但只要你把环境规划好、把组件之间的关系理解清楚、把常见的坑提前躲开后面使用起来反而没有太多幺蛾子。希望这篇踩坑指南能帮你少走几步弯路省下几个周末。
Wazuh安装避坑指南：从环境规划到常见报错的完整排查手册
1. 为什么Wazuh最难的不是使用而是第一步安装先交代一下背景。我大概在一年前第一次接触Wazuh当时公司内部需要一个开源的安全监控平台能把服务器上的入侵检测、漏洞扫描、日志分析和文件完整性监控统一起来。调研了一圈Suricata偏流量侧OSSEC单纯做HIDS而Wazuh既有HIDS能力又带SIEM的日志分析功能还有比较完整的Web管理界面看起来是性价比最高的选择。但说真的Wazuh最大的门槛不在你后期怎么写规则、怎么配告警而是安装这一步就能劝退一大批人。我见过有人在虚拟机里折腾了整整一周最后连Dashboard的登录页都没看到也见过照着官方文档一步一步执行结果因为一个端口没放开整个安装过程全部作废。这个现象不奇怪。Wazuh不是那种一条命令装完就跑的轻量工具它的架构里包含索引器、服务器端组件、Dashboard前端和Agent端四部分任何一个环节出问题都会表现为服务起来了但连不上或者页面打不开。更麻烦的是官方文档里给出的快速安装方式虽然简化了命令但对系统资源和网络环境的要求非常硬核很多人在第一步就栽了。这篇文章我就把自己的实际安装过程、踩过的坑、排查的链路和最终采用的稳妥方案完整记录下来。无论你是第一次尝试Wazuh的初学者还是已经部署过一两次但被各种报错折磨过的运维这篇文章应该都能帮你省下不少时间。2. 部署前的环境核对这些细节没做好后面全是连环坑2.1 官方给的最低配置是所有坑的根源先直接把结论放在这里Wazuh官方文档写的最低硬件要求在真实部署场景里几乎跑不动。官方口径是2个CPU、4GB内存起步我实测下来4GB内存的虚拟机装完四组件之后系统可用内存只剩三四百MB索引器一启动就开始疯狂交换分区Dashboard页面转圈圈Agent注册后状态迟迟不显示Active。如果你的环境是虚拟机建议直接按以下配比来资源项AIO一体化安装最低建议拆分安装服务端索引器DashboardCPU4核服务端4核索引器4核Dashboard2核内存8GB实测10GB更稳服务端6GB索引器8GBDashboard2GB磁盘50GB索引器单独给100GB以上SSD系统Ubuntu 22.04 LTS / 24.04 LTS同左避免用CentOS 7这个表是我折腾了各种配置之后总结出来的舒服线。低于这个规格不是一定起不来但你会陷入装完—内存不足—服务挂掉—重启—又挂掉的循环排查起来极其痛苦。2.2 网络规划别偷懒主机名必须提前想好Wazuh安装过程中会生成自签名证书而证书里的CommonName跟你的主机名强绑定。如果你安装之后改了hostname证书校验就会失败Dashboard会报Invalid certificate之类的错误服务之间的通信也会出问题。我推荐的做法是在安装之前就定好主机名比如wazuh-server然后把它写进/etc/hosts并且保证本机的hostname和hostname -f解析结果一致。这里有个很隐蔽的细节很多人只改了/etc/hostname没有同步改/etc/hosts结果hostname -f返回的还是旧名字或者空值安装脚本在生成证书的时候就会出各种灵异问题。sudo hostnamectl set-hostname wazuh-server echo 127.0.0.1 wazuh-server | sudo tee -a /etc/hosts hostname -f确认最后一条命令输出的是wazuh-server再继续下一步。2.3 防火墙是最大的隐形杀手很多人在配置完一切之后发现Dashboard页面打不开第一反应是服务没起来各种查日志、重启服务折腾半天才发现是防火墙把端口拦了。Wazuh的端口清单比较长而且不同版本会有细微差异这里以4.7/4.8为例端口用途55000/TCPWazuh Server的RESTful API1514/TCPAgent日志接收1515/TCPAgent注册1516/TCPAgent群组管理443/TCPDashboard Web访问9300/TCP索引器节点间通信9200/TCP索引器RESTful接口仅本机必要时如果你用的是ufw直接这样放行sudo ufw allow 55000/tcp sudo ufw allow 1514/tcp sudo ufw allow 1515/tcp sudo ufw allow 1516/tcp sudo ufw allow 443/tcp sudo ufw allow 9300/tcp sudo ufw reload如果你在云服务器上部署除了系统防火墙还要去安全组里放行。这一步最容易漏掉因为很多时候你在服务器本机测试端口是通的但外部访问就是不行问题就出在安全组上。2.4 系统源和基础依赖先处理干净Wazuh的安装脚本会依赖curl、tar、openssl、python3这些基础工具以及systemd的正常工作。我遇到过一台最小化安装的Ubuntu连curl都没有安装脚本直接在下载阶段就报错。所以先跑一遍sudo apt update sudo apt upgrade -y sudo apt install -y curl tar openssl python3 python3-pip systemd另外Swap空间建议至少配4GB。虽然前面我吐槽了内存不足会触发Swap但在部署初期Swap可以避免OOM直接杀掉进程。等后面稳定运行了你可以在/etc/wazuh-indexer/jvm.options里调整堆大小。3. 两种安装路径的差异与各自的坑3.1 一体化快速安装AIO适合什么场景Wazuh官方现在推荐一体化安装All-in-One也就是一条命令把Wazuh Indexer、Wazuh Server和Wazuh Dashboard都装在同一台机器上。命令很简单curl -sO https://packages.wazuh.com/4.8/wazuh-install.sh sudo bash wazuh-install.sh --generate-config-files sudo bash wazuh-install.sh --install装完后脚本会输出一个随机生成的Dashboard密码用这个密码就能登录Web界面。如果你是在生产环境之外做测试验证或者团队规模在几台主机以内这种装法完全够用。AIO的坑在于第一对内存的要求更高因为三个组件挤在一起我实测8GB内存才能稳定运行4GB会频繁出现索引器进程被OOM第二一旦系统里已经有其他服务占用了443或9200端口安装脚本会直接卡住或者报错。我遇到一次是因为机器上提前装了一个Nginx占了443端口安装过程卡在Dashboard配置阶段排查了很长时间才发现问题。3.2 分布式拆分安装更稳妥的逻辑如果你要监控的主机数量超过50台或者对数据保留周期有较长要求建议把Wazuh Indexer和Server拆到两台机器上甚至在更大规模下把索引器单独扩展到三个节点。分布式安装的好处是各组件资源不互相争抢出问题的时候排查边界也清晰。但代价是安装配置要多好几个步骤你需要先装索引器集群再装服务端并指向索引器地址最后装Dashboard并完成证书分发。证书这块是分布式安装最容易出错的地方官方脚本生成的一套证书文件在拷贝到各节点的时候要确保路径和权限都一致否则节点间通信就起不来。3.3 我最终采用的安装方式结合自身的实际使用场景我最终用的是AIO安装加手动调整JVM参数的方式。这台机器跑的是Ubuntu 22.04给了4核8GB内存系统装在一块NVMe SSD上数据目录我单独挂了一块100GB的虚拟磁盘。安装命令执行完之后我没有立刻去登录Dashboard而是先把各服务状态检查了一遍sudo systemctl status wazuh-indexer sudo systemctl status wazuh-manager sudo systemctl status wazuh-dashboard sudo systemctl status filebeat这四个服务都必须是active (running)状态任何一个不对都别急着往下走先解决当前问题再继续。不要相信反正待会还会自动启动这种侥幸心理Wazuh启动失败经常是连环式的一个组件没起来会导致后续依赖它的组件全部异常。4. 安装过程中最常见的七个报错与处理顺序4.1 内存不足导致索引器反复崩溃这个放在第一个讲因为它是新手的头号杀手。现象是安装过程看着一切正常装完后wazuh-indexer服务一会儿就挂journalctl里出现Out of memory或者java.lang.OutOfMemoryError。根本原因是Wazuh索引器基于OpenSearch默认JVM堆内存设置是机器物理内存的50%在8GB机器上就是4GB堆加上索引进程实际运行开销整个索引器会吃掉接近7GB内存一旦机器上还有其他服务系统内存就爆了。解决办法是修改JVM堆大小sudo vi /etc/wazuh-indexer/jvm.options找到-Xms和-Xmx改成-Xms2g -Xmx2g改完之后重启sudo systemctl restart wazuh-indexer这里有个经验JVM堆大小不要把-Xms和-Xmx设置成不同值Wazuh官方推荐设成一致避免运行时堆动态扩容带来的性能波动。4.2 Dashboard页面打不开443端口没有任何响应如果你访问https://你的IP始终转圈或者提示拒绝连接先检查Dashboard服务状态如果状态正常再用ss -lntp | grep 443看端口是否真的在监听。常见原因有三个防火墙没放行、Dashboard服务根本没起来、或者服务起来但监听的地址不是所有网卡。第三个问题比较隐蔽Wazuh Dashboard默认监听地址是0.0.0.0但如果你在配置文件里改过server.host就可能导致只能本机访问。检查方式sudo grep -r server.host /etc/wazuh-dashboard/opensearch_dashboards.yml正常应该看到server.host: 0.0.0.0。如果改成了localhost或具体IP改成0.0.0.0再重启。4.3 Agent注册不上一直显示Disconnected这个问题排在第三是因为它完全没有报错但就是连不上。现象是你在另一台机器上装了Agent之后/var/ossec/etc/ossec.conf里配置的address写的是服务器的IP但Dashboard上Agent状态永远是Disconnected。排查链路是这样的先在服务器上确认1514和1515端口在监听在Agent机器上用telnet 服务器IP 1514和1515测试端口连通性如果端口不通检查防火墙和安全组如果端口通但Agent还是连不上看Agent日志/var/ossec/logs/ossec.log我遇到过一次很经典的场景防火墙全开了端口也是通的Agent日志里反复出现ERROR: Invalid signature。最后发现是Agent和Server的版本不一致Agent版本比Server新导致通信密钥校验失败。Wazuh的版本兼容性比较严格官方要求Agent和Server保持同版本。解决办法也很简单curl -s https://packages.wazuh.com/4.x/apt/ | sudo tee /etc/apt/sources.list.d/wazuh.list sudo apt update sudo apt install wazuh-agent -y或者直接用打包好的版本覆盖安装然后重启Agent服务。4.4 Filebeat数据管道连接失败Dashboard能登录但服务器管理页面的数据始终显示不出来告警也没有信息这时候大概率是Filebeat没有成功把数据推送到索引器。排查命令sudo /usr/share/filebeat/filebeat test output正常情况下会输出elasticsearch: http://127.0.0.1:9200...并显示Connection successful。如果显示连接失败检查Filebeat配置文件/etc/filebeat/filebeat.yml中的output.elasticsearch.hosts是不是指向了正确的索引器地址。还有一个容易忽略的点Filebeat和索引器之间的TLS证书校验。如果ssl.certificate_authorities指向的证书文件路径不对或者文件权限不对Filebeat会一直报TLS握手失败。把证书路径列出来检查sudo ls -l /etc/filebeat/certs/看到证书文件存在且有读权限再重启Filebeat。4.5 安装脚本卡在Installing Wazuh indexer长时间没反应这个坑我没少遇到原因多半是下载依赖包太慢或者网络到Wazuh官方仓库的连接不稳定。Wazuh的安装脚本会从packages.wazuh.com下载索引器、Dashboards、Agent等一堆软件包在网络环境不太好的时候下载到一半就卡死了。遇到这种情况不建议反复重跑安装脚本因为残留的配置和未完成的安装状态会导致二次安装报错。正确的做法是sudo bash wazuh-install.sh --uninstall先做干净卸载然后把/etc/wazuh-indexer、/etc/wazuh-dashboard、/var/lib/wazuh-indexer等残留目录手动清理掉再重新安装。另外可以尝试配置国内镜像源sudo vi /etc/apt/sources.list.d/wazuh.list把URL改成可访问的镜像地址或者直接下载deb包手动安装。我实际测试下来配置代理是最省事的方案如果没有代理就用离线安装包的方式避免反复卡下载。4.6 证书校验失败导致索引器集群无法启动分布式安装时索引器节点之间要互相信任。如果你的节点是从其他机器拷贝证书过来的很容易出现证书的CN和节点主机名不匹配的问题。报错关键字在/var/log/wazuh-indexer/wazuh-indexer.log里会看到SSLHandshakeException PKIX path building failed解决方案是重新生成证书。注意Wazuh官方脚本生成的证书是针对安装时的主机名和IP生成的所以如果你拷贝到另一台机器使用必须保证那台机器的主机名和IP与生成证书时一致。更稳妥的做法是在每台节点上分别生成证书文件而不是拷贝同一套。4.7 Dashboard登录后显示Security无法访问或者API显示红点Dashboard能进去但API连接显示异常首先要检查Wazuh Server的API服务是否正常curl -k -u wazuh-wui:wazuh-wui https://localhost:55000/如果返回401 Authorization Required说明API服务在正常工作问题出在Dashboard和Server之间的认证配置。如果连接被拒绝检查/etc/wazuh-dashboard/opensearch_dashboards.yml里的wazuh配置段的hosts是否指向了正确的Server API地址。另一个常见的原因是API用户wazuh-wui的密码变了但你不知道。Wazuh安装脚本会随机生成这个密码并写入配置如果你之前手动重置过API密码Dashboard里的配置就不会自动更新。这种时候直接去Dashboard的配置页面重新填一遍API连接信息即可。5. 服务起不来时的排查链路比重装更省事5.1 从systemd日志里找真正的关键词安装完之后遇到服务起不来的情况很多人的第一反应是去翻安装脚本的输出日志。但装完之后的运行期问题最好的入口是systemd日志。以Wazuh Manager为例sudo journalctl -u wazuh-manager --no-pager -n 100这里的输出会直接告诉你报错的关键词。我印象最深刻的一次是wazuh-manager起来之后过几秒就自己退了日志里只有一行ERROR: Unable to open file: /var/ossec/etc/ossec.conf: No such file or directory后来一查是之前手动清理时把/var/ossec目录删得太干净连配置文件一起没了。重新复制配置模板后服务就正常了。5.2 检查文件和目录权限Wazuh对权限的要求比较严格尤其是/var/ossec目录下所有文件的属主必须是wazuh:wazuh。如果你用root去修改过配置文件或者拷贝文件时没有保留属主信息服务就会出各种莫名其妙的问题。sudo chown -R wazuh:wazuh /var/ossec还有索引器的数据目录sudo chown -R wazuh-indexer:wazuh-indexer /var/lib/wazuh-indexer sudo chown -R wazuh-indexer:wazuh-indexer /var/log/wazuh-indexer一个隐藏比较深的细节是证书文件。Wazuh安装时会把OpenSearch证书放在/etc/wazuh-indexer/certs如果这些文件的权限包含了group或other的可读权限OpenSearch会在启动时报错提示私钥文件权限过大。处理方式sudo chmod 600 /etc/wazuh-indexer/certs/*.key sudo chmod 644 /etc/wazuh-indexer/certs/*.pem5.3 vm.max_map_count不达标导致索引器异常退出这是OpenSearch系产品的经典坑跟Wazuh本身无关但影响一致。安装完索引器后启动过程中可能会出现ERROR: [1] bootstrap checks failed其中一项就是max virtual memory areas vm.max_map_count [65530] is too low。解决方案sudo sysctl -w vm.max_map_count262144 echo vm.max_map_count262144 | sudo tee -a /etc/sysctl.conf改完不用重启系统重新启动索引器即可。这个问题在Docker部署方式下尤其常见因为宿主机内核参数会直接影响容器内进程。5.4 磁盘空间被日志撑爆Wazuh的日志和分析组件都很健谈尤其是索引器的工作日志和数据目录在短时间内就能吃掉几个GB。如果你部署时磁盘只给了20GB可能运行不到一周就被数据写满然后各种服务开始报磁盘空间不足的错。建议在安装完后检查一下日志轮转配置sudo cat /etc/logrotate.d/wazuh如果你的环境中没有自动清理策略可以手动清理索引数据。还可以在Dashboard的Indexer Management里配置索引生命周期策略规定数据保留天数超过的数据自动删除。6. 首次登录后必须立即做的验证和收尾工作6.1 确认四个组件都处于健康状态安装完、服务都起来之后先不要急着去配置告警规则。用下面一组命令验证系统是否真的健康# 索引器集群状态 curl -k -u admin:你的密码 https://localhost:9200/_cluster/health?pretty # 预期结果是 status 为 green 或 yellow # Filebeat 输出测试 sudo /usr/share/filebeat/filebeat test output # Wazuh Manager 服务状态 sudo systemctl status wazuh-manager sudo /var/ossec/bin/wazuh-control status这里wazuh-control status会列出Manager内部各个进程的状态正常情况应该有以下几项且都为runningwazuh-analysisdwazuh-authdwazuh-dbwazuh-execdwazuh-integratordwazuh-logcollectorwazuh-monitordwazuh-modulesdwazuh-remotedwazuh-syscheckd如果一个或多个进程没有运行优先去/var/ossec/logs/ossec.log里找原因。6.2 修改默认密码和关闭无用端口安装脚本会输出两个随机密码一个是Dashboard登录密码另一个是admin用户密码两者默认是一样的。登录进去之后建议立刻在Stack Management Users里修改密码。如果这些密码泄露给非授权人员对方就能通过API拿你所有Agent的完整信息包括文件完整性监控的结果。还有权限收紧的问题。我见到很多人的机器上9200端口是对所有IP开放的这就意味着任何人都可以直接查询你的索引数据。如果你不需要远程直接访问OpenSearch API就把9200端口限制为只能本机访问sudo ufw deny 9200/tcpDashboard既然提供了Web界面9200端口对外不开放完全不影响正常使用。6.3 第一时间安装Agent做联通测试别在零Agent的状态下就开始研究告警规则配置先把一台测试机装上Agent确认走通全链路再说。Agent安装比较简单curl -s https://packages.wazuh.com/4.x/apt/pubkey.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import echo deb [signed-by/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main | sudo tee /etc/apt/sources.list.d/wazuh.list sudo apt update sudo apt install wazuh-agent -y sudo systemctl enable wazuh-agent sudo systemctl start wazuh-agent然后编辑/var/ossec/etc/ossec.conf把address改成你服务器的IP或域名重启Agent。关键点Agent启动之后在Dashboard上要过一小段时间通常几十秒到两三分钟才会显示Online。不要刚启动就看一眼发现是Disconnected就慌给它一点时间。如果持续五分钟还是Disconnected再按第4.3节的排查链路去查。6.4 用一个小实验验证安全告警全链路我建议在验证完Agent联通性之后做一个小实验来确认整个告警链路是通的。这个实验很简单在Agent机器上创建一个临时文件然后修改它触发syscheck的文件完整性告警。echo test /root/test_wazuh.txt echo modified /root/test_wazuh.txt过几十秒Dashboard的Security events模块里应该会出现一条关于/root/test_wazuh.txt的告警事件类型是syscheck。如果能看到这条告警就说明Agent → Manager → Filebeat → Indexer → Dashboard的完整链路是健康的后面再做规则定制就放心了。7. 安装过程中的几个经验沉淀关于Wazuh安装这件事我踩的坑够多每次重装都会有新的感悟。这里把经验集中讲一下。**第一个经验是少用一条龙脚本的思路。**Wazuh提供的wazuh-install.sh确实很强大自动帮你生成配置、装好所有组件。但正因为自动化程度太高出了问题你反而很难定位是哪个环节出了错。我推荐的做法是第一次安装时用官方脚本装但每执行完一步都手动验证一下当前的状态。比如脚本生成配置文件后先检查生成的证书文件和配置文件内容是否正确再继续下一步。**第二个经验是先学会卸载再学安装。**Wazuh在部署过程中你大概率会有装废了重来的时刻。这时候如果不会干净卸载残留的配置文件和未完全清理的服务状态会导致第二次安装失败而且报错还特别莫名其妙。官方提供了一个卸载脚本sudo bash wazuh-install.sh --uninstall但如果你使用的是手动分布式部署方式卸载时需要自己清理的目录比这多得多包括/var/lib/wazuh-indexer、/etc/wazuh-dashboard、/etc/filebeat、/var/ossec以及各自的日志目录。我只想说重装之前把残留清理干净比你花两小时去排查一个由残留配置文件导致的诡异报错要划算得多。**第三个经验是关于环境一致性的执念。**Wazuh官方支持CentOS、Ubuntu、Debian以及较新版本也支持一些其他发行版但我在测试中发现同样的版本在不同发行版上的安装行为会有细微差异。比如某些老版本在CentOS 7上安装时需要手动处理OpenSSL版本的兼容问题而在Ubuntu 22.04上就是一路绿灯。如果你非要用Wazuh就优先选择官方文档中标注为强烈推荐的发行版。这不是瞧不起其他系统而是你不太想在排查安全平台本身问题之外还要花额外精力去排查操作系统层面的坑。**第四个经验是安装文档里的每一个端口都有它存在的意义别乱改。**比如那个9300端口是索引器集群内部通信用的单机部署时看起来没什么用但如果你把它从配置里删了或者防火墙没放行后面你想扩展成三节点集群的时候就会遇到各种节点之间连不上的问题。我建议在初始化部署时就按端口清单把防火墙规则配置齐全哪怕现在用不上也先把规则加上后面用的时候少一层麻烦。8. 最后再分享一个安装完成以后的优化方向装好Wazuh并跑通全链路之后很多人就认为大功告成直接把服务器扔那不管了。其实安装只是第一步如果想让平台长期稳定运行还有几件收尾工作要做。第一是索引生命周期管理。Wazuh默认会无限期保存索引数据磁盘消耗速度远比你想象得快。建议在Dashboard的Indexer Management里创建一个ISPM策略比如把监控数据保留30天到期后自动删除或归档。第二是调整Agent端的上报频率。默认的syscheck扫描间隔和日志轮询时间是按通用场景配置的你可以根据自己的需求调整比如把文件完整性检查的间隔从每小时改成每6小时减少Agent机器的资源消耗同时仍然能保持有效的监控覆盖。第三是配置告警通知。Wazuh支持把告警接入邮件、Slack、钉钉等渠道安装完成后最好第一时间把通知渠道配上否则告警只在Dashboard里显示谁会天天守着页面看呢。从我个人的经验来说Wazuh是一个功能上限很高的安全监控平台安装阶段是最枯燥也最容易劝退人的部分。但只要你把环境规划好、把组件之间的关系理解清楚、把常见的坑提前躲开后面使用起来反而没有太多幺蛾子。希望这篇踩坑指南能帮你少走几步弯路省下几个周末。
