OSSEC 与 Wazuh 规则引擎之对比

参考：https://blog.csdn.net/qq_29490749/article/details/142253399

引言

Wazuh 是 ossec的分支，那为啥非要用分支不用原生呢？其实问题就在于Wazuh对ossec的规则引擎进行改良和扩展，使得规则不限制于少量且写死的字段，譬如源地址、目的地址等字段，可以进行无限制的字段扩展！

两者规则引擎，支持以下共同特性 ——单事件正则，统计类规则，前后关联，例如暴力破解，爆破成功检测；
Wazuh本质上语法层面和 ossec 没有变化，但是公共字段提取出来了，同时正则匹配数据提取灵活性更强。

一、OSSEC 规则

OSSEC包括两类规则，分别是静态c编译规则，动态xml扩展规则。

规则语法详解：https://ossec-documentation.readthedocs.io/en/latest/manual/lids/rules.html

（一）预编译规则（Compiled Rules）-- 静态

OSSEC的静态预编译规则（Compiled Rules）为了方便不喜欢编写xml格式规则的用户。
ossec预编译规则的位置是源代码的 src/analysisd/compiled_rules 目录。
利用这项功能，用户可以直接使用 c语言来编写日志处理规则，在编译的时候，连接到 analysisd 程序。并非一种动态的规则扩展机制。
为了了解预编译规则，我们先看一下ossec的xml规则定义。

（二）XML 规则 -- 动态

ossec 的动态配置规则是XML格式的，可以继续划分为两个子类：
解码规则：用于判断日志的种类和格式，所有的内容都在decode.xml文件中；
检测规则：依赖于检测规则，主要用于检测日志中记录的安全问题。

OSSEC的解码规则与检测规则是其入侵检测能力的核心组件，两者协同工作以实现日志分析和威胁识别。以下为详细解析：

1. 解码规则（Decoders）

功能与作用‌
解码器用于将原始日志解析为结构化数据，提取关键字段（如时间戳、IP地址、事件类型等），为后续规则匹配提供标准化输入。例如，针对SSH登录日志的解码器会提取用户名、IP和登录状态等信息‌。

配置方式‌

解码器定义在 /var/ossec/etc/decoders.xml 文件中，支持正则表达式匹配日志格式‌。
每个解码器需指定 parent 字段继承父类解码逻辑，或通过 prematch 预匹配条件筛选日志‌。

自定义开发‌
用户可为特定应用日志编写自定义解码器。例如，解析自定义服务日志需在 <decoder> 标签中定义匹配规则和字段提取逻辑‌。

2. 检测规则（Rules）

功能与作用‌
检测规则基于解码后的结构化数据，通过逻辑条件匹配异常行为或攻击特征。例如，检测多次SSH登录失败可触发暴力破解告警‌。

配置方式‌

规则定义在 /var/ossec/rules/ 目录下的XML文件中，按威胁类型分类（如系统、Web应用等）‌。
规则包含<if_sid>引用父规则ID，实现多级关联分析。XML Code 例如：

<rule id="10001" level="5">
<decoded_as>ssh_login</decoded_as>
<description>SSH login failed</description>
</rule>
<rule id="10002" level="10">
<if_sid>10001</if_sid>
<same_source_ip />
<description>Multiple SSH login failures from same IP</description>
</rule>

此规则链在单次失败（level 5）基础上，检测同一IP的多次失败并提升告警级别（level 10）‌。

自定义开发‌
用户可通过 <rule> 标签定义新规则，结合 <regex> 匹配字段内容，并通过 <group> 分类告警类型‌。

（三）协同工作流程

1. 日志处理流程‌：

ossec-logcollector  // 收集日志
ossec-analysisd     // 范式化日志并进行分析，匹配规则并触发告警信息
ossec-syscheckd     // 检测定义监控的文件完整性变化(校验和、权限、属组)
ossec-maild         // 触发邮件或短信告警
ossec-execd         // 触发执行响应处理脚本
ossec-remoted       // 服务端与客户端通信服务守护进程(UDP 1514)

I. ossec-logcollector（源代码在src/logcollector）监控各种日志的变更，ossec支持syslog、mysql、postgresql、snort、nmap，以及djbmultilog等日志；
II. 一旦发现日志变动，就读取信产生的日志，根据日志类型的不同，分别调用read_syslog、read_djbmultilog、 read_nmapg、read_mysql_log、read_snortfull、read_postgresql_log等函数进行处理。在这里我们只关注syslog的处理。
III. read_syslog读取日志条目，调用 SendMSG 向 ossec-analysisd (源代码在src/analysisd)投递。在ossec启动时，analysisd会打开一个UNIX套接字，接收事件日志，进行分析处理。
IV. ossec-analysisd调用OS_ReadMSG_analysisd函数接收事件信息，然后调用OS_CleanMSG将收到的数据转换为 Eventinfo 结构。

typedef struct _Eventinfo
{
    /* 从事件信息中提取的数据 */
    char *log;
    char *full_log;
    char *location;
    char *hostname;
    char *program_name;

    /* 从解码器中提取的数据 */
    char *srcip;
    char *dstip;
    char *srcport;
    char *dstport;
    char *protocol;
    char *action;
    char *srcuser;
    char *dstuser;
    char *id;
    char *status;
    char *command;
    char *url;
    char *data;
    char *systemname;

    /* Pointer to the rule that generated it */
    RuleInfo *generated_rule;

    /* Pointer to the decoder that matched */
    OSDecoderInfo *decoder_info;

    /* Sid node to delete */
    OSListNode *sid_node_to_delete;

    /* Extract when the event fires a rule */
    int size;
    int p_name_size;

    /* Other internal variables */
    short int matched;
    
    int time;
    int day;
    int year;
    char hour[9];
    char mon[4];
}Eventinfo;

Eventinfo 是 ossec检测的核心对象，所有的检测都是针对Eventinfo进行的。
ossec-analysisd接收原始日志对Eventinfo的处理又分以下阶段：
a. 预处理阶段。OS_CleanMSG函数从接收到的信息中，提取相关数据，填写Eventinfo的第一部分；
b. 解码阶段。调用 DecodeEvent 函数，完成解码处理。应用解码器解析原始日志为结构化数据;
c. 检测阶段。剩下的检测过程全部由OS_ReadMSG / OS_ReadMSG_analysisd调度完成。

规则匹配‌：基于结构化数据，调用OS_CheckIfRuleMatch逐级匹配检测规则；
事件处理（记录事件/触发警报/执行响应）：OS_Exec(execdq, arq, lf, *rule_ar) 触发对应告警级别，并执行预设响应动作（如阻断IP）‌

预编译规则
ossec预编译规则的位置是源代码的 src/analysisd/compiled_rules 目录。
在上述阶段中，预处理规则只能用于" c.检测阶段 " ，与 xml 定义的检测规则等同。下面我们看一下ossec源代码中的一段示例，检测源用户和目标用户是否相同。

void *comp_srcuser_dstuser(Eventinfo *lf)
{
    if(!lf->srcuser || !lf->dstuser)
    {
        return(lf);
    }
    /* 对比Eventinfo中，srcuser是否等于dstuser */
    if(strcmp(lf->srcuser, lf->dstuser) == 0)
    {
        return(lf);
    }
    /* In here, srcuser and dstuser are present and are different. */
    return(NULL);
}

编写预处理插件时，我们只需要编写我们需要的功能即可，剩下的相关工作可以由 register_rule.sh 脚本完成，然后重新编译 ossec 的源代码，即可完成安装。register_rule.sh支持以下选项：

add <函数名>    #添加函数
list           #列出加入的函数
build          #生成头文件 compiled_rules.h
save           #备份函数列表
restore        #恢复函数列表

2. 测试工具‌

使用ossec-logtest工具可模拟日志输入，实时查看解码和规则匹配结果。bash Code 例如：

/var/ossec/bin/ossec-logtest
> Jul 4 09:42:16 enigma sshd[11990]: Failed password for root from 192.168.1.10

输出将显示匹配的解码器、规则ID及告警级别‌。

（四）配置文件与目录结构

组件	路径/文件	说明	来源
解码器‌	/var/ossec/etc/decoders.xml	存储全局解码器定义
规则‌	/var/ossec/rules/*.xml	按类别存储检测规则	（如syslog_rules.xml）
测试工具‌	/var/ossec/bin/ossec-logtest	模拟日志输入验证解码器与规则有效性

通过合理配置解码规则与检测规则，OSSEC可实现细粒度威胁检测，例如精准识别Web攻击、异常登录行为及文件篡改等场景‌。

二、Wazuh 规则

Wazuh 规则定义‌：Wazuh规则是一组用XML格式编写的条件，用于解释日志数据。这些规则位于/var/ossec/etc/rules/和 /var/ossec/ruleset/rules/ ，由Wazuh Manager使用，用于在日志消息中检测特定的模式或行为，并相应地生成警报或响应。

规则语法详解：https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html

（一）规则分类

分为两类，默认规则和自定义规则。

1. 默认规则

Wazuh 默认规则是随 Wazuh 安装包一起提供的内置规则。这些规则可以在 Wazuh 服务器的 /var/ossec/ruleset/rules/ 目录下找到。这些规则涵盖了广泛的安全事件和日志来源，为常见的安全威胁提供了一个基准。
默认规则旨在检测各种类型的攻击、漏洞或可疑活动。它们由Wazuh团队不断更新和维护，以应对新出现的威胁，并确保安全检测能力的有效性。
例如，Wazuh内置的对网络入侵检测引擎Suricata日志解析的规则示例，该规则示例在/var/ossec/ruleset/rules/0475-suricata_rules.xml文件中。

2. 自定义规则

Wazuh中的自定义规则允许用户定义特定条件或模式，这些条件或模式与他们独特的环境、应用程序或安全需求相关。这些规则可以在 Wazuh 服务器的 /var/ossec/etc/rules/ 目录下找到。虽然Wazuh自带一组默认规则，覆盖了广泛的安全事件，但自定义规则使用户能够根据他们的具体需求定制系统，并增强其能力。
Wazuh有两种方式供用户选择，分别是新增自定义规则和修改默认规则。

‌Wazuh规则的添加‌：

（1）新增自定义规则‌：用户可以创建自定义规则来扩展Wazuh的功能。自定义规则与解码器类似，都是以XML配置文件方式实现，根据不同的条件来识别日志内容。例如，可以创建一个自定义规则来检测命令执行日志，首先将命令转存到日志文件中，然后使用解码器解析这些日志‌。

　　自定义规则有以下三点需要注意：

新增的规则ID应该设置为100000~120000范围。
如果新增规则数量较少，可以在/var/ossec/etc/rules/local_rules.xml文件中添加，如果规则数量较多，建议在/var/ossec/etc/rules/文件夹下创建规则文件。
更改规则后需要执行systemctl restart wazuh-manager命令重启wazuh-manager才能生效。

（2）根规则与派生规则‌：根规则是基础规则，负责区分规则类别；派生规则可以引用根规则进行更详细的过滤和匹配，从而派生出更具体的描述安全事件的规则‌。

（3）修改默认规则：Wazuh默认的规则文件在 /var/ossec/ruleset/rules 文件夹下，如果想要修改默认规则，先将默认的规则文件拷贝复制到 /var/ossec/etc/rules/ 文件夹下，然后进行修改，并添加overwrite="yes"属性。
需要注意的是，尽量不要在/var/ossec/ruleset/rule s文件夹下直接修改规则文件，因为这样在Wazuh升级的时候很有可能会将之前的修改覆盖掉。

‌Wazuh的安装和配置‌：

‌安装方式‌：Wazuh可以通过仓库安装、虚拟机OVA安装、镜像下载、部署在Docker、K8s上、使用ES安装、使用ansible安装等多种方式进行安装。具体步骤可以参考Wazuh的官方文档‌。
‌主动响应‌：Wazuh支持主动响应功能，当检测到危险或告警时，可以根据设定的条件执行一系列反应，如禁止账户登录等。主动响应的脚本位于/var/ossec/active-response/bin目录下‌。

（二）规则分级

Wazuh规则被分为多个级别，从最低的0级到最高的16级。下面的表格概述了每个级别，提供了对每个触发警报的严重性的见解，并帮助创建自定义规则。

下面是对不同等级规则的介绍：
这段内容描述了一个安全事件管理系统中不同级别的事件及其描述。每个级别代表了事件的严重性及其对安全的影响。以下是对每个级别的简要解释：

低：

0 - Ignored: 无操作。用于避免误报。这些规则在其他所有规则之前被扫描，包括没有安全相关性的事件，并且不会出现在安全事件仪表板中。
2 - System low priority notification: 系统低优先级通知。系统通知或状态消息。这些没有安全相关性，不会出现在安全事件仪表板中。
3 - Successful/Authorized events: 成功/授权事件。包括成功的登录尝试、防火墙允许事件等。
4 - System low priority error: 系统低优先级错误。与不良配置或未使用的设备/应用程序相关的错误。这些没有安全相关性，通常由默认安装或软件测试引起。
5 - User generated error: 用户生成的错误。包括错过的密码、被拒绝的操作等。就其本身而言，这些没有安全相关性。
6 - Low relevance attack: 低相关性攻击。表明对系统没有影响的蠕虫或病毒（例如对Apache服务器的代码红等）。这也包括频繁的IDS事件和频繁的错误。

中：
7 - “Bad word” matching: “坏词”匹配。包括“坏”、“错误”等词。这些事件大多数时候是未分类的，可能有一定的安全相关性。
8 - First time seen: 第一次看到。包括第一次看到的事件。第一次IDS事件被触发或用户第一次登录。它还包括安全相关的操作，如激活嗅探器或类似活动。
9 - Error from invalid source: 来自无效源的错误。包括作为未知用户或来自无效源的登录尝试。可能具有安全相关性（特别是如果重复出现）。这也包括关于“管理员”（root）账户的错误。
10 - Multiple user generated errors: 多个用户生成的错误。包括多个错误的密码、多次失败的登录等。这可能表明攻击，或者仅仅是用户忘记了他们的凭据。
11 - Integrity checking warning: 完整性检查警告。包括有关二进制文件修改或存在rootkit（由Rootcheck检测）的消息。这可能表明成功的攻击。还包括将被忽略的IDS事件（重复次数高）。

高：
12 - High importance event: 高重要性事件。包括来自系统、内核等的错误或警告消息。这可能表明针对特定应用程序的攻击。
13 - Unusual error (high importance): 不寻常的错误（高重要性）。大多数时候匹配常见的攻击模式。
14 - High importance security event: 高重要性安全事件。大多数时候通过相关性触发，表明攻击。

严重：
15 - Severe attack: 严重攻击。没有误报的可能性。需要立即关注。

posted @ 2025-02-26 22:52 suntroop 阅读(297) 评论(0) 收藏举报

刷新页面返回顶部