通過集中日誌記錄來減少安全風險
日誌記錄和日誌分析對於保護基礎設施安全來說至關重要,尤其是當我們考慮到通用漏洞的時候。這篇文章基於我在 FOSDEM'19 上的閃電秀《Let's use centralized log collection to make incident response teams happy》,目的是提高大家對日誌匱乏這種安全問題的重視,提供一種避免風險的方法,並且倡議更多的安全實踐(利益聲明: 我為 NXLog 工作)。
為什麼要收集日誌?為什麼要集中日誌記錄?
確切的說,日誌是寫入磁碟的僅追加的記錄序列。在實際生活中,日誌可以在你嘗試尋找異常的根源時幫助你調查基礎設施的問題。當你有多個使用自己的標準與格式的日誌的異構系統,並且想用一種可靠的方法來接收和處理它們的時候,挑戰就來臨了。這通常以元數據為代價的。集中日誌記錄解決方案需要共性,這種共性常常會去除許多開源日誌記錄工具所提供的豐富的元數據。
日誌記錄與監控匱乏的安全風險
開源 Web 應用程序安全項目 (OWASP)是一個為業界貢獻了許多傑出項目(包括許多專註於軟體安全的工具)的非營利組織。OWASP 定期為應用開發人員和維護者報告最危險的安全挑戰。在最新一版《10 項最嚴重的 Web 應用程序安全風險》中,OWASP 將日誌記錄和監控匱乏加入了列表中。OWASP 警告下列情況會導致日誌記錄、檢測、監控和主動響應的匱乏:
- 未記錄重要的可審計性事件,如:登錄、登錄失敗和高額交易。
- 告警和錯誤事件未能產生、產生不足或不清晰的日誌信息。
- 日誌信息僅在本地存儲。
- 對於實時或准實時的主動攻擊,應用程序無法檢測、處理和告警。
可以通過集中日誌記錄(例如,不僅將日誌本地存儲)和結構化日誌數據以進一步分析來緩解上述情形(例如,在告警儀錶盤和安全套件中)。
舉例來說, 假設一個 DNS 查詢會導向名為 hacked.badsite.net 的惡意網站。通過 DNS 監控,管理員監控並且主動的分析 DNS 請求與響應。DNS 監控的效果依賴於充足的日誌記錄與收集來發現潛在問題,同樣也依賴於結構化 DNS 日誌的結果來進一步分析。
2019-01-29
Time (GMT) Source Destination Protocol-Info
12:42:42.112898 SOURCE_IP xxx.xx.xx.x DNS Standard query 0x1de7 A hacked.badsite.net
你可以在 NXLog 社區版 中自己嘗試一下這個例子,也可以嘗試其他例子和代碼片段。 (再次聲明:我為 NXLog 工作)
重要的一點:非結構化數據與結構化數據
花費一點時間來考慮下日誌數據格式是很重要的。例如,讓我們來考慮以下日誌消息:
debug1: Failed password for invalid user amy from SOURCE_IP port SOURCE_PORT ssh2
這段日誌包含了一個預定義的結構,例如冒號前面的元數據關鍵詞(debug1
)然而,餘下的日誌欄位是一個未結構化的字元串(Failed password for invalid user amy from SOURCE_IP port SOURCE_PORT ssh2
)。因此,即便這個消息是人類可輕鬆閱讀的格式,但它不是一個計算機容易解析的格式。
非結構化的事件數據存在局限性,包括難以解析、搜索和分析日誌。重要的元數據通常以一種自由字元串的形式作為非結構化數據欄位,就像上面的例子一樣。日誌管理員會在他們嘗試標準化/歸一化日誌數據與集中日誌源的過程中遇到這個問題。
接下來怎麼做
除了集中和結構化日誌之外,確保你收集了正確的日誌數據——Sysmon、PowerShell、Windows 事件日誌、DNS 調試日誌、ETW、內核監控、文件完整性監控、資料庫日誌、外部雲日誌等等。同樣也要選用適當的工具和流程來來收集、匯總和幫助理解數據。
希望這對你從不同日誌源中集中日誌收集提供了一個起點:將日誌發送到儀錶盤、監控軟體、分析軟體以及像安全性資訊與事件管理(SIEM)套件等外部源。
你的集中日誌策略會是怎麼樣?請在評論中分享你的想法。
via: https://opensource.com/article/19/2/reducing-security-risks-centralized-logging
作者:Hannah Suarez 選題:lujun9972 譯者:leommxj 校對:wxy
本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive