如何配置日誌聚合器來驗證數據？
背景：遠端日誌聚合被認為是提高安全性的一種方式。通常，這解決了破壞系統的攻擊者可以編輯或刪除日誌以阻止取證分析的風險。我一直在研究常用日誌工具中的安全選項。
但是感覺有些不對勁。我看不到如何配置任何常見的遠端記錄器（例如 rsyslog、syslog-ng、logstash）來驗證傳入消息是否真正來自聲稱的主機。如果沒有某種策略約束，一個日誌發起者可以代表另一個日誌發起者偽造消息。
rsyslog 的作者似乎對驗證日誌數據發出警告：
最後要注意的是：transport-tls 保護髮送者和接收者之間的連接。它不一定能防止消息本身中存在的攻擊。特別是在中繼環境中，消息可能源自惡意系統，該系統將無效的主機名和/或其他內容放入其中。如果沒有針對此類事物的配置，這些記錄可能會顯示在接收者的儲存庫中。-transport-tls 不能防止這種情況（但它可能會有所幫助，正確使用）。請記住，syslog-transport-tls 提供逐跳安全性。它不提供端到端的安全性，也不驗證消息本身（只是最後一個發送者）。
所以接下來的問題是：什麼是一個好的/實用的配置（在您選擇的任何常用日誌工具中——rsyslog、syslog-ng、logstash 等），它提供了一定程度的真實性？
或者…如果沒有人驗證日誌數據，那為什麼不呢？
–
（除此之外：在討論/比較時，使用RFC 5424 中的一些圖表或術語可能會有所幫助：第 4.1 節：範例部署場景——例如“發起者”與“中繼”與“收集者”）
這是一個很好的問題。
我使用logstash 來完成您所提議的事情。使用 logstash（或 logstash-forwarder）將日誌發送到您的中央收集系統，添加一個 logstash 配置以向消息中添加一個關鍵欄位，其值是每個伺服器唯一的長隨機字元串。
然後在接收端，您可以添加相應的規則來丟棄（或警告）特定主機的密鑰與您對其主機名的期望不匹配的任何消息。
這不是萬無一失的，但它是朝著正確方向邁出的堅實一步。