Wazuh安全监控实验指南：从部署到攻击检测与规则调优

Wazuh 是我一直想在实验室里完整跑一遍的东西，这次总算抽出时间，从一台空白的 Ubuntu 服务器开始，把整套环境搭了起来：部署 Manager、接入 Agent、模拟攻击触发告警、再调规则、排故障，整个过程走下来收获很大。

简单说，Wazuh 是一套开源的主机安全监控平台，核心价值在于统一收集主机日志、做威胁检测、文件完整性监控、漏洞和合规检查。很多安全团队拿它当 SIEM 来用，替代一部分商业产品。但我一直认为，工具装上去不等于就能用，如果不对规则、日志、告警之间的联系有体感，生产环境一上线就会被海量告警淹没。

这篇文章就是一次完整的 Wazuh 检测实验室实操记录，内容包括环境规划、组件部署、Agent 接入、攻击模拟验证、告警解读、规则调优和排错实录。适合安全运维、蓝队成员、刚接触 Wazuh 的分析人员参考。如果你是第一次搭，跟着走一遍基本能跑通“攻击发生到告警触发”的完整链路。

1. 实验定位与环境规划

1.1 为什么一定要先在实验室里跑通检测链路

很多人上来就在生产环境装 Wazuh，装完发现要么收不到日志，要么告警多到没人看，最后草草卸载。问题不在 Wazuh 本身，而是缺少一个对“检测链路”的整体认知。

一套完整的主机安全检测链路应该是这样的：主机产生日志，Agent 采集并转发，Server 接收后解析和匹配规则，匹配结果写入 Indexer，最后由 Dashboard 展示。任何一环断了，安全能力就是零。这个链路在实验室里如果不亲手验证一遍，上线后出了问题根本不知道从哪查起。

所以这个实验的核心目标很明确：搭一个隔离环境，用真实的攻击动作把每一条告警“打”出来，再亲手调优规则和存储策略。这个过程远比读文档有价值。

1.2 组件逻辑与版本选型

Wazuh 4.x 的架构主要由四个部分组成，理解这几个角色的关系能避免很多部署上的迷惑：

• Wazuh Indexer：基于 OpenSearch 的分布式检索集群，负责存储和检索告警与归档日志，相当于整个平台的“数据库+检索引擎”。
• Wazuh Server：核心分析引擎，包含 Manager 和 API。所有 Agent 的数据到这里解析、关联、匹配规则，也负责下发策略。
• Wazuh Dashboard：可视化界面，就是用户日常操作的那块面板，查告警、管理 Agent、看仪表盘都在这。
• Wazuh Agent：部署在被监控主机上的轻量客户端，采集日志、配置信息、文件变更并回传 Server。

我在实验里选择 All-in-One 单机部署，也就是把 Indexer、Server、Dashboard 装在同一台机器上。这样做的好处是省资源、部署快、跑通逻辑足够了；坏处是性能上不做隔离，生产环境不建议这样干。生产至少要把 Indexer 单独拆出去，甚至三节点起步，这些后面有机会再单独写。

版本方面，我使用的是当前 4.7.x 稳定版。实验环境建议直接用官方最新稳定版，没必要追新，也不要贪旧版稳定就刻意降级，因为 Wazuh 的规则和组件耦合度比较高，新版本对规则语法和 dashboard 功能都有改进。

操作系统选的 Ubuntu 22.04 LTS，原因只有一个：官方支持好、坑少。Agent 则刻意准备了三类环境：Ubuntu、CentOS、Windows，把三种主流的安装方式都过一遍。

1.3 实验网络与主机角色分配

实验室我用的是 VMware 的 Host-Only 网络，网段是 192.168.56.0/24。Host-Only 的好处是宿主机能和虚拟机互通，虚拟机不暴露到外部网络，做爆破、扫描这类模拟攻击时安全边界是可控的。

主机规划大致是这样：

有一个细节提个醒：所有实验主机务必开启时间同步，用 chrony 或 ntp 都行。因为告警时间基于主机日志的时间戳，如果 Agent 和 Server 时间差太多，会出现攻击发生在 10:00，告警却显示 12:00，索引检索完全对不上，排查起来极其痛苦。

2. 核心组件部署与 Agent 接入

2.1 Wazuh Server 安装实操

部署 Wazuh 官方提供了一键安装脚本，它会把 Indexer、Server、Dashboard 全部装好，并且自动生成证书和随机密码。对实验环境来说这是最高效的方式。

安装过程是这样的：

curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh sudo bash wazuh-install.sh --generate-config-files

执行后脚本会检查依赖、生成配置文件，然后开始安装各组件。注意这一步不能用 root 直接跑，会提示你用有 sudo 权限的普通用户执行。全程大概 10 到 15 分钟，取决于网络和机器性能。

安装完成后，脚本会在最后输出一段摘要，包含 Dashboard 的访问地址和管理员密码，同时把信息写入/root/wazuh-install-files/wazuh-passwords.txt。一定要保存好这个文件，后面重新登录、调用 API 都靠它。

访问 Dashboard 是走 HTTPS，地址是https://192.168.56.10，浏览器会提示证书不受信任，因为装的是自签名证书，实验环境点“继续访问”即可。

2.2 验证 Dashboard 与 Indexer 状态

安装完成不要急着接 Agent，先把平台本身的健康状态确认一遍。登录 Dashboard 后，左侧菜单的“Wazuh”主界面会展示 Manager 和 Indexer 的状态卡片，两个都必须显示绿色健康。

Indexer 的健康状态也可以在命令行直接验证。Wazuh Indexer 的接口默认在 9200 端口，但因为启用了认证和 TLS，直接用 curl 访问需要带证书和用户名密码：

curl -k -u admin:<密码> https://localhost:9200/_cluster/health

正常响应里会看到"status" : "green"和"number_of_nodes" : 1。如果这里不是 green，Dashboard 上经常表现为“数据加载不出来”或者“Indexer 状态异常”。

我实际操作中遇到过一次 Dashboard 能打开但没有任何数据的问题，查下来是因为 Filebeat 推送索引模板失败。重启 filebeat 后恢复正常：

sudo systemctl restart filebeat

检查 Filebeat 是否正常，看日志路径/var/log/filebeat/filebeat，这个不显眼但很关键。

2.3 Agent 部署与注册

在 Dashboard 的 Agents 页面点击“Deploy new agent”，可以生成对应的安装命令，它会根据你选择的操作系统给出完整的安装步骤。

以 Ubuntu Agent 为例，界面生成的命令大致是：

curl -s https://packages.wazuh.com/4.x/wazuh-agent.deb -o wazuh-agent.deb sudo WAZUH_MANAGER='192.168.56.10' dpkg -i wazuh-agent.deb sudo systemctl daemon-reload sudo systemctl enable --now wazuh-agent

需要注意环境变量WAZUH_MANAGER，这是 Agent 连接 Server 的地址。如果机器不是通过 DHCP 获取 IP，建议直接写 Server 的内网 IP，别写域名，避免 DNS 解析出现问题导致的注册失败。

CentOS 的安装思路完全一样，只是包格式变成了 rpm，端口和注册流程没有任何区别。Windows Agent 则是一个安装 exe，安装时可以指定 Manager 地址，也可以装完在C:\Program Files (x86)\ossec-agent\ossec.conf里改address字段，再重启服务。

安装完成后，Agent 会向 Server 发起注册请求，Server 端默认监听 TCP 1515 端口处理注册。注册成功后 Dashboard 的 Agents 页面里，这台机器的状态会从 Disconnected 变为 Active。

我经常看到有人问“为什么 Agent 显示了 Active 但没数据”，其实 Active 只代表心跳正常，等于 Agent 还活着；不代表日志已经被正确采集。验证部署是否真正成功，要看 Server 端日志：

sudo tail -f /var/ossec/logs/ossec.log

能看到类似Agent key generated和Adding agent的记录，说明注册链路没问题。

这里把常用的端口整理一下，方便排查安全组或防火墙策略时对照：

实验环境建议把防火墙先关闭或放行这些端口，免得排查半天问题出在防火墙。

2.4 日志源扩展：接入通用 Syslog

实验室里如果只有 Wazuh Agent 作为日志源，能演示的场景还是有限。实际企业环境中有大量设备不支持安装 Agent，比如交换机、防火墙、路由器，这时就要靠 Syslog 把日志送过来。

我在实验里加了一个简单的 Syslog 源，用于模拟这类场景。需要在 Server 端的/var/ossec/etc/ossec.conf中确认 remote 配置开启：

<remote> <connection>syslog</connection> <port>1514</port> <protocol>udp</protocol> </remote>

默认配置下这一项通常是有的，关键是<connection>syslog</connection>这个设置代表允许接收外部原始 Syslog。配置好之后，用任意一台机器发一条测试日志：

logger -n 192.168.56.10 -P 1514 -u "test syslog message from lab"

Server 端查看归档日志确认是否收到：

sudo tail -f /var/ossec/logs/archives/archives.log

如果能看到对应日志，说明 Syslog 接入链路没问题。后面如果要限制来源，可以在<remote>块里加<allowed-ips>字段，只允许指定网段发送，避免生产环境被垃圾日志塞满。

3. 攻击检测验证：从模拟到告警

3.1 SSH 暴力破解模拟与告警

这部分是整个实验室最有意思的地方。我部署完 Agent 后，第一件事就是拿一台实验 Agent 开 SSH，然后从 Kali 上用 Hydra 做暴力破解模拟。

命令大致是这个样子，只打 20 个密码，避免把实验主机锁掉：

hydra -l root -P /tmp/pass.txt ssh://192.168.56.21 -t 4 -f

爆破开始后几十秒，Dashboard 的 Security events 页面就会开始刷出告警。SSH 暴力破解最典型的是规则 ID 5710，标题大致是sshd: multiple authentication failures，它表示同一来源 IP 短时间内多次认证失败，level 通常在 10 以上，属于高等级告警。

我第一次跑通这个场景的时候，真正体会到了检测平台的价值：攻击行为从发生到规则匹配，再到 Dashboard 展示，整个过程不到一分钟，时间轴上可以清楚看到攻击源的每一个动作。

查看告警详情时，重点看几个字段：

• agent.name：哪台主机被攻击了。
• rule.id和rule.level：命中了什么规则，严重程度如何。
• data.srcip：攻击源 IP。
• location：日志最终来源路径，通常是/var/log/auth.log。
• timestamp：告警发生时间。

如果是真实攻击，这几个字段能快速还原事件轮廓。实验里我还会刻意把爆破的步长调快一点，就是为了让规则在高频失败后稳定触发，而不是偶尔一条两条。

注意：暴力破解模拟只适合在隔离实验网络里做，并且账号要提前做好保护，避免真实服务器被 lock 或者被爆破成功。

3.2 端口扫描与异常连接检测

第二类场景是端口扫描。渗透测试里信息收集阶段一定会做扫描，所以能否感知扫描行为是一个检测平台的基本功。

我从 Kali 上执行：

nmap -sS -p- 192.168.56.21

SYN 扫描的特点是速度快、连接数多，它在目标主机上留下的日志主要是防火墙的会话记录和应用层的连接日志。Wazuh 对扫描行为的检测不完全依赖默认规则，因为每个系统的日志格式差别太大。我的做法是先在告警列表里搜srcip，能看到同一来源在短时间内对目标的不同端口发起了大量连接。

如果希望有一个明确的“扫描行为”告警，最靠谱的手段是自定义规则。比如针对防火墙日志里SYN大量出现的模式写一条规则；或者针对 Windows 安全日志中的事件 ID 5152、5156 做频率统计。频率类的检测 Wazuh 也支持，可以用<rule>配合时间窗口统计实现，不过那部分放到后面的规则调优里细说。

实验中最常见的结果是：Wazuh 确实收到了大量连接日志，但默认规则并没有弹出高等级告警。这其实正常，Wazuh 更擅长检测“有明确攻击特征”的行为，比如爆破、Web 攻击、恶意软件特征，而不是泛泛的扫描。理解这一点，能避免你对工具产生不合理的预期。

3.3 Webshell 与文件完整性监控验证

文件完整性监控是 Wazuh 的一个核心模块，默认就会监控一批系统关键目录，像/etc、/usr/bin、/bin这些，对应配置在ossec.conf里的syscheck部分。

我做了一个与 Web 攻击结合的场景：在一台装了 Nginx 的 Agent 上，手动往 web 目录写了一个一句话木马，模拟攻击者上传了 webshell。写一句话木马的大家都知道那串字符，我这里就不贴具体代码了，避免被搜索引擎不加上下文地收录。

文件写入后几秒钟，Dashboard 立刻弹出告警。规则 ID 554 对应File added to the system，并在告警详情里直接给出新增文件的完整路径、文件权限、属主以及 SHA256 哈希。

这个场景最大的价值在于：你可以直观看到文件变更检测的“检测粒度”。哪怕是一个字节的修改，规则 550 也会触发。生产环境中一旦 FIM 误报太多，就可以通过配置nodiff、ignore和白名单把正常变更排除掉，这个后面会讲。

我建议每个团队在部署 FIM 后，都亲手做一次“写文件、改文件、删文件”的验证，确认 syscheck 确实在采集这个路径。因为很多人默认它是开着的，实际上可能只监控了系统目录，web 目录根本没覆盖到。

3.4 主动响应配置与验证

主动响应是 Wazuh 的自动化处置能力，意思是当某个高等级告警触发时，Server 或 Agent 可以直接执行一个动作，比如把来源 IP 加进防火墙黑名单。

我在实验里配置了一个 SSH 爆破自动封禁场景。首先在/var/ossec/etc/ossec.conf中加入命令和响应规则：

<command> <name>firewall-drop</name> <executable>firewall-drop.sh</executable> <timeout_allowed>yes</timeout_allowed> </command> <active-response> <disabled>no</disabled> <command>firewall-drop</command> <location>local</location> <rules_id>5710,5715</rules_id> <timeout>600</timeout> </active-response>

这里简单解释一下几个关键点：

• firewall-drop.sh是 Wazuh 自带的脚本，作用就是把来源 IP 加入 iptables DROP 规则。
• location填local表示告警在哪个 Agent 触发，就在哪个 Agent 上执行网络封禁。
• rules_id指定哪些规则触发主动响应。
• timeout是封禁时长，600 秒后自动解封，实验阶段别设永久封禁，否则测完攻击机就把自己锁在门外了。

配置完执行sudo systemctl restart wazuh-manager，再次用 Hydra 爆破，几轮之后去 Agent 上检查 iptables：

sudo iptables -L -n | grep 192.168.56.100

看到攻击机 IP 已经处于 DROP 状态，同时 Dashboard 上会显示 active response 的执行记录。

主动响应是双刃剑。我在测试中把 timeout 调成 600 秒都遇到过正常运维 IP 被误封的情况，因为监控规则没有考虑来源 IP 的“可信度”。生产环境建议先加白名单，或者在规则层面把数据库、备份服务器的 IP 排除掉，再启用主动响应。

4. 告警处理与规则调优

4.1 解读一条告警的标准姿势

在 Dashboard 里点开一条告警，很多人只瞄一眼 level 和标题就不管了，这其实浪费了告警里最值钱的上下文信息。我用一个例子来说明我平时看告警的固定顺序。

假设收到一条sshd: multiple authentication failures，level 10。我首先看rule.id，是 5710 还是 5712，这决定了规则匹配的是几次失败；接着看agent.name，确认是哪台主机中招；再看data.srcip和data.dstip，确认攻击流量走向；最后一定回看data.log字段，也就是最原始的日志内容，这一步强调的是“告警只是索引，原始日志才是真相”。

我自己的经验是：宁可花 5 秒钟看原始日志，也不要在告警列表里反复猜。Wazuh 的告警字段已经是结构化数据，但攻击者的行为动机很少能在结构化字段里完全体现。比如同样是 SSH 爆破，有些攻击是全网扫描，有些是对特定主机的针对性爆破，区分这一点要看原始日志里尝试的用户名列表和频率。

养成这个习惯之后，分析告警的速度会快很多。我还建议把常用字段加到 Dashboard 的表头显示里，不用每次都点开详情才能看到关键字段。

4.2 告警轰炸的治理思路

实验环境里数据量小，你可能会觉得“告警越多越有安全感”。真实生产环境完全不是这么回事，告警多到没人看等于没有告警。

实验跑了一周之后，我统计了一下告警量，发现大量 level 3 到 level 5 的低危告警，比如系统认证失败这类，占掉了 80% 的存储。治理方案是分两步走：

第一步，调整写入门槛。在ossec.conf的<alerts>字段里设置log_alert_level：

<alerts> <log_alert_level>3</log_alert_level> </alerts>

这个参数的意思是：只把 level 大于等于 3 的告警写入 alerts 索引。level 1 到 2 的信息仍然会进 archives，但不会占用告警分析的注意力。配合 Dashboard 里的过滤条件，可以快速把低价值告警排除在视线之外。

第二步，在规则层面对重复告警做降噪。比如某个规则一天触发了几千次，但来源都是同一台内部扫描器，就可以直接写一条本地规则，把对应来源的告警 level 降低。这个操作后面展开讲。

我还试过用 Wazuh 的<rule>时间窗口做频率告警，比如“同一来源一小时内失败次数超过 50 才报 level 10，否则只报 level 5”，效果不错，但需要匹配<if_sid>和<frequency>参数。这种策略在大规模环境中很有价值，能极大减少噪音。

4.3 自定义检测规则实操

自定义规则是 Wazuh 进阶使用必须掌握的能力，否则你只能依赖官方规则库，面对自己业务特有的攻击手法时几乎没有检测能力。

我实验里加了一条规则：检测有人通过 sudo 尝试读取/etc/shadow。这在真实攻击中意味着攻击者已经拿到了低权限 shell，正在尝试提取密码哈希。

在/var/ossec/etc/rules/local_rules.xml里添加：

<group name="local,"> <rule id="100010" level="10"> <decoded_as>syslog</decoded_as> <field name="program_name">sudo</field> <regex>cat\s+/etc/shadow</regex> <description>Detect attempt to read /etc/shadow via sudo</description> <group>local,pci_dss_10.6.1,</group> </rule> </group>

规则写完之后，先做语法校验：

sudo /var/ossec/bin/wazuh-logtest

wazuh-logtest是一个交互式测试工具，可以直接把一段日志贴进去，看能不能命中规则。这一步非常实用，写完规则马上就验证，不用真的去执行危险命令。

校验没问题后重启 Manager：

sudo systemctl restart wazuh-manager

验证方式很简单，在 Agent 上执行一次sudo cat /etc/shadow，几秒钟内就应该在 Dashboard 上看到规则 100010 的告警。

这里要强调一个容易踩的坑：官方规则的 ID 范围是 0 到 100000，自定义规则的 ID 必须从 100000 以后开始，否则会和官方规则冲突。曾经手滑把自定义规则写成了 10000，导致整个规则文件加载失败，Manager 直接没起来。添加自定义规则时，假如有多条，注意 ID 不能重复，每条规则要保证语法完整。

4.4 告警存储与索引生命周期

实验环境跑了一周，磁盘占用从 15G 涨到了 40G，这是正常现象，因为 Wazuh 会把告警和归档日志都写入 Indexer。如果不做索引生命周期管理，磁盘迟早被打满。

Indexer 底层是 OpenSearch，所以可以用现成的 Index State Management 策略。在 OpenSearch Dashboards 的 Index Management 里，新建一个策略，大致思路是：hot 阶段保留 7 天，warm 阶段保留 14 天，delete 阶段删除 30 天以前的数据。然后把这个策略应用到 Wazuh 相关的索引模板上。

如果你不想在界面上折腾，也可以用命令行方式直接调用 OpenSearch API，但实验阶段界面操作更直观，我也建议先看界面熟悉概念。

这里给一个经验值：如果每天日志量在 1G 左右，保留 30 天，磁盘至少预留 40G 到 60G。以前我部署时就是没算好磁盘，跑了两周索引攒了 60G，直接把节点干趴了。

5. 排查实录与避坑清单

5.1 现象：Agent 显示 Active 却收不到日志

这是我遇到次数最多的问题，现象是 Dashboard 上 Agent 状态是 Active，心跳正常，但 Security events 里就是搜不到这台主机的任何告警。

首先明确一点，Active 只代表 Agent 和 Server 的心跳通信正常。日志收不到，要从 Agent 侧开始查。第一步，在 Agent 机器上执行：

sudo /var/ossec/bin/wazuh-control status

正常应该输出wazuh-agent is running。如果服务没起来，大概率是配置文件写错了，尤其是ossec.conf中 Manager 地址那一段。

第二步，确认 Agent 配置了正确的日志路径。比如 CentOS 的认证日志在/var/log/secure，Ubuntu 在/var/log/auth.log，Wazuh 默认规则会自动识别，但如果你自己改了 Agent 的<localfile>配置，很可能路径不存在，导致日志根本没被采集。

第三步，还有一类隐蔽原因：时间不同步。Agent 和 Server 时间偏差超过几分钟，Server 在写入索引时会把日志标记为“未来时间”或“过期时间”，Dashboard 默认按当前时间过滤，自然就看不到了。实验环境重启过虚拟机后经常出现这个问题，date命令一对比就能发现。

5.2 现象：Syslog 接入后只进 archives 不产生告警

接入外部 Syslog 后，我在 archives 日志里能看到数据，但 Dashboard 的 Security events 页面没有任何告警。这个现象很典型。

原因是 Wazuh 对外部 Syslog 的处理逻辑和 Agent 日志不同：Agent 日志经过严格的解析和规则匹配，而原始 Syslog 进来后，如果解码器没有识别出对应的程序名或格式，只会被归档，不会触发规则。

排查命令是：

sudo /var/ossec/bin/wazuh-logtest

把 syslog 里的原始日志贴进去，看它最终走了哪个 decoder、匹配了哪条规则。如果发现规则没有命中，就需要针对这个日志源单独写解码器和规则。我当时模拟的是一条自定义网络设备日志，官网自带的 decoder 没有覆盖，于是花了一个下午写了正则，终于跑通了一条专属告警。这个过程让我对 Wazuh 的 decoder 机制有了非常深的理解。

另外还有一类低级错误：发送端虽然指定了 UDP 1514，但 Server 端防火墙没放行，或者ossec.conf里 remote 配置被改成了别的连接模式。用tcpdump -i any udp port 1514可以直接看到底有没有流量进来。

5.3 安装部署阶段常见报错

部署阶段最容易出的问题集中在资源不足和端口占用。我列一个速查表：

安装阶段如果反复失败，最彻底的办法是把/var/lib/wazuh-indexer、/var/lib/filebeat、/etc/wazuh-*这些目录清理干净再重装。注意备份好密码文件，否则重置起来很麻烦。

5.4 Agent 群组与策略下发

Agent 多了以后，会出现一个实际问题：不同主机需要的监控策略不同。比如 Web 服务器需要监控网站目录，数据库服务器需要监控特定配置变更，如果所有 Agent 共用一套策略，要不就是覆盖不足，要不就是日志量爆炸。

Wazuh 通过 Agent 群组（Group）解决这个问题。在 Dashboard 的 Agents 页面，可以把不同 Agent 分配到不同分组，每个分组对应一套独立的 Agent 配置和规则文件。实验里我分了 web 组和 db 组，分别下发不同的<localfile>配置，验证发现确实能做到策略隔离。

这个功能对于做“策略即代码”的团队很有用，可以直接把分组配置文件放到配置管理工具里管理，大批量调整时不用一台一台登录。

5.5 后续扩展方向与个人体会

这次实验环境跑起来之后，我后续打算做几件事：一是把 Suricata 的 IDS 日志接入 Wazuh，做主机侧加网络侧的联动检测；二是对接 API，把告警自动同步到工单系统，减少人工盯屏；三是完善主动响应策略，从只封 IP 扩展到调用云安全组 API 自动隔离失陷主机。

整套搭下来，我最深的体会是：Wazuh 的上手门槛不在安装，而在规则和日志的理解。很多人觉得装完就能用，但真正跑一轮攻击模拟，你才知道哪些规则没覆盖、哪些日志没采集、哪些告警是无效噪音。检测平台的价值是规则喂出来的，规则质量决定检测效果。建议所有准备上 Wazuh 的团队，先花一周时间在实验室里把这些细节跑通，再谈生产部署。这套实验环境搭建过程中踩过的坑，后面会继续整理成专题分享，尤其是 decoder 编写和规则调优的部分，希望对你有帮助。