企业官网建设流程全解析

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_count=262144 echo 'vm.max_map_count=262144' >> /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.sha256

sha256 比对无误后，先只生成配置文件，不执行安装。这一步的官方理由是：它会生成集群所需的证书和密码信息，你可以提前检查：

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/TCP，agent 安装时设置WAZUH_AGENT_NAME和WAZUH_MANAGER变量即可完成注册。如果使用代理或手动安装，需要在/var/ossec/etc/ossec.conf里修改 manager 地址。Windows agent 在安装时会把环境变量转成配置项，安装后想改地址，就要去C:\Program Files (x86)\ossec-agent\ossec.conf修改<client><server><address>这一节。

第三个问题：agent 的 hostname 是否唯一？如果多个 agent 取了相同的名称，manager 侧会出现客户端 key 冲突，一个 agent 把另一个挤下线。为了避免这个问题，我建议 agent 名称就用主机名加用途后缀，比如web01-nginx、db01-mysql。

3.2 agent 装完连不上，按这个顺序查

我在实际使用中，agent 连不上 manager 的排查路径基本是固定的。

先看 agent 端日志，Linux 上默认位置是/var/ossec/logs/ossec.log，Windows 上在安装目录的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 常见问题速查表

下面这张表是我自己在多次安装和排障中整理出来的高频问题，挺实用，建议收藏。

除了表格外，我觉得最值得记录的一点是：不要过度依赖 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-indexer：

systemctl restart wazuh-indexer

如果机器只有 4G 内存，建议把堆内存设为 1-2G，给系统和其他组件留出余量。这个参数不是越大越好，堆内存过大会导致 GC 暂停，反而影响稳定性。

第二，给索引数据配置生命周期管理。Wazuh 的告警数据会不断写入 indexer，时间久了磁盘会被索引撑爆。官方推荐给索引设置 ILM（Index Lifecycle Management）策略，或者直接用索引抹除脚本定期清理 90 天前的数据。我自己写了一个简单的 cron 任务，每天凌晨清理 90 天以上的告警索引，保证磁盘占用可控。

第三，备份关键配置。Wazuh 的配置分散在几个地方：manager 在/var/ossec/etc，indexer 在/etc/wazuh-indexer，dashboard 在/etc/wazuh-dashboard，Filebeat 在/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 从“能用”变成“好用”的关键一步。