具有多個域的大規模 Windows 事件轉發
讓我開始解釋我正在嘗試做的事情：我們在許多 Windows 伺服器上安裝了一個 RMM 工具。它能夠將 Windows 事件日誌發送到中央儲存，但不是以一種有效或可靠的方式。我想在 Windows 伺服器上使用本機 WEF 將特定事件發送到解析任何冗餘雜訊的中央儲存（所以，事件 ID、源和其他特定於事件 ID/源的詳細資訊是什麼，例如使用者名嘗試，工作站/源 IP）。這些伺服器不在同一個域中，並且在地理上分散在全球各地。我知道有很多平台可以做到這一點（例如 Splunk），但它們通常價格過高，並且因為試圖執行這項簡單的任務而變得臃腫無稽。
我最初的想法是在伺服器上配置 WEF，並讓它們將日誌發送到中央伺服器，並設置訂閱來監聽它們，在那裡解析日誌以獲取重要細節，然後使用類似 logstash/filebeat/nxlog 的東西來推送它們到 ELK，以便我們可以控制重要事件（登錄失敗、安全日誌被清除、kerberos priv escalation 漏洞/黃金票創建等）。越深入，我就越意識到這不是 WEF/WinRM 的用途。他們希望您在同一個域中擁有一個本地伺服器來儲存日誌。我能找到的最接近的是這篇文章：https ://blogs.msdn.microsoft.com/canberrapfe/2015/09/21/diy-client-monitoring-setting-up-tiered-event-forwarding/但它針對的是屬於同一域的 AD 中的多個站點。在我們的例子中，中央日誌儲存伺服器將不在任何域上，並且需要接受來自許多其他域的事件日誌。
在我花了幾個小時進行設置之前，我想我會在這裡問 - 這是我應該使用 filebeat 直接從有問題的伺服器解析和推送而不是打擾 WEF 的那種事情嗎？這就是現在的感覺，但我只是想伸出手來確保我沒有忽略一些明顯的事情。
自從我嘗試在 Windows 上進行本機日誌傳送已經有很長時間了，但我確實記得這比我希望的要困難得多。無法想像在域之外，甚至在聯邦之外這樣做。這將是一個logstash答案，因為這就是我所知道的。
您的直覺是正確的，在單個域之外執行此操作的方法是使用Winlogbeat之類的東西從生產者中提取 Windows 事件並將它們傳輸到您可以處理它們的地方。根據您對 Windows 事件操作的熟練程度，您可能更容易在 Windows 事件級別進行過濾（僅將您想要的事件發送到同一伺服器事件日誌，然後指向 WinlogBeat），而不是在節拍級別上進行。
大規模地這樣做意味著考慮權衡。對於大量 Windows 安全日誌生成器，您在攝取時會看到很高的事件率。對於較大的設置，強烈建議在節拍和執行所有標記的 Logstash 層之間使用某種緩衝隊列。有幾個選項，但如果 Redis 和 Kafka 已經在您的基礎架構中，則支持這些選項。
你也可以直接從 beats 發送到 Elasticsearch，但這留下了 Logstash 的很多變革力量。此外，當有幾個節點執行大型批量插入而不是許多節點執行較小的批量插入時，ES 更快地攝取數據（每秒更多事件）。同樣，您可能已經在現場擁有 ElasticSearch 基礎設施/專業知識，這可能不是問題。