接下來這個部分，我們要來談及一個很重要的核心內容
而且，並不是對於Wazuh來說很重要
而是從SIEM，從藍隊防禦，從安全的角度來說非常重要的部分
就是撰寫警告的規則

這邊接下來提到的許多部份，我想不會是「絕對正確」的觀念
多數是我主觀的一些想法，供大家做為參考

先談談日誌(Log)跟警告(Alert)這件事情吧
大致上可以把人的想法分成兩種
第一種：就是紀錄跟觸發，需要的／想要的／可能需要或想要的....
第二種：我全都要！給我他媽的加爆，log有多少收多少，alert有多細就收多細

以我自己的想法，我認為一個好的警告
不應該有過多的雜訊與過量的警報，所以我的第一步是選擇先收斂
把一些覺得沒甚麼用，調整過忽略或是針對特定條件忽略

另外，請記住一件事情
有限的資源以及人力
所以有時候Log跟Alert可能也是不能加爆的原因之一XD

先前聽大佬birdman的一場演講分享
我覺得講得很有道理
內容也是提到EDR還是SOC那邊遇到誤判誤爆的數量非常多
當然，我也不想誤導大家
他提的是一個問題點
那我這邊自己是用了粗暴的方式解決XDDDDD

然後，我們來談一下每個事件Event (或是要稱為Alert也可以)
我認為可以從兩個角度切入來去判斷
首先是安全異常，第二個是行為異常

當然這是一種比較籠統的概念說法而已
舉個例子來說說甚麼是安全異常
一個被觸發的告警，從pattern上來看是否具有安全相關的影響特徵
包含惡意Payload，或是相對機敏跟相對重要的檔案操作
例如
今天觸發了一個警告 Web Server 的 log 有出現

../../../../../../etc/passwd

顯然是有人想進行LFI / Path Traversal 的攻擊
或是有人去修改了/etc/passwd跟/etc/shadow的檔案
從Event本身可以直接觀察出可能跟安全性相關

那如果是

sudo echo 'test' > test

docker ps -a

這種可能也都會出現events
但看起來並沒有任何漏洞利用或修改設定，撈取機敏資料的行為
就跟安全異常無關

接著談談我想說的第二個面向
甚麼是行為異常
Log顯示的是某個開發團隊同事的帳號在半夜三點，執行了docker ps -a
顯然這個在我們公司，不太像是正常的行為　（其他公司我就不知道了XDDD）
簡單來說，沒有甚麼安全特徵，但當人事時地物不太對勁的，就是行為異常
這種也必須要非常注意
畢竟駭客也是可以有機會取得員工帳號，也是可以使用正常合法軟體進行攻擊

聊完準備開始實作看Wazuh的規則寫法
基於我上面所提到的
我在撰寫規則時，首先就是把不需要的Rule都忽略

我們先寫完第一條，然後開始解釋欄位
以及rule可以做到哪些事情
語法跟可以用的欄位，官方有提供
https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html

重要
建議有需要更改rule，都請自己新增新的rule
不要去修改wazuh原本的rule,

忽略規則/誤判過濾

第一個

<rule id="100009" level="0">
  <if_sid>5104</if_sid>
  <description>Suppression Interface entered in promiscuous(sniffing) mode.</description>
  <group>suppression</group>
</rule>

以上的rule，rule id是100009
自定義的規則
我們的id要從100001開始起跳才行
表示的是如果rule 5104觸發，
則觸發100009這條rule，並且level為0
透過將level重寫為0這樣的方式，就可以忽略掉5104這條rule id
因為等級被設定為0
而我們的event是level為3以上才會發出警告
description 就是你對這條規則的描述而已，可以自由發揮
group 是指你要將這個alert歸類在哪一個group
對於這種忽略的，我習慣採用suppression
但實際上就是ctrl+f搜尋時好找而已
畢竟這條rule的事件不會出現在dashboard當中

接著針對一些誤判

<rule id="100030" level="0">
  <if_sid>31101</if_sid>
  <srcip>10.10.10.10</srcip>
  <match>404 '-' "Zabbix</match>
  <description>Suppression Zabbix 404.</description>
  <group>suppression</group>
</rule>

假設我們內網有一台zabbix 10.10.10.10
因為該rule為誤判
但是並非所有該rule id都是誤判
這時候我們就需要透過更多的條件判斷來排除它
以這邊寫法為例 如果觸發了event rule 31101
full log當中有match到特定的字串Zabbix
並且來源的IP是10.10.10.10
就將這個event設為rule id 100030，且level 0

另一個範例

<rule id="100031" level="0">
  <if_sid>5402</if_sid>
  <field name="pwd">/home/zabbix</field>
  <field name="command">^/usr/sbin/dmidecode</field>
  <description>Suppression zabbix periodically execute command.</description>
  <group>suppression</group>
</rule>

這邊則是針對規則5402進行抑制
透過的欄位data.pwd跟data.command這兩個欄位
以這邊寫法為例
data.pwd當中有match到特定的字串/home/zabbix
並且data.command是以/usr/sbin/dmidecode開頭
就將這個event設為rule id 100031，且level 0

這邊必須要多說明一下
match一定是最不嚴謹的
但不管是直接使用match
還是針對欄位字串內容的過濾
盡可能都還是要用regex讓字串完全符合比較好
避免發生被繞過沒有偵測到的情況

例如我忽略了/usr/sbin/dmidecode這個指令
但如果駭客的指令是
/usr/sbin/dmidecode | cat /etc/passwd
這一串log裡面因為包含了我要忽略的內容
所以會整個被忽略

不過... 畢竟EDR不像是外層防護設備
本質上攻擊者在安裝agent的主機觸發了行為
也不會被阻擋
所以我覺得要繞過應該也很難
要也是直接先關掉，或是整個全繞過(?

基於特定時間

然後Wazuh也可以基於特定時間來進行規則的觸發
例如規則17101設定6 pm - 8:30 am有成功更入才發出告警

<rule id="17101" level="9">
  <if_group>authentication_success</if_group>
  <time>6 pm - 8:30 am</time>
  <description>Successful login during non-business hours.</description>
  <group>login_time,pci_dss_10.2.5,pci_dss_10.6.1,gpg13_7.1,gpg13_7.2,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,nist_800_53_AU.6,</group>
</rule>

時間範圍與發生頻率 if_matched_sid

if_matched_sid內建的的一種寫法
在120秒內如果有觸發10次 30315事件，則觸發30316事件

<rule id="30316" level="10" frequency="10" timeframe="120">
  <if_matched_sid>30315</if_matched_sid>
  <same_source_ip />
  <description>Apache: Multiple Invalid URI requests from same source.</description>
  <mitre>
    <id>T1499</id>
  </mitre>
  <group>gdpr_IV_35.7.d,hipaa_164.312.b,invalid_request,nist_800_53_AU.14,nist_800_53_AC.7,nist_800_53_SI.4,pci_dss_10.2.4,pci_dss_11.4,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
</rule>

升降級

接下來是如果我們要針對某個rule進行升級或是降級
注意這邊的寫法是rule id是不變的用法
首先把原本的複製過來
然後修改等級加上overwrite
https://documentation.wazuh.com/current/user-manual/ruleset/custom.html#changing-an-existing-rule

這邊是把5402等級改成8
這個也是滿好用的，因為前面有提到預設alert等級大於3會送到index
然後還可以設定等級多少要發送通知(例如信件通知，或是外掛模組送到telegram, google chat, line)
對於通知來說，調整這個alert level就重要了
畢竟你總不希望收到一堆垃圾通知

<rule id="5402" level="8" overwrite="yes">
    <if_sid>5400</if_sid>
    <regex> ; USER=root ; COMMAND=| ; USER=root ; TSID=\S+ ; COMMAND=</regex>
    <description>Successful sudo to ROOT executed.</description>
    <mitre>
      <id>T1548.003</id>
    </mitre>
    <group>pci_dss_10.2.5,pci_dss_10.2.2,gpg13_7.6,gpg13_7.8,gpg13_7.13,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,nist_800_53_AC.6,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
  </rule>

特定欄位關鍵字Match建立新的Rule

還有當然就是建立一個全新的規則
這邊是如果log被JSON這個decode給觸發
然後JSON解析過後
有一個欄位是ctx，並且.+表示符合全部
也就是只要有欄位ctx不管內容是甚麼，ctx這一行就符合
但還有另一個條件，是有欄位s
必且s欄位的內容是W
符合以上兩個條件，就觸發rule id 100199 然後level為0
當我們要建立一整個系列的規則時
通常會將第一項level設為0 (其實可以看看wazuh內建規則也都這樣搞)
其實第一個只是要讓他有觸發一個rule id
接著後面才去寫rule，用if_sid來關聯

  <rule id="100199" level="0">
    <decoded_as>json</decoded_as>
    <field name="ctx">\.+</field>
    <field name="s">W</field>
    <description>MongoDB JSON WARN messages.</description>
    <group>mongodb</group>
  </rule>

例如
以下我們建立一個rule id 100200
當觸發規則100199
並且觸發的100199 Log裡面
有個欄位是data.msg，內容有match到Access control
就觸發這條100200

  <rule id="100200" level="6">
    <if_sid>100199</if_sid>
    <field name="msg">Access control</field>
    <description>MongoDB: Access control Warn.</description>
    <group>mongodb</group>
  </rule>

今天的內容，其實是真的還滿重要的
寫規則的時候有滿滿滿的想法
但寫文章之後，總覺得好像有點不夠充實XD