主机入侵检测（HIDS）：OSSEC / Wazuh 部署与规则编写

文章目录

- - 写在前面
- [一、HIDS 在纵深防御中的位置](#一、HIDS 在纵深防御中的位置)
- - [1.1 能力地图](#1.1 能力地图)
  - [1.2 适合解决的问题](#1.2 适合解决的问题)
  - [1.3 不该幻想的事](#1.3 不该幻想的事)
- [二、OSSEC 与 Wazuh：怎么选](#二、OSSEC 与 Wazuh：怎么选)
- - [2.1 关系简述](#2.1 关系简述)
  - [2.2 架构组件（以 Wazuh 为例）](#2.2 架构组件（以 Wazuh 为例）)
  - [2.3 关键数据流](#2.3 关键数据流)
- 三、部署实战要点
- - [3.1 规划清单（先写后装）](#3.1 规划清单（先写后装）)
  - [3.2 Manager 部署原则](#3.2 Manager 部署原则)
  - [3.3 Agent 部署原则](#3.3 Agent 部署原则)
  - [3.4 最小 `ossec.conf` 思维模型](#3.4 最小 ossec.conf 思维模型)
  - [3.5 Windows 日志特别提醒](#3.5 Windows 日志特别提醒)
  - [3.6 验证部署成功的五步](#3.6 验证部署成功的五步)
- [四、规则体系：Decoder + Rule](#四、规则体系：Decoder + Rule)
- - [4.1 Decoder：先让引擎"读懂"日志](#4.1 Decoder：先让引擎“读懂”日志)
  - [4.2 Rule：条件、级别与分组](#4.2 Rule：条件、级别与分组)
  - [4.3 第一条企业规则：应用登录失败](#4.3 第一条企业规则：应用登录失败)
  - [4.4 关联官方规则：在内置之上加企业语义](#4.4 关联官方规则：在内置之上加企业语义)
  - [4.5 忽略规则：治理误报的正规军](#4.5 忽略规则：治理误报的正规军)
  - [4.6 CDB 列表：黑白名单](#4.6 CDB 列表：黑白名单)
  - [4.7 Windows 事件规则思路](#4.7 Windows 事件规则思路)
- [五、FIM 规则与策略](#五、FIM 规则与策略)
- - [5.1 监控什么](#5.1 监控什么)
  - [5.2 告警怎么用](#5.2 告警怎么用)
- 六、主动响应：双刃剑
- 七、实战用例库（可写成规则需求）
- - [用例 1：SSH 爆破 → 封禁](#用例 1：SSH 爆破 → 封禁)
  - [用例 2：新增 sudo 用户](#用例 2：新增 sudo 用户)
  - [用例 3：webshell 落地](#用例 3：webshell 落地)
  - [用例 4：审计日志被清](#用例 4：审计日志被清)
  - [用例 5：云元数据异常访问](#用例 5：云元数据异常访问)
  - [用例 6：合规 SCA](#用例 6：合规 SCA)
- 八、调优与运营
- - [8.1 误报治理四步](#8.1 误报治理四步)
  - [8.2 性能](#8.2 性能)
  - [8.3 安全加固 Manager 自身](#8.3 安全加固 Manager 自身)
  - [8.4 与 SIEM/SOAR](#8.4 与 SIEM/SOAR)
  - [8.5 度量](#8.5 度量)
- [九、90 天落地路线](#九、90 天落地路线)
- 十、结语
- - [附录 A：术语表](#附录 A：术语表)
  - [附录 B：规则编写检查单](#附录 B：规则编写检查单)

写在前面

防火墙看的是"包有没有进出"，EDR/杀软看的是"进程像不像恶意"，而 HIDS（Host-based Intrusion Detection System，主机入侵检测系统） 盯的是另一层真相：

系统日志有没有异常、关键文件有没有被改、账号有没有被偷偷拉进管理员组、谁在什么时候执行了可疑命令。

一、HIDS 在纵深防御中的位置

1.1 能力地图

能力	典型实现（Wazuh/OSSEC）
日志采集与分析	syslog、auth、审计、Windows Event、应用日志
文件完整性监控 FIM	关键目录校验与变更告警
根kit / 异常检测	定期检查（能力随版本变化）
配置合规 SCA	CIS 类检查（Wazuh 强化）
主动响应	封禁 IP、禁用账号（需谨慎）
与 SIEM/SOAR 联动	告警外发、工单

1.2 适合解决的问题

Linux sshd 爆破、sudo 异常、用户增删；
Windows 登录失败风暴、新建服务、审计日志清除（需日志源配合）；
Web 目录被写入 webshell、二进制被替换；
配置项偏离基线（权限开放、危险参数）；
云主机与传统机混部时的统一可视。

1.3 不该幻想的事

替代反病毒/EDR 的内存与行为深度对抗；
在未开日志的情况下"凭空"看到进程命令行；
无调优时对复杂业务零误报；
代理被 rootkit 彻底控制后的绝对可信（需与加固、防篡改一起设计）。

一句话：HIDS 是主机侧的"黑匣子与哨兵"，不是一键免疫。

二、OSSEC 与 Wazuh：怎么选

2.1 关系简述

OSSEC：经典开源 HIDS，奠定了 manager--agent、解码器--规则、FIM 等模型。
Wazuh：自 OSSEC 生态发展而来，补强了规则集、RESTful API、仪表盘（常与 OpenSearch/Elastic 栈配合）、SCA、云与容器相关能力、更活跃的发布节奏。

当前企业新建项目，多数会直接选 Wazuh；仍维护纯 OSSEC 的环境，规则思想相通，语法需注意版本差异。

2.2 架构组件（以 Wazuh 为例）

text 复制代码

[Wazuh Agent] × N
      │  加密上报事件
      ▼
[Wazuh Manager]  ←  分析引擎、规则、FIM 数据库、主动响应
      │
      ▼
[索引与可视化]  ←  OpenSearch/Elastic + Wazuh Dashboard

小型环境可单机 all-in-one；生产建议：Manager 高可用、索引集群独立、按安全区分级部署。

2.3 关键数据流

Agent 读本地日志/抓 FIM 事件；
预处理、归一化；
Manager 侧 Decoder 抽字段；
Rules 匹配并打分（level）；
写入告警索引 / 邮件 / 脚本 / SOAR；
可选 Active Response 触发处置。

规则编写的本质，就是在步骤 3～4 把"原始日志"变成"可运营告警"。

三、部署实战要点

3.1 规划清单（先写后装）

项	建议
覆盖范围	先域控/跳板/Web/数据库，再推全量
网络	Agent→Manager 端口放行（默认 1514/udp 或 tcp，以文档为准）；仪表盘与 API 另计
身份	Manager 与 Dashboard 强认证、MFA、仅管理网访问
存储	日志保留天数、磁盘水位告警
权限	Agent 安装包签名校验；防卸载策略
时间同步	NTP 必须，否则关联分析崩溃

3.2 Manager 部署原则

使用官方文档推荐的操作系统与安装方式（软件包或 Docker，生产慎用"实验用一键"不加加固）。
安装后立刻：改默认口令、限制 SSH、配置 TLS（按版本指南）、备份 ossec.conf / 证书。
接好邮件或 IM Webhook，做一条测试告警验证链路。
分层配置：local_rules.xml、local_decoder.xml 专放企业定制，避免改官方文件导致升级覆盖。

3.3 Agent 部署原则

Linux 示例思路：

添加厂商仓库 → 安装 agent → 指向 Manager 地址 → 获取认证密钥（或使用注册服务）→ 启动服务。

Windows 示例思路：

MSI 安装 → 指定 Manager → 注册 → 服务自动启动；
用软件分发（SCCM/Intune/Ansible）批量推送；
验证：Manager 上 agent 列表为 Active。

注册安全：

避免长期使用"开放注册 + 已知密码"暴露在公网；
生产用认证注册、一次性密钥或自动化签发；
Agent 卸载应有主机加固与监控（防攻击者拆掉眼睛）。

3.4 最小 `ossec.conf` 思维模型

管理端/代理配置围绕：

全局：邮件、告警级别阈值；
本地文件：监控哪些日志路径；
rootcheck / SCA / FIM 目录；
主动响应开关；
与云、Docker、Syscollector 等相关模块（Wazuh）。

FIM 目录务必克制 ：从 /etc、/usr/bin、/usr/sbin、Web 根目录、关键业务目录开始，而不是整盘实时哈希拖垮 IO。

3.5 Windows 日志特别提醒

要让 HIDS 发挥前文《4624 到 4688》的价值，主机需先开启：

登录成功/失败；
进程创建（含命令行，如需要）；
其它对象访问等。

否则 Agent "没东西可读"，规则再精也无用。

3.6 验证部署成功的五步

Agent 状态 Active；
制造一次失败 SSH 登录，Manager 出告警；
修改受 FIM 监控的测试文件，出完整性告警；
Dashboard 能按主机检索；
断网/恢复后事件是否积压与补传符合预期。

四、规则体系：Decoder + Rule

4.1 Decoder：先让引擎"读懂"日志

Decoder 用模式（含正则）识别日志家族，并提取字段（program_name、srcip、user......）。

官方已覆盖大量 syslog/auth/sshd 等；企业定制通常针对自研应用日志。

编写原则：

先写能稳定匹配的 prematch / program_name；
字段名尽量复用官方约定，便于通用规则；
一种日志格式一个解码器族，避免巨型万能正则。

教学示意（结构示意，非照搬生产）：

xml 复制代码

<!-- local_decoder.xml 思路示意 -->
<decoder name="myapp">
  <prematch>^MyApp:</prematch>
</decoder>

<decoder name="myapp-login-fail">
  <parent>myapp</parent>
  <regex offset="after_parent">user (\S+) from (\S+) fail</regex>
  <order>user, srcip</order>
</decoder>

用 ossec-logtest / wazuh-logtest（名称随版本）把样例日志喂进去，确认字段提取正确，再写规则。

4.2 Rule：条件、级别与分组

规则在解码后的事件上匹配：匹配成功则生成告警，带 level（0～15）、description、groups 等。

常见匹配维度：

match / regex：内容；
decoded_as：解码器名；
program_name、id（Windows 事件 ID）；
if_sid / if_group：依赖其它规则（关联）；
frequency + timeframe：频率规则（爆破检测）；
same_source_ip 等：同一来源聚合。

级别建议（实践惯例）：

Level	用途
0～3	噪声/信息，可不入库告警通道
4～6	需关注
7～11	安全告警，进 SOC
12～15	紧急，电话级

企业应用规则建议从 level 5～10 调起，避免一上来 15 刷屏。

4.3 第一条企业规则：应用登录失败

xml 复制代码

<!-- local_rules.xml 思路示意 -->
<group name="myapp,authentication_failed,">
  <rule id="100100" level="5">
    <decoded_as>myapp-login-fail</decoded_as>
    <description>MyApp login failure</description>
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>

  <rule id="100101" level="10" frequency="6" timeframe="120">
    <if_matched_sid>100100</if_matched_sid>
    <same_source_ip />
    <description>MyApp brute force: multiple failures from same srcip</description>
    <group>authentication_failures,brute_force,</group>
  </rule>
</group>

要点：

企业自定义 ID 使用官方预留高段（如 100000+，以当前文档为准），避免与内置冲突；
频率规则挂在单次失败之上，形成"单次记录 + 爆破聚合"；
group 便于仪表盘过滤与 MITRE 映射（Wazuh 支持 mitre 节点）。

4.4 关联官方规则：在内置之上加企业语义

不必重写 sshd 爆破，可用 if_sid 引用官方规则 ID，再提高级别或追加描述。

升级前导出依赖的官方 ID，防止大版本规则号变化导致逻辑失效（需做升级回归）。

4.5 忽略规则：治理误报的正规军

xml 复制代码

<rule id="100200" level="0">
  <if_sid>XXXX</if_sid>
  <match>known_scanner_useragent</match>
  <description>Ignore known benign scanner</description>
</rule>

或用 overwrite 机制调整官方规则级别（按版本文档）。

禁止为省事直接删官方规则文件；用 local 覆盖，便于审计"我们忽略了什么"。

4.6 CDB 列表：黑白名单

将 IP、用户名、哈希放入 CDB列表，规则中 list 匹配。

适用：办公出口 IP 白名单、威胁情报 IP 黑名单、特权账号清单。

名单要有更新流程，否则白名单会变成攻击者的免检徽章。

4.7 Windows 事件规则思路

对 4625/4624/4688/1102 等：

确认 Agent 能收到对应通道；
用 event ID 字段匹配；
对 1102（审计日志清除）直接高 level；
对 4688 需配合命令行审计，规则匹配 powershell -enc 等模式（注意性能与误报）。

与本系列日志取证文联动：HIDS 负责实时哨，取证文负责事件语义。

五、FIM 规则与策略

5.1 监控什么

优先：

二进制目录、/etc、Web 可写目录、crontab、sudoers、SSH 授权密钥、业务配置；
Windows：关键注册表项可配合其它工具；系统目录与启动项相关路径按文档配置。

谨慎：

高变日志目录、缓存、容器层临时文件------会导致 FIM 风暴。

5.2 告警怎么用

工作时间 Web 目录新增 .php/.jsp → 高优先级；
/usr/bin 变更 → 变更单核对；
非变更窗口 sudoers 变更 → 紧急。

FIM 与变更管理联动后，误报率会显著下降。

六、主动响应：双刃剑

OSSEC/Wazuh 可在规则触发后执行脚本：防火墙丢弃源 IP、禁用本地用户等。

建议：

先只对 level≥10 且已调优的爆破类启用；
防止攻击者伪造日志源搞"自黑"造成拒绝服务；
响应脚本要幂等、有白名单、有审计日志；
生产先 shadow mode（只告警不动作）观察两周。

七、实战用例库（可写成规则需求）

用例 1：SSH 爆破 → 封禁

官方规则已覆盖大半；企业补：白名单跳板 IP；自动响应对接防火墙 API。

用例 2：新增 sudo 用户

匹配 /var/log/auth.log 或 secure 中 useradd/usermod；level 12；通知 IAM。

用例 3：webshell 落地

FIM 盯 Web 目录 + 规则匹配扩展名；结合 Web 访问日志中的 POST 异常（需解码器）。

用例 4：审计日志被清

Windows 1102 或 Linux auditd 异常停止；P1 流程。

用例 5：云元数据异常访问

主机出站访问 169.254.169.254 的频率基线；容器/K8s 节点重点看。

用例 6：合规 SCA

开启 CIS 策略，对失败项出工单，不全部当入侵，分流"合规"与"入侵"队列。

八、调优与运营

8.1 误报治理四步

确认解码是否错误（字段抽错会导致乱匹配）；
收紧 regex 或加白名单；
降 level 或改 frequency 阈值；
记录到误报库，季度回顾是否可删忽略规则。

8.2 性能

减少无用日志源；
避免灾难级正则；
FIM 目录精简；
Manager 横向扩展或按区域分片；
索引生命周期管理，防止磁盘写满丢告警。

8.3 安全加固 Manager 自身

Manager 是肉鸡梦寐以求的目标：拿下它≈可投毒规则、致盲全网。

按"一级域控级"养：补丁 SLA、管理面隔离、配置完整性监控（可用另一套机制互监）。

8.4 与 SIEM/SOAR

告警统一进 SIEM，HIDS 不单独烟囱值班；
字段规范化：host、srcip、user、rule.id、mitre；
SOAR 剧本：爆破封禁、高危 FIM 开主机隔离工单。

8.5 度量

代理在线率；
高危规则触发量与关闭时长；
误报率；
规则覆盖 MITRE 技术数量；
从告警到确认的 MTTA。

九、90 天落地路线

30 天： 装好 Manager + Dashboard；覆盖跳板、域控、对外 Web；验证 SSH 失败与 FIM；企业 local_rules 目录建立。

60 天： Windows 关键事件规则；爆破频率调优；主动响应影子模式；SCA 基线。

90 天： 全生产推送 Agent；SOAR/IM 联动；规则评审会；Manager 高可用与备份演练。

十、结语

OSSEC/Wazuh 类 HIDS 的价值，不在于"安装了开源安全产品"这句汇报词，而在于：

你是否为每一类真正关心的主机行为，写下了可解码、可匹配、可分级、可响应、可调优的规则，并与资产、变更、应急流程咬合。

部署是起点；local_decoder + local_rules + FIM 策略 + 误报治理 才是能力本身。它与本系列的 Windows 日志取证、补丁 SLA、供应链防护共用同一哲学：可见、可测、可追责。

建议你读完后立刻做三件事：

在测试机安装 Agent，用官方 logtest 跑通一条 SSH 失败样例；
为业务应用写一条"登录失败 + 频率爆破"规则（ID 落在企业号段）；
给 /etc 与 Web 目录配置 FIM，并人为改一个文件确认告警到达 Dashboard。

三步完成，你就已经跨过"听说过 OSSEC/Wazuh"，进入"能写规则的主机检测"阶段------而这正是蓝队工程化的入门门槛。

附录 A：术语表

术语	含义
HIDS	主机入侵检测
Decoder	日志解析与字段提取
Rule	匹配逻辑与告警级别
FIM	文件完整性监控
SCA	安全配置评估
Active Response	告警触发的自动处置
Manager/Agent	管理端/主机代理

主机入侵检测（HIDS）：OSSEC / Wazuh 部署与规则编写

文章目录

写在前面

一、HIDS 在纵深防御中的位置

1.1 能力地图

1.2 适合解决的问题

1.3 不该幻想的事

二、OSSEC 与 Wazuh：怎么选

2.1 关系简述

2.2 架构组件（以 Wazuh 为例）

2.3 关键数据流

三、部署实战要点

3.1 规划清单（先写后装）

3.2 Manager 部署原则

3.3 Agent 部署原则

3.4 最小 ossec.conf 思维模型

3.5 Windows 日志特别提醒

3.6 验证部署成功的五步

四、规则体系：Decoder + Rule

4.1 Decoder：先让引擎"读懂"日志

4.2 Rule：条件、级别与分组

4.3 第一条企业规则：应用登录失败

4.4 关联官方规则：在内置之上加企业语义

4.5 忽略规则：治理误报的正规军

4.6 CDB 列表：黑白名单

4.7 Windows 事件规则思路

五、FIM 规则与策略

5.1 监控什么

5.2 告警怎么用

六、主动响应：双刃剑

七、实战用例库（可写成规则需求）

用例 1：SSH 爆破 → 封禁

用例 2：新增 sudo 用户

用例 3：webshell 落地

用例 4：审计日志被清

用例 5：云元数据异常访问

用例 6：合规 SCA

八、调优与运营

8.1 误报治理四步

8.2 性能

8.3 安全加固 Manager 自身

8.4 与 SIEM/SOAR

8.5 度量

九、90 天落地路线

十、结语

附录 A：术语表

附录 B：规则编写检查单

3.4 最小 `ossec.conf` 思维模型