在第一篇文章我們有概略的介紹了Wazuh，架設完成後大家在介面上也可以看到很多模組、功能、項目，因為Wazuh算是挺強大的，對於初次使用來說，確實是有些眼花撩亂。不過實際上也不會太複雜，就讓我們來一一了解吧。

因為我們不是業務、PreSales （無貶意，不要誤會）。身為工程師，身為技術人員，應該要有技術實驗精神。至少要做個簡單的POC，來確認看看能不能達到產品宣稱的功能。當然更佳的情況，是已經有預想好額外的場景和威脅，可以測試看看該產品是否能達到你預期的效用，成功檢測到設想的威脅。

接下來文章來帶大家手把手測試與確認Wazuh的檢測功能。同時從這個POC過程也可以讓我們更加了解Wazuh功能與運作方式。（如果你是有打算實際派上用場的，建議也這一段可以實際跟著操作進行！因為確實我的友人曾經發現過，有某些rule是POC失敗的，設定看起來都正常卻沒有觸發alert）

POC之前，這邊先從我自己的角度切入，提一些想法。我在導入Wazuh的時候，有從官方看了他的功能介紹。從Use cases的列表我們可以看到有10個項目

https://documentation.wazuh.com/4.3/getting-started/use-cases/index.html

首先我注重的有四個項目，我希望四個項目是有效果的，分別是：

• Log data analysis
• File integrity monitoring
• Rootkits detection
• Container security

接著四個項目是我沒那麼重視的，可能會派上用場，可能考慮作為輔助或是未來啟用。

這四個輔助目標為：

• Active response
• Configuration assessment
• System inventory
• Vulnerability detection

兩個項目另外還有兩個是我不在意的：

• Regulatory compliance
• Cloud security

根據上面描述，我會針對前面四個主要目標POC

Log data analysis

第一個是要進行Log data分析，這個其實就是SIEM的主要功能。
wazuh agent會抓取系統上的log然後傳送到wazh manger進行分析，
如果有匹配到rule則會觸發alert，當alert的level是在一定等級以上，則會發送到indexer
我們在indexer+dashboard (elasticsearch+kibana)的地方就可以查看與搜尋到該alert資訊
我們來做幾個簡單的測試，我利用sudo查看shadow，
接著我們到wazuh的dashboard查看，馬上就會發現有一筆alert。
並且我們可以知道location為/var/log/auth.log，
也就是表示這個事件被觸發，是解析該agent上面auth.log得到的結果

sudo cat /etc/shadow

接著我們來嘗試ssh登入，從其他台主機來針對我們的nginx主機進行ssh登入
同樣是可以得到PAM: User login failed.的事件
位置也是在 /var/log/auth.log

ssh root@192.168.101.142

所以呢…Log data analysis總之是正常可以work的
那查看alert事件，除了在agent的地方查看Security以外，
還有一個地方式可以看到全部的event。
實際上我在實務監控的過程，更常在那邊進行查看與搜尋。

在面板上的左上的三條線點開，選擇discover，
這邊我們可以看到所有完整的alert。

這邊可以看到剛才的事件，可以點開任一個事件，
查看一下事件的所有欄位。

跟大家先說幾項值得注意的事情，
第一個就是，並非所有的事件都具有一樣的欄位，這個其實是很合理。
並且每個log或是不同的事件，會產生的log形式與內容不同
所以欄位就可能不同。
但是有些欄位是一定有的，例如：

• agent.id
• agent.name
• rule.id
• rule.description
• rule.level
• timestamp

這幾項當然是很重要的資訊～
再來還有一些項目也是滿重要的，例如：

• full_log 這個是它取得的原始資料
• location 取得資料的位置
• data.command 觸發該事件的使用者執行的指令
  還有像是來源使用者、目的使用者、來源IP、目的IP
  不過這些欄位並非是所有的alert都會有的欄位

第二個，還記得我們剛剛利用查看/etc/shadow所觸發事件的POC嗎
雖然我特別挑選了/etc/shadow這個重要的檔案
但是我們可以注意一下那個事件的描述
這個事件觸發的規則原因是因為我們使用了sudo被記錄在log當中
所以要理解一下這個觀念跟這個事件
不是因為shadow這個檔案本身被做了甚麼事件而觸發alert
而是因某個使用者使用了sudo這個操作而觸發alert

第三個也是最重要的事情了
Log data analysis 光名稱就爆雷給你了
他就是基於log的分析，所以沒有被記錄在log的事情，
就表示沒有監控到了，也就不會有alert。
不過除了Log監控分析以外wazuh也是有其他功能，這個後面提。
那基於Log的檢測，當然要找到LOG的檔案就很重要，
要知道到底有推送哪一些LOG去給Server分析才行。
如果要查看有分析哪些檔案，
可以從Agent主機上面的路徑/var/osssec底下的ossec.conf查看到。

<localfile>
    <log_format>syslog</log_format>
    <location>/var/ossec/logs/active-responses.log</location>
  </localfile>

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/auth.log</location>
  </localfile>

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/syslog</location>
  </localfile>

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/dpkg.log</location>
  </localfile>

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/kern.log</location>
  </localfile>

那關於我們剛剛安裝的nginx呢
其實可以用一些工具去掃我們的nginx 80看看
例如我們使用nikto來去掃我們的Nginx
https://github.com/sullo/nikto
是不會觸發events的

雖然nginx有log
但因為agent根本沒有將nginx的log給推送到wazuh進行分析
所以當然不會有events

OK 總之我們目前是確定Log data analysis是會work的
實際上這個功能也是wazuh最主要，產生最多alert的功能 (預設情況下可能會是這樣)

File integrity monitoring

接下來我們要來測第二個功能，
是監控主機上的檔案內容或檔案權限是否有更動。

https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/fim-configuration.html

預設的設定如下，可以看到會去檢測/etc, /usr/bin, /usr/sbin, /bin, /sbin, /boot等幾個重要的目錄
但同時也會忽略一些檔案，例如/etc/mtab, /etc/mail/statistics

官方的說法

The check_all attribute of the directories option allows checks of the file size, permissions, owner, last modification date, inode, and all the hash sums (MD5, SHA1, and SHA256)

預設就會去檢查檔案大小/權限/擁有者/修改時間/雜湊值的變化
預設的掃描時間是每12小時掃描一次
Scan的時間可以用frequency來設定多久掃描
也可以用scan_time跟scan_day來設定例如每周日的早上十點掃描
也可以設定real-time來掃描 (僅限於針對directories)
還有一種whodata是用來取代real-time一種方法，這種方法也是real-time並且會多一個who-data的資訊，這個需要額外有設定Linux Audit或是Windows SACL才可用

如同前面提到，設定檔如果有用遠端管理，遠端的內容根本地有衝突的話會覆蓋掉Agent本地的ossec.conf設定，所以我們可以從遠端用中央方式去設定我們監控的目錄

另外是，預設的alert_new_files是啟用yes的, 也就是如果有出現新檔案, 也會通知

對於完整性監控的查看，
可以從Dashboard的Integrity monitoring查看
Inventory可以看到有監控的檔案，還有觸發的事件

這邊我們來做三個POC，測試看看是不是會檢測成功
這邊….沒有截圖，因為原本POC在公司測的，不能貼上截圖XDD
架設的Demo機器需要等待，懶得改掃描時間又不想等
(有機會的話... 再補圖)

第一個POC: 檔案內容修改
針對有監控的檔案 /etc/networks 進行修改
偵測結果 → 成功
本質上是透過size跟hash
所以沒辦法直接知道有哪些內容被改了

第二個POC: 檔案權限修改
將/etc/ufw/user.rules的權限修改將u+r
偵測結果 → 成功
可以直接觀察出permission修改前後差異

第三個POC: 新增檔案
偵測結果 → 成功
因為事件是檔案新增，所以滿單純的
但仍然有個問題，是不會知道新增的內容是甚麼
只知道有個檔案被新增

以上三個根據檔案做的POC都是有成功檢測到
不過沒有在Security events顯示，是在Integrity monitoring裡面的event

另一個需要探討的問題是檢測的頻率，目前預設是12小時掃描一次
按照理論來說，如果在兩次掃描之間更動，掃描時復原，應該會掃不出來。
也就是說如果駭客新增了一個檔案，但是在下次掃描之前就刪掉，
integrity monitoring應該不會發現有這件事情（尚未實際測試過這個想法）

如果要更安全，是可以嘗試調整頻率或是設定為即時。
但有幾個問題需要考量，首先是性能問題，這樣是否會讓agent占用太多資源在掃描，
還有就是這樣是否會導致警報疲勞，會有過多的誤報。

今天內容就先到這邊，明天一樣是POC