1. 项目概述：这不是一份“安装文档”，而是一份Wazuh部署现场的故障日志复盘
Wazuh不是点几下Next就能跑起来的图形化软件，它是一套融合了HIDS（主机入侵检测）、SIEM（安全信息与事件管理）、CIS合规检查、云工作负载保护和漏洞扫描能力的开源安全平台。它的核心逻辑是“代理-服务器-索引器”三层架构：终端上轻量级wazuh-agent采集系统日志、进程行为、文件完整性变化；wazuh-manager集中接收、解析、关联分析并触发告警；Elasticsearch（或OpenSearch）负责存储与检索海量原始日志与告警数据，Kibana（或OpenSearch Dashboards）提供可视化界面。这个结构决定了它的安装不是单点操作，而是跨组件、跨依赖、跨权限、跨版本的系统性工程——任何一环出错，整个链条就卡死在“启动失败”“连接拒绝”“索引为空”这些看似模糊却极难定位的状态里。
我过去三年在金融、政务、制造类客户现场部署Wazuh超过27次，平均每次部署耗时11.6小时，其中63%的时间花在解决安装阶段的非预期问题上。所谓“踩坑”，不是指命令敲错了，而是指：你严格按照官网文档执行了curl -sO https://packages.wazuh.com/4.8/wazuh-install.sh && sudo bash ./wazuh-install.sh -a，结果systemctl status wazuh-manager显示active (exited)，但journalctl -u wazuh-manager -n 50 --no-pager里只有一行Started Wazuh manager.，再无后续；或者你成功启用了manager，agent却始终报ERROR: Unable to connect to server (127.0.0.1:1514)，而你确认防火墙已关、端口监听正常、证书路径也对——这种“全链路看起来都对，但就是不工作”的状态，才是Wazuh安装最典型的陷阱。本指南不讲“如何安装”，只讲“为什么装不上”以及“怎么一眼看出卡在哪一层”。关键词Wazuh、安装、踩坑指南，每一个词都对应一个真实战场：Wazuh代表其多组件耦合的本质，安装代表从零构建环境的过程，踩坑指南则意味着所有结论都来自journalctl滚动日志里的第37行报错、/var/ossec/logs/ossec.log中被忽略的warning级别提示、以及/etc/wazuh-indexer/opensearch.yml里一个空格引发的集群发现失败。适合正在Ubuntu 22.04虚拟机里反复重装第三遍的运维工程师，也适合刚接触SIEM概念、想用Wazuh做毕设的网络安全专业学生——只要你需要亲手把Wazuh跑起来，而不是只看演示视频，这份指南就值得你逐行对照。
2. 安装方案选型与底层逻辑拆解：为什么必须放弃“一键脚本”幻想
Wazuh官方提供三种主流部署路径：All-in-One（单机集成版）、Distributed（分布式分离版）和Docker Compose版。绝大多数新手直接选择All-in-One，因为它承诺“一条命令完成全部安装”。但正是这个“全部”埋下了最大隐患。我们来拆解wazuh-install.sh脚本在后台实际干了什么：
2.1 All-in-One脚本的真实行为链
该脚本并非原子化操作，而是一个由17个独立子任务组成的流水线，每个环节都可能因环境差异中断：
- 系统预检：检查
lsb_release -sc是否为jammy（Ubuntu 22.04）或focal（20.04），若为noble（24.04）则直接退出并报错Unsupported OS version——哪怕你手动修改脚本绕过此检查，后续步骤仍会因内核模块兼容性失败； - 依赖注入：自动安装
openjdk-17-jre-headless、curl、wget、gnupg等基础工具，但不会校验java -version输出是否含OpenJDK Runtime Environment (build 17.x.x+xx)，若系统已存在Java 11，脚本会静默跳过安装，导致后续Indexer启动时报Unsupported Java version； - 证书生成：调用
/var/ossec/wodles/certs/ssl_certs.sh生成自签名证书，该脚本硬编码了openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/wazuh-indexer/certs/tls.key -out /etc/wazuh-indexer/certs/tls.crt -subj "/C=US/ST=CA/L=San Francisco/O=Wazuh/CN=localhost"，但若/etc/wazuh-indexer/certs/目录权限为755而非700，OpenSearch服务将因无法读取私钥而拒绝启动，错误日志仅显示Failed to load SSL configuration，完全不提示权限问题； - 服务注册：使用
systemctl enable --now wazuh-manager启用服务，但该命令不等待服务真正进入active (running)状态就返回成功，此时若manager内部初始化（如数据库迁移、规则加载）耗时超30秒，systemctl is-active wazuh-manager可能返回activating，而脚本已进入下一阶段，造成后续agent连接manager时遭遇Connection refused。
提示：我实测过，在4核8G的VMware虚拟机上，All-in-One脚本全程耗时约8分23秒，但其中前2分15秒是OpenSearch集群等待主节点选举完成的时间。如果你在脚本执行完立刻执行
curl -k https://localhost:55000，90%概率得到curl: (7) Failed to connect to localhost port 55000: Connection refused——这不是安装失败，而是你没给服务留够“热身时间”。
2.2 分布式部署为何反而更稳健？
分布式方案要求你手动安装三个独立组件：Wazuh Manager、Wazuh Indexer（替代Elasticsearch）、Wazuh Dashboard（替代Kibana）。表面看步骤更多，实则优势显著：
- 故障隔离：Manager启动失败不影响Indexer运行，你可以先确保
/usr/share/wazuh-indexer/bin/opensearch能稳定监听9200端口，再排查manager的/var/ossec/logs/ossec.log； - 版本可控：All-in-One脚本强制绑定Wazuh 4.8 + OpenSearch 2.11.0，而分布式允许你单独升级Indexer至2.12.0修复已知的TLS握手内存泄漏问题；
- 配置透明：所有配置文件路径明确（
/etc/wazuh-manager/ossec.conf、/etc/wazuh-indexer/opensearch.yml、/etc/wazuh-dashboard/opensearch_dashboards.yml），无需反编译脚本查找参数位置。
注意：分布式部署的“手动”不等于“裸写配置”。Wazuh提供
wazuh-manager-ctl、wazuh-indexer-ctl等控制脚本，它们封装了服务启停、配置验证、日志轮转等高频操作，比直接systemctl更安全。例如sudo /usr/share/wazuh-indexer/bin/opensearch-ctl status会返回详细的集群健康状态（green/yellow/red），而systemctl status wazuh-indexer只显示进程状态。
2.3 Docker方案的适用边界在哪里？
Docker Compose方案（docker-compose -f docker-compose.yml up -d）在开发测试场景极具价值：它通过docker network create wazuh创建隔离网络，彻底规避宿主机防火墙、SELinux策略干扰；volumes映射确保配置修改后docker-compose restart即可生效，无需systemctl daemon-reload。但它有硬伤：
- 性能损耗：Wazuh Agent需监控宿主机
/proc、/sys等伪文件系统，Docker默认不挂载这些路径，需在docker-compose.yml中显式添加volumes: - /proc:/host/proc:ro，否则agent无法获取进程列表； - 证书信任链断裂：容器内生成的证书CN为
wazuh-indexer，但Dashboard容器访问Indexer时使用https://wazuh-indexer:9200，若未在Dashboard的opensearch_dashboards.yml中配置opensearch.ssl.verificationMode: none，将因证书域名不匹配而拒绝连接； - 资源争抢：单机运行3个容器（indexer、dashboard、manager）至少需6GB内存，若VMware虚拟机分配内存不足8GB，OpenSearch会因JVM GC频繁触发
OutOfMemoryError，日志中表现为[opensearch.index.search.slowlog] [index_name] took [15s]后服务假死。
我的建议是：生产环境首选分布式部署，开发调试用Docker，All-in-One仅用于快速POC验证功能点。三者不是替代关系，而是不同成熟度阶段的工具选择。
3. 核心组件安装实操与避坑细节：从系统准备到服务验证的完整链路
以下以Ubuntu 22.04 LTS（Linux 5.15.0-107-generic）为基准环境，按分布式部署路径展开。所有命令均经实机验证，参数值标注来源依据。
3.1 系统层预处理：绕过90%的“环境不兼容”报错
Wazuh对系统环境有隐性要求，这些要求不会在安装文档首屏强调，但会直接导致后续步骤失败：
内核参数调优（影响OpenSearch稳定性）
OpenSearch基于Lucene构建，对vm.max_map_count（进程可创建的最大内存映射区数量）敏感。默认值65530在高负载下易触发max virtual memory areas vm.max_map_count [65530] is too low错误。执行：echo 'vm.max_map_count=262144' | sudo tee -a /etc/sysctl.conf sudo sysctl -p验证：
sysctl vm.max_map_count应输出262144。此参数需重启生效，但sysctl -p可立即加载，避免重启虚拟机。时区与NTP同步（影响告警时间戳准确性）
Wazuh Manager日志时间戳若与Indexer不一致，会导致KQL查询@timestamp > "now-1h"返回空结果。执行：sudo timedatectl set-timezone Asia/Shanghai sudo systemctl enable --now systemd-timesyncd sudo timedatectl status | grep "System clock synchronized"输出
yes表示同步成功。若为no，需检查防火墙是否放行UDP 123端口，或更换NTP服务器：sudo timedatectl set-ntp false && sudo systemctl stop systemd-timesyncd && sudo ntpdate -s time.windows.com禁用swap分区（OpenSearch强制要求）
OpenSearch启动时会检查/proc/sys/vm/swappiness，若值大于0则拒绝启动。执行：echo 'vm.swappiness=1' | sudo tee -a /etc/sysctl.conf sudo swapoff -a sudo sed -i '/swap/d' /etc/fstab验证：
free -h中Swap行应全为0B。此步不可跳过，否则/usr/share/wazuh-indexer/bin/opensearch-ctl start会静默失败。
实操心得：我在某银行客户现场曾因未禁用swap，导致OpenSearch反复崩溃。
journalctl -u wazuh-indexer -n 20只显示Started Wazuh Indexer.，而/var/log/wazuh-indexer/opensearch.log末尾有ERROR: bootstrap checks failed，但日志级别为ERROR，需主动搜索bootstrap关键词才能定位。建议将上述三步做成precheck.sh脚本，每次部署前运行一次。
3.2 Wazuh Indexer安装：OpenSearch的定制化加固
Wazuh Indexer是OpenSearch的发行版，但移除了部分企业插件（如SQL查询），增加了Wazuh专用索引模板。安装必须使用Wazuh官方APT仓库，而非通用OpenSearch包：
添加GPG密钥与源
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --dearmor -o /usr/share/keyrings/wazuh-stable-keyring.gpg echo "deb [arch=amd64 signed-by=/usr/share/keyrings/wazuh-stable-keyring.gpg] https://packages.wazuh.com/4.8/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/wazuh-stable.list sudo apt update关键点：
$(lsb_release -sc)必须输出jammy，若为focal需手动替换。signed-by路径必须是.gpg格式，若误用.asc文件，apt update会报NO_PUBKEY错误且不提示具体缺失密钥ID。安装Indexer并初始化证书
sudo apt install wazuh-indexer sudo /usr/share/wazuh-indexer/opensearch-tls tool generate-http-certs -v -H localhost,wazuh-indexer -ip 127.0.0.1,::1此命令生成HTTP通信证书，
-H参数必须包含localhost和主机名（hostname -f输出），否则Dashboard连接时会报CERT_HAS_EXPIRED。生成的证书存于/etc/wazuh-indexer/certs/，需确保：sudo chown -R wazuh-indexer:wazuh-indexer /etc/wazuh-indexer/certs/ sudo chmod 700 /etc/wazuh-indexer/certs/ sudo chmod 600 /etc/wazuh-indexer/certs/tls.*配置OpenSearch核心参数
编辑/etc/wazuh-indexer/opensearch.yml，关键修改项：# 必须项：集群名称需与Wazuh Manager配置一致 cluster.name: wazuh-cluster # 必须项：绑定地址，0.0.0.0允许外部访问（测试环境） network.host: 0.0.0.0 # 必须项：HTTP端口，Wazuh Manager默认连9200 http.port: 9200 # 必须项：发现种子主机，单节点设为自己 discovery.seed_hosts: ["127.0.0.1:9300"] # 必须项：初始主节点，单节点必须包含自己 cluster.initial_master_nodes: ["wazuh-indexer"] # 性能优化：禁用分片分配（单节点无需） cluster.routing.allocation.disk.threshold_enabled: false # 安全加固：启用SSL plugins.security.disabled: false opensearch.ssl.http.enabled: true opensearch.ssl.http.pemcert_filepath: certs/tls.crt opensearch.ssl.http.pemkey_filepath: certs/tls.key opensearch.ssl.http.pemtrustedcas_filepath: certs/root-ca.pem注意：
cluster.initial_master_nodes的值必须是节点名称（node.name默认为wazuh-indexer），而非IP或主机名。若修改过node.name，此处必须同步更新，否则集群无法形成。启动并验证Indexer
sudo systemctl daemon-reload sudo systemctl enable --now wazuh-indexer # 等待90秒让集群初始化 sleep 90 curl -k https://localhost:9200/_cat/health?v正常输出应为：
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent 1718234567 10:02:47 wazuh-cluster green 1 1 0 0 0 0 0 0 - 100.0%若
status为yellow，说明副本分片未分配（单节点正常）；若为red，需检查/var/log/wazuh-indexer/opensearch.log中Caused by:行。
3.3 Wazuh Manager安装：规则引擎与数据管道中枢
Manager是Wazuh的数据处理核心，其配置复杂度远超Indexer：
安装Manager并生成SSL证书
sudo apt install wazuh-manager sudo /var/ossec/wodles/certs/ssl_certs.sh -A-A参数生成Manager与Indexer通信的证书。生成的证书存于/var/ossec/etc/sslmanager.cert和/var/ossec/etc/sslmanager.key，需确保：sudo chown wazuh:wazuh /var/ossec/etc/sslmanager.* sudo chmod 600 /var/ossec/etc/sslmanager.*配置Manager连接Indexer
编辑/var/ossec/etc/ossec.conf，在<ossec_config>根节点下添加：<elasticsearch> <hosts>https://localhost:9200</hosts> <user>admin</user> <password>admin</password> <ssl_certificate>/var/ossec/etc/sslmanager.cert</ssl_certificate> <ssl_key>/var/ossec/etc/sslmanager.key</ssl_key> <ssl_ca>/etc/wazuh-indexer/certs/root-ca.pem</ssl_ca> <port>9200</port> <index>ossec-alerts-*</index> </elasticsearch>关键点：
<user>和<password>必须与Indexer的plugins.security.authcz.admin_dn配置匹配。Wazuh Indexer默认管理员DN为CN=admin,OU=UNIT,O=ORG,L=LOC,ST=ST,C=CC，密码为admin，无需额外创建用户。启用关键模块
在ossec.conf中取消注释以下模块：<!-- 启用FIM（文件完整性监控） --> <syscheck> <frequency>43200</frequency> <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories> </syscheck> <!-- 启用日志分析（SSHD、Apache等） --> <localfile> <log_format>syslog</log_format> <location>/var/log/auth.log</location> </localfile> <!-- 启用Active Response（自动响应） --> <active-response> <command>firewall-drop</command> <location>server</location> <level>10</level> <timeout>600</timeout> </active-response>启动Manager并验证数据流
sudo systemctl enable --now wazuh-manager # 检查Manager日志是否有Indexer连接成功记录 sudo tail -n 50 /var/ossec/logs/ossec.log | grep "Connected to Elasticsearch" # 手动触发一条测试告警 echo "Jun 12 10:00:00 ubuntu sshd[1234]: Invalid user test from 192.168.1.100" | sudo /var/ossec/bin/ossec-logtest # 查看是否生成告警 curl -k -u admin:admin "https://localhost:9200/ossec-alerts-*/_search?pretty" -H 'Content-Type: application/json' -d' { "query": { "match": { "rule.description": "Invalid user" } } }'若返回JSON中
hits.total.value大于0，证明数据管道贯通。
3.4 Wazuh Dashboard安装：可视化层的HTTPS握手陷阱
Dashboard是OpenSearch Dashboards的定制版，其HTTPS配置极易出错：
安装Dashboard并配置SSL
sudo apt install wazuh-dashboard sudo /usr/share/wazuh-dashboard/opensearch-dashboards-tls tool generate-http-certs -v -H localhost,wazuh-dashboard -ip 127.0.0.1,::1配置Dashboard连接Indexer
编辑/etc/wazuh-dashboard/opensearch_dashboards.yml：# 必须项：Dashboard监听地址 server.host: "0.0.0.0" # 必须项：Indexer地址，必须用https且端口9200 opensearch.hosts: ["https://localhost:9200"] # 必须项：认证凭据 opensearch.username: "admin" opensearch.password: "admin" # 必须项：SSL验证模式，因使用自签名证书，设为none opensearch.ssl.verificationMode: "none" # 必须项：证书路径 opensearch.ssl.certificateAuthorities: ["/etc/wazuh-indexer/certs/root-ca.pem"] # 必须项：Dashboard自身HTTPS证书 server.ssl.enabled: true server.ssl.certificate: "/etc/wazuh-dashboard/certs/tls.crt" server.ssl.key: "/etc/wazuh-dashboard/certs/tls.key"踩坑实录：某次部署中，
opensearch.ssl.verificationMode被误设为full，Dashboard启动后访问https://localhost:5601显示Kibana server is not ready yet，/var/log/wazuh-dashboard/opensearch_dashboards.log中反复出现Unable to retrieve version information from OpenSearch nodes。排查方法：临时将opensearch.ssl.verificationMode改为none，若页面正常，则确认是证书验证问题。启动Dashboard并访问
sudo systemctl enable --now wazuh-dashboard # 等待120秒初始化 sleep 120 # 检查服务状态 sudo systemctl status wazuh-dashboard # 浏览器访问 https://<your-server-ip>:5601，用户名admin，密码admin
4. 全链路验证与典型故障排查：从“服务启动”到“告警可见”的闭环检验
安装完成不等于可用。真正的验收标准是：在Dashboard中能看到Agent发来的实时告警，并能执行搜索、图表、合规报告。以下是经过27次现场验证的闭环检验清单：
4.1 基础连通性四步验证法
按顺序执行，任一环节失败即停止：
| 步骤 | 命令 | 预期输出 | 失败原因定位 |
|---|---|---|---|
| 1. Indexer HTTP可达 | curl -k -I https://localhost:9200 | HTTP/2 200+content-type: application/json | 检查systemctl status wazuh-indexer、netstat -tuln | grep 9200、/var/log/wazuh-indexer/opensearch.log |
| 2. Manager连接Indexer | sudo tail -n 20 /var/ossec/logs/ossec.log | grep "Elasticsearch" | Connected to Elasticsearch+Version: 2.11.0 | 检查/var/ossec/etc/ossec.conf中<elasticsearch>配置、证书路径权限、Indexer集群状态 |
| 3. Dashboard连接Manager | curl -k -u admin:admin "https://localhost:9200/_cat/indices?v|grep ossec" | ossec-alerts-2024.06.12等索引名 | 若无输出，检查Dashboard日志中opensearch.hosts是否指向正确端口，opensearch.ssl.verificationMode是否为none |
| 4. Agent注册成功 | sudo /var/ossec/bin/agent_control -l | grep "Active" | wazuh-agent1 (ubuntu) Active | 若为Never connected，检查Agent配置中<server><address>是否为Manager IP，<client><server-id>是否匹配 |
提示：
agent_control -l输出中的Active状态需持续30秒以上才可靠。若刚启动Agent就查，可能显示Pending。
4.2 告警生成全流程跟踪
以SSH暴力破解为例，模拟并追踪数据流向：
在Agent主机触发事件
# 在安装了wazuh-agent的客户端执行 ssh invalid@localhost # 输入任意密码后退出，触发auth.log写入检查Agent日志是否捕获
# 在Agent主机执行 sudo tail -n 10 /var/ossec/logs/ossec.log | grep "sshd" # 应看到类似：2024 Jun 12 10:30:22 (ubuntu) 127.0.0.1->/var/log/auth.log Rule: 5715 (level 5) -> 'sshd: authentication failure.'检查Manager是否收到并解析
# 在Manager主机执行 sudo tail -n 10 /var/ossec/logs/archives/archives.log | grep "sshd" # 应看到归档的原始日志行 sudo tail -n 10 /var/ossec/logs/alerts/alerts.json | grep "sshd" # 应看到JSON格式告警，含"rule":{"id":"5715","description":"sshd: authentication failure."}检查Indexer是否索引
# 在Manager或Indexer主机执行 curl -k -u admin:admin "https://localhost:9200/ossec-alerts-*/_search?pretty" -H 'Content-Type: application/json' -d' { "query": {"match": {"rule.description": "sshd: authentication failure."}} }' # `hits.total.value`应≥1检查Dashboard是否展示
访问https://<server>:5601/app/wazuh#/management/agents，应看到Agent状态为绿色；进入Security Events面板，筛选rule.description: "sshd: authentication failure."，应有实时事件。
4.3 常见故障速查表与独家修复方案
| 故障现象 | 根本原因 | 修复命令/操作 | 验证方式 |
|---|---|---|---|
systemctl status wazuh-manager显示active (exited) | Manager启动脚本/var/ossec/bin/ossec-control start执行后立即退出，未等待内部初始化完成 | sudo /var/ossec/bin/ossec-control start && sleep 60 && sudo /var/ossec/bin/ossec-control status | sudo /var/ossec/bin/ossec-control status输出wazuh-analysisd、wazuh-remoted等进程为running |
Dashboard登录页显示Kibana server is not ready yet | opensearch.ssl.verificationMode未设为none，或opensearch.hosts端口错误（如写成9300） | sudo sed -i 's/verificationMode:.*/verificationMode: "none"/' /etc/wazuh-dashboard/opensearch_dashboards.yml && sudo systemctl restart wazuh-dashboard | curl -k https://localhost:5601/api/status | jq '.status.overall.state'应返回"green" |
Agent状态为Never connected，但telnet <manager-ip> 1514通 | Agent证书未更新，或Manager未生成Agent注册密钥 | sudo /var/ossec/bin/manage_agents→ 选A添加Agent → 记录Key → 在Agent执行sudo /var/ossec/bin/manage_agents -i <key>→sudo systemctl restart wazuh-agent | sudo /var/ossec/bin/agent_control -l中Agent状态变为Active |
Indexer日志报max file descriptors [4096] for opensearch process is too low | 系统nofile限制过低，OpenSearch要求≥65536 | echo 'wazuh-indexer soft nofile 65536' | sudo tee -a /etc/security/limits.conf && echo 'wazuh-indexer hard nofile 65536' | sudo tee -a /etc/security/limits.conf && sudo reboot | sudo su - wazuh-indexer -c 'ulimit -n'应输出65536 |
Dashboard图表显示No data to display，但告警JSON存在 | Kibana索引模式未正确关联，或时间范围过滤过严 | 进入Stack Management > Index Patterns，删除wazuh-alerts-*，重新创建，Time field选@timestamp；在仪表板右上角时间选择器设为Last 24 hours | 重新加载仪表板，数据应出现 |
实操心得：我总结出一个“15分钟故障定位法”：当遇到未知问题，立即执行以下三行命令，90%的问题线索就藏在输出里：
# 查看所有Wazuh服务状态 systemctl list-units \| grep wazuh # 查看各组件最新10行错误日志 journalctl -p 3 -n 10 \| grep -E "(wazuh|opensearch|dashboard)" # 查看证书有效期（证书过期是静默失败的头号杀手） openssl x509 -in /etc/wazuh-indexer/certs/tls.crt -text -noout \| grep "Not After"这三行命令覆盖了服务状态、错误根源、证书时效三大维度，比盲目重启高效得多。
5. 后续演进与生产加固建议：从能用到好用的关键跨越
安装完成只是起点。在真实生产环境中，还需完成以下加固动作，否则将面临性能瓶颈、安全风险或维护噩梦：
5.1 性能调优：应对日均10GB日志的吞吐挑战
默认配置在日志量>5GB/天时会出现延迟。关键调优点：
- OpenSearch JVM堆内存：编辑
/etc/wazuh-indexer/jvm.options，将-Xms4g和-Xmx4g改为-Xms6g和-Xmx6g（需宿主机内存≥12GB），避免频繁GC； - Manager日志轮转：编辑
/var/ossec/etc/ossec.conf，在<global>下添加：
防止<logall>no</logall> <logall_json>yes</logall_json> <alerts_log>yes</alerts_log> <archives>yes</archives> <max_size>100M</max_size> <rotate_interval>7</rotate_interval>/var/ossec/logs/archives/目录膨胀至数百GB； - Agent FIM监控范围收敛：将
<syscheck><directories>从/etc,/usr/bin,/usr/sbin精简为/etc/passwd,/etc/shadow,/usr/bin/sudo等关键文件，降低CPU占用。
5.2 安全加固：关闭默认的“高危便利”
Wazuh默认配置为方便入门，但生产环境必须收紧：
- 禁用默认管理员账户：在
/etc/wazuh-indexer/opensearch.yml中添加：
然后创建专用用户：plugins.security.authcz.adc: false plugins.security.audit.type: internal_opensearchsudo /usr/share/wazuh-indexer/plugins/opensearch-security/tools/hash.sh -p MySecurePass123 # 将生成的hash粘贴到`/etc/wazuh-indexer/opensearch-security/config.yml`中 - 限制Dashboard访问IP：在
/etc/wazuh-dashboard/opensearch_dashboards.yml中设置：server.host: "127.0.0.1" # 仅本地监听 # 通过Nginx反向代理暴露HTTPS，并配置IP白名单 - Agent通信加密升级：将Agent与Manager间通信从默认的AES-128-CBC升级为AES-256-GCM，在
/var/ossec/etc/ossec.conf中添加：<client> <encryption_algorithm>aes-256-gcm</encryption_algorithm> </client>
5.3 可观测性增强：让运维不再“盲人摸象”
在/var/ossec/etc/ossec.conf中启用以下模块，将Wazuh自身变成可观测对象：
<!-- 监控Wazuh Manager自身进程 --> <localfile> <log_format>syslog</log_format> <location>/var/ossec/logs/ossec.log</location> </localfile> <!-- 监控磁盘空间，防止日志填满根分区 --> <localfile> <log_format>command</log_format> <command>df -h /</command> <frequency>3600</frequency> </localfile> <!-- 监控Agent连接数，及时发现失联 --> <localfile> <log_format>command</log_format> <command>/var/ossec/bin/agent_control -l \| wc -l</command> <frequency>600</frequency> </localfile>然后在Dashboard中创建自定义仪表板，聚合这些指标。当df -h /输出Use%>90%时，自动触发邮件告警——这才是真正落地的SRE实践。
我个人在实际操作中的体会是
