今天的文章滿特別的
因為這幾天稍微規劃跟確認了整個系列文的走向跟內容
所以直接把這篇文章當成目錄文章XD

順便解釋和分享一下我的一些想法
大家在學習或是研究資安的這條路上
其實根據個人的領域、職位、程度、興趣，都會有不同的需求
可以釐清自己所需，去找到適當的學習資源
在廣度與深度之間，在理論和實作之間，取得良好的平衡

例如，從比較High Level (抽象) 排序到 Low Level (具體)

1. 資安治理 / 資訊安全管理 ( ISO 27001, PCI DSS, NIST SP 800-53 …)
2. 了解特定領域或是大項目的內容，例如了解紅隊演練、軟體安全開發、SOC在幹嘛
3. 了解特定領域或是項目的規劃或是流程，知道SOC的規劃與流程
4. 對於特定技術或是小項目具有了解或是入門實作能力
5. 對於特定技術、工具具備熟悉的知識和實作能力

以上內容沒有任何誰好誰壞，哪種比較厲害
畢竟人的時間是有限的，所以多少要能取捨去根據需求找到適合內容
當然也建議可以的話盡可能多方嘗試，了解不同內容
不要僅停留在某一個地方，除非你已經目標很明確可能另外了XD

不要說只知道一些工具，然後安裝了之後也不熟怎麼用
或是只熟一套工具，其他的有甚麼類似或可以整合的也不清楚
或是知道一些工具，但沒有整體規劃概念和格局，會推薦某套工具只是單純知道這套
或是在規劃跟管理階段，不知道技術跟工具實作原理，規劃跟設計的架構存在問題

以下是本系列文章的目錄
(連結會慢慢補上)

一個人的藍隊

• SOC visibility triad & Observability
  • SOC 鐵三角 (SOC visibility triad) 與 可觀測性三本柱 (Observability)
• Cyber Defense Matrix
  • 透過 CDM (Cyber Defense Matrix) 框架規劃藍隊防禦策略
• Wazuh XDR & SIEM
  • 一個人的藍隊－甚麼是Wazuh？打造你的鷹眼
  • 第一次架設Wazuh就上手
  • Wazuh Agent安裝與介面查看
  • Wazuh 架構
  • Wazuh 的管理和設定
  • Wazuh 檢測能力POC：Part 1
  • Wazuh 檢測能力POC：Part 2
  • Wazuh 檢測能力POC：Part 3
  • Wazuh 自訂規則撰寫及關聯分析
  • Wazuh Log路徑位置指定與agent多重group除錯
  • 管理與刪除 Agent (順便安裝Mongodb)
  • Wazuh Decoder與監控容器日誌(監控Mongo)
  • Wazuh Change Password 這個坑
  • Wazuh 整合 Telegram 告警通知
  • Anti-flooding mechanism 防止洪水機制
  • Wazuh 備份與升版
  • Wazuh agent 驗證機制
• OpenVAS (Greenbone)
  • OpenVAS 開源弱點檢測平台架設與架構說明
  • OpenVAS 弱點掃描設定與檢測執行
• OpenCVE
  • OpenCVE 開源弱點訂閱管理平台架設
  • OpenCVE 資訊說明，從 CVE、NVD 到 CVSS
• OpenCTI
  • OpenCTI 開源威脅情資平台架設與介紹
  • OpenCTI 連接器 (Connectors) 安裝
  • OpenCTI 使用方式：從案例著手
• Infrastructure as Code
  • 利用 IaC 來進行合規設定，以 Ansible 為例
• Compliance as Code
  • Compliance as Code 入門，利用 Inspec 進行合規檢查
• SSH
  • SSH 防禦：把最基本的做好
• Cloud Security
  • 利用 Prowler 進行 AWS 雲端合規檢查

Anti-flooding mechanism 防止洪水機制

好了~ 今天要來談 Anti-flooding mechanism 防止洪水機制

先簡單介紹甚麼是 Flooding 洪水

以攻擊來說的話，"洪水攻擊"（Flooding Attack）是指攻擊者試圖通過向目標系統或網路發送大量的請求、數據或流量，以耗盡目標資源，從而導致服務不可用或性能降低的攻擊行為。這種行為的目標是讓目標系統無法正常工作，使其難以提供正常的服務。

因為我們這邊談的是 Wazuh SIEM 的 Flooding，所以關注的就是 Log Flooding。當我們所監控的 Agent 上面 Log 太多怎麼辦？短時間內大量過多的 Log 被推送到 Server 上面，可能會造成：

• 儲存空間被占用：如果沒有設定防洪水機制或是主機的其他安全防護機制，從大量的 Agnet 大量的事件被推送到 Server上，會造成 Server 上面空間快速大量地被占用，最糟糕的情況可能使容量超載系統不可用。
• 性能資源被消耗：一樣的道理，Server 端短時間接受到來自多方的大量 Log，可能會需要消耗大量資源去進行處理，可能會使性能下降，甚至系統崩潰‧
• 干擾及混淆：當大量的事件被觸發時，可能會導致許多誤判的事件反而造成要分析真實的惡意行為變得更困難。

這種 Log Flooding 的場景，有可能是攻擊者的行為，但也有可能是正常的行為，有時間一些資料庫服務、大量管理或監控的服務（例如 K8S、Zabbix、LiberNMS 等），甚至是其他的排程或是應用程式，雖然是正常的行為，都有可能造成。

只要短時間內有大量的寫入Log的行為，或是其他EDR有監控到的行為，都有可能造成。這邊要特定提醒一下，Wazuh Agent會把監控的LOG檔案裡面所有的內容都推送到Server去分析，所以不管你這個內容到底有沒有觸發到Wazuh Alert Rule或是Decoder，每一行都還是會被推送過去。這當然也是很合理的吧，畢竟你沒到Server分析，我怎麼知道這一筆LOG是有沒有問題的。

不過也因此，這個Flood的重點是Log的內容數量，跟Decoder和Rule無關，不會因為你去調整了Rule，原本發生的Flood事件就不會發生了。

這個也牽扯到我們之前討論過的，究竟是要我日誌就開到爆，還是更精準的紀錄。有些服務，例如資料庫好了，如果你開啟到Debug等級的日誌，當有多數使用者在使用服務時，可能會很容易就出現Flood的情況。

好，回到 Wazuh 這個服務，雖然 Flood 感覺很可怕難搞（確實是難搞）。但 Wazuh 強大的先幫我們把這個問題算是解決了唷，他本身有提供 Anti-flooding mechanism 防止洪水機制。

可以參考以下官方文件和圖

https://documentation.wazuh.com/current/user-manual/agents/antiflooding.html

這邊白話簡單翻譯

主機上面安裝的 Agent，他每秒最多就是傳送 500 個事件到 Server，然後如果來不及傳送的就到buffer 排隊（queue）。這個排隊的人潮最多就是 5000 個，超過 5000 個的就捨棄（drop）。

排隊人潮到 90% 的時候，他就會發送一個 alert，告訴你這台主機目前排隊的人快滿了唷。排隊滿人的時候也會發一個 alert，告訴你目前排隊人滿了，所以待會有些事件可能會被捨棄。

這個防洪水機制個人覺得是滿讚滿貼心的，至少你不用太擔心 Server 硬碟突然爆掉或是性能崩潰 （不過還是要視你的伺服器資源而定）。不過還是要注意，如果排隊人滿了，還有事件在還沒消化完之前進來，Agent 就會把它捨棄掉，這樣的情況仍然是有可能造成真實的惡意事件被捨棄，根本沒有被拋到 Server 端進行分析。

所以這個 Buffer 當然是可以讓你調整的，如果你的 Server 資源夠力，這個 Log 你也不想忽略掉，是可以把 Client buffer 去增加的，反之亦然。

可以在client的ossec.conf去調整

設定的格式如下，這邊的5000跟500就是預設的值

<client_buffer>
  <!-- Agent buffer options -->
  <disabled>no</disabled>
  <queue_size>5000</queue_size>
  <events_per_second>500</events_per_second>
</client_buffer>

這個設定因為是在client ossec.conf
如同我們之前多次提及的
我們也可以在Server端集中配置，透過Server上的agent.conf來設定