wazuh日志审计--定制规则

日志审计--定制规则

目录布局

规则集文件夹结构如下所示:

在接收到agent传来的日志后,manager会根据/var/ossec/ruleset/decoders里面的各种规则对日志进行处理,提取到了指定字段的值之后再根据/var/ossec/ruleset/rules里面的各种规则进行匹配,告警日志输出到/var/ossec/logs/alerts/alerts.json,logstash再将其解析后传输到elasticsearch上面。

更新规则集

每周运行update_ruleset,通过向系统中添加crontab作业,使Wazuh规则集安装保持最新。

一种方法是运行sudo crontab -e,并在文件的末尾添加以下行

@weekly root cd /var/ossec/bin && ./update_ruleset -r

 

Jeson规则解释器

Wazuh现在为JSON日志合并了一个集成的解码器,使之能够以这种格式从任何来源提取数据。

此解码器有能力提取以下数据类型:

示例一:

下面的示例展示了Wazuh如何解码JSON日志并为Suricata生成警报。

下面的示例展示了包含在文件0470-suricata_rules.xml中的规则是如何工作的。最初,有一个父规则检查' timestamp '和' event_type '字段是否存在,以确定日志的类型(Suricata),然后子规则使用提取的字段的值显示警报

JSON记录的ossec-logtest输出如下:

示例二:

我们使用这个输入日志::

2018 Apr 04 13:11:52 nba_program: this_is_an_example: " player_information: "{ "name": "Stephen", "surname": "Curry", "team": "Golden State Warriors", "number": 30, "position": "point guard"}

Docker解释器:

<decoder name="raw_json">
    <program_name>nba_program</program_name>
    <prematch>player_information: "</prematch>
    <plugin_decoder offset="after_prematch">JSON_Decoder</plugin_decoder>
</decoder>

Rule规则:

<rule id="100001" level="5">
    <decoded_as>raw_json</decoded_as>
    <description>Raw JSON event</description>
</rule>

解析结果:

**Phase 1: Completed pre-decoding.
    full event: '2018 Apr 04 13:11:52 nba_program: this_is_an_example: " player_information: "{ "name": "Stephen", "surname": "Curry", "team": "Golden State Warriors", "number": 30, "position": "point guard"}'
    timestamp: '2018 Apr 04 13:11:52'
    hostname: 'ubuntu18'
    program_name: 'nba_program'
log: 'this_is_an_example: " player_information: "{ "name": "Stephen", "surname": "Curry", "team": "Golden State Warriors", "number": 30, "position": "point guard   "}'
 
**Phase 2: Completed decoding.
    decoder: 'raw_json'
    name: 'Stephen'
    surname: 'Curry'
    team: 'Golden State Warriors'
    number: '30'
position: 'point guard'
 
**Phase 3: Completed filtering (rules).
    Rule id: '100001'
    Level: '5'
    Description: 'Raw JSON event'
**Alert to be generated.

示例三

我们使用如下日志:

2018 Jun 08 13:11:52 nba_email_db: json_data: { "name": "Stephen", "surname": "Curry", "email": "curry@gmail.com"}
新特性是混合插件解码器和正则表达式的能力,看看下面的日志:
<decoder name="json_parent">
    <program_name>nba_email_db</program_name>
</decoder>
 
<decoder name="json_child">
    <parent>json_parent</parent>
    <prematch>json_data: </prematch>
    <plugin_decoder offset="after_prematch">JSON_Decoder</plugin_decoder>
</decoder>
 
<decoder name="json_child">
    <parent>json_parent</parent>
    <regex>@(\S+)"</regex>
    <order>email.domain</order>
</decoder>
解析结果:
**Phase 1: Completed pre-decoding.
    full event: '2018 Apr 04 13:11:52 nba_email_db: json_data: { "name": "Stephen", "surname": "Curry", "email": "curry@gmail.com"}'
    timestamp: '2018 Apr 04 13:11:52'
    hostname: 'ubuntu18'
    program_name: 'nba_email_db'
    log: 'json_data: { "name": "Stephen", "surname": "Curry", "email": "curry@gmail.com"}'
 
**Phase 2: Completed decoding.
    decoder: 'json_parent'
    name: 'Stephen'
    surname: 'Curry'
    email: 'curry@gmail.com'
    email.domain: 'gmail.com'

 

自定制规则和解码器

场景一:自定义规则和解释器

    我们将使用local_decoder.xmllocal_rules.xml来实现一些小的更改。对于对现有解码器和规则进行更大规模的更改/添加,我们建议您创建一个新的解码器和/或规则文件在/var/ossec/etc/decoders/var/ossec/etc/rules下。

场景二:修改现有规则和解释器

修改规则如果我们想将SSH规则5710的级别值从5更改为10,我们将执行以下操作:

1、打开规则文件/var/ossec/ruleset/rules/0095-sshd_rules.xml

2、从规则文件中找到并复制对应要修改的rule代码

3、将代码粘贴到/var/ossec/etc/rules/local_rules中。,修改level值,并添加overwrite="yes",表示该规则覆盖已定义的规则。
<rule id="5710" level="10" overwrite="yes">

 

修改解释器

              1、/ruleset/decoders/0310-ssh_decoders.xml从默认文件夹转移到用户文件夹/var/ossec /etc/decoders,以保持更改。

              2、从OSSEC加载列表中排除原始的解码器文件ruleset/decoders/0310-ssh_decoders.xml。为此,在ossec .conf文件中使用标签<decoder_exclude>。因此,指定的解码器将不会从默认的解码器文件夹加载,而会加载保存在用户文件夹中的解码器文件。

              3、在/var/ossec /etc/decoders/0310-ssh_decoders.xml文件中执行更改。

例如:负责处理Windows日志的decoder就是/var/ossec/ruleset/decoders/0380-windows_decoders.xml
为了让自己修改后的规则库不会因为后期的软件包更新而被覆盖,如下操作

1、先手动复制一份原有的规则cp -a ruleset/decoders/0380-windows_decoders.xml etc/decoders/

2、修改etc/ossec.conf,在</ruleset>节点新增一行,将原有的解码器从ossec的载入列表中排除,看上去如下:

3在/var/ossec /etc/decoders/0310-ssh_decoders.xml文件中执行更改。

               

4、如果以后官方更新了0380-windows_decoders.xml,就需要手动合并新旧两个版本了。打开0380-windows_decoders.xml

              

合并后:

              

出现了两次security_id的取值,是按照先后顺序取到的。
因为无法匹配中英混合字符串,于是改为单次匹配提取,即将其原本一次性提取4个特征改为分为4次提取特征。
提取规则会跟下面有所重复,但是<order></order>是不一样的,而且是按字符串先后顺序只提取一次

比如第一次匹配到的安全ID是S-1-5-18,会作为subject.security_id的值。
第二次匹配到的安全ID是S-1-5-21-3320951223-3242959419-3755421162-500,会作为security_id的值。

每次修改规则之后,需要重新运行bin/ossec-logtest,才能验证规则是否有效。

验证通过后,重启manager以便让新规则生效,另外kibana会提示你刷新索引以便更新字段。

测试:

有这样一条日志Dec 25 20:45:02 MyHost example[12345]: User 'admin' logged from '192.168.1.100'
为了解码这条日志,需要编写自定义解码器,修改/var/ossec/etc/decoders/local_decoder.xml,name是解码规则的名称,program_name是匹配日志以example开头,regex表示用正则提取,order表示正则提取出来值依次是user,srcip。


现在修改/var/ossec/etc/rules/local_rules.xmllevel就是告警的等级。


然后运行/var/ossec/bin/ossec-logtest来测试写的规则是否能正常运作。另外这个命令还有好几个参数(-v),可以看到更详细的过程。

解释器语法:

官方链接:https://documentation.wazuh.com/3.13/user-manual/ruleset/ruleset-xml-syntax/decoders.html#parent

decoder它的属性将用于定义解码器。

parent:它将引用父解码器,当前的解码器将成为子解码器。

accumulate:它允许在多个日志消息上跟踪事件。

program_name:它定义了与解码器相关联的程序的名称。

prematch:它将在日志中寻找匹配,如果匹配,则将使用解码器。

regex:解码器将使用此选项来查找感兴趣的字段并提取它们。

orderregex将提取的值将存储在这些组中。

fts:第一次见过。

ftscomment:添加一个评论到fts

plugin_decoder:指定一个插件来进行解码。当用正则表达式提取是不可行的。

use_own_name:仅适用于子解码器。

json_null_field:添加决定如何存储JSON中的空值的选项。

json_array_structure:添加决定如何存储JSON中的数组结构的选项。

var:定义可以在同一文件中重用的变量。

decoder规则示例:

设置ossec的解码器名称:

<decoder name="ossec">

  ...

</decoder>

program_name规则示例:

定义译码器与syslogd进程相关:

<decoder name="syslogd_decoder">

  <program_name>syslogd</program_name>

  ...

</decoder>

规则语法:

官方链接:https://documentation.wazuh.com/3.13/user-manual/ruleset/ruleset-xml-syntax/rules.html

rule它开始一个新的规则和它的定义选项。

match:它将尝试在日志中找到匹配项,决定是否应该触发该规则。

regex:它的作用与match相同,但使用的是regex而不是sregex

decided_as:它将与由特定解码器解码的日志进行匹配。

if_sid:它的工作类似于父解码器。如果规则ID之前已经匹配,则它将匹配。

 

rule规则示例:

使用ID: 3151创建规则,如果规则3102在过去120秒内匹配了8次,则将触发10级警报。

<rule id="3151" level="10" frequency="8" timeframe="120">

  <if_matched_sid>3102</if_matched_sid>

  <same_source_ip />

  <description>sendmail: Sender domain has bogus MX record. </description>

  <description>It should not be sending e-mail.</description>

  <group>multiple_spam,pci_dss_11.4,gdpr_IV_35.7.d,nist_800_53_SI.4,</group>

</rule>

match规则示例: 

如果规则匹配id 100200并且日志包含队列溢出!短语在它,规则激活和触发一个3级警报。

<rule id="100001" maxsize="300" level="3">

  <if_sid>100200</if_sid>

  <match>Queue flood!</match>

  <description>Flooded events queue.</description>

</rule>

regex规则示例:

如果规则匹配id 100500,并且事件包含任何有效的IP,则触发规则并生成一个3级警报。

<rule id="100001" level="3">

  <if_sid>100500</if_sid>

  <regex>\d+.\d+.\d+.\d+</regex>

  <description>Matches any valid IP</description>

</rule>

正则表达语法:

正则表达式是定义模式的字符序列。

正则表达式有两种类型:regex (OS_Regex)和sregex (OS_Match)。

正则表达式(OS_Regex)语法

这是一个快速而简单的C语言正则表达式库。

这个库设计得很简单,同时仍然支持最常见的正则表达式。

支持表达式:   

   

编辑器:

   

        特殊字符:

           

        转义字符:

           

    注意事项(限制):

        1*+修饰符只能用于反斜杠表达式,而不能用于纯字符(例如,支持\d+,不支持0+)

              2、你不能在组中使用变更,例如(foo|bar)是不允许的

              3、不支持复杂的回溯,例如\p*\d*\s*\w*:不匹配单个冒号,因为\p*消耗冒号

              4. 匹配文字点,而\ . 匹配任何字符

              5\s只匹配ASCII空格(32),不匹配制表符等其他空格

              6、没有匹配文字插入符号、星号或加号的语法(尽管\p将匹配星号或加号以及其他一些字符)

Sregex (OS_Match) syntax

              这比OS_Regex快,但是只支持简单的字符串匹配和以下特殊字符。

测试解码器和规则

工具ossec-logtest允许我们测试事件是如何解码的,以及是否生成了警报。

运行工具/var/os /bin/os -logtest,粘贴以下日志:

Mar  8 22:39:13 ip-10-0-0-10 sshd[2742]: Accepted publickey for root from 73.189.131.56 port 57516

 

$ /var/ossec/bin/ossec-logtest

阶段2中显示的解码器名称将是父解码器的名称。此外,您可以使用“-v”选项来显示有关规则的更多信息:

 

$ /var/ossec/bin/ossec-logtest -v

自定义警报:

     配置示例:

ID T1110与暴力攻击有关。这种技术非常适合以下规则100002,该规则检测暴力破解攻击并生成警报。下面是一个如何将此技术扩展到该规则的例子。

将以下代码行添加到/var/ossec /etc/rules/local_rule.xml:

重启Wazuh,您将完成规则的配置。

如果你想配置一个规则使用两个以上的技术,你可以这样做:

     警报示例:……待更新

(个人学习笔记,若有侵权请联系我删除)

©️2020 CSDN 皮肤主题: 游动-白 设计师:上身试试 返回首页