Wazuh 4.7部署故障排查：从内存溢出到证书校验的全链路解析

1. 这不是一份“安装文档”而是一份Wazuh部署现场的故障日志复盘Wazuh不是点几下Next就能跑起来的图形化软件它是一套基于Elastic Stack构建的、面向生产环境的开源安全监控与合规平台。我第一次在Ubuntu 22.04上部署Wazuh Manager时以为照着官网文档走完curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh sudo bash wazuh-install.sh -a就万事大吉——结果卡在第3步Elasticsearch服务反复崩溃日志里只有一行java.lang.OutOfMemoryError: Java heap space。后来发现这根本不是配置错误而是Wazuh安装脚本默认把Elasticsearch堆内存设为2GB而我的测试虚拟机只有3GB总内存系统连Swap都没开。这种“安装失败”背后是资源规划、依赖版本、系统内核参数、SELinux/AppArmor策略、甚至Python模块编译环境等多重因素的叠加失效。你搜“Wazuh 安装踩坑指南”大概率正被某个具体报错卡住可能是wazuh-manager服务启动失败也可能是wazuh-indexer无法注册节点或是wazuh-dashboard页面空白显示“Kibana is not ready”。这些表象背后本质是Wazuh不是一个独立运行的单体程序而是一个由Wazuh Manager分析引擎、Wazuh Indexer替代Elasticsearch的专用索引器、Wazuh Dashboard可视化前端和Wazuh Agent终端探针四个核心组件构成的分布式系统。它们之间通过HTTP/gRPC通信共享TLS证书体系共用一套集群发现机制。任何一个环节的证书不匹配、端口被占用、Java版本不兼容、或系统ulimit限制过低都会导致整个链路中断——而安装脚本往往只告诉你“Failed”却不告诉你失败在哪一层。这份指南不讲“第一步下载脚本第二步执行安装”而是还原我在三类典型环境物理服务器、VMware虚拟机、Docker容器中部署Wazuh 4.7.x的真实过程记录每一次systemctl status wazuh-manager返回的Exit code截图journalctl -u wazuh-manager -n 50 --no-pager里的关键报错行保存/var/ossec/logs/ossec.log中Agent注册失败的完整上下文。我会告诉你为什么apt install openjdk-17-jre-headless比apt install default-jre更稳妥为什么/etc/security/limits.conf里对wazuh用户的nofile设置必须大于65536为什么在VMware里启用vmxnet3网卡驱动能避免Agent心跳包丢包以及最关键的——如何用wazuh-control工具绕过安装脚本分步验证每个组件的健康状态。如果你刚接触Wazuh建议先跳到第4节“常见问题速查表”找到你的报错关键词再回溯对应章节的根因分析。这不是教程是故障排除手册。2. 安装方案选型为什么放弃All-in-One脚本转向手动分步部署2.1 All-in-One脚本的便利性与隐藏陷阱Wazuh官方提供的wazuh-install.sh脚本确实省事一行命令自动完成Indexer、Dashboard、Manager的下载、解压、配置、服务注册和启动。它适合快速搭建POC环境但在我经手的17个生产部署案例中有12个首次安装失败都源于该脚本的“过度自动化”。问题不在于脚本本身有Bug而在于它做了三件危险的事第一无差别覆盖系统配置。脚本会强制修改/etc/sysctl.conf添加vm.max_map_count262144和fs.file-max65536然后执行sysctl -p。这在干净的Ubuntu系统上没问题但如果目标服务器已运行MySQL或Nginxfs.file-max被调高可能导致其他服务文件描述符耗尽。更致命的是它会直接覆盖/etc/default/wazuh-indexer中的JAVA_HOME路径而这个路径可能与系统已有的Java环境冲突。第二静默降级依赖版本。当检测到系统已安装OpenJDK 11时脚本不会报错退出而是自动卸载并重装OpenJDK 17。但在某些定制化内核如AWS Graviton ARM64实例上OpenJDK 17的ARM版存在JIT编译器缺陷会导致Indexer进程CPU占用率100%且无响应。此时脚本已完成安装你只能手动回滚。第三证书生成逻辑过于理想化。脚本默认使用openssl req -x509 -nodes -days 3650生成自签名证书密钥长度固定为2048位。而Wazuh 4.7要求Indexer与Dashboard间通信必须使用SHA-256签名的证书2048位RSA密钥在部分FIPS合规环境中不被接受。脚本不校验证书签名算法只检查文件是否存在导致Dashboard启动后反复报错Invalid certificate signature algorithm。提示All-in-One脚本仅推荐用于全新安装的Ubuntu 22.04/24.04或CentOS 8 Stream虚拟机且内存≥4GB、磁盘≥50GB。若服务器已运行其他Java服务如Tomcat、Logstash或需对接现有Elasticsearch集群请务必跳过此脚本。2.2 手动分步部署的底层逻辑与收益我最终采用的方案是完全弃用wazuh-install.sh改用Wazuh官方APT仓库手动配置分步验证。核心逻辑是将Wazuh拆解为三个独立可验证的单元Indexer单元专注解决数据存储与检索。它替代了Elasticsearch但并非完全兼容——Indexer使用RocksDB作为底层存储引擎不支持Elasticsearch的DSL查询语法。因此必须单独验证其集群状态curl -k -u admin:admin https://localhost:9200/_cat/health?v、证书有效性openssl s_client -connect localhost:9200 -servername indexer -CAfile /etc/wazuh-indexer/certs/root-ca.pem和索引创建能力curl -k -X PUT https://localhost:9200/test-index?pretty -H Content-Type: application/json -d{settings:{number_of_shards:1}} -u admin:admin。Manager单元作为分析中枢它不直接处理数据而是将Agent上报的日志解析后转发给Indexer。关键验证点是/var/ossec/etc/ossec.conf中indexer段落的URL、证书路径和认证凭据是否与Indexer实际配置一致同时检查/var/ossec/logs/ossec.log是否有INFO: Connected to indexer字样。Dashboard单元本质是Kibana的定制分支所有可视化依赖Indexer的API响应。必须确认其/usr/share/wazuh-dashboard/config/wazuh.yml中wazuh.hosts[0].url指向正确的Indexer地址且wazuh.ssl.verification_mode设置为strict而非none以启用证书校验。这种分步法的收益是故障定位效率提升3倍以上。例如当Dashboard页面显示“Unable to fetch Wazuh API information”时传统方式需重启全部服务并翻查数十个日志而分步法下我只需执行# 验证Indexer是否存活 curl -k -I https://localhost:9200 2/dev/null | head -1 # 验证Manager能否连接Indexer sudo /var/ossec/bin/wazuh-control status | grep indexer # 验证Dashboard配置是否正确 grep -A 5 hosts: /usr/share/wazuh-dashboard/config/wazuh.yml三步即可锁定问题在Indexer证书未被Dashboard信任而非盲目重装。2.3 环境适配决策树从物理机到云环境的选型依据不同部署环境对Wazuh组件有差异化要求以下是基于我实际部署经验的决策树环境类型推荐组件版本关键适配措施典型失败场景VMware虚拟机Ubuntu 22.04Wazuh 4.7.2 OpenJDK 17.0.1必须禁用VMware Tools的vmxnet3驱动的TCP Segmentation OffloadTSO功能ethtool -K ens33 tso offAgent心跳包丢失Manager日志出现Connection reset by peer物理服务器CentOS 7.9Wazuh 4.6.4 OpenJDK 11.0.22需手动编译wazuh-agent的syscheck模块因CentOS 7内核缺少fanotify支持cd /var/ossec/src/agents/syscheck make cp syscheck.so /var/ossec/lib/Agent启动后立即退出ossec.log报错syscheck: fanotify_init failedDocker容器Ubuntu 24.04基础镜像Wazuh 4.7.3 OpenJDK 17.0.2必须挂载/proc和/sys为ro否则Indexer的cgroup内存限制失效docker run -v /proc:/proc:ro -v /sys:/sys:ro ...Indexer容器OOM被Killeddocker logs显示java.lang.OutOfMemoryError特别注意不要在WSL2中部署Wazuh Manager。WSL2的网络栈与Windows宿主共享导致Indexer监听的0.0.0.0:9200端口被Windows防火墙拦截而wazuh-control start命令无法提示此错误。我曾为此耗费11小时排查最终解决方案是改用原生Ubuntu VM。3. 核心细节解析从系统准备到证书生成的27个关键操作点3.1 系统层预检被90%教程忽略的5项硬性要求Wazuh对操作系统的要求远超一般应用。以下检查必须在执行任何安装命令前完成否则后续所有操作都是徒劳1. 内核版本与模块支持Wazuh Agent的syscheck文件完整性监控和rootcheck恶意软件扫描依赖Linux内核的fanotify和inotify接口。执行uname -r # 必须≥5.4.0Ubuntu 20.04默认 zcat /proc/config.gz | grep -i fanotify\|inotify # 输出应含y若fanotify为m模块需加载sudo modprobe fanotify并写入/etc/modules永久生效。2. 文件描述符限制Wazuh Manager需同时处理数千Agent连接ulimit -n必须≥65536。编辑/etc/security/limits.confwazuh soft nofile 65536 wazuh hard nofile 65536 * soft nofile 65536 * hard nofile 65536然后重启shell或执行sudo su - wazuh -c ulimit -n验证。注意此设置对systemd服务无效还需修改/etc/systemd/system/wazuh-manager.service在[Service]段添加LimitNOFILE655363. 时间同步精度Wazuh组件间通信依赖精确时间戳时钟偏差5秒会导致证书校验失败。强制使用chrony而非ntpdsudo apt install chrony -y sudo systemctl enable chrony sudo systemctl start chrony chronyc tracking # 输出应显示System clock offset 10ms4. SELinux/AppArmor策略Ubuntu默认启用AppArmor其/etc/apparmor.d/usr.sbin.wazuh-manager策略文件存在路径白名单漏洞。临时禁用验证sudo aa-disable /usr/sbin/wazuh-manager sudo systemctl restart wazuh-manager若服务正常则需更新AppArmor策略而非永久禁用。5. Python环境隔离Wazuh Manager自带Python 3.9解释器位于/var/ossec/framework/python/bin/python3但某些插件如AWS S3日志导入需额外模块。切勿用系统pip安装而应sudo /var/ossec/framework/python/bin/python3 -m pip install boto3否则/var/ossec/framework/python/下的site-packages会被污染导致Manager启动时报ImportError: No module named wazuh。注意以上5项检查缺一不可。我曾遇到一个案例客户服务器ulimit -n显示65536但/etc/security/limits.conf未配置wazuh用户导致Manager启动后仅能维持200个Agent连接第201个连接即被拒绝错误日志却只显示socket: too many open files无任何进程名提示。3.2 依赖安装实操OpenJDK、Git、Systemd的精准版本控制Wazuh 4.7.x明确要求OpenJDK 17非Oracle JDK且必须是headless版本无GUI组件减少攻击面。以下是经过验证的安装流程OpenJDK 17安装Ubuntu 22.04默认源提供openjdk-17-jre-headless但版本为17.0.1而Wazuh 4.7.3需17.0.2。手动下载Debian包wget https://github.com/adoptium/temurin17-binaries/releases/download/jdk-17.0.2%2B8/OpenJDK17U-jre_x64_linux_hotspot_17.0.2_8.deb sudo dpkg -i OpenJDK17U-jre_x64_linux_hotspot_17.0.2_8.deb sudo update-alternatives --install /usr/bin/java java /opt/java/jdk-17.0.28-jre/bin/java 1 sudo update-alternatives --set java /opt/java/jdk-17.0.28-jre/bin/java验证java -version输出应为17.0.2且which java指向/opt/java/jdk-17.0.28-jre/bin/java。Git配置要点Wazuh Manager需Git拉取规则集更新。关键配置是禁用SSL验证因内网Git服务器无有效证书git config --global http.sslVerify false git config --global user.name wazuh git config --global user.email wazuhlocalhost但此配置存在安全风险生产环境应改为git config --global http.https://git.internal.company.com/.sslCAInfo /etc/ssl/certs/internal-ca.crtSystemd服务优化Wazuh官方service文件未设置内存限制导致Indexer在内存不足时OOM。编辑/etc/systemd/system/wazuh-indexer.service[Service] MemoryLimit3G RestartSec30 Restarton-failure EnvironmentJAVA_HOME/opt/java/jdk-17.0.28-jre然后执行sudo systemctl daemon-reload。3.3 证书体系构建从Root CA到Node证书的7步手工签发Wazuh的TLS证书体系是故障高发区。All-in-One脚本生成的证书常因subjectAltName缺失导致Dashboard无法连接Indexer。以下是符合RFC 5280标准的手工签发流程步骤1生成Root CA私钥与证书openssl genrsa -out root-ca.key 4096 openssl req -x509 -new -nodes -key root-ca.key -sha256 -days 3650 -out root-ca.pem \ -subj /CUS/STCalifornia/LSan Francisco/OWazuh/CNWazuh Root CA步骤2创建Indexer证书请求配置新建indexer.cnf[req] default_bits 4096 prompt no default_md sha256 req_extensions req_ext distinguished_name dn [dn] C US ST California L San Francisco O Wazuh CN indexer [req_ext] subjectAltName alt_names [alt_names] DNS.1 localhost DNS.2 indexer IP.1 127.0.0.1 IP.2 192.168.1.100 # 替换为服务器实际IP步骤3生成Indexer私钥与CSRopenssl genrsa -out indexer.key 4096 openssl req -new -key indexer.key -out indexer.csr -config indexer.cnf步骤4用Root CA签发Indexer证书openssl x509 -req -in indexer.csr -CA root-ca.pem -CAkey root-ca.key -CAcreateserial \ -out indexer.pem -days 3650 -sha256 -extfile indexer.cnf -extensions req_ext步骤5生成Dashboard证书复用同一CAdashboard.cnf中CN dashboardalt_names包含DNS.1 dashboard和服务器IP。步骤6生成Manager证书Manager证书的alt_names必须包含所有Agent将连接的IP/DNS例如IP.1 192.168.1.100 DNS.1 manager.local DNS.2 wazuh-manager.company.com步骤7证书权限与路径标准化所有证书文件必须属主wazuh权限600sudo chown -R wazuh:wazuh /etc/wazuh-indexer/certs/ sudo chmod 600 /etc/wazuh-indexer/certs/*.pem /etc/wazuh-indexer/certs/*.key且路径必须严格匹配配置文件Indexer/etc/wazuh-indexer/certs/Dashboard/usr/share/wazuh-dashboard/certs/Manager/var/ossec/etc/wazuh-cert/实操心得证书签发后务必用openssl verify -CAfile root-ca.pem indexer.pem验证链完整性。若返回OK再执行curl -k -v https://localhost:9200检查TLS握手是否成功。很多“连接被拒绝”错误实为证书校验失败而非端口未监听。4. 实操过程全记录从零开始部署Wazuh 4.7.3的逐行命令与结果分析4.1 环境初始化Ubuntu 22.04虚拟机的12项预配置我使用的测试环境是VMware Workstation 17.0虚拟机配置4 vCPU、4GB RAM、50GB SSD。以下是开机后的首屏操作1. 系统更新与基础工具安装sudo apt update sudo apt upgrade -y sudo apt install curl wget gnupg2 apt-transport-https software-properties-common -y2. 添加Wazuh APT仓库curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --dearmor -o /usr/share/keyrings/wazuh-stable.gpg echo deb [archamd64 signed-by/usr/share/keyrings/wazuh-stable.gpg] https://packages.wazuh.com/4.x/apt/ stable main | sudo tee /etc/apt/sources.list.d/wazuh.list sudo apt update3. 安装OpenJDK 17.0.2如前所述略见3.2节。4. 创建专用用户与目录sudo useradd -r -s /sbin/nologin wazuh sudo mkdir -p /etc/wazuh-indexer/certs /usr/share/wazuh-dashboard/certs /var/ossec/etc/wazuh-cert sudo chown -R wazuh:wazuh /etc/wazuh-indexer /usr/share/wazuh-dashboard /var/ossec5. 配置系统参数echo vm.max_map_count262144 | sudo tee -a /etc/sysctl.conf echo fs.file-max65536 | sudo tee -a /etc/sysctl.conf sudo sysctl -p6. 预检ulimitecho wazuh soft nofile 65536 | sudo tee -a /etc/security/limits.conf echo wazuh hard nofile 65536 | sudo tee -a /etc/security/limits.conf7. 安装Indexersudo apt install wazuh-indexer -y sudo systemctl daemon-reload8. 部署Indexer证书将前述生成的root-ca.pem、indexer.pem、indexer.key复制到/etc/wazuh-indexer/certs/并设置权限。9. 配置Indexer编辑/etc/wazuh-indexer/opensearch.ymlplugins.security.allow_default_init_securityindex: true plugins.security.ssl.transport.pemcert_filepath: certs/indexer.pem plugins.security.ssl.transport.pemkey_filepath: certs/indexer.key plugins.security.ssl.transport.pemtrustedcas_filepath: certs/root-ca.pem plugins.security.ssl.http.pemcert_filepath: certs/indexer.pem plugins.security.ssl.http.pemkey_filepath: certs/indexer.key plugins.security.ssl.http.pemtrustedcas_filepath: certs/root-ca.pem10. 启动Indexer并验证sudo systemctl enable wazuh-indexer sudo systemctl start wazuh-indexer sleep 30 # 等待集群初始化 curl -k -u admin:admin https://localhost:9200/_cat/health?v # 应返回 green 状态11. 安装Dashboardsudo apt install wazuh-dashboard -y12. 部署Dashboard证书将root-ca.pem、dashboard.pem、dashboard.key复制到/usr/share/wazuh-dashboard/certs/权限600。此时Indexer与Dashboard已就绪但尚未关联。下一步是配置Dashboard连接Indexer。4.2 Dashboard配置3个文件的17处关键参数详解Dashboard的配置分散在三个文件中任何一处错误都会导致前端白屏文件1/usr/share/wazuh-dashboard/config/wazuh.yml这是Dashboard连接Indexer的主配置wazuh: - hosts: - url: https://192.168.1.100:9200 # 必须是Indexer监听的IP不能用localhost username: admin password: admin nodes: 1 ssl: verification_mode: strict # 绝对不可设为none certificate_authorities: - /usr/share/wazuh-dashboard/certs/root-ca.pem关键点url必须使用服务器实际IP因Dashboard容器内localhost指向自身而非Indexercertificate_authorities路径必须绝对准确且root-ca.pem内容需与Indexer使用的CA完全一致。文件2/usr/share/wazuh-dashboard/config/opensearch_dashboards.yml这是Kibana框架的通用配置server.host: 0.0.0.0 server.port: 5601 opensearch.ssl.verificationMode: strict opensearch.ssl.certificateAuthorities: [/usr/share/wazuh-dashboard/certs/root-ca.pem] opensearch.username: admin opensearch.password: admin opensearch.requestTimeout: 90000关键点server.host必须设为0.0.0.0否则Dashboard仅监听本地回环requestTimeout需≥90秒因Indexer首次启动需加载大量规则集。文件3/usr/share/wazuh-dashboard/config/kibana.yml旧版遗留Wazuh 4.7仍保留此文件需注释掉所有elasticsearch.*配置否则会与opensearch_dashboards.yml冲突# elasticsearch.hosts: [https://localhost:9200] # elasticsearch.username: admin # elasticsearch.password: admin配置完成后启动Dashboardsudo systemctl enable wazuh-dashboard sudo systemctl start wazuh-dashboard sudo journalctl -u wazuh-dashboard -n 50 --no-pager | grep -i listening\|error正常输出应含Server running at http://localhost:5601。若出现Error: connect ECONNREFUSED 127.0.0.1:9200说明wazuh.yml中url配置错误。4.3 Manager安装与Agent注册从服务启动到首条告警的全流程Manager是Wazuh的神经中枢其安装需与Indexer、Dashboard协同1. 安装Managersudo apt install wazuh-manager -y2. 配置Manager连接Indexer编辑/var/ossec/etc/ossec.conf在ossec_config内添加indexer urlhttps://192.168.1.100:9200/url useradmin/user passwordadmin/password ssl certificate_authorities/var/ossec/etc/wazuh-cert/root-ca.pem/certificate_authorities /ssl /indexer注意url必须与Dashboard配置中的url完全一致certificate_authorities路径需存在且可读。3. 部署Manager证书将root-ca.pem、manager.pem、manager.key复制到/var/ossec/etc/wazuh-cert/权限600。4. 启动Managersudo systemctl enable wazuh-manager sudo systemctl start wazuh-manager sudo journalctl -u wazuh-manager -n 50 --no-pager | grep -E (Connected to indexer|ERROR)成功日志应含INFO: Connected to indexer。5. 注册首个Agent在另一台Ubuntu机器上安装Agentcurl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --dearmor -o /usr/share/keyrings/wazuh-stable.gpg echo deb [archamd64 signed-by/usr/share/keyrings/wazuh-stable.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 /var/ossec/bin/manage_agents # 选择A添加Agent记下Key回到Manager服务器执行sudo /var/ossec/bin/manage_agents # 选择E提取Key粘贴到Agent端 sudo systemctl enable wazuh-agent sudo systemctl start wazuh-agent6. 验证Agent状态在Manager上执行sudo /var/ossec/bin/agent_control -l # 应显示Agent状态为Active sudo tail -f /var/ossec/logs/ossec.log | grep -i received message from agent约1分钟后Dashboard前端应出现首条告警“New agent registered”。5. 常见问题与排查技巧实录21个真实报错的根因与速修方案5.1 Indexer类问题从集群红灯到索引损坏的应急处理问题1curl -k -u admin:admin https://localhost:9200/_cat/health?v返回red根因Indexer节点无法形成集群通常因discovery.seed_hosts未配置或防火墙阻断9300端口。速修# 检查集群配置 sudo grep -A 5 discovery.seed_hosts /etc/wazuh-indexer/opensearch.yml # 应为discovery.seed_hosts: [192.168.1.100:9300] # 开放端口 sudo ufw allow 9300 sudo systemctl restart wazuh-indexer问题2Indexer service failed with exit code 143根因OOM Killer终止进程因MemoryLimit设置过低或Java堆内存不足。速修# 查看OOM日志 dmesg -T | grep -i killed process # 调整Java堆内存 sudo sed -i s/-Xms2g -Xmx2g/-Xms3g -Xmx3g/ /etc/wazuh-indexer/jvm.options sudo systemctl restart wazuh-indexer问题3Failed to create index [.wazuh-monitoring-10-2024.05.01]根因Indexer磁盘空间不足或/var/lib/wazuh-indexer分区满。速修df -h /var/lib/wazuh-indexer # 清理旧索引谨慎 curl -k -X DELETE https://localhost:9200/.wazuh-monitoring-10-2024.04.* -u admin:admin5.2 Dashboard类问题前端白屏与API失效的诊断链问题4Dashboard页面显示Kibana server is not ready yet根因Dashboard无法连接Indexer99%因证书校验失败。速修# 检查证书链 sudo openssl verify -CAfile /usr/share/wazuh-dashboard/certs/root-ca.pem \ /usr/share/wazuh-dashboard/certs/dashboard.pem # 若失败重新签发Dashboard证书确保subjectAltName包含服务器IP问题5Error: Unable to fetch Wazuh API information根因Manager未向Indexer推送API元数据。速修# 强制Manager同步 sudo /var/ossec/bin/wazuh-control restart # 检查Manager日志 sudo tail -50 /var/ossec/logs/ossec.log | grep -i api # 应含INFO: API started on port 55000问题6Dashboard登录后空白Network标签显示401 Unauthorized根因/usr/share/wazuh-dashboard/config/opensearch_dashboards.yml中opensearch.username/password与Indexer的admin凭据不匹配。速修# 重置Indexer管理员密码 sudo /usr/share/wazuh-indexer/plugins/opensearch-security/tools/hash.sh -p admin # 将输出的hash替换到/etc/wazuh-indexer/opensearch-security/config/opensearch-security/config.yml sudo systemctl restart wazuh-indexer5.3 Manager与Agent类问题连接中断与日志丢失的深度排查问题7ossec.log持续刷ERROR: Connection refused, waiting for server根因Manager未监听Agent连接端口1514/1515或防火墙阻止。速修# 检查Manager监听状态 sudo ss -tlnp | grep :1514 # 若无输出检查/var/ossec/etc/ossec.conf中remote段落 # 应含port1514/port 和 protocoltcp/protocol sudo ufw allow 1514问题8Agent注册成功但无日志上报根因Agent配置中serverIP错误或Manager的clientuse_password设为yes但未配置密码。速修# 在Agent端检查配置 sudo cat /var/ossec/etc/ossec.conf | grep -A 5 server # 应为address192.168.1.100/address # 在Manager端检查密码配置 sudo grep -A 3 client /var/ossec/etc/ossec.conf # 若use_passwordyes则需在Agent端执行 sudo /var/ossec/bin/manage_agents -a # 重新生成带密码的Key问题9wazuh-control status显示wazuh-manager为inactive (dead)但ps aux | grep wazuh有进程根因systemd服务文件Typeforking与Manager实际启动模式不匹配。速修# 编辑服务文件 sudo nano /etc/systemd/system/wazuh-manager.service # 将Typeforking改为Typesimple sudo systemctl daemon-reload sudo systemctl restart wazuh-manager5.4 系统级问题资源争用与内核参数失效的终极解法问题10systemctl start wazuh-indexer后立即退出journalctl无日志根因/etc/security/limits.conf