使用 WEF 和 WEC 进行集中式日志收集的基本知识

上周我们介绍了事件日志记录的基础知识：确保所有系统都能记录其上发生的重要事件或活动。本周我们将介绍如何在 Windows 事件收集器 (WEC) 服务器上集中收集这些事件日志，然后将所有日志转发到 Elastic Security。

WEF 与 WEC

现代版本的 Windows 包含实现 WS-Management (WSman) 协议的 Windows 远程管理 (WinRM) 服务，此外，这些功能都是 Windows 管理工具 (WMI) 的一部分。WinRM 的一个组成部分是 Windows 事件转发 (WEF) 服务，因此需要启用 WinRM 及相关功能。WEF 可以将 Windows 事件日志转发到运行 Windows 事件收集器 (WEC) 服务的 Windows 服务器上。

转发有两种模式：

1. 源端发起：WEF 服务连接到 WEC 服务器
2. 收集器发起：WEC 服务连接到 WEF 服务

两者均使用 WSman 转发日志，并且需要运行 WinRM。

搭建 WEF 和 WEC 平台会遇到许多陷阱和障碍。遵循我们的《WEC 操作指南》，您可以避免这些问题。但是，为了提供更全面的视角和更丰富的背景信息，我们将在本文中讨论这些问题，以及操作指南中提供的解决方案。

“转发事件”事件日志文件

Windows 事件日志系统包含多个通道。这些通道最终由一个事件日志文件支持，该文件存储了写入该通道的所有事件日志。Windows 系统自带了一组预定义的通道，应用程序可以通过注册新的“提供程序”来添加自己的通道。

这意味着，WEC 服务器默认仅拥有与普通 Windows 服务器用于存储自身日志相同的通道。那么，所有转发到 WEC 服务器的日志应存储在哪里呢？有三种选择；我们来逐一分析：

1.将日志存储在与远程通道对应的本地通道中（即，远程“Security”通道的事件存储在 WEC 的本地“Security”通道中）。

陷阱：

• 所有远程日志会与本地日志混合在一起。
• WEC 服务器可能会将自身的事件日志循环发送到此通道。
• 日志管理和访问控制将变得非常困难。

2.将所有远程日志存储在本地“转发事件”通道中。

陷阱：

• 写入性能差，因为所有写入操作都针对单个文件。
• 搜索和读取性能差，因为事件未被分区到单独的文件中。
• 数据生命周期管理能力差，因为这是以日志文件为单位的，因此所有转发的事件都被视为同等重要。
• WEC 服务器资源利用率低，因为所有操作都集中在单个文件上，容易形成瓶颈。
• 访问管理能力差，使用单独的文件可以实现差异化的文件访问控制。
• 覆盖范围/可见性差——由于上述问题，许多系统会严格限制转发哪些事件日志，导致事件日志的可见性存在漏洞。

3.为 WEC 服务器创建新通道。

这并不像看起来那么简单，大多数人不了解这是一个选项，也是可以理解的。

许多 WEC 服务器最初设置了选项 1 或 2（如上），直到 Microsoft 内部 Security 团队大约 15 年前发布了一篇博客文章，介绍他们如何利用 Windows SDK 实现选项 3。以下是 2016 年发布的类似修订版。

新的 WEC 事件通道

拥有创建任意事件通道的能力后，我们究竟该创建什么？我们应如何组织和构建 WEC 服务器？对此有多种不同思路——《WEC 使用指南》将企业资产进行分组，以便您可以相应地管理日志的访问控制和数据生命周期。

在深入探讨之前，先看看另一种方法。你们中有些人可能已经看过 Palantir 的 WEC 架构与指南。他们为每种事件日志类型（Powershell、WMI、DNS、防火墙等）创建了通道。这些通道包含所有资产类型（域控制器、域服务器、域工作站）和部门/业务单位/OU 的日志。由于它们没有按层级组织，所以在事件查看器里只是一长串列表。每个通道也拥有其 WEC 订阅。Palantir 还提供了一套推荐的审计策略。

我想指出其他方法，例如 Palantir 的这种方法，因为没有放之四海而皆准的方案，他们的方法可能比我们的《操作手册》中列出的方法更适合您的组织。

如果您查看过 Palantir 的通道列表，您会注意到其“WEC#-Something”格式，其中数字“#”每七个通道递增一次。这是因为，在 Windows 事件日志系统中，通道是由所谓的“提供商”定义的，并且每个提供商最多只能定义八个通道：

然而，我们这些非 Windows SDK 开发人员的安全人员使用的“ecmangen”工具中存在一个漏洞，导致每个提供商的通道数超过七个时会非常麻烦。

Microsoft 并没有修复其中的诸多漏洞，而是似乎从 Windows SDK 中移除了 ecmangen。这意味着您要么使用旧版 SDK，要么自己创建 Manifest XML 文件——或许可以使用您最喜欢的 XML 编辑器来完成。

和大家一样，我最初也使用 ecmangen，并且为了方便起见，并使用七个通道以简化操作。目前的《操作手册》基于 PowerShell 脚本生成 XML 文件。因此不再需要 ecmangen，您可以自由选择八个通道，尽管《操作手册》仍然只推荐使用七个通道。

注意：可以将提供商视为一个包含八个通道的盒子，其中每个通道最终都是一个单独的日志文件。

按资产整理

利用可以拥有任意数量提供商这一特性，我们可以按资产进行组织。在您的 AD 环境中，您可能已经按资产类型（例如，域服务器、域控制器、工作站等）和/或按这些资产所属的部门（或者说组织单元）对域成员进行了分组。

因此，在《操作手册》中，您可以轻松创建与 AD 组织相匹配的提供商，例如按部门（业务单元或 OU）和/或按资产类型和/或按资产重要性（实验室/测试/生产）创建提供商。

按资产类型进行分类后，您可以更好地管理访问控制和日志生命周期，从而获得额外的益处。如果您需要查看特定资产类型的日志，您就清楚其存储位置。

为了简化操作，所有提供商都获得同一组（最多八个通道）。然后系统被映射到一个提供商（通过 OU），该系统上的事件日志则映射到该提供商的通道。

默认情况下，用于配置 WEC 服务器以匹配您的 AD 架构的“wec_config.ps1”脚本已定义了一些提供商和资产分配：

• 域控制器：此处的成员分配应较为明确。
• 域服务器：您域中的服务器
• 域客户端：用户工作站（台式机/笔记本电脑）
• 域特权：权限更高的系统（例如，跳转主机或 WEC 服务器）
• 域成员：作为通用组，包含未归入其他组的普通域成员
• 域杂项：用于无法归类的其他主机

建议您根据自己的 AD 环境对列表进行完善和编辑。

那么，默认的频道列表如下：

• 应用程序：“应用程序”及类似日志
• Security：“Security”及类似日志
• Sysmon：“Microsoft-Windows-Sysmon/Operational”
• 系统：“系统”、“HardwareEvents”、“DNS-Client”、“DHCP-Client”、“设置”及类似日志
• 脚本：“Windows PowerShell”及类似日志
• 服务：DNS-Server、DHCP-Server 和其他服务日志
• 其他：任何其他杂项日志

同样，您可以根据需要自由修改这些设置。

WEC 订阅

WEC 订阅定义了以下内容：

• 事件日志 (XPath) 筛选器，用于选择应转发的事件。
• 目标通道，用于指定将接收到的事件存储在 WEC 服务器上的位置。
• 类型：
  • 由收集器发起，WEC 连接到 WEF 服务
    • 目标计算机，即要连接的计算机列表。
  • 源发起，WEF 连接到 WEC 服务器
    • 计算机组，可访问此订阅的 AD 组（其成员为计算机）
• 事件交付选项，用于控制带宽/延迟和/或 HTTP/HTTPS
• 格式类型：RenderedText 或仅事件 XML

《使用手册》脚本（特别是 setup_subscriptions.ps1）配置了事件 XML 格式类型。这种格式的文件更小，这意味着更高的吞吐量、更多的日志存储、更低的负载和更少的带宽占用。然而，缺点在于，如果源提供商（位于远程系统上）未在 WEC 服务器的事件日志系统中本地注册，则事件查看器将无法以您的本地语言显示该消息的文本描述。但是，发送已渲染文本事件会消耗大量资源，因此很难证明其合理性。

我在开头提到过，WEF 是 WinRM 的一个功能。这个 WinRM 组件以本地系统的“网络服务”用户身份运行。这意味着 WEF 实际上无法读取您的大部分系统日志，WEC 服务器只会收到一个非常普通的事件 ID 111 消息，而不会收到其他任何日志。因此，本《使用手册》会引导您创建一个 GPO，将“网络服务”添加到本地的“事件日志读取器”组中。

WinRM 如何获取 WEF 的配置？在上述同一个 GPO 中，我们还发布了一个 WSman URL，其中列出了该服务器上的所有 WEC 订阅。实际上，我们可以列出来自多个 WEC 服务器的多个 WSman 订阅 URL，WEF 服务会尝试获取并执行所有这些 URL，从而实现 WEC 服务器的冗余。

所有订阅？我不想让我的工作站将事件日志发送到我的域控制器日志文件中！代表订阅的 WSman 条目会应用在订阅配置中设置的 AD 组权限。这意味着，如果运行 WEF 的计算机不是具有读取订阅权限的 AD 组的成员，则其无法获取并执行该订阅。这也意味着，如果您不小心，让一台计算机同时属于多个 WEC 订阅的 AD 组，那么您将在 WEC 上收到来自该 WEF 主机的多个相同的事件日志！

计算机组？但我希望根据计算机所在的 OU 来映射它们！遗憾的是，WEF/WEC/WinRM/WSman 并不支持这种方式。不过，《操作手册》提供了一种机制，可以使给定组的成员资格与指定的 OU 位置保持同步。因此，您可以假装所有操作都是通过 OU 完成的！

整合所有内容

在为实现良好的可观测性或安全用例而设置 WEF 和 WEC 时，涉及许多复杂且相互关联的组件，需要正确处理。

不过别担心，我们的《操作手册》已经准备就绪，并附带了一套 PowerShell 脚本，可以自动完成大部分步骤。这意味着出错的几率更小，可重复执行操作，因此也更容易修复错误。

一切都从 wec_config.ps1 脚本开始，您可以根据需要对其进行编辑。所有后续脚本都将以此为基础。因此，您可以在 wec_config.ps1 中轻松更改用于选择转发哪些事件日志的事件日志筛选器，然后重新运行 setup_subscriptions.ps1 以应用更改。

让我们来看看这些脚本的作用（《操作手册》详细介绍了如何使用它们）：

• wec_config.ps1 - 您的 WEC 服务器的配置文件，源自其他脚本
• gen_manifest.ps1 - 这将创建适用于 Windows SDK 的用于描述您的所有提供商及其通道的清单 XML（无需再使用 ecmangen！）
• build_man2dll.ps1 - 根据您的清单，构建实现所有新提供商和通道的 Windows 事件子系统模块 DLL，可在安装该 DLL 的任何系统上运行（通常是 WEC 服务器）
• install_channels.ps1 - 获取 DLL 和清单并将其安装在本地系统上
• configure_channels.ps1 - 将日志路径和日志大小配置（来自 wec_config.ps1）应用于所有新安装的通道
• setup_subscriptions.ps1 - 将设置（创建或重新配置）WEC 服务器上的提供商/通道的所有订阅
• map_ou2group.ps1 - 您可能想要使用您的 AD 的 OU，但 WEC 订阅是通过 AD 组来选择计算机的。此脚本将根据 wec_config.ps1 中的配置，将指定组的成员同步到特定 OU 下的计算机。
• gen_winlogbeat_config.ps1 - Winlogbeat 附带的配置无法识别您所有额外的 WEC 订阅通道，因此这将为您更新该配置
• beat_cmd.ps1 - 用于在 PowerShell 上与 Beat 命令进行交互的辅助脚本

不幸的是，AD 端的所有配置（例如组策略）仍需手动完成——但《操作手册》提供了带屏幕截图的分步指南。我将来也可能为此编写脚本，敬请期待。

最后，需要配置 Winlogbeat 将所有 WEC 日志发送到 Elastic Security。《操作手册》将指导您完成此操作。

结论

我希望在阅读完这篇博客文章，以及可能还有《操作手册》之后，您能清楚地了解在开始之前需要做出的各项决策，并且现在已拥有创建适合您企业的完美 WEC 服务器所需的全部指导和工具。

现在您已制定了适当的审计策略，配置了 WEF，并设置了 WEC 服务器，用于将 AD 域的事件日志转发至 Elastic Security，在接下来的博客文章中，我们将探讨如何在 Elastic Security 中充分利用这些极为重要且实用的日志数据。

如果您是 Elastic Security 的新用户，可以在 Elastic Cloud 上的 Elasticsearch Service 上体验我们的最新版本。此外，请务必参加我们的快速入门培训，以便顺利上手。

请参阅我撰写的其他《操作手册》指南：https://ela.st/tjs-cookbook-lib