日誌審計--定製規則

目錄佈局

規則集資料夾結構如下所示:

在接收到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，您將完成規則的配置。

如果你想配置一個規則使用兩個以上的技術，你可以這樣做:

     警報示例:……待更新

（個人學習筆記，若有侵權請聯絡我刪除）