資訊安全新知分享
NEITHNET 資安實驗室
一般來說,資安人員執行資訊安全的相關分析時,都會從不同的維度去執行檢查跟資料關聯。比方說使用 Endpoint 的資料在 MDR 上面做分析跟 policy 的比對;或是在相關設備做 IOC 情資分析與網路流量資料比對。另外資安人員也經常參照其他的資料做關聯,最常見的就是使用 Firewall 的 Traffic log 來分析。
但是 Firewall 設備品牌眾多,各家都有自己的格式,如果要處理各種格式的 log ,無疑需要消耗相當多的人力與時間,我們今天就來簡單談一下如何處理這些 log。
基本的方式會直接從設備匯出 log 檔案,再透過 SIEM 的輸入功能,把 log 檔案匯入資料庫做分析。但是這樣操作比較沒有效率,所以通常是把設備的 log 透過 Syslog 的傳輸協定,直接傳送給 SIEM,這樣做更直接,而且不用透過檔案轉介。(參考下圖)
![](https://blog.neithnet.com/wp-content/uploads/2022/11/222.jpg)
把資料匯入 SIEM 來分析時,我們經常遇到這些問題,如:
- 分隔符號不固定
比方說 key-value 資料是用 = 做為 key 和 value 分隔符號,但有些設備匯出可能還會有其他分隔符號干擾。
- 資料欄位內有空格
如果 log 格式有使用雙引號當做每個欄位資料的分隔符號,如果有些欄位會出現雙引號,有些則沒有;甚至還有 escape char。
- Key-value資料不固定
Log 資料的 key-value 順序不固定,或是數量不固定。這樣的格式也是比較鬆散,輸入做log剖析都很辛苦。
- 非一般格式化的資料
大部分 log 在設計的時候,都會考慮到使用 log 資料的方便性。但是如果遇到既不是關聯式資料,也不是 JSON 格式時,剖析 log 資料的步驟就會相當繁瑣。
綜合以上的狀況,一般都會盡量讓設備可以匯出良好格式化的 log 資料,比方說:
- Key-Value
- CSV (comma-separated values)
- CEF (for Syslog)
- JSON
我通常會選擇使用 JSON 來當作設備跟 SIEM 中間的傳輸格式。
因為 JSON 格式有以下優點:
- 語法簡單。
- 有支援 schema。
- 剖析速度快。(不論 server 端、前端,還是手持裝置)
那對照第一張圖的流程來說,我們的資料處理就會變成這樣:
![](https://blog.neithnet.com/wp-content/uploads/2022/11/333.jpg)
而在 Preprocess 這個方塊,執行下列動作:
- 去除冗餘資料
像是多出來的標點符號或分隔符號。 - 過濾資料
去蕪存菁。後續不用的資料先過濾掉。 - 格式轉換
比方說把 Key-Value 轉換成 JSON,或是把 CSV 轉換成 JSON。
現在市面上有許多現成的工具,或是 GitHub 上的開源程式,都可以做到上述這些工作。比方說:
- 在 BASH 裡面,使用 AWK, sed 等工具來框選某段文字,或是剖析、分切資料成文字區段。
- 透過程式語言來處理,比方:Python 或是 Golang 來撰寫。(有需要的讀者可以去 GitHub 搜尋CSV, JSON, KV 等關鍵字。)
以常見的開源專案 Elasticsearch 來當作例子,我們最後再加上一個 Filebeat 模組來幫我們把 JSON 檔案讀取進來 Elasticsearch :
![](https://blog.neithnet.com/wp-content/uploads/2022/11/444.jpg)
Filebeat 原生就支援 JSON 格式的檔案,可以直接寫入Elasticsearch。底下是 filebeat.yml 的設定範例,這樣的設定非常簡潔:
![](https://blog.neithnet.com/wp-content/uploads/2022/11/555.jpg)
最後再補充一下, ELK 的系統裡面,當我們還要對 JSON 做處理的時候,以下這幾個是不錯的選擇:
- Filebeat 的 Processor
- 丟給下一階的 Logstash 處理
- 使用 Elasticsearch的 Ingest Pipeline
這三個方案中,以第三個方案最多人應用,因為使用上彈性較高,而且處理起來效率也比較好。如果系統配置上有需求,還可以添加專責的 ingest node 來處理。
以上就是本次的介紹。