Wazuh 4.14.9 配置参数详解
逐段讲清 Wazuh 4.14.9 manager ossec.conf 的 global/remote/syscheck/syscollector/vulnerability-detection/indexer/ruleset/auth/cluster 参数与 agent 侧配置,含自定义规则、解码器、logall 归档、syslog 接收的实测验证与 ID 冲突等排障实录。
Wazuh 4.14.9 配置参数详解
目标:逐段讲清 Wazuh 4.14.9 manager 主配置
ossec.conf(/var/ossec/etc/ossec.conf)的核心参数与 agent 侧配置、ruleset/decoder 规则体系,每类参数配修改方法与实测验证。全文在 Ubuntu 22.04 实测环境(Wazuh 4.14.9 manager + Ubuntu 22.04 agent)逐项验证,配置块均来自实测环境中的真实文件。
一、环境信息
本文实测环境:
- 操作系统:Ubuntu 22.04 LTS(x86_64,内核 6.8)
- Wazuh 版本:4.14.9(manager v4.14.9、agent 4.14.9-1,
wazuh-control info -v实测输出v4.14.9) - manager 主配置:
/var/ossec/etc/ossec.conf(Docker Compose 部署时由宿主侧wazuh_manager.conf挂载生成,部署方式见 《Wazuh 4.14.9 Docker Compose 部署指南》) - agent 主配置:
/var/ossec/etc/ossec.conf(apt 安装 wazuh-agent 4.14.9-1 自带默认值) - manager 进程版本信息(
/var/ossec/bin/wazuh-control info -v与info -r实测):
v4.14.9
---
rc2
(-v 输出版本号,-r 输出 revision 号 rc2。)
二、前置条件
- 已按部署篇完成 manager 运行(
/var/ossec/bin/wazuh-control status核心守护进程 running)。 - 能编辑 manager 主配置文件。容器/Compose 部署与裸机/系统包部署的文件物理位置相同(
/var/ossec/etc/ossec.conf),差别只在修改后的生效方式(见第三章)。 - 掌握
wazuh-logtest的基本用法(第四章实测反复用到):把一行日志喂给正在运行的 analysisd,实时回显解码与规则匹配结果,是验证配置/规则改动的标准工具。
三、参数查看与修改方式
3.1 配置文件位置
| 角色 | 文件 | 说明 |
|---|---|---|
| manager 主配置 | /var/ossec/etc/ossec.conf | 全部 manager 参数(本篇主角) |
| manager 自定义规则 | /var/ossec/etc/rules/local_rules.xml | 用户规则默认文件(可直接追加) |
| manager 自定义解码器 | /var/ossec/etc/decoders/local_decoder.xml | 用户解码器默认文件 |
| CDB 列表 | /var/ossec/etc/lists/ | 键值_lookup 列表(CDB 编译格式) |
| agent 主配置 | /var/ossec/etc/ossec.conf(agent 上) | agent 侧采集与连接参数 |
| 运行时内部参数 | /var/ossec/etc/internal_options.conf | 低层调优项(毫秒/缓冲区级) |
3.2 修改与生效流程(实测结论)
Docker Compose 部署时,宿主侧 wazuh_manager.conf 挂载为容器内 /wazuh-config-mount/etc/ossec.conf,容器初始化脚本在启动时拷贝为 /var/ossec/etc/ossec.conf(启动日志实测可见):
Identified Wazuh configuration files to mount...
'/wazuh-config-mount/etc/ossec.conf' -> '/var/ossec/etc/ossec.conf'
因此正确的修改流程是(每步均实测):
# 1. 编辑宿主侧配置(Compose 部署)或直接编辑 /var/ossec/etc/ossec.conf(系统包部署)
vim config/wazuh_cluster/wazuh_manager.conf
# 2. 重建 manager 使挂载文件重新拷贝生效
docker compose up -d --force-recreate wazuh.manager
# 3. 验证新配置已加载(以追加 syslog 接收段为例)
docker compose exec wazuh.manager grep -c "<connection>syslog" /var/ossec/etc/ossec.conf
实测回显(第 3 步,返回计数 1 即已加载):
1
同时 manager 主日志 /var/ossec/logs/ossec.log 出现监听行:
2026/10/20 03:17:48 wazuh-remoted: INFO: Remote syslog allowed from: '10.89.60.0/24'
2026/10/20 03:17:48 wazuh-remoted: INFO: Started (pid: 704). Listening on port 514/UDP (syslog).
⚠️ 不要用
docker compose restart wazuh.manager加载新配置。实测 restart 触发容器重新初始化时,初始化脚本可能在 multigroups 卷拷贝一步报错提前退出(Error executing command: 'cp -ar .../var/multigroups/...',exited 1),后续的配置拷贝步骤被跳过,新配置不生效。系统包部署则直接/var/ossec/bin/wazuh-control restart即可。
3.3 语法自检与在线验证
- XML 语法错误时 manager 启动日志会直接报出文件与行号,修正后重启即可;
- 规则/解码器的逻辑验证用
wazuh-logtest(在线、不改运行态),样例见 5.9; - 规则 ID 冲突等问题在重启后立即写进
/var/ossec/logs/ossec.log(实测样例见 5.9 的排障实录)。
四、参数总览
ossec.conf 由多个 <ossec_config> 段组成(可有多段,合并生效),每个段内按功能块组织。实测环境 manager 配置的功能块清单:
| 功能块 | 作用 | 关键参数(本文详解小节) |
|---|---|---|
<global> | 全局输出开关、邮件、agent 掉线判定 | jsonout_output、alerts_log、logall、email_notification、agents_disconnection_time(5.1) |
<alerts> | 告警输出阈值 | log_alert_level、email_alert_level(5.1) |
<logging> | manager 自身日志格式 | log_format(5.1) |
<remote> | 事件接收监听 | connection、port、protocol、queue_size、allowed-ips(5.2) |
<rootcheck> | Rootkit 检测 | disabled、check_*、frequency(5.4) |
<wodle name="syscollector"> | 资产清点 | interval、hardware/os/network/packages/ports/processes(5.5) |
<sca> | 安全配置评估 | enabled、interval、scan_on_start(5.5) |
<vulnerability-detection> | 漏洞检测 | enabled、index-status、feed-update-interval(5.6) |
<indexer> | 告警输出到 indexer | enabled、hosts、ssl(5.7) |
<syscheck> | 文件完整性监控(FIM) | directories、ignore、nodiff、frequency、max_eps(5.3) |
<command> + <active-response> | 主动响应 | name、executable、timeout_allowed(5.8) |
<localfile> | 日志采集 | log_format、location/command、frequency(5.9) |
<ruleset> | 规则/解码器/列表装载 | decoder_dir、rule_dir、rule_exclude、list(5.10) |
<rule_test> | wazuh-logtest 服务 | enabled、threads、max_sessions、session_timeout(5.10) |
<auth> | agent 注册服务 | port、use_password、purge、ssl_*(5.11) |
<cluster> | manager 集群 | name、node_name、node_type、key、disabled(5.12) |
<wodle name="cis-cat">、<wodle name="osquery"> | 可选集成 | 默认 disabled=yes(5.5 末) |
💡 说明:同一段出现两个
<global>是官方模板的合法写法(第二处放 white_list 供主动响应使用),Wazuh 合并所有同名段。
五、核心参数分类详解
5.1 全局输出与告警阈值(global / alerts / logging)
这一组参数决定「什么进日志、什么成为告警」。实测环境默认配置:
<global>
<jsonout_output>yes</jsonout_output>
<alerts_log>yes</alerts_log>
<logall>no</logall>
<logall_json>no</logall_json>
<email_notification>no</email_notification>
<smtp_server>smtp.example.wazuh.com</smtp_server>
<email_from>wazuh@example.wazuh.com</email_from>
<email_to>recipient@example.wazuh.com</email_to>
<email_maxperhour>12</email_maxperhour>
<email_log_source>alerts.log</email_log_source>
<agents_disconnection_time>10m</agents_disconnection_time>
<agents_disconnection_alert_time>0</agents_disconnection_alert_time>
</global>
<alerts>
<log_alert_level>3</log_alert_level>
<email_alert_level>12</email_alert_level>
</alerts>
逐项说明:
| 参数 | 默认 | 含义与影响 |
|---|---|---|
| jsonout_output | yes | 写 /var/ossec/logs/alerts/alerts.json(dashboard/API 消费的主数据源) |
| alerts_log | yes | 写纯文本 /var/ossec/logs/alerts/alerts.log(grep 友好) |
| logall / logall_json | no | 归档全部接收事件(含未成告警的)到 /var/ossec/logs/archives/;排查「这条日志 manager 到底收没收到」时的利器,磁盘占用大,生产按需短开 |
| email_notification | no | 邮件告警总开关(yes 时 wazuh-maild 进程才运行,实测 wazuh-control status 可见该进程从 not running 翻转) |
| email_maxperhour | 12 | 每小时邮件上限,防轰炸 |
| agents_disconnection_time | 10m | agent 超过该时长无 keepalive 判为 disconnected |
| agents_disconnection_alert_time | 0 | agent 掉线多久后发告警,0=不告警 |
| log_alert_level | 3 | 规则 level ≥ 3 才写告警文件(1-2 级仅统计) |
| email_alert_level | 12 | level ≥ 12 才触发邮件 |
| log_format(logging 段) | plain | manager 自身日志格式,可 plain/json/plain,json |
logall 实测:把 logall、logall_json 改为 yes 并重建 manager 后,/var/ossec/logs/archives/ 目录出现 archives.json 与 archives.log,全量事件(包括未触发规则的后台事件)开始归档,实测样例行:
2026 Oct 20 03:30:20 (wazuh-agent-host) any->journald Oct 20 03:30:19 wazuh-agent-host kernel: workqueue: e1000_watchdog [e1000] hogged CPU for >10000us 16 times, consider switching to WQ_UNBOUND
2026 Oct 20 03:28:44 wazuh->rootcheck Ending rootcheck scan.
(第一行来自 agent 的 journald 采集,第二行是 manager 自身 rootcheck 扫描结束事件——这类事件默认不写 alerts.json,开 logall 后全部落盘。)
archives 时效排障实录:新增 localfile 目标(如 /var/log/myapp.log)时,若文件在 logcollector 启动后才创建,日志会先报 wazuh-logcollector: ERROR: (1103): Could not open file '/var/log/myapp.log' due to [(2)-(No such file or directory)].,随后进入 INFO: (1950): Analyzing file: 的轮询状态;实测等待数分钟仍可能不采集。可靠做法是保证文件在 manager 启动前已存在,或修改配置后重启 manager 让 logcollector 以「文件在位」状态启动(实测启动后即 Analyzing file: '/var/log/myapp.log',不再报 1103)。
5.2 事件接收监听(remote)
<remote> 段定义 manager 的接收通道,可配多个。实测默认只开 agent 加密通道:
<remote>
<connection>secure</connection>
<port>1514</port>
<protocol>tcp</protocol>
<queue_size>131072</queue_size>
</remote>
| 参数 | 取值 | 说明 |
|---|---|---|
| connection | secure / syslog | secure=agent 加密通道(必须 1514 配 agent);syslog=接收原始 syslog(网络设备/应用直发) |
| port | 1514(secure)/ 514(syslog 惯例) | 监听端口 |
| protocol | tcp / udp(可逗号并列) | 传输协议 |
| queue_size | 131072 | 接收队列长度(仅 tcp secure),高峰防丢包 |
| allowed-ips | 网段/正则 | syslog 连接必配,白名单源;不配则拒绝一切来源 |
syslog 接收实测:追加一段 syslog remote 并重建 manager:
<ossec_config>
<remote>
<connection>syslog</connection>
<port>514</port>
<protocol>udp</protocol>
<allowed-ips>10.89.60.0/24</allowed-ips>
</remote>
</ossec_config>
重建后 ossec.log 实测出现双监听:
2026/10/20 03:17:48 wazuh-remoted: INFO: Remote syslog allowed from: '10.89.60.0/24'
2026/10/20 03:17:48 wazuh-remoted: INFO: Started (pid: 704). Listening on port 514/UDP (syslog).
2026/10/20 03:17:48 wazuh-remoted: INFO: Started (pid: 703). Listening on port 1514/TCP (secure).
从同网段主机发送一条 syslog 测试事件(Python socket 直发,带 syslog PRI 头):
python3 -c "
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
msg = '<34>Oct 20 11:45:01 wazuh-agent-host sshd[20001]: Failed password for admin from 10.0.0.77 port 60001 ssh2'
s.sendto(msg.encode(), ('<manager地址>', 514))
print('sent')
"
实测回显:
sent
约 5 秒后 manager 告警文件中出现该事件(照抄实测 JSON 关键字段):
rule: 100002 level: 10 | Custom: SSH authentication failure detected for user. | location: 10.89.60.5
两个实测细节:其一,syslog 直发事件的 location 是源 IP(而非 agent 名),这是 syslog 通道与 agent 通道在告警里的显著区别;其二,用系统 logger -n <manager> -P 514 -t sshd "..." 直发同内容实测不产生告警(其封装的 PRI/格式与解码器期望不一致),排障时优先用上面的 socket 直发或走 agent 通道。
5.3 文件完整性监控(syscheck)
实测默认配置(保留注释要点):
<syscheck>
<disabled>no</disabled>
<frequency>43200</frequency>
<scan_on_start>yes</scan_on_start>
<alert_new_files>yes</alert_new_files>
<auto_ignore frequency="10" timeframe="3600">no</auto_ignore>
<directories>/etc,/usr/bin,/usr/sbin</directories>
<directories>/bin,/sbin,/boot</directories>
<ignore>/etc/mtab</ignore>
<ignore type="sregex">.log$|.swp$</ignore>
<nodiff>/etc/ssl/private.key</nodiff>
<skip_nfs>yes</skip_nfs>
<skip_dev>yes</skip_dev>
<skip_proc>yes</skip_proc>
<skip_sys>yes</skip_sys>
<process_priority>10</process_priority>
<max_eps>100</max_eps>
<synchronization>
<enabled>yes</enabled>
<interval>5m</interval>
<max_interval>1h</max_interval>
<max_eps>10</max_eps>
</synchronization>
</syscheck>
逐项说明:
| 参数 | 默认 | 说明 |
|---|---|---|
| disabled | no | FIM 总开关 |
| frequency | 43200 | 全量扫描周期(秒),默认 12h |
| scan_on_start | yes | manager/agent 启动即扫一轮 |
| alert_new_files | yes | 新出现文件产生告警 |
| auto_ignore | no | 同一文件短时间反复变化时是否自动忽略(防告警风暴) |
| directories | /etc 等 | 监控目录清单;可附加属性 check_all="yes" realtime="yes"(实时 inotify 监控)、report_changes="yes"(附 diff) |
| ignore | — | 忽略清单,type="sregex" 表示 OS_Regex 正则(默认忽略 .log/.swp) |
| nodiff | — | 不做 diff 的文件(如私钥),只告警变化不泄露内容 |
| skip_nfs/dev/proc/sys | yes | 跳过特殊文件系统/目录 |
| max_eps | 100 | 每秒最大事件上报条数(削峰) |
| synchronization | 5m/1h/10 | agent 与 manager 的 FIM 数据库同步节奏与限速 |
验证手段:agent 侧 agent_control -i <id> 实测输出包含 syscheck 最近扫描时间——
Syscheck last started at: Tue Oct 20 03:08:22 2026
Syscheck last ended at: Tue Oct 20 03:08:23 2026
💡 技术拓展:
directories的监控触发方式有三种可选——周期全量(frequency,资源消耗最低但时效差)、realtime(inotify 实时,仅 Linux/macOS,目录级)、whodata(auditd 实时+审计元数据,最精细但依赖 audit 服务)。默认模板用周期全量;生产对/etc等关键目录建议加realtime="yes"。本文实测环境保持官方默认(周期 12h + 启动即扫)。
5.4 Rootkit 检测(rootcheck)
实测默认配置:
<rootcheck>
<disabled>no</disabled>
<check_files>yes</check_files>
<check_trojans>yes</check_trojans>
<check_dev>yes</check_dev>
<check_sys>yes</check_sys>
<check_pids>yes</check_pids>
<check_ports>yes</check_ports>
<check_if>yes</check_if>
<frequency>43200</frequency>
<rootkit_files>etc/rootcheck/rootkit_files.txt</rootkit_files>
<rootkit_trojans>etc/rootcheck/rootkit_trojans.txt</rootkit_trojans>
<skip_nfs>yes</skip_nfs>
</rootcheck>
要点:check_* 七个开关对应隐藏文件、特洛伊木马签名、异常 /dev、系统文件异常属性、隐藏进程、隐藏端口、异常网卡混杂模式;frequency 与 syscheck 一样默认 12h;签名库位于 etc/rootcheck/。实测 rootcheck 扫描结束事件(开 logall 后可见):Ending rootcheck scan.。
5.5 资产清点与配置评估(syscollector / sca)
实测默认配置:
<wodle name="syscollector">
<disabled>no</disabled>
<interval>1h</interval>
<scan_on_start>yes</scan_on_start>
<hardware>yes</hardware>
<os>yes</os>
<network>yes</network>
<packages>yes</packages>
<ports all="yes">yes</ports>
<processes>yes</processes>
<synchronization>
<max_eps>10</max_eps>
</synchronization>
</wodle>
<sca>
<enabled>yes</enabled>
<scan_on_start>yes</scan_on_start>
<interval>12h</interval>
<skip_nfs>yes</skip_nfs>
</sca>
| 参数 | 默认 | 说明 |
|---|---|---|
| syscollector.interval | 1h | 资产清点周期(硬件/OS/网络/软件包/端口/进程六维开关各自 yes/no) |
| ports all="yes" | — | 是否同时收录监听外的全部连接(all=yes 时含 established) |
| sca.interval | 12h | SCA 基线扫描周期,scan_on_start 启动即扫 |
SCA 实测取证(manager API GET /sca/001,Ubuntu 22.04 agent 首扫结果):
"name": "CIS Ubuntu Linux 22.04 LTS Benchmark v2.0.0.",
"pass": 78, "fail": 80, "invalid": 49, "total_checks": 207, "score": 49
(CIS 基线 207 项检查,实过 78 项。)
可选集成 cis-cat、osquery 两个 wodle 默认 disabled=yes,启用需分别安装 CIS-CAT Pro 与 osquery,不启用可保持默认。
5.6 漏洞检测(vulnerability-detection)
实测默认配置:
<vulnerability-detection>
<enabled>yes</enabled>
<index-status>yes</index-status>
<feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>
enabled 打开漏洞检测引擎;index-status 把每个 agent 的漏洞清单索引进 indexer(dashboard 的 Vulnerability Detection 模块数据源);feed-update-interval 为 CVE 内容包更新周期(60 分钟拉一次)。实测 ossec.log 中引擎启动行:
2026/10/20 03:04:40 wazuh-modulesd:vulnerability-scanner: INFO: Vulnerability scanner module started.
5.7 告警输出到 indexer(indexer)
实测默认配置:
<indexer>
<enabled>yes</enabled>
<hosts>
<host>https://wazuh.indexer:9200</host>
</hosts>
<ssl>
<certificate_authorities>
<ca>/etc/ssl/root-ca.pem</ca>
</certificate_authorities>
<certificate>/etc/ssl/filebeat.pem</certificate>
<key>/etc/ssl/filebeat.key</key>
</ssl>
</indexer>
该段驱动 manager 内置 Filebeat 把 alerts.json 转发到 indexer。hosts 可列多个 indexer 做负载;证书三元组(CA/客户端证书/私钥)必须与生成的一致。Compose 部署时这三项与 compose 环境变量(INDEXER_URL/INDEXER_USERNAME 等)共同生效,改密码时两处要同步。
5.8 主动响应(command / active-response)
实测默认已定义 7 个响应命令(disable-account、restart-wazuh、firewall-drop、host-deny、route-null 及两个 Windows 版),每个形态如下:
<command>
<name>firewall-drop</name>
<executable>firewall-drop</executable>
<timeout_allowed>yes</timeout_allowed>
</command>
| 参数 | 说明 |
|---|---|
| name | 响应名(规则里 <active_response> 引用) |
| executable | /var/ossec/active-response/bin/ 下的脚本名 |
| timeout_allowed | 是否支持超时自动解除(如封禁 N 秒后解封) |
默认模板的 <active-response> 段整体被注释(不主动触发任何响应)。启用示例:对特定规则触发 firewall-drop 封禁 10 分钟:
<active-response>
<command>firewall-drop</command>
<location>local</location>
<rules_id>5760</rules_id>
<timeout>600</timeout>
</active-response>
配合的白名单在第二个 <global> 段:
<global>
<white_list>127.0.0.1</white_list>
<white_list>^localhost.localdomain$</white_list>
</global>
(白名单地址永不触发封禁类响应,生产务必先补齐内网网段。)
5.9 日志采集(localfile)
manager 与 agent 共用 <localfile> 语法。实测默认模板在 manager 上配了三条命令型采集:
<localfile>
<log_format>command</log_format>
<command>df -P</command>
<frequency>360</frequency>
</localfile>
<localfile>
<log_format>full_command</log_format>
<command>netstat -tulpn | sed ... | sort -k 4 -g | ...</command>
<alias>netstat listening ports</alias>
<frequency>360</frequency>
</localfile>
<localfile>
<log_format>full_command</log_format>
<command>last -n 20</command>
<frequency>360</frequency>
</localfile>
| log_format | 用途 | 说明 |
|---|---|---|
| syslog | 常规文本日志文件 | location=文件路径,逐行读取(如 /var/log/auth.log) |
| command / full_command | 周期执行命令取输出 | frequency 秒;full_command 会额外跑 timeout 包裹防卡死 |
| journald | systemd journal | location=journald,4.14 的 Linux agent 默认启用 |
| eventlog / eventchannel | Windows 事件日志 | 仅 Windows agent |
agent 侧实测:4.14.9 的 agent 默认 localfile(Ubuntu 22.04 实测 grep '<location>' /var/ossec/etc/ossec.conf):
<localfile>
<log_format>journald</log_format>
<location>journald</location>
</localfile>
<localfile>
<log_format>syslog</log_format>
<location>/var/ossec/logs/active-responses.log</location>
</localfile>
<localfile>
<log_format>syslog</log_format>
<location>/var/log/dpkg.log</location>
</localfile>
端到端采集实测(agent 追加 auth.log 监控):在 agent 的 /var/ossec/etc/ossec.conf 的 </ossec_config> 前追加:
<localfile>
<log_format>syslog</log_format>
<location>/var/log/auth.log</location>
</localfile>
重启 agent(systemctl restart wazuh-agent)后注入一条 sshd 失败事件:
echo "Oct 20 11:25:01 wazuh-agent-host sshd[12346]: Failed password for admin from 10.0.0.99 port 51235 ssh2" >> /var/log/auth.log
manager 侧 alerts.json 实测收到(关键 JSON 字段照抄):
"rule":{"level":5,"description":"sshd: authentication failed.","id":"5760",...}
"agent":{"id":"001","name":"wazuh-agent-host","ip":"10.89.60.5"}
"decoder":{"parent":"sshd","name":"sshd"}
"data":{"srcip":"10.0.0.99","srcport":"51235","dstuser":"admin"}
"location":"/var/log/auth.log"
5.10 规则体系(ruleset / rule_test)与自定义规则、解码器实测
内置规则库规模实测(manager 容器内):
ls /var/ossec/ruleset/rules/ | wc -l -> 168
ls /var/ossec/ruleset/decoders/ | wc -l -> 120
(168 个规则文件、120 个解码器文件;经 API GET /rules 与 GET /decoders 统计,展开后的规则 4514 条、解码器 1576 个。)
实测默认 ruleset 段:
<ruleset>
<decoder_dir>ruleset/decoders</decoder_dir>
<rule_dir>ruleset/rules</rule_dir>
<rule_exclude>0215-policy_rules.xml</rule_exclude>
<list>etc/lists/audit-keys</list>
<list>etc/lists/amazon/aws-eventnames</list>
<list>etc/lists/security-eventchannel</list>
<list>etc/lists/malicious-ioc/malicious-ip</list>
<list>etc/lists/malicious-ioc/malicious-domains</list>
<list>etc/lists/malicious-ioc/malware-hashes</list>
<decoder_dir>etc/decoders</decoder_dir>
<rule_dir>etc/rules</rule_dir>
</ruleset>
装载顺序:内置 ruleset/ 先载、用户 etc/ 后载,因此用户规则可覆盖内置。CDB 列表文件(如 etc/lists/ 下的 audit-keys)需编译成 .cdb 后由 <list> 引用,实测目录同时存在文本源与编译产物:
audit-keys audit-keys.cdb
security-eventchannel security-eventchannel.cdb
malicious-ioc/malicious-domains malicious-ioc/malicious-domains.cdb
<rule_test> 段是 wazuh-logtest 的服务端配置(默认 enabled、单线程、64 会话、15 分钟会话超时),保持默认即可。
自定义规则实测:向 /var/ossec/etc/rules/local_rules.xml 追加(对默认 sshd 失败规则 5760 升级为 level 10):
<group name="local,syslog,sshd">
<rule id="100002" level="10">
<if_sid>5760</if_sid>
<description>Custom: SSH authentication failure detected for user.</description>
</rule>
</group>
重启 manager 后用 wazuh-logtest 验证(输入同一行 sshd 日志),实测输出:
**Phase 3: Completed filtering (rules).
id: '100002'
level: '10'
description: 'Custom: SSH authentication failure detected for user.'
排障实录(规则 ID 冲突):首次实测把新规则命名为 ID 100001,而默认 local_rules.xml 里已有一个 100001 示例规则(sshd: authentication failed from IP 1.1.1.1),重启后 ossec.log 报实测告警:
2026/10/20 03:11:53 wazuh-analysisd: WARNING: (7612): Rule ID '100001' is duplicated. Only the first occurrence will be considered.
重复 ID 只保留先载入的那条,新规则静默失效——自定义规则一律从 100002 起编号(或先检查 local_rules.xml 已占用 ID)。
自定义解码器实测:向 /var/ossec/etc/decoders/local_decoder.xml 写入:
<decoder name="myapp-decoder">
<program_name>myapp</program_name>
</decoder>
<decoder name="myapp-status">
<parent>myapp-decoder</parent>
<regex>status=(\w+) user=(\w+)</regex>
<order>status, user</order>
</decoder>
重启 manager 后 logtest 喂入 Oct 20 12:10:01 web01 myapp[900]: status=ok user=alice,实测输出(节选):
program_name: 'myapp'
**Phase 2: Completed decoding.
name: 'myapp-decoder'
dstuser: 'alice'
status: 'ok'
(program_name 匹配父解码器、正则抽出 status/user 两个字段;dstuser 是 sshd 系预置字段的自动抽取。)
5.11 agent 注册服务(auth)
实测默认配置:
<auth>
<disabled>no</disabled>
<port>1515</port>
<use_source_ip>no</use_source_ip>
<purge>yes</purge>
<use_password>no</use_password>
<ciphers>HIGH:!ADH:!EXP:!MD5:!RC4:!3DES:!CAMELLIA:@STRENGTH</ciphers>
<ssl_verify_host>no</ssl_verify_host>
<ssl_manager_cert>etc/sslmanager.cert</ssl_manager_key>
<ssl_manager_key>etc/sslmanager.key</ssl_manager_key>
<ssl_auto_negotiate>no</ssl_auto_negotiate>
</auth>
| 参数 | 默认 | 说明 |
|---|---|---|
| port | 1515 | 注册监听端口 |
| use_source_ip | no | yes 时把 agent 来源 IP 写为其注册 IP(默认 any) |
| purge | yes | 同名 agent 重新注册时删除旧记录 |
| use_password | no | yes 时注册需携带密码(防未授权注册,生产建议开启) |
| ssl_manager_cert/key | 自签 | 注册通道 TLS 证书(首次启动自动生成,实测日志 Creating wazuh-authd key and cert) |
实测注册链路日志(agent 首次连接时 ossec.log):
2026/10/20 03:06:18 wazuh-authd: INFO: Received request for a new agent (wazuh-agent-host) from: 10.89.60.5
2026/10/20 03:06:18 wazuh-authd: INFO: Agent key generated for 'wazuh-agent-host' (requested by any)
5.12 manager 集群(cluster)
实测默认(单机)配置:
<cluster>
<name>wazuh</name>
<node_name>node01</node_name>
<node_type>master</node_type>
<key>aa093264ef885029653eea20dfcf51ae</key>
<port>1516</port>
<bind_addr>0.0.0.0</bind_addr>
<nodes>
<node>wazuh.manager</node>
</nodes>
<hidden>no</hidden>
<disabled>yes</disabled>
</cluster>
单机部署保持 disabled=yes,此时 wazuh-control status 实测显示 wazuh-clusterd not running...(正常现象,非故障)。扩集群时改 disabled=no,worker 节点 node_type=worker、nodes 指向 master 地址,key 全群一致(端口 1516/tcp 需放通)。实测验证集群关闭时执行 cluster_control -l 返回:
ERROR: Cluster is not running.
5.13 agent 侧连接参数
agent 的 /var/ossec/etc/ossec.conf 核心段(apt 安装时由 WAZUH_MANAGER 环境变量写入):
<ossec_config>
<client>
<server>
<address>wazuh.manager</address>
<port>1514</port>
<protocol>tcp</protocol>
</server>
<config-profile>ubuntu, ubuntu22, ubuntu22.04</config-profile>
<notify_time>10</notify_time>
<time-reconnect>60</time-reconnect>
<auto_restart>yes</auto_restart>
<crypto_method>aes</crypto_method>
</client>
</ossec_config>
| 参数 | 默认 | 说明 |
|---|---|---|
| server.address | 安装时写入 | manager 地址(IP/域名) |
| server.port / protocol | 1514 / tcp | 与 manager <remote> 段对应 |
| notify_time | 10 | keepalive 间隔(秒) |
| time-reconnect | 60 | 连接断开后的重连间隔(秒) |
| auto_restart | yes | 配置变更/异常时 agent 自启 |
| crypto_method | aes | 传输加密算法 |
💡 技术拓展:agent 掉线判定是两端参数的联动结果——manager 的
agents_disconnection_time(默认 10m)要求该值内收到 keepalive,agent 的notify_time(默认 10s)决定发送频率。若把 manager 阈值调到 1m,agent 默认 10s 的 keepalive 依然安全;把 agentnotify_time调大(如 300s)则必须同步放大 manager 阈值,否则会批量误报掉线。本文实测环境保持两端默认。
六、生产配置模板
适用场景:8-16 GB 内存、NVMe SSD、单 manager 承载 ≤ 500 agent 的中小规模安全监控。基于实测默认模板做五处增量修改(其余保持官方默认):
<ossec_config>
<global>
<jsonout_output>yes</jsonout_output>
<alerts_log>yes</alerts_log>
<logall>no</logall>
<logall_json>no</logall_json>
<email_notification>yes</email_notification>
<smtp_server>smtp.example.wazuh.com</smtp_server>
<email_from>wazuh@example.wazuh.com</email_from>
<email_to>soc@example.wazuh.com</email_to>
<email_maxperhour>60</email_maxperhour>
<email_log_source>alerts.log</email_log_source>
<agents_disconnection_time>10m</agents_disconnection_time>
<agents_disconnection_alert_time>0</agents_disconnection_alert_time>
</global>
<alerts>
<log_alert_level>3</log_alert_level>
<email_alert_level>10</email_alert_level>
</alerts>
<remote>
<connection>secure</connection>
<port>1514</port>
<protocol>tcp</protocol>
<queue_size>131072</queue_size>
</remote>
<syscheck>
<directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
<max_eps>200</max_eps>
</syscheck>
</ossec_config>
增量点说明:① 开启邮件告警并把阈值从 12 降到 10(level 10+ 多为真实攻击信号);② 生产关闭 logall(磁盘开销大,排障临时开);③ syscheck 关键目录加 realtime 实时监控、max_eps 提到 200(500 agent 峰值缓冲);④ auth 段建议追加 <use_password>yes</use_password> 防未授权注册;⑤ 定期核对 <ruleset> 里用户目录 etc/rules、etc/decoders 的文件均为合法 XML(一次解析失败会连带启动失败)。
七、常见问题
Q1:改了 ossec.conf 重启 manager 后行为没变?
按 3.2 节流程排查:Compose 部署确认改动写在宿主侧 wazuh_manager.conf(挂载源),并用 up -d --force-recreate 而非 restart(restart 时初始化脚本可能提前退出跳过配置拷贝,实测详见 3.2 与部署篇 FAQ Q2)。系统包部署确认编辑的是 /var/ossec/etc/ossec.conf 且 wazuh-control restart 返回 Completed。
Q2:自定义规则不生效?
三步定位:① grep duplicated /var/ossec/logs/ossec.log 看是否 ID 冲突(实测 7612 告警见 5.10);② 规则文件是否被 <ruleset> 的用户目录装载(默认 local_rules.xml 已在装载清单);③ 用 wazuh-logtest 喂真实日志看 Phase 3 命中的实际规则 ID——logtest 未重启前连的是旧规则集,改完必须重启 manager。
Q3:wazuh-logtest 报无法连接?
确认 <rule_test> 段 enabled=yes 且 analysisd 进程 running;logtest 会话由 analysisd 的 wazuh-db socket 承载,manager 刚重启后需等 analysisd 完全起来(数秒)。
Q4:syslog 设备发来的日志收不到?
依次确认:<remote> 有 syslog 连接段且端口/协议正确(实测监听验证看 ossec.log 的 Listening on port 514/UDP (syslog) 行);allowed-ips 覆盖源地址;发方用标准 syslog 格式(logger 直发实测不触发解码,见 5.2 实测注记);事件命中 level ≥ 3 规则才写 alerts.json,可临时开 logall 用 archives.json 确认事件是否到达(见 5.1)。
Q5:agent 显示 Never connected / disconnected?
Never connected:注册成功但 1514 通道不通(查防火墙与 <remote> secure 段);disconnected:keepalive 超过 agents_disconnection_time,核对 agent 侧 notify_time 与 manager 阈值的联动关系(见 5.13 技术拓展)。
Q6:Sca/漏洞检测无数据?
SCA 首扫发生在 agent 启动后(scan_on_start),稍等片刻后用 GET /sca/<agent_id> 核对(实测样例见 5.5);漏洞检测依赖 CVE 内容包首次下载(feed-update-interval 默认 60m),刚启动的 manager 索引里可能尚无漏洞数据。
八、参考链接
- ossec.conf 官方手册:https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/index.html
- 规则语法与 ruleset 手册:https://documentation.wazuh.com/current/user-manual/ruleset/index.html
- 自定义规则/解码器入门:https://documentation.wazuh.com/current/user-manual/ruleset/custom.html
- CDB 列表:https://documentation.wazuh.com/current/user-manual/ruleset/cdb-list.html
- FIM 用法:https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/index.html
- 漏洞检测:https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/index.html
- 本平台部署篇:《Wazuh 4.14.9 Docker Compose 部署指南》
- 本平台认知篇:《Wazuh 4.14.9 介绍与选型指南》