日志审计--定制规则

目录布局

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

在接收到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.xml和local_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.xml，level就是告警的等级。

然后运行/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：解码器将使用此选项来查找感兴趣的字段并提取它们。

order：regex将提取的值将存储在这些组中。

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，您将完成规则的配置。

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

     警报示例:……待更新

（个人学习笔记，若有侵权请联系我删除）