Wazuh通过logcollector模块收集日志，需在ossec.conf中显式配置localfile或remote段并指定正确log_format（如syslog、eventlog），否则日志将被丢弃或解析失败；Linux系统日志建议用syslog格式，Windows事件日志须用eventlog或eventchannel格式，路径含空格时Windows需加双引号，轮转日志需配置ignore和frequency，远程syslog需启用manager端syslog接收并开放514端口。
系统日志收集：确认 logcollector 是否启用并匹配正确格式
Wazuh 默认通过 ossec-logcollector 进程读取日志，但必须在 ossec.conf 中显式配置
Linux 系统日志（如 /var/log/auth.log）建议用 syslog 格式；Windows 事件日志必须用 eventlog（如 Security）或 eventchannel（如 Microsoft-Windows-PowerShell/Operational）。
- 路径含空格或特殊字符时，Windows 下需用双引号包裹
- 若日志轮转频繁（如
auth.log.1.gz），需额外配置 - 远程 syslog 接入需在 manager 的
syslog
文件完整性监控（FIM）：syscheckd 启动后仍无告警的典型原因
FIM 功能由独立进程 ossec-syscheckd 驱动，它不依赖 logcollector。即使
-
/etc/）会触发递归扫描异常，应写为/etc - Linux 下未启用
who-data模式时，无法记录修改进程名和用户，且对 inotify 句柄数有硬限制（默认 8192），大目录需调高/proc/sys/fs/inotify/max_user_watches - Windows 下若目标路径在重定向文件夹（如 OneDrive 同步目录），FIM 可能因权限或句柄不可见而静默跳过
- 首次运行后，基线数据库生成需等待一个完整
主动响应（Active Response）：规则匹配后命令不执行的关键检查点
主动响应不是“检测即阻断”，它依赖三要素同时满足：rule 触发、active-response 配置启用、agent 端具备执行权限。最容易忽略的是 agent 侧限制：
- Linux agent 默认禁用 shell 命令执行，需在 agent 的
ossec.conf中设yes - Windows agent 执行 PowerShell 脚本需提前在 GPO 或本地策略中设置
ExecutionPolicy RemoteSigned或更低限制 - 响应命令超时默认 5 秒，封禁 IP 类操作（如调用
iptables或netsh）若耗时略长会被强制终止，建议加timeout="10"属性 - manager 端定义的
联动验证：如何确认日志→FIM→响应整条链路跑通
不要等真实攻击发生才测试。最简验证路径是：手动改一个被监控文件 → 查看 agent 日志 → 确认 manager 是否收到 FIM 事件 → 检查是否触发预设 rule → 观察 active-response 命令是否出现在 agent 的 ossec.log 中。
关键日志位置：
- agent 侧：查看
/var/ossec/logs/ossec.log（Linux）或C:\Program Files (x86)\ossec-agent\ossec.log（Windows），搜索syscheck或active-response - manager 侧：用
wazuh-control status确保ossec-analysisd和ossec-execd均在运行；用tail -f /var/ossec/logs/alerts/alerts.json实时观察结构化输出 - 规则调试：临时把目标 rule 的
真正难的不是配置语法，而是每个模块都运行着但彼此“听不见”——比如 syscheckd 发出的事件没被 analysisd 的规则覆盖，或者 analysisd 匹配成功了，execd 却因权限被 agent 拒绝执行。盯住日志里那几行 timestamp + module + action，比反复改配置有用得多。
