1. Wazuh主机安全监控工程导论

主机安全监控的目标,是让一台服务器在“正常运行”与“已经异常”之间变得可观测、可追溯、可告警。Wazuh 是一套开源的主机安全监控与 XDR 平台,它把日志采集、文件完整性校验、漏洞与配置合规检查、入侵检测规则、告警聚合与可视化整合到一条数据链路中。本课程围绕“工程化落地”展开:不是只讲某个功能怎么点,而是讲清一台主机从接入到产生可用告警的完整路径,以及每一步的输入、处理、输出和判断依据。

课程目标与学习路径

学完本课程,你应当能够独立完成以下任务:在受监控主机上部署并注册 Wazuh Agent;在 Manager 侧确认 Agent 上线并下发策略;配置日志采集、文件完整性监控(FIM)、安全配置评估(SCA)等模块;理解规则与解码器如何把原始日志变成告警;在 Dashboard 中定位告警、区分误报与真实风险;并对常见故障(Agent 未连接、日志不采集、告警不触发)进行排查。课程会持续使用一组示例参数,例如 Agent 名称 web-01、Manager 地址 192.168.10.20、注册端口 1515、通信端口 1514,这些均为教学示例,实际部署时需替换为你的环境值。

Wazuh 核心组件与数据链路

Wazuh 由四个核心组件构成,理解它们的分工是后续所有配置的基础。

  • Agent:部署在被监控主机上,负责采集日志、监控文件变化、执行 SCA 检查、收集系统清单,并通过加密通道把事件发送给 Manager。Agent 本身不做复杂关联分析,它的职责是“采集与上报”。
  • Manager:整个平台的分析中枢。它接收 Agent 事件,用解码器(Decoder)解析字段,用规则(Rule)匹配并生成告警,同时管理 Agent 注册、策略下发和规则库更新。Manager 还负责把告警写入 Indexer。
  • Indexer:基于 OpenSearch 的存储与检索组件,负责接收 Manager 输出的告警和事件,建立索引,供 Dashboard 查询与聚合。
  • Dashboard:基于 OpenSearch Dashboards 的 Web 界面,提供告警浏览、Agent 状态、合规视图、漏洞视图和自定义可视化。

四者的数据流方向是:Agent → Manager → Indexer → Dashboard。反向的控制流是:Dashboard/Manager 下发策略与注册指令 → Agent。下图展示了这一链路以及各环节的关键输入输出。

Wazuh 主机安全监控数据链路 Agent web-01 日志采集 FIM 文件校验 SCA 合规检查 系统清单 Manager 192.168.10.20 Decoder 字段解析 Rule 规则匹配 告警生成 Agent 注册管理 策略下发 端口 1514 / 1515 Indexer 告警存储 索引建立 全文检索 聚合查询 Dashboard 告警浏览 Agent 状态 合规视图 漏洞视图 事件上报 告警写入 查询 注册 / 策略下发 采集层 分析层 存储层 展示层

主机安全监控的典型场景

Wazuh 在主机侧的价值,集中体现在几类高频场景中。理解这些场景,有助于你在配置时知道“要采集什么、要匹配什么、要看到什么”。

场景一:SSH 暴力破解检测。Agent 采集 /var/log/auth.log(Debian/Ubuntu)或 /var/log/secure(RHEL/CentOS)。当同一源 IP 在短时间内出现多次 Failed password,Manager 的规则会触发告警,例如规则 5710(SSH 认证失败)在达到阈值后升级为 5720(暴力破解)。在 Dashboard 中可以看到源 IP、目标用户、尝试次数和首次/末次时间。

场景二:关键文件完整性监控。对 /etc/passwd、/etc/shadow、/etc/sudoers、Web 根目录等路径开启 FIM。Agent 计算文件校验和,一旦内容、权限或属主发生变化,就上报事件。例如 /etc/sudoers 被追加一行,会触发规则 550 或 554,提示“文件被修改”。这类告警需要结合变更窗口判断是运维操作还是入侵行为。

场景三:安全配置评估。SCA 模块按策略检查主机配置,例如“是否允许空密码登录”“SSH 是否禁用 root 直连”“密码最长有效期是否小于等于 90 天”。每项检查返回 pass/fail,Dashboard 给出合规得分。示例中若 web-01 的 SCA 得分为 72%,说明有若干项未通过,需要逐条查看修复建议。

场景四:漏洞与软件清单。Agent 收集已安装软件包版本,Manager 与漏洞库比对,识别 CVE。例如检测到 openssl 1.1.1k 存在已知漏洞,会在漏洞视图列出 CVE 编号、严重级别和受影响主机。

工程化落地的关键判断

部署完成后,不要只看“Agent 是否显示 Active”,还要验证数据是否真正流动。一个实用的检查顺序是:在 Agent 侧确认服务运行且能连通 Manager 的 1514 端口;在 Manager 侧用 /var/ossec/bin/agent_control -l 查看 Agent 状态;在 Dashboard 的 Security Events 中按 agent.name: web-01 过滤,确认最近有事件;再手动触发一次测试(例如在受控环境执行一次失败的 SSH 登录),观察是否产生对应告警。若 Agent 在线但无事件,优先检查采集路径是否存在、权限是否足够、规则是否匹配。

建议在实验环境中先用一台主机跑通“采集—分析—展示”全链路,再批量接入。批量接入时,Agent 名称、分组和策略要提前规划,避免后期告警无法按业务维度聚合。