前阵子帮一个朋友排查 Wazuh 装不上问题他折腾了两天换了好几个版本的 Elasticsearch、OpenSearch最后卡在 Dashboard 登录转圈。我问他一句“你到底装的什么版本”他发来一个截图我一看就知道问题出在哪了Wazuh 4.x 的三件套版本全部对不上。其实 Wazuh 安装本身并不难难的是你踩过的坑已经让你怀疑人生。这篇博文不是官方文档的复读是我把 Wazuh 4.x 系列从零开始装、卸载、再装、分布式部署、Agent 接入这一整套流程跑完之后的经验汇总。里面每一个坑我都自己踩过每条命令都是实际执行过的。如果你是第一次接触 Wazuh或者之前装过但没起来这篇文章应该能帮你少走几个小时弯路。1. 装之前先把资源账算清楚Wazuh 对服务器到底有多挑剔Wazuh 是一个开源的主机安全监控平台核心功能集中在威胁检测、日志分析、文件完整性监控、漏洞检测和合规管理这几块。它的架构说白了就是三个组件协同工作Indexer 负责存储和检索数据Server 负责收集处理日志和触发告警Dashboard 是给你看数据的可视化界面。这三件套装完之后你会得到一个类似 SIEM 的 Web 控制台所有 Agent 的告警和安全事件都会汇到这里。理解了这套架构后面的安装步骤就好懂多了——因为每一步无非就是在部署这三个东西并让它们互相通信。1.1 不是所有机器都能跑 Wazuh内存和 CPU 的隐形门槛官方文档写的最低要求是 4GB 内存、2 核 CPU但我必须告诉你实话4GB 只能让你把页面打开真正跑起检测任务会非常吃力。我自己实测过4GB 内存的机器装完 All-in-One 之后剩余可用内存不到 800MBAgent 一接入马上开始频繁 swapDashboard 面板加载要等十几秒文件完整性监控的数据库初次同步直接卡死。我的建议是测试环境4GB 内存起步6GB 更稳磁盘 50GB 够用。生产环境8GB 内存是底线最好 16GB磁盘按日志增长速度算通常建议 200GB 起。CPU 方面2 核勉强能动4 核以上体验会有明显提升。这里有个常被忽略的点内存大小直接决定了你给 Elasticsearch/OpenSearch 分配的 JVM 堆大小。Wazuh Indexer 默认的 heap 分配会按系统总内存自动计算但它有个毛病——如果系统内存太小它反而会分配一个非常尴尬的值。我见过 4GB 机器上 Indexer 自动分配了 1GB heap结果启动后一会儿就 OOM。你可以在/etc/wazuh-indexer/jvm.options里手动改-Xms和-Xmx建议设置为物理内存的 25% 到 50%不要超过 50%因为还要给系统留余地。还有一个硬件层面的坑不要拿 32 位系统去装Wazuh 4.x 从很早开始就放弃 32 位兼容了。另外如果你用的是 ARM 架构的机器部分组件虽然能跑但官方提供的预编译包可能不完整AI 部署脚本会自动判断架构并选择合适的包这一步比较容易翻车建议新手直接用 x86_64 架构的服务器省事很多。1.2 操作系统版本与内核的地狱匹配Wazuh 对操作系统的支持范围比较广CentOS 7/8/9、Rocky Linux、Ubuntu 18.04/20.04/22.04、Debian、Amazon Linux 这些主流发行版都在官方支持列表里。但“支持”和“顺利装上”是两码事我这里直接给结论。最省心的组合Ubuntu 22.04 或 CentOS 7.9。这两个系统下 Wazuh 的依赖全都现成我装了多次几乎没遇到过系统层面的坑。最折磨人的组合Ubuntu 24.04 搭配某些旧版本 Wazuh。新版系统太激进Old 的依赖包装不上去比如 libssl 版本不对、Python 版本不对各种问题。内核太新也有问题Wazuh 的 Agent 在内核模块层面做文件监控如果你内核版本过高而 Wazuh 版本旧相关内核模块可能不被支持会导致 Agent 安装成功但文件监控不生效或者直接报错。所以如果你选择用虚拟机新建环境跑 Wazuh镜像优先选系统自带 20.04 或 22.04 的别选最新版的 24.x 镜像。1.3 网络端口规划还没装就先把“门牌号”定好Wazuh 安装过程里对端口的要求非常讲究如果你机器上跑着别的服务占用了端口安装脚本不会替你处理冲突只会直接报错。默认端口规划组件端口用途Wazuh Indexer9200/tcp接收日志和查询数据Wazuh Server55000/tcpAgent 与 Server 通信Wazuh Server1515/tcpAgent 注册EnrollmentWazuh Server1516/tcpAgentless 通信Wazuh Dashboard443/tcpWeb 界面入口尤其是 9200 端口如果你机器上之前装过 Elasticsearch 或者别的搜索引擎端口占用的概率极高。我在刚开始踩坑时就是遇到这个情况安装脚本跑了大半天最后卡在 indexer 初始化日志里写着 Address already in use一查才发现旧的 Elasticsearch 进程还赖着没走。所以安装前先执行一下端口检查ss -lntp | grep -E 9200|55000|1515|1516|443看到有结果先把端口空出来再继续。另外如果你的服务器开了防火墙比如 ufw 或者 firewalld记得提前把这几条端口规则放行不然装完之后 Agent 和 Server 之间会像失联一样这个坑埋得很深因为安装脚本本身不会帮你在防火墙上打洞。2. 安装方式选型All-in-One、分布式还是包安装Wazuh 提供了几种官方安装路径不同路径对应不同的场景。我第一次装的时候没搞清楚直接按照网上一个老教程走了 RPM 包手动安装结果组件之间的版本关系完全靠猜折腾了半天才明白 Wazuh 4.x 的官方定位是让你优先使用部署助手wazuh-install.sh。这个工具会从一个脚本出发自动完成索引器、服务器、仪表板三件套的安装和初始化省去了大量手动配置的繁琐过程。不过它也不是万能的后面我会专门讲它容易在哪里踩坑。2.1 三种安装路线各自的适用场景All-in-One 和分布式这两条路线是官方推荐的它们的本质区别在于三件装配不配在同一台机器上。选哪条路线取决于你想把监控系统扛到什么样的规模。All-in-One 单机版三件套都装在一台机器上适合测试环境、个人实验室、中小企业规模不过微型企业可能根本用不上这么重的方案。这个方案的优势是安装简单维护成本低一条命令就搞定。缺点也明显一旦这台机器挂了监控平台整个瘫痪。分布式部署三件套分别装在三台或更多机器上Indexer 甚至可以组成集群。适合生产环境扩展性好任何单点故障都不会影响全局。代价是安装步骤多一大截证书分发、组件之间的网络配置、节点加入集群这些环节都得自己处理。包管理器手动安装通过apt/yum安装单个组件。这条路线最灵活可以自定义每个组件的版本和配置但也最容易出错因为 Wazuh 各个组件之间存在严格的版本兼容关系手动装很容易装出一个混搭版本组合。你如果不想让 Wazuh 团队帮你管理全部配置只想把某个组件融入现有环境可以考虑这个方案。为什么不推荐新手直接从包安装开始因为 Wazuh 三件套之间的版本关系之严格有点像手机系统和 App 的兼容性Indexer 版本差一点点Dashboard 连不上Server 多更新一个小版本Agent 连接不稳定。手动装的时候你一不小心就掉进版本黑洞排查起来非常浪费时间。2.2 为什么我建议新手先走 All-in-One我自己测试过很多次后得出的结论是第一次接触 Wazuh不要直接上分布式先用 All-in-One 把整个流程跑通搞清楚组件之间怎么通信、Agent 怎么接入、告警怎么查看再上生产环境做分布式会容易得多。All-in-One 一条命令部署完成后的效果是你可以直接通过 HTTPS 打开 Dashboard登录后能看到所有 Agent 的安全事件、告警、漏洞信息。对有经验的工程师来说这种“即装即用”的模式可能略显粗糙但对新人来说能在半小时内看到自己的第一台监控服务器上线这种成就感很重要。另外如果你最终目标是生产环境我的建议是先搭一台 All-in-One 当测试机用来验证规则、测试告警逻辑、调整索引参数再在另一批机器上搭分布式。这样你在分布式环境里遇到的“配置改坏了”一类问题不会影响现有业务。2.3 安装前的依赖准备版本兼容才是天大的事不管走哪条路线有几个基础工具是绕不开的这里特别提醒一下你网上搜安装教程的时候经常会看到 Python 安装教程、Git 安装教程、Vim 安装教程之类的文章以为这些是必须的前置条件。实际上 Wazuh 安装脚本所需的依赖在官方支持的系统上大多数是预装好的。在 Ubuntu 22.04 上我的实践如下apt update apt install curl tar openssl git vim -y这几个工具基本够用。CentOS 7.9 相应地用yum install curl tar openssl git vim -y关于 PythonWazuh 的安装脚本依赖 Python 3.8 以上但不需要你手动装。如果你系统里恰好自己编译过 Python还要特别注意 PATH 优先级问题——安装脚本可能会调用到错误的解释器版本。这点我在第 5 部分的分布式部署中再展开。另外Git 在安装阶段基本用不上除非你打算直接从 GitHub 拉 Wazuh 源码手动编译。如果你只是想用官方仓库安装Git 可以不需要。网络热词里常出现 Git 安装教程、Python 安装教程等那更多是通用开发环境的需求Wazuh 安装大可不必被这些教程牵着走。3. 实操记录All-in-One 完整安装与配置过程这一节开始进入正题。我将以 Ubuntu 22.04 为例逐步演示 All-in-One 的完整安装过程并穿插说明每一步的目的和容易踩的坑。3.1 准备阶段用软链接解决 /tmp 空间不足的坑这一步看起来和 Wazuh 无关但我在安装过程中踩过一次印象深刻。Wazuh 的部署助手在安装阶段会下载大量组件包并解压默认的临时目录是/tmp。如果你装系统的分区时候给/tmp分配的空间太小安装会在中途报磁盘空间不足整个安装流程被迫打断重来。我踩坑现场是这样的当时虚拟机给根分区只划了 20GB装到一半脚本报 No space left on device我第一反应是清理 apt 缓存删掉旧内核腾了 2GB 左右出来重新装又卡在同一位置。最后发现是/tmp被单独分区只有 2GB安装包解压一下就满了。解决方式把/tmp软链接到空间足够的目录或者直接给/tmp扩容。我当时的处理办法是在根分区下新建一个/root/tmp然后rm -rf /tmp ln -s /root/tmp /tmp之后重新执行安装问题解除。这个坑官方文档没提但实际操作里隔三差五会遇到。3.2 安装脚本一段命令执行后的真实输出Wazuh 官方给出的 All-in-One 安装命令非常简洁就一行curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh bash wazuh-install.sh --generate-config-files --instances 1这个命令里面的4.9是 Wazuh 的主版本号你需要把它替换成当前的最新版本。可以在 Wazuh 官网上查 Latest Version。注意不要随便用latest之类的不固定版本号因为脚本的下载路径和版本强绑定写死版本号是最稳的。命令执行后脚本会做以下几件事检查系统版本、架构、可用内存和端口。下载并安装 Wazuh Indexer、Server、Dashboard 三个组件。生成需要的证书自签名 CA 和节点证书并自动配置。启动三个服务并设置开机自启。整个流程大概十几分钟取决于你的网络状况。如果中间哪一步失败脚本一般会报个 Error installing 并退出。这时不要慌先去日志里看具体的失败原因。安装完成后脚本会在控制台打印一段类似这样的信息dashboard_install.sh: OK wazuh-indexer: OK wazuh-manager: OK --- Summary --- You can access the web interface https://server-ip User: admin Password: 随机生成的密码这段输出很重要请先记录因为admin的初始密码是自动生成的如果丢了后面要重置会比较麻烦。3.3 证书生成与文件权限最容易翻车的两个环节如果你安装的是 All-in-One部署助手会自动处理证书生成和权限配置基本不用你手工干预。但如果你选的是手动安装或者分布式部署证书这个环节是出错重灾区。先说证书生成的坑。Wazuh 三件套之间全部采用 HTTPS 双向 TLS 认证也就是每个节点都要有自己的证书并且要由同一个 CA 签发。如果某台机器拿到的证书和另一台对不上组件之间通信会直接失败而且报错信息非常具有迷惑性比如 Dashboard 页面提示 Failed to connect to search guard 或者索引器日志里报 unable to parse message from REST API。我第一次做分布式部署时就遇到过证书混淆问题三台机器的证书生成到同一个 tar 包里解压的时候我少拷贝了一个文件结果 Indexer 和 Server 之间互验证书失败日志里全是 SSL 错误。排查了很久才发现是某个节点的证书文件缺失。再说文件权限。Wazuh 三件套对证书文件的权限要求极其严格用户和组必须匹配权限位必须正确。具体来说Indexer 使用的证书和密钥文件属主必须是wazuh-indexer:wazuh-indexer权限建议660。ServerManager使用的证书属主必须是wazuh:wazuh权限建议660。Dashboard 使用的证书属主必须是wazuh-dashboard:wazuh-dashboard权限建议660。权限不对时服务启动时会报 Permission denied 或者 SSL 初始化失败。这种情况用chown和chmod改一下就能解决但如果你不知道这个规则可能会在 SSL 错误里打转很久。3.4 验证安装端口、进程、页面三层检查安装脚本执行完成后先别急着登录 Dashboard用这三步验证一下安装状态第一层检查端口监听状态。ss -lntp | grep -E 9200|443|55000|1515正常的输出应该同时看到 9200、443、55000、1515 这几个端口都在 LISTEN 状态。如果缺少某个端口说明对应的服务没有启动成功优先去系统日志里翻相关进程的报错。第二层检查关键服务进程。systemctl status wazuh-indexer wazuh-manager wazuh-dashboard理想状态是三个服务都显示 active (running)。如果某个服务启动失败可以单独查看journalctl -u wazuh-indexer --no-pager -n 100 journalctl -u wazuh-manager --no-pager -n 100 journalctl -u wazuh-dashboard --no-pager -n 100这里的日志是排查问题的最重要入口比网上任何教程都更接近真实原因。第三层检查 Indexer 集群健康状态。curl -k -u admin:你的密码 https://127.0.0.1:9200/_cluster/health正常情况下返回的status应该是greennumber_of_nodes应该是1。如果返回yellow说明索引存在副本未分配的情况如果返回red说明有主分片未分配问题会比较大。这块我在第 5 章详细展开。4. 分布式部署要点三件套的安装顺序与衔接生产环境一般不做 All-in-One而是把三件套拆开。这一节我结合自己的实操给出分布式部署的完整顺序和关键细节。分布式部署中最需要注意的就是安装顺序必须先装 Indexer再装 Server最后装 Dashboard因为后面的组件在安装时就跟前面的组件建立信任关系装反了后面接入阶段很容易报错。4.1 先装 Wazuh IndexerIndexer 是整条数据链路的底层存储它不启动后面任何组件都白搭。在分布式部署中你需要在 Indexer 节点上单独下载安装脚本curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh然后先执行配置生成bash wazuh-install.sh --generate-config-files --instances 3这里的--instances 3表示要生成三个节点的配置包括证书和 yml 配置文件。执行完成后脚本会在当前目录生成一个wazuh-install-files.tar.gz压缩包里面包含所有节点的证书和配置文件。这个 tar 包需要你手动分发到三台机器上。Indexer 节点安装bash wazuh-install.sh --install-elasticsearch实际命令名可能是--install-indexer不同版本略有差异请以脚本的--help输出为准。安装完成后Indexer 会自动启动并监听 9200 端口。此时先不要急着装其他组件先验证 Indexer 自身集群状态。4.2 再装 Wazuh ServerServerManager节点的职责是接收 Agent 的日志和事件进行解析和告警然后写入 Indexer。安装方式类似bash wazuh-install.sh --install-wazuhServer 安装过程中需要用到前面 tar 包里的证书文件脚本会自动从解压目录找到对应的wazuh-server.pem、wazuh-server-key.pem等文件。这里最容易出的问题就是证书路径不对或者文件权限不对。Server 启动后你需要验证它和 Indexer 之间的通信是否正常。这个验证在 Server 节点上执行/usr/share/wazuh-indexer/bin/wazuh-indexer --version嗯上面的命令其实不适用于 Server 节点。正确的做法是检查 Server 的配置里是否指向了正确的 Indexer 地址然后让 Server 往 Indexer 写入一条测试数据。你可以在 Server 节点上执行curl -k -u admin:密码 https://indexer-ip:9200如果返回了版本信息说明网络通路正常、证书校验也过了。4.3 最后装 Wazuh DashboardDashboard 是用户的 Web 入口它需要连接 Indexer 和 Server所以在三件套里它依赖的组件最多。安装命令bash wazuh-install.sh --install-dashboard这里有个关键点Dashboard 的配置文件中需要指定server.host、server.port以及指向 Indexer 和 Server 的地址。如果你在安装前没有把wazuh-install-files.tar.gz正确解压在 Dashboard 节点上脚本会报找不到配置文件的错。Dashboard 安装完成后访问https://dashboard-ip用admin和你记录的密码登录。如果出现登录界面但输入密码后一直转圈大概率是 Dashboard 和 Indexer 的通信出了问题重点查 Dashboard 节点上的journalctl -u wazuh-dashboard日志。4.4 证书分发与节点配置同步分布式部署的证书分发环节是最容易乱的地方。我的建议是在所有安装命令执行前先把wazuh-install-files.tar.gz拷贝到三台机器的同一目录下比如/opt/wazuh-install/。解压后确认每个节点只保留自己需要的证书文件不要把其他节点的证书留在本机。每个节点的/etc/wazuh-indexer/opensearch.yml里discovery.seed_hosts要写清楚集群内所有节点的 IP如果是单节点 Indexer记得把discovery.type设为single-node。所有节点的时间必须同步NTP 或 chrony否则证书校验会因时间偏差失败。这个问题很隐蔽我见过因为服务器时间差了几分钟导致 TLS 握手失败的案例。5. 常见问题与排查技巧实录踩坑清单这一节把我在实际操作中遇到的典型问题和排查思路整理成清单方便你按图索骥。5.1 “Dashboard 登录一直转圈”排查思路这个问题在 Wazuh 社区里出现的频率非常高现象就是登录页能出来输入 admin 密码后一直转圈过一会儿提示无效凭据或者连接失败。排查路径先确认 Dashboard 能否连上 Indexer。在 Dashboard 节点执行curl -k -u admin:密码 https://127.0.0.1:9200能返回版本信息说明本机到 Indexer 的通路没问题如果超时或拒绝连接重点查端口和防火墙。再确认 Dashboard 配置里的server.host是不是0.0.0.0如果写死了127.0.0.1远程访问会失败。查看 Dashboard 日志journalctl -u wazuh-dashboard --no-pager -n 100常见错误包括 Failed to connect to opensearch 或者 SearchGuard authentication failed。如果是SearchGuard相关错误多半是证书不一致。检查 Dashboard 使用的证书是不是和 Indexer 同一个 CA 签发的。5.2 Indexer 状态 yellow/red 的排查Indexer 集群状态为yellow或者red是很常见的问题。yellow表示主分片已经分配但副本分片没有分配。在只有一台 Indexer 节点的环境里这是因为默认的副本数为 1但节点数只有 1副本无法分配。解决方式是把副本数改为 0curl -k -u admin:密码 https://127.0.0.1:9200/_settings -X PUT -H Content-Type: application/json -d {index:{number_of_replicas:0}}或者修改索引模板。如果你想知道为什么会这样因为 Wazuh 默认创建的索引模板副本数为 1在单节点集群里找不到副本节点就会一直保持 yellow。red状态更严重表示有主分片没有分配。可能原因包括节点之间网络不通、磁盘空间不足超过水位线导致分片无法分配、或者索引数据损坏。排查方式curl -k -u admin:密码 https://127.0.0.1:9200/_cat/shards?v看哪个索引卡在 UNASSIGNED再查看原因字段一般会给出线索。5.3 Filebeat 无法连接 IndexerWazuh Server 通过 Filebeat 将告警和事件写入 Indexer。如果 Server 的日志里有大量 could not connect to elasticsearch 或者 fail to send batch 之类的报错需要按顺序排查Filebeat 配置文件/etc/filebeat/filebeat.yml里的hosts是否正确指向 Indexer 节点 IP。证书文件权限是否为wazuh:wazuh且权限位为660。密码是否正确Filebeat 输出的认证信息是否和 Indexer 的内部用户一致。最后用命令手动测试 Filebeat 与 Indexer 的通路filebeat test output这个命令会给出明确的连接成功或失败信息非常实用。5.4 升级或重装后启动失败的“老规矩”如果你是升级版本或者重装遇到服务启动失败先不要乱卸载按这个顺序来检查系统日志journalctl -u wazuh-manager -n 50 journalctl -u wazuh-indexer -n 50 journalctl -u wazuh-dashboard -n 50如果是配置错误导致的启动失败通常日志末尾会写清楚哪个配置文件有问题。如果是证书问题导致的三件套互相连不上重新生成证书并分发是最快的解决路径。我见过有人因为升级后 Dashboard 起不来直接把整个环境卸载重装的其实很多升级失败的问题就出在/etc/wazuh-dashboard/opensearch_dashboards.yml里还残留旧版本配置项手动清理掉就能恢复。5.5 虚拟机环境下的兼容性很多人在虚拟机上装 Wazuh我自己也是从 VMware 虚拟机开始玩的。这里有一个额外的坑如果你用 VMware Workstation 跑 Ubuntu默认虚拟网卡模式如果是 NATWazuh 的安装脚本通常可以正常跑但 Agent 从外部接入时需要你额外配置端口转发否则 Agent 上报的数据根本到不了 Server。另外虚拟机的磁盘如果分配太小Wazuh Indexer 写数据很容易触发磁盘水位线索引变成只读表现是 Dashboard 里看不到新数据。所以虚拟机里建议至少分配 60GB 磁盘并预留扩展分区的能力。6. 装完以后还要做的事从“能打开页面”到“真正能用”安装完成、Dashboard 能登录这只是第一步。要真正把 Wazuh 跑起来还有几个必须做的配置项。6.1 修改默认账号密码Wazuh 安装后默认的admin密码在安装日志里打印但这密码是随机生成的很多人直接拿着用也不改。建议登录后立即在 Wazuh Dashboard 里通过 “OpenSearch Dashboards Security” 插件重置密码或者在 API 里调用相关接口修改。如果你需要给团队多人分配账号可以创建不同角色的用户分别授予只读、告警管理等权限避免所有人共用 admin。6.2 安装 Agent 并验证事件流不安装 Agent 的 Wazuh 只是个空壳监控平台没有任何意义。Agent 的安装方式支持 RPM、DEB、MSI 安装包也可以用脚本部署。在测试环境里我推荐直接在 Wazuh Server 本机装一个 Agent用来验证事件链路是否完整。curl -s https://packages.wazuh.com/4.x/wazuh-install.sh | bash -s -- -a -i server-ip -p password实际上命令细节可能因版本而异更通用的方式是在 Dashboard 的 Agents 页面选择“Deploy new agent”系统会给出对应系统的安装命令复制到目标机器执行即可。Agent 安装完成后回到 Dashboard 的 Agents 页面状态变成 Active 就说明注册成功。然后在 Agent 上执行一些安全操作比如安装一个后门程序或者修改系统文件等一两分钟后Dashboard 的 Security events 页面应该能看到对应的告警。如果没有告警检查 Agent 的/var/ossec/etc/ossec.conf里 Server 地址是否配置正确。6.3 磁盘监控与空间规划Wazuh 运行中最现实的问题就是磁盘被日志塞满。默认的索引保留策略是 90 天日志量大时每天可能产生几个 GB 的数据。建议从安装之初就规划好磁盘空间并开启索引清理策略。Wazuh 提供了索引生命周期管理ILM策略默认会按天数删除旧索引。你可以在 Dashboard 的 Indexer Settings 里调整保留时间。如果没有正确设置索引满了以后 Indexer 会自动把索引设为只读表现就是 Dashboard 没数据了这个坑很常见。我的个人实践是测试环境保留 30 天生产环境按合规要求 180 天到 365 天。磁盘不够了就提前扩容别等到水位线告警再处理。6.4 升级与维护注意事项Wazuh 的升级策略是小版本升级比如 4.7 到 4.8可以直接通过官方脚本完成大版本升级需要先做完整备份。升级前一定要先备份这几样东西/etc/wazuh-indexer目录下的配置文件和证书/etc/wazuh-manager目录下的规则配置Dashboard 的系统索引如果你有自定义的 dashboard 面板升级过程里最容易翻车的地方在于 Group 配置就是你在 Dashboard 里设置的 Agent 组策略升级脚本会保留这些配置但如果新旧版本的 schema 有变化旧的配置可能导致 Wazuh Manager 起不来。所以大版本升级前建议先在测试环境验证一遍。另外Wazuh 对新版本的老系统支持也是有限的。比如你还在 CentOS 7.9 上跑着老版本 Wazuh 4.5 想升级到 4.9大概率会碰到依赖问题。我的经验是老系统就留在旧版本新环境直接上新版没必要强行在旧系统上折腾最新版本。写在最后的实操体会安装 Wazuh 这件事说难也难说简单也简单关键是别被各种教程误导。我刚开始装的时候网上搜到一堆跟我情况完全不同的教程有讲单节点的、有讲大规模集群的、有讲源码编译的最后照着他们操作反而把自己带偏了。后来学乖了一切以官方文档和官方安装脚本为准遇到问题先看日志再搜索踩坑效率高了好几倍。如果你这个周末准备装 Wazuh 来体验一把我给的最实在的建议是这两条也是我自己反复用到的经验第一条别在一个环境里反复折腾装坏了就重开虚拟机比修安全监控平台要快得多。装 Wazuh 玩这个过程本身就是练手和熟悉三件套逻辑的好机会很多问题你在重装过程中自然就懂了。第二条所有改配置文件之前先备份一份Wazuh 的配置文件之间关联性很强一改改错一个点半天时间就没了。我习惯在/root下面建个backup目录把要改的配置先拷贝进去然后再动手。这个习惯在很多其他服务上同样适用。最后再说一句Wazuh 这个平台本身很强大但如果只停留在“装好了”这个阶段你会错过它真正的价值。花点时间把文件完整性监控、漏洞检测、合规检查这些功能都打开让它真实地监控几台机器你才能体会到一个能落地的安全平台该有的样子。
Wazuh 4.x安装实战：从零部署到踩坑排查全指南
前阵子帮一个朋友排查 Wazuh 装不上问题他折腾了两天换了好几个版本的 Elasticsearch、OpenSearch最后卡在 Dashboard 登录转圈。我问他一句“你到底装的什么版本”他发来一个截图我一看就知道问题出在哪了Wazuh 4.x 的三件套版本全部对不上。其实 Wazuh 安装本身并不难难的是你踩过的坑已经让你怀疑人生。这篇博文不是官方文档的复读是我把 Wazuh 4.x 系列从零开始装、卸载、再装、分布式部署、Agent 接入这一整套流程跑完之后的经验汇总。里面每一个坑我都自己踩过每条命令都是实际执行过的。如果你是第一次接触 Wazuh或者之前装过但没起来这篇文章应该能帮你少走几个小时弯路。1. 装之前先把资源账算清楚Wazuh 对服务器到底有多挑剔Wazuh 是一个开源的主机安全监控平台核心功能集中在威胁检测、日志分析、文件完整性监控、漏洞检测和合规管理这几块。它的架构说白了就是三个组件协同工作Indexer 负责存储和检索数据Server 负责收集处理日志和触发告警Dashboard 是给你看数据的可视化界面。这三件套装完之后你会得到一个类似 SIEM 的 Web 控制台所有 Agent 的告警和安全事件都会汇到这里。理解了这套架构后面的安装步骤就好懂多了——因为每一步无非就是在部署这三个东西并让它们互相通信。1.1 不是所有机器都能跑 Wazuh内存和 CPU 的隐形门槛官方文档写的最低要求是 4GB 内存、2 核 CPU但我必须告诉你实话4GB 只能让你把页面打开真正跑起检测任务会非常吃力。我自己实测过4GB 内存的机器装完 All-in-One 之后剩余可用内存不到 800MBAgent 一接入马上开始频繁 swapDashboard 面板加载要等十几秒文件完整性监控的数据库初次同步直接卡死。我的建议是测试环境4GB 内存起步6GB 更稳磁盘 50GB 够用。生产环境8GB 内存是底线最好 16GB磁盘按日志增长速度算通常建议 200GB 起。CPU 方面2 核勉强能动4 核以上体验会有明显提升。这里有个常被忽略的点内存大小直接决定了你给 Elasticsearch/OpenSearch 分配的 JVM 堆大小。Wazuh Indexer 默认的 heap 分配会按系统总内存自动计算但它有个毛病——如果系统内存太小它反而会分配一个非常尴尬的值。我见过 4GB 机器上 Indexer 自动分配了 1GB heap结果启动后一会儿就 OOM。你可以在/etc/wazuh-indexer/jvm.options里手动改-Xms和-Xmx建议设置为物理内存的 25% 到 50%不要超过 50%因为还要给系统留余地。还有一个硬件层面的坑不要拿 32 位系统去装Wazuh 4.x 从很早开始就放弃 32 位兼容了。另外如果你用的是 ARM 架构的机器部分组件虽然能跑但官方提供的预编译包可能不完整AI 部署脚本会自动判断架构并选择合适的包这一步比较容易翻车建议新手直接用 x86_64 架构的服务器省事很多。1.2 操作系统版本与内核的地狱匹配Wazuh 对操作系统的支持范围比较广CentOS 7/8/9、Rocky Linux、Ubuntu 18.04/20.04/22.04、Debian、Amazon Linux 这些主流发行版都在官方支持列表里。但“支持”和“顺利装上”是两码事我这里直接给结论。最省心的组合Ubuntu 22.04 或 CentOS 7.9。这两个系统下 Wazuh 的依赖全都现成我装了多次几乎没遇到过系统层面的坑。最折磨人的组合Ubuntu 24.04 搭配某些旧版本 Wazuh。新版系统太激进Old 的依赖包装不上去比如 libssl 版本不对、Python 版本不对各种问题。内核太新也有问题Wazuh 的 Agent 在内核模块层面做文件监控如果你内核版本过高而 Wazuh 版本旧相关内核模块可能不被支持会导致 Agent 安装成功但文件监控不生效或者直接报错。所以如果你选择用虚拟机新建环境跑 Wazuh镜像优先选系统自带 20.04 或 22.04 的别选最新版的 24.x 镜像。1.3 网络端口规划还没装就先把“门牌号”定好Wazuh 安装过程里对端口的要求非常讲究如果你机器上跑着别的服务占用了端口安装脚本不会替你处理冲突只会直接报错。默认端口规划组件端口用途Wazuh Indexer9200/tcp接收日志和查询数据Wazuh Server55000/tcpAgent 与 Server 通信Wazuh Server1515/tcpAgent 注册EnrollmentWazuh Server1516/tcpAgentless 通信Wazuh Dashboard443/tcpWeb 界面入口尤其是 9200 端口如果你机器上之前装过 Elasticsearch 或者别的搜索引擎端口占用的概率极高。我在刚开始踩坑时就是遇到这个情况安装脚本跑了大半天最后卡在 indexer 初始化日志里写着 Address already in use一查才发现旧的 Elasticsearch 进程还赖着没走。所以安装前先执行一下端口检查ss -lntp | grep -E 9200|55000|1515|1516|443看到有结果先把端口空出来再继续。另外如果你的服务器开了防火墙比如 ufw 或者 firewalld记得提前把这几条端口规则放行不然装完之后 Agent 和 Server 之间会像失联一样这个坑埋得很深因为安装脚本本身不会帮你在防火墙上打洞。2. 安装方式选型All-in-One、分布式还是包安装Wazuh 提供了几种官方安装路径不同路径对应不同的场景。我第一次装的时候没搞清楚直接按照网上一个老教程走了 RPM 包手动安装结果组件之间的版本关系完全靠猜折腾了半天才明白 Wazuh 4.x 的官方定位是让你优先使用部署助手wazuh-install.sh。这个工具会从一个脚本出发自动完成索引器、服务器、仪表板三件套的安装和初始化省去了大量手动配置的繁琐过程。不过它也不是万能的后面我会专门讲它容易在哪里踩坑。2.1 三种安装路线各自的适用场景All-in-One 和分布式这两条路线是官方推荐的它们的本质区别在于三件装配不配在同一台机器上。选哪条路线取决于你想把监控系统扛到什么样的规模。All-in-One 单机版三件套都装在一台机器上适合测试环境、个人实验室、中小企业规模不过微型企业可能根本用不上这么重的方案。这个方案的优势是安装简单维护成本低一条命令就搞定。缺点也明显一旦这台机器挂了监控平台整个瘫痪。分布式部署三件套分别装在三台或更多机器上Indexer 甚至可以组成集群。适合生产环境扩展性好任何单点故障都不会影响全局。代价是安装步骤多一大截证书分发、组件之间的网络配置、节点加入集群这些环节都得自己处理。包管理器手动安装通过apt/yum安装单个组件。这条路线最灵活可以自定义每个组件的版本和配置但也最容易出错因为 Wazuh 各个组件之间存在严格的版本兼容关系手动装很容易装出一个混搭版本组合。你如果不想让 Wazuh 团队帮你管理全部配置只想把某个组件融入现有环境可以考虑这个方案。为什么不推荐新手直接从包安装开始因为 Wazuh 三件套之间的版本关系之严格有点像手机系统和 App 的兼容性Indexer 版本差一点点Dashboard 连不上Server 多更新一个小版本Agent 连接不稳定。手动装的时候你一不小心就掉进版本黑洞排查起来非常浪费时间。2.2 为什么我建议新手先走 All-in-One我自己测试过很多次后得出的结论是第一次接触 Wazuh不要直接上分布式先用 All-in-One 把整个流程跑通搞清楚组件之间怎么通信、Agent 怎么接入、告警怎么查看再上生产环境做分布式会容易得多。All-in-One 一条命令部署完成后的效果是你可以直接通过 HTTPS 打开 Dashboard登录后能看到所有 Agent 的安全事件、告警、漏洞信息。对有经验的工程师来说这种“即装即用”的模式可能略显粗糙但对新人来说能在半小时内看到自己的第一台监控服务器上线这种成就感很重要。另外如果你最终目标是生产环境我的建议是先搭一台 All-in-One 当测试机用来验证规则、测试告警逻辑、调整索引参数再在另一批机器上搭分布式。这样你在分布式环境里遇到的“配置改坏了”一类问题不会影响现有业务。2.3 安装前的依赖准备版本兼容才是天大的事不管走哪条路线有几个基础工具是绕不开的这里特别提醒一下你网上搜安装教程的时候经常会看到 Python 安装教程、Git 安装教程、Vim 安装教程之类的文章以为这些是必须的前置条件。实际上 Wazuh 安装脚本所需的依赖在官方支持的系统上大多数是预装好的。在 Ubuntu 22.04 上我的实践如下apt update apt install curl tar openssl git vim -y这几个工具基本够用。CentOS 7.9 相应地用yum install curl tar openssl git vim -y关于 PythonWazuh 的安装脚本依赖 Python 3.8 以上但不需要你手动装。如果你系统里恰好自己编译过 Python还要特别注意 PATH 优先级问题——安装脚本可能会调用到错误的解释器版本。这点我在第 5 部分的分布式部署中再展开。另外Git 在安装阶段基本用不上除非你打算直接从 GitHub 拉 Wazuh 源码手动编译。如果你只是想用官方仓库安装Git 可以不需要。网络热词里常出现 Git 安装教程、Python 安装教程等那更多是通用开发环境的需求Wazuh 安装大可不必被这些教程牵着走。3. 实操记录All-in-One 完整安装与配置过程这一节开始进入正题。我将以 Ubuntu 22.04 为例逐步演示 All-in-One 的完整安装过程并穿插说明每一步的目的和容易踩的坑。3.1 准备阶段用软链接解决 /tmp 空间不足的坑这一步看起来和 Wazuh 无关但我在安装过程中踩过一次印象深刻。Wazuh 的部署助手在安装阶段会下载大量组件包并解压默认的临时目录是/tmp。如果你装系统的分区时候给/tmp分配的空间太小安装会在中途报磁盘空间不足整个安装流程被迫打断重来。我踩坑现场是这样的当时虚拟机给根分区只划了 20GB装到一半脚本报 No space left on device我第一反应是清理 apt 缓存删掉旧内核腾了 2GB 左右出来重新装又卡在同一位置。最后发现是/tmp被单独分区只有 2GB安装包解压一下就满了。解决方式把/tmp软链接到空间足够的目录或者直接给/tmp扩容。我当时的处理办法是在根分区下新建一个/root/tmp然后rm -rf /tmp ln -s /root/tmp /tmp之后重新执行安装问题解除。这个坑官方文档没提但实际操作里隔三差五会遇到。3.2 安装脚本一段命令执行后的真实输出Wazuh 官方给出的 All-in-One 安装命令非常简洁就一行curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh bash wazuh-install.sh --generate-config-files --instances 1这个命令里面的4.9是 Wazuh 的主版本号你需要把它替换成当前的最新版本。可以在 Wazuh 官网上查 Latest Version。注意不要随便用latest之类的不固定版本号因为脚本的下载路径和版本强绑定写死版本号是最稳的。命令执行后脚本会做以下几件事检查系统版本、架构、可用内存和端口。下载并安装 Wazuh Indexer、Server、Dashboard 三个组件。生成需要的证书自签名 CA 和节点证书并自动配置。启动三个服务并设置开机自启。整个流程大概十几分钟取决于你的网络状况。如果中间哪一步失败脚本一般会报个 Error installing 并退出。这时不要慌先去日志里看具体的失败原因。安装完成后脚本会在控制台打印一段类似这样的信息dashboard_install.sh: OK wazuh-indexer: OK wazuh-manager: OK --- Summary --- You can access the web interface https://server-ip User: admin Password: 随机生成的密码这段输出很重要请先记录因为admin的初始密码是自动生成的如果丢了后面要重置会比较麻烦。3.3 证书生成与文件权限最容易翻车的两个环节如果你安装的是 All-in-One部署助手会自动处理证书生成和权限配置基本不用你手工干预。但如果你选的是手动安装或者分布式部署证书这个环节是出错重灾区。先说证书生成的坑。Wazuh 三件套之间全部采用 HTTPS 双向 TLS 认证也就是每个节点都要有自己的证书并且要由同一个 CA 签发。如果某台机器拿到的证书和另一台对不上组件之间通信会直接失败而且报错信息非常具有迷惑性比如 Dashboard 页面提示 Failed to connect to search guard 或者索引器日志里报 unable to parse message from REST API。我第一次做分布式部署时就遇到过证书混淆问题三台机器的证书生成到同一个 tar 包里解压的时候我少拷贝了一个文件结果 Indexer 和 Server 之间互验证书失败日志里全是 SSL 错误。排查了很久才发现是某个节点的证书文件缺失。再说文件权限。Wazuh 三件套对证书文件的权限要求极其严格用户和组必须匹配权限位必须正确。具体来说Indexer 使用的证书和密钥文件属主必须是wazuh-indexer:wazuh-indexer权限建议660。ServerManager使用的证书属主必须是wazuh:wazuh权限建议660。Dashboard 使用的证书属主必须是wazuh-dashboard:wazuh-dashboard权限建议660。权限不对时服务启动时会报 Permission denied 或者 SSL 初始化失败。这种情况用chown和chmod改一下就能解决但如果你不知道这个规则可能会在 SSL 错误里打转很久。3.4 验证安装端口、进程、页面三层检查安装脚本执行完成后先别急着登录 Dashboard用这三步验证一下安装状态第一层检查端口监听状态。ss -lntp | grep -E 9200|443|55000|1515正常的输出应该同时看到 9200、443、55000、1515 这几个端口都在 LISTEN 状态。如果缺少某个端口说明对应的服务没有启动成功优先去系统日志里翻相关进程的报错。第二层检查关键服务进程。systemctl status wazuh-indexer wazuh-manager wazuh-dashboard理想状态是三个服务都显示 active (running)。如果某个服务启动失败可以单独查看journalctl -u wazuh-indexer --no-pager -n 100 journalctl -u wazuh-manager --no-pager -n 100 journalctl -u wazuh-dashboard --no-pager -n 100这里的日志是排查问题的最重要入口比网上任何教程都更接近真实原因。第三层检查 Indexer 集群健康状态。curl -k -u admin:你的密码 https://127.0.0.1:9200/_cluster/health正常情况下返回的status应该是greennumber_of_nodes应该是1。如果返回yellow说明索引存在副本未分配的情况如果返回red说明有主分片未分配问题会比较大。这块我在第 5 章详细展开。4. 分布式部署要点三件套的安装顺序与衔接生产环境一般不做 All-in-One而是把三件套拆开。这一节我结合自己的实操给出分布式部署的完整顺序和关键细节。分布式部署中最需要注意的就是安装顺序必须先装 Indexer再装 Server最后装 Dashboard因为后面的组件在安装时就跟前面的组件建立信任关系装反了后面接入阶段很容易报错。4.1 先装 Wazuh IndexerIndexer 是整条数据链路的底层存储它不启动后面任何组件都白搭。在分布式部署中你需要在 Indexer 节点上单独下载安装脚本curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh然后先执行配置生成bash wazuh-install.sh --generate-config-files --instances 3这里的--instances 3表示要生成三个节点的配置包括证书和 yml 配置文件。执行完成后脚本会在当前目录生成一个wazuh-install-files.tar.gz压缩包里面包含所有节点的证书和配置文件。这个 tar 包需要你手动分发到三台机器上。Indexer 节点安装bash wazuh-install.sh --install-elasticsearch实际命令名可能是--install-indexer不同版本略有差异请以脚本的--help输出为准。安装完成后Indexer 会自动启动并监听 9200 端口。此时先不要急着装其他组件先验证 Indexer 自身集群状态。4.2 再装 Wazuh ServerServerManager节点的职责是接收 Agent 的日志和事件进行解析和告警然后写入 Indexer。安装方式类似bash wazuh-install.sh --install-wazuhServer 安装过程中需要用到前面 tar 包里的证书文件脚本会自动从解压目录找到对应的wazuh-server.pem、wazuh-server-key.pem等文件。这里最容易出的问题就是证书路径不对或者文件权限不对。Server 启动后你需要验证它和 Indexer 之间的通信是否正常。这个验证在 Server 节点上执行/usr/share/wazuh-indexer/bin/wazuh-indexer --version嗯上面的命令其实不适用于 Server 节点。正确的做法是检查 Server 的配置里是否指向了正确的 Indexer 地址然后让 Server 往 Indexer 写入一条测试数据。你可以在 Server 节点上执行curl -k -u admin:密码 https://indexer-ip:9200如果返回了版本信息说明网络通路正常、证书校验也过了。4.3 最后装 Wazuh DashboardDashboard 是用户的 Web 入口它需要连接 Indexer 和 Server所以在三件套里它依赖的组件最多。安装命令bash wazuh-install.sh --install-dashboard这里有个关键点Dashboard 的配置文件中需要指定server.host、server.port以及指向 Indexer 和 Server 的地址。如果你在安装前没有把wazuh-install-files.tar.gz正确解压在 Dashboard 节点上脚本会报找不到配置文件的错。Dashboard 安装完成后访问https://dashboard-ip用admin和你记录的密码登录。如果出现登录界面但输入密码后一直转圈大概率是 Dashboard 和 Indexer 的通信出了问题重点查 Dashboard 节点上的journalctl -u wazuh-dashboard日志。4.4 证书分发与节点配置同步分布式部署的证书分发环节是最容易乱的地方。我的建议是在所有安装命令执行前先把wazuh-install-files.tar.gz拷贝到三台机器的同一目录下比如/opt/wazuh-install/。解压后确认每个节点只保留自己需要的证书文件不要把其他节点的证书留在本机。每个节点的/etc/wazuh-indexer/opensearch.yml里discovery.seed_hosts要写清楚集群内所有节点的 IP如果是单节点 Indexer记得把discovery.type设为single-node。所有节点的时间必须同步NTP 或 chrony否则证书校验会因时间偏差失败。这个问题很隐蔽我见过因为服务器时间差了几分钟导致 TLS 握手失败的案例。5. 常见问题与排查技巧实录踩坑清单这一节把我在实际操作中遇到的典型问题和排查思路整理成清单方便你按图索骥。5.1 “Dashboard 登录一直转圈”排查思路这个问题在 Wazuh 社区里出现的频率非常高现象就是登录页能出来输入 admin 密码后一直转圈过一会儿提示无效凭据或者连接失败。排查路径先确认 Dashboard 能否连上 Indexer。在 Dashboard 节点执行curl -k -u admin:密码 https://127.0.0.1:9200能返回版本信息说明本机到 Indexer 的通路没问题如果超时或拒绝连接重点查端口和防火墙。再确认 Dashboard 配置里的server.host是不是0.0.0.0如果写死了127.0.0.1远程访问会失败。查看 Dashboard 日志journalctl -u wazuh-dashboard --no-pager -n 100常见错误包括 Failed to connect to opensearch 或者 SearchGuard authentication failed。如果是SearchGuard相关错误多半是证书不一致。检查 Dashboard 使用的证书是不是和 Indexer 同一个 CA 签发的。5.2 Indexer 状态 yellow/red 的排查Indexer 集群状态为yellow或者red是很常见的问题。yellow表示主分片已经分配但副本分片没有分配。在只有一台 Indexer 节点的环境里这是因为默认的副本数为 1但节点数只有 1副本无法分配。解决方式是把副本数改为 0curl -k -u admin:密码 https://127.0.0.1:9200/_settings -X PUT -H Content-Type: application/json -d {index:{number_of_replicas:0}}或者修改索引模板。如果你想知道为什么会这样因为 Wazuh 默认创建的索引模板副本数为 1在单节点集群里找不到副本节点就会一直保持 yellow。red状态更严重表示有主分片没有分配。可能原因包括节点之间网络不通、磁盘空间不足超过水位线导致分片无法分配、或者索引数据损坏。排查方式curl -k -u admin:密码 https://127.0.0.1:9200/_cat/shards?v看哪个索引卡在 UNASSIGNED再查看原因字段一般会给出线索。5.3 Filebeat 无法连接 IndexerWazuh Server 通过 Filebeat 将告警和事件写入 Indexer。如果 Server 的日志里有大量 could not connect to elasticsearch 或者 fail to send batch 之类的报错需要按顺序排查Filebeat 配置文件/etc/filebeat/filebeat.yml里的hosts是否正确指向 Indexer 节点 IP。证书文件权限是否为wazuh:wazuh且权限位为660。密码是否正确Filebeat 输出的认证信息是否和 Indexer 的内部用户一致。最后用命令手动测试 Filebeat 与 Indexer 的通路filebeat test output这个命令会给出明确的连接成功或失败信息非常实用。5.4 升级或重装后启动失败的“老规矩”如果你是升级版本或者重装遇到服务启动失败先不要乱卸载按这个顺序来检查系统日志journalctl -u wazuh-manager -n 50 journalctl -u wazuh-indexer -n 50 journalctl -u wazuh-dashboard -n 50如果是配置错误导致的启动失败通常日志末尾会写清楚哪个配置文件有问题。如果是证书问题导致的三件套互相连不上重新生成证书并分发是最快的解决路径。我见过有人因为升级后 Dashboard 起不来直接把整个环境卸载重装的其实很多升级失败的问题就出在/etc/wazuh-dashboard/opensearch_dashboards.yml里还残留旧版本配置项手动清理掉就能恢复。5.5 虚拟机环境下的兼容性很多人在虚拟机上装 Wazuh我自己也是从 VMware 虚拟机开始玩的。这里有一个额外的坑如果你用 VMware Workstation 跑 Ubuntu默认虚拟网卡模式如果是 NATWazuh 的安装脚本通常可以正常跑但 Agent 从外部接入时需要你额外配置端口转发否则 Agent 上报的数据根本到不了 Server。另外虚拟机的磁盘如果分配太小Wazuh Indexer 写数据很容易触发磁盘水位线索引变成只读表现是 Dashboard 里看不到新数据。所以虚拟机里建议至少分配 60GB 磁盘并预留扩展分区的能力。6. 装完以后还要做的事从“能打开页面”到“真正能用”安装完成、Dashboard 能登录这只是第一步。要真正把 Wazuh 跑起来还有几个必须做的配置项。6.1 修改默认账号密码Wazuh 安装后默认的admin密码在安装日志里打印但这密码是随机生成的很多人直接拿着用也不改。建议登录后立即在 Wazuh Dashboard 里通过 “OpenSearch Dashboards Security” 插件重置密码或者在 API 里调用相关接口修改。如果你需要给团队多人分配账号可以创建不同角色的用户分别授予只读、告警管理等权限避免所有人共用 admin。6.2 安装 Agent 并验证事件流不安装 Agent 的 Wazuh 只是个空壳监控平台没有任何意义。Agent 的安装方式支持 RPM、DEB、MSI 安装包也可以用脚本部署。在测试环境里我推荐直接在 Wazuh Server 本机装一个 Agent用来验证事件链路是否完整。curl -s https://packages.wazuh.com/4.x/wazuh-install.sh | bash -s -- -a -i server-ip -p password实际上命令细节可能因版本而异更通用的方式是在 Dashboard 的 Agents 页面选择“Deploy new agent”系统会给出对应系统的安装命令复制到目标机器执行即可。Agent 安装完成后回到 Dashboard 的 Agents 页面状态变成 Active 就说明注册成功。然后在 Agent 上执行一些安全操作比如安装一个后门程序或者修改系统文件等一两分钟后Dashboard 的 Security events 页面应该能看到对应的告警。如果没有告警检查 Agent 的/var/ossec/etc/ossec.conf里 Server 地址是否配置正确。6.3 磁盘监控与空间规划Wazuh 运行中最现实的问题就是磁盘被日志塞满。默认的索引保留策略是 90 天日志量大时每天可能产生几个 GB 的数据。建议从安装之初就规划好磁盘空间并开启索引清理策略。Wazuh 提供了索引生命周期管理ILM策略默认会按天数删除旧索引。你可以在 Dashboard 的 Indexer Settings 里调整保留时间。如果没有正确设置索引满了以后 Indexer 会自动把索引设为只读表现就是 Dashboard 没数据了这个坑很常见。我的个人实践是测试环境保留 30 天生产环境按合规要求 180 天到 365 天。磁盘不够了就提前扩容别等到水位线告警再处理。6.4 升级与维护注意事项Wazuh 的升级策略是小版本升级比如 4.7 到 4.8可以直接通过官方脚本完成大版本升级需要先做完整备份。升级前一定要先备份这几样东西/etc/wazuh-indexer目录下的配置文件和证书/etc/wazuh-manager目录下的规则配置Dashboard 的系统索引如果你有自定义的 dashboard 面板升级过程里最容易翻车的地方在于 Group 配置就是你在 Dashboard 里设置的 Agent 组策略升级脚本会保留这些配置但如果新旧版本的 schema 有变化旧的配置可能导致 Wazuh Manager 起不来。所以大版本升级前建议先在测试环境验证一遍。另外Wazuh 对新版本的老系统支持也是有限的。比如你还在 CentOS 7.9 上跑着老版本 Wazuh 4.5 想升级到 4.9大概率会碰到依赖问题。我的经验是老系统就留在旧版本新环境直接上新版没必要强行在旧系统上折腾最新版本。写在最后的实操体会安装 Wazuh 这件事说难也难说简单也简单关键是别被各种教程误导。我刚开始装的时候网上搜到一堆跟我情况完全不同的教程有讲单节点的、有讲大规模集群的、有讲源码编译的最后照着他们操作反而把自己带偏了。后来学乖了一切以官方文档和官方安装脚本为准遇到问题先看日志再搜索踩坑效率高了好几倍。如果你这个周末准备装 Wazuh 来体验一把我给的最实在的建议是这两条也是我自己反复用到的经验第一条别在一个环境里反复折腾装坏了就重开虚拟机比修安全监控平台要快得多。装 Wazuh 玩这个过程本身就是练手和熟悉三件套逻辑的好机会很多问题你在重装过程中自然就懂了。第二条所有改配置文件之前先备份一份Wazuh 的配置文件之间关联性很强一改改错一个点半天时间就没了。我习惯在/root下面建个backup目录把要改的配置先拷贝进去然后再动手。这个习惯在很多其他服务上同样适用。最后再说一句Wazuh 这个平台本身很强大但如果只停留在“装好了”这个阶段你会错过它真正的价值。花点时间把文件完整性监控、漏洞检测、合规检查这些功能都打开让它真实地监控几台机器你才能体会到一个能落地的安全平台该有的样子。