PowerMax 9.2 的 Unisphere 遠端安全系統記錄
Zusammenfassung: PowerMax 專用的 Unisphere 安全 Syslog 如何使用以及何時使用。設計和行業標準
Symptome
系統記錄歷程記錄
系統日誌是由埃裡克·保羅·奧爾曼(生於 1955 年 9 月 2 日)於 1980 年代開發的。
Eric 是一位美國計算機程式師,他在 1970 年代末和 1980 年代初在加州大學伯克利分校開發了 Sendmail 及其前身 Delivermail。1998年,Allman和Greg Olson共同創立了Sendmail,Inc.公司。MTA 消息傳輸代理使用的日誌記錄格式,稱為系統日誌。系統日誌最初僅由Sendmail使用,但最終成為其他不相關程式用於日誌記錄的非官方標準格式。後來,這種格式在 2001 年由 RFC 3164 正式發佈;但是,原始格式已被最新修訂版 RFC 5424 淘汰。
互聯網工程任務組
互聯網工程任務組 (IETF) 是一個開放標準組織,它制定和推廣自願性互聯網標準,特別是由互聯網協定套件 (TCP/IP) 組成的標準。
它沒有正式的成員名冊或成員要求。所有參與者和經理都是志願者,儘管他們的工作是由僱主或贊助商資助的。
互聯網架構委員會(IAB)負責監督IETF的外部關係以及與RFC編輯器的關係。IAB為互聯網發展提供長期技術指導。IAB還共同負責IETF行政監督委員會(IAOC),該委員會負責監督IETF行政支持活動(IASA),為IETF提供後勤支援等。
IAB還管理互聯網研究任務組(IRTF),IETF與該工作組具有多個跨組關係。
指導小組
互聯網工程指導小組 (IESG) 是一個由互聯網工程任務組 (IETF) 主席和區域主任組成的機構。它提供互聯網標準的最終技術審查,並負責IETF的日常管理。它接受對工作組決定的上訴,IESG決定在標準軌道上推進檔。
系統記錄通訊協定
Syslog utilizes three layers o "syslog content" is the management information contained in a syslog message. o The "syslog application" layer handles generation, interpretation, routing, and storage of syslog messages. o The "syslog transport" layer puts messages on the wire and takes them off the wire. o An "originator" generates syslog content to be carried in a message. o A "collector" gathers syslog content for further analysis. o A "relay" forwards messages, accepting messages from originators or other relays and sending them to collectors or other relays. o A "transport sender" passes syslog messages to a specific transport protocol. o A "transport receiver" takes syslog messages from a specific transport protocol. Diagram 1 shows the different entities separated by layer. +-------------------------+ +----------------------+ | content | | content | |------------------------| |----------------------| | syslog application | | syslog application | | | | | (originator, | | | | (collector, relay) |------------------------| |----------------------| | syslog transport | | syslog transport | (transport sender, | | | | (transport receiver) +------------------------+ +----------------------+ ^ ^ | | -----------------------------
系統記錄是如何傳輸的?
有兩種常見的方法可傳送系統記錄訊息。儘管 RFC 5424 要求所有系統日誌實現必須支持通過 TCP 進行的加密 TLS 網路傳輸,但大多數系統日誌消息仍使用較舊的 UDP 方法傳遞。在 UDP 版本中,消息只是放入 UDP 數據包的數據部分,並通過 UDP 連接埠 514 發送到伺服器。每條消息通常適合單個數據包。UDP 是無狀態的,會話較少,因此沒有確認。數據包被發送到網路。這有一個明顯的問題,即任何類型的網路問題都可能阻止數據包的傳遞,在這種情況下,您可能不知道網路已關閉,因為它無法告訴您。這也意味著有時重要的數據包可能會在傳輸過程中丟失或損壞。
基本原則
以下原則適用於系統日誌通信:
o 系統日誌協定不提供消息傳遞確認。儘管某些傳輸可能提供狀態資訊,但從概念上講,系統日誌是一種純單純形通信協定。
o 發起方和中繼可以配置為將相同的消息發送到多個收集器和中繼器。
o 發起方、中繼器和收集器功能可能駐留在同一系統上。
最低要求傳輸對應
此規範的所有實現都必須支援基於 TLS 的傳輸,如 [RFC5425] 中所述。
此規範的所有實現還應支援基於 UDP 的傳輸,如 [RFC5426] 中所述。建議此規範的部署使用 TLS 型傳輸。
系統日誌消息的自由形式性質是系統日誌最大的優勢,但它也是系統日誌最大的問題。解析日誌(包括來自不同供應商的數十個不同系統的事件)並同時理解它們非常困難。哪些消息代表哪些功能?哪些代表關鍵事件,而不僅僅是資訊性消息?
為了處理這些問題,系統日誌協定(在 RFC 5424 中定義)為這些自由格式的消息提供了稱為“設施”和“嚴重性”的特殊欄位。
(請注意,RFC 5424 是系統日誌的標準,但並非所有系統日誌實現都符合 RFC 5424。系統日誌協議已經存在了很長時間,並且仍然有一些標準前實現仍在使用中。
系統記錄的安全性要求
系統記錄訊息可能會經過數個躍點,以到達預期的收集器。發起方、中繼方或接收方可能不信任某些中間網路,因為網路位於不同的安全域中,或者與發起方、中繼或收集器處於不同的安全級別。另一個安全問題是發起方、中繼或接收方本身位於不安全的網路中。
為了系統記錄安全性,有幾種威脅需要解決。
主要威脅包括
o 假面舞會。未經授權的傳輸發送方可能會向合法的傳輸接收方發送消息,或者未經授權的傳輸發送方可能會試圖欺騙合法的傳輸發送方向其發送系統日誌消息。
o 修改。傳輸發送方和傳輸接收方之間的攻擊者可以修改傳輸中系統日誌消息,然後將該消息轉發到傳輸接收方。這種修改可能會使傳輸接收方誤解消息或導致其以不良方式行事。
o 披露。未經授權的實體可能會檢查系統日誌消息的內容,從而獲得對資訊的未經授權的訪問。系統記錄訊息中的某些資料是敏感的,可能會對攻擊者有用,例如授權管理員或使用者的密碼。
次要威脅是
o 消息流修改。攻擊者可以從一系列消息中刪除一條或多條系統日誌消息、重播消息或更改傳遞順序。系統記錄通訊協定本身並非以訊息順序為基礎。但是,系統日誌消息中的事件可能在語義上與其他消息中的事件相關,因此消息排序對於瞭解事件序列可能很重要。
下列威脅被認為對系統記錄不太重要,因此不會在本文件中處理:
o 拒絕服務
o 流量分析
使用 TLS 保護系統記錄
TLS 可作為安全傳輸,以對抗上述對系統記錄的所有主要威脅
o 保密以反擊消息內容的披露。
o 完整性檢查,以逐跳方式計數器對消息的修改。
o 伺服器或相互身份驗證以對抗偽裝。
注意:此安全傳輸 (即 TLS) 僅以逐跳方式保護系統日誌傳輸,與系統日誌消息的內容無關。特別是,傳輸發送方的經過身份驗證的身份(例如,證書中的消費者名稱)不一定與系統日誌消息的主機名字段相關。需要驗證系統記錄訊息來源時,可以使用 [SYS-SIGN]。
Ursache
上圖顯示 PowerMax 在 Unisphere 中設定安全系統記錄的畫面。