利用 osquery 在 Windows 上实现实时文件监控

本文详细介绍了如何使用 osquery 的 ntfs_journal_events 表在 Windows 上进行实时文件监控，包括技术实现、NTFS 日志访问方法以及与其他监控方式的对比分析。

利用 osquery 在 Windows 上实现实时文件监控

TL;DR: Trail of Bits 开发了 ntfs_journal_events，这是一个基于事件的 osquery 表，用于 Windows 上的实时文件变更监控。您可以使用此表高效地监控 Windows 终端上特定文件、目录和整个模式的更改。阅读模式文档此处！

文件监控用于车队安全和管理目的

文件事件监控和审计是终端安全和管理的重要基础：

  • 许多恶意活动可以通过众所周知且易于识别的文件系统活动模式可靠地哨兵或预测：重写系统库、将有效负载投放到固定位置以及（尝试）移除防御程序都表明可能存在入侵。
  • 非恶意的完整性违规也可以通过文件监控检测到：员工越狱公司设备或以其他方式规避安全策略。
  • 跨大型车队的软件部署、更新和自动化配置：“每个主机是否都安装并更新到版本 Y 的软件 X？”
  • 非安全问题的自动故障排除和修复：共享文件的权限不正确、网络配置错误、磁盘（过度）使用。

Windows 文件监控简要调查

Windows 上的文件监控方法通常分为三种方法之一：

  • Win32/WinAPI 接口：FindFirstChangeNotification、ReadDirectoryChangesW
  • 文件系统过滤器驱动程序和微过滤器
  • 日志监控

下面我们将介绍每种方法的技术细节，以及它们的优缺点（包括一般性和与 osquery 相关的）。

Win32 APIs

Windows API 提供了一组（大部分）文件系统无关的函数，用于轮询注册目录上的事件：

  • FindFirstChangeNotification 可用于在特定目录的条目（以及所有子目录的条目，如果需要）上放置一组通知过滤器。
  • FindFirstChangeNotification 返回的句柄可与标准 Windows 对象等待例程一起使用，如 WaitForSingleObject 和 WaitForMultipleObjects。
  • 等待并处理后，可以使用 FindNextChangeNotification 排队后续事件。

这些例程有几个问题：

  • FindFirstChangeNotification 不监控指定目录本身，只监控其条目。因此，监控目录及其条目的“正确”方法是调用该函数两次：一次用于目录本身，另一次用于其父目录（或驱动器根目录）。这反过来需要额外的过滤，如果父目录中唯一感兴趣的条目是目录本身。

  • 这些例程提供了检索文件系统事件的过滤和同步，但不暴露事件本身或其关联的元数据。实际事件必须通过 ReadDirectoryChangesW 检索，该函数接受被监视目录的打开句柄和许多与轮询函数相同的参数（因为它可以完全独立于它们使用）。用户还必须与 OVERLAPPED 的怪异世界打交道，以便在异步上下文中安全地使用 ReadDirectoryChangesW。

  • 最后但并非最不重要的是，ReadDirectoryChangesW 为每个目录句柄内部使用固定大小的缓冲区，如果无法跟上事件数量，将在处理之前刷新所有更改记录。换句话说，其内部缓冲区不作为环运行，并且不能信任在存在大量高 I/O 负载时逐渐或优雅地降级。

还存在一个较旧的解决方案：SHChangeNotifyRegister 可用于将窗口注册为通过 Windows 消息从 shell（即 Explorer）接收文件通知的接收者。这种方法也有许多缺点：它要求接收应用程序维护一个窗口（即使只是一个仅消息窗口），使用一些奇怪的“项目列表”视图的文件系统路径，并且受 Windows 消息传递（有限）吞吐量的限制。

总而言之，这些 API 的性能和准确性问题使它们不适合 osquery。

过滤器驱动程序和微过滤器

像 Windows 环境中的许多其他工程挑战一样，文件监控有一个核选项，即内核模式 API。Windows 足够友好地为此提供了两个一般类别：旧的文件系统过滤器 API 和最近的微过滤器框架。我们将在本文中介绍后者，因为它是 Microsoft 推荐的。

微过滤器是内核模式驱动程序，直接介入 Windows 文件系统执行的 I/O 操作。因为它们操作在通用文件系统接口层，微过滤器（大部分）对其底层存储不可知——它们（理论上）可以介入 NT 内核已知的任何文件系统操作，无论文件系统类型或底层实现如何。微过滤器也是可组合的，意味着多个过滤器可以在没有冲突的情况下注册并与文件系统交互。

微过滤器通过过滤器管理器实现，该管理器根据配置的唯一“高度”（较低的高度对应于较早的加载，因此较早的访问）和“加载顺序组”中的存在建立过滤器加载顺序，该组对应于唯一的高度范围。加载顺序组本身按升序加载，其成员按随机顺序加载，这意味着与同一组中的另一个微过滤器相比具有较低的高度并不能保证更高的优先级。Microsoft 在此处提供了一些（公共）加载顺序组和高度范围的文档；公开已知的高度列表可在此处获得。您甚至可以自己请求一个！

虽然强大且灵活，并且通常是内省 Windows 上文件系统的正确选择，但微过滤器不适合 osquery 的文件监控目的：

  • 对于树内（即非扩展）表，osquery 有反对系统修改的策略。安装微过滤器要求我们通过加载驱动程序来修改系统，并且要求 osquery 要么随驱动程序一起提供，要么在安装时获取一个。
  • 因为微过滤器是完整的内核模式驱动程序，它们带来不希望的安全和稳定性风险。
  • osquery 的设计向其用户做出某些保证：它是一个单可执行文件、用户模式代理，在运行时自我监控其性能开销——内核模式驱动程序将违反该设计。

日志监控

第三种选择可供我们使用：NTFS 日志。

像大多数（相对）现代的文件系统一样，NTFS 是日志的：对底层存储的更改之前会更新一个（通常是环形的）区域，该区域记录与更改关联的元数据。Dan Luu 的“Files are fraught with peril”包含一些以“撤销日志”形式记录日志的良好动机示例。

日志记录提供了许多好处：

  • 增加对损坏的恢复能力：单个 I/O 操作（例如，取消链接文件）的完整用户空间到内核到硬件操作链在内部不是原子的，意味着崩溃可能使文件系统处于不确定或损坏状态。拥有最后预提交操作的日志记录使文件系统更有可能回滚到已知良好状态。
  • 因为日志提供了文件系统操作的可逆记录，与底层存储硬件的交互可以更积极：触发提交的批处理大小可以增加，提高性能。
  • 由于日志是及时且小的（相对于文件系统），它可以用于避免昂贵的文件系统查询（例如，stat）以获取元数据。这在 Windows 上尤其相关，其中元数据请求通常涉及获取完整的 HANDLE。

NTFS 的日志机制实际上分为两个独立的组件：$LogFile 是一个预写日志，用于处理回滚目的的日志记录，而更改日志（$Extend$UsnJrnl）按类型记录卷上的最近更改（即，没有回滚所需的偏移和大小信息）。

Windows 将其文件历史功能用于后者，我们也将使用它。

访问更改日志

⚠ 下面的示例已为简洁起见进行了简化。它们不包含错误处理和边界检查，这两者对于安全正确使用都是必不可少的。在复制之前阅读 MSDN 和/或 osquery 中的完整源代码！⚠

对我们来说幸运的是，打开句柄并从卷的 NTFS 更改日志读取是一个相对轻松的事情，只需几个步骤。

我们通过普通的 CreateFile 调用获取要监控的卷的句柄：

1
2
3
4
5
6
7
8
9

HANDLE volume_handle = CreateFile(
    L"\\\\?\\C:",  // 卷路径
    GENERIC_READ | GENERIC_WRITE,
    FILE_SHARE_READ | FILE_SHARE_WRITE,
    NULL,
    OPEN_EXISTING,
    FILE_FLAG_BACKUP_SEMANTICS,
    NULL
);

我们在句柄上发出 DeviceIoControl[FSCTL_QUERY_USN_JOURNAL] 以获取最新的更新序列号（USN）。USN 唯一标识一批一起提交的记录；我们将使用我们的第一个按时间顺序“锚定”我们的查询：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

USN_JOURNAL_DATA journal_data;
DWORD bytes_returned;
DeviceIoControl(
    volume_handle,
    FSCTL_QUERY_USN_JOURNAL,
    NULL,
    0,
    &journal_data,
    sizeof(journal_data),
    &bytes_returned,
    NULL
);

我们发出另一个 DeviceIoControl，这次使用 FSCTL_READ_USN_JOURNAL，从日志中拉取原始记录缓冲区。我们使用 READ_USN_JOURNAL_DATA_V1 告诉日志只给我们从最后一步获得的 USN 开始的记录：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

READ_USN_JOURNAL_DATA_V1 read_data = {0};
read_data.StartUsn = journal_data.NextUsn;
read_data.ReasonMask = 0xFFFFFFFF;  // 所有原因
read_data.ReturnOnlyOnClose = FALSE;
read_data.Timeout = 0;  // 无超时
read_data.BytesToWaitFor = 0;
read_data.UsnJournalID = journal_data.UsnJournalID;
read_data.MinMajorVersion = 2;
read_data.MaxMajorVersion = 3;

char buffer[4096];
DeviceIoControl(
    volume_handle,
    FSCTL_READ_USN_JOURNAL,
    &read_data,
    sizeof(read_data),
    buffer,
    sizeof(buffer),
    &bytes_returned,
    NULL
);

注意最后两个字段（2U 和 3U）——它们稍后会相关。

解释更改记录缓冲区

DeviceIoControl[FSCTL_READ_USN_JOURNAL] 给我们一个可变长度 USN_RECORD 的原始缓冲区，前缀是一个单独的 USN，我们可以用它来发出未来请求：

1
2
3
4
5
6
7
8

USN* next_usn = reinterpret_cast<USN*>(buffer);
char* record_ptr = buffer + sizeof(USN);

while (record_ptr < buffer + bytes_returned) {
    USN_RECORD* record = reinterpret_cast<USN_RECORD*>(record_ptr);
    process_usn_record(record);
    record_ptr += record->RecordLength;
}

然后，在我们的 process_usn_record 中：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

void process_usn_record(USN_RECORD* record) {
    if (record->MajorVersion == 4) {
        return;  // 跳过 v4 记录
    }

    // 转换为适当的版本
    if (record->MajorVersion == 2) {
        USN_RECORD_V2* v2_record = reinterpret_cast<USN_RECORD_V2*>(record);
        // 处理 v2 记录
    } else if (record->MajorVersion == 3) {
        USN_RECORD_V3* v3_record = reinterpret_cast<USN_RECORD_V3*>(record);
        // 处理 v3 记录
    }
}

回想 READ_USN_JOURNAL_DATA_V1 中的最后两个字段——它们对应于返回给我们的 USN_RECORD 版本范围，包括。我们明确排除 v4 记录，因为它们仅作为范围跟踪的一部分发出，并且不包含我们需要的任何额外信息。您可以在其 MSDN 页面上阅读更多关于它们的信息。

MSDN 明确说明这些转换是必要的：USN_RECORD 是 USN_RECORD_V2 的别名，并且 USN_RECORD_V3 不保证有任何共同的布局，除了 USN_RECORD_COMMON_HEADER 中定义的布局。

然而，一旦解决了这个问题，以下字段在两者中都可用：

  • Reason: 指示当前记录中累积的更改的标志位掩码。参见 MSDN 的 USN_RECORD_V2 或 USN_RECORD_V3 获取原因常量列表。
  • FileReferenceNumber: 引用底层文件系统对象的唯一（通常为 128 位）序号。这与通过使用 FileIdInfo 作为信息类调用 GetFileInformationByHandleEx 获得的 FRN 相同。FRN 大致对应于 UNIX 领域的“inode”概念，并具有类似的语义（每个文件系统唯一，不是系统范围的）。
  • ParentFileReferenceNumber: 另一个 FRN，用于此记录所属文件或目录的父目录（或卷）。
  • FileNameLength、FileNameOffset、FileName: 此记录所属文件或目录的文件名的字节长度、偏移量和指针。注意 FileName 是基本（即未限定的）名称——检索完全限定的名称要求我们通过打开其句柄（OpenFileById）、调用 GetFinalPathNameByHandle 并连接两者来解析父 FRN 的名称。

砰：通过更改日志的文件事件。观察我们的方法避开了文件监控中的许多常见性能和开销问题：我们完全异步操作，并且完全不阻塞文件系统。这本身就是对微过滤器模型的重大改进，该模型对每个 I/O 操作施加开销。

注意事项

像提到的其他技术一样，更改日志方法文件监控并非没有缺点。

正如表的名称所示，更改日志监控仅适用于 NTFS（和 ReFS，似乎部分被放弃）。它不能用于监控 FAT 或 exFAT 卷上的更改，因为这些完全缺乏日志记录。它也不适用于 SMB 共享，尽管它适用于适当底层格式的集群共享卷。

重命名操作的处理也稍微烦人：更改日志记录一个事件用于“旧”文件被重命名，另一个用于“新”文件被创建，意味着我们必须将两者配对成一个事件以进行连贯的呈现。这不难（事件相互引用并具有不同的掩码），但这是一个额外的步骤。

更改日志文档也明显缺少关于丢弃记录可能性的信息：需要起始 USN 和在原始缓冲区中返回后续 USN 意味着后续查询预期成功，但没有提供关于更改日志环绕行为大小的官方细节。此博客文章表明默认大小为 1MB，这可能对大多数工作负载足够。它也可以通过 fsutil 更改。

可能更重要的是 MSDN 文档中 Reason 位掩码的这一行：

标识自文件或目录打开以来在此文件或目录日志记录中累积的更改原因的标志。

当文件或目录关闭时，会生成一个最终的 USN 记录，设置 USN_REASON_CLOSE 标志。下一次更改（例如，在下一次打开操作或删除之后）启动一个新记录，带有一组新的原因标志。

这意味着在打开文件生命周期上下文中的重复事件可以合并到 Reason 掩码中的单个位：USN_REASON_DATA_EXTEND 每个记录只能设置一次，因此由打开、两次写入和关闭组成的 I/O 模式将仅指示发生了某些写入，而不是哪个或多少次。因此，更改日志无法回答关于开放资源上 I/O 大小的详细问题；只能回答是否发生了某些事件。然而，对于完整性监控的目的，这不是一个主要缺陷，因为我们主要感兴趣的是知道文件何时更改以及它们更改时的最终状态。

将更改日志引入 osquery

上面的代码片段为我们从单个卷检索和解释更改日志记录奠定了基础。osquery 的用例更复杂：我们希望监控用户注册感兴趣的每个卷，并对检索到的记录执行过滤以将输出限制为一组配置的模式。

每个 NTFS 卷都有自己的更改日志，因此每个都需要独立打开和监控。osquery 的发布-订阅框架非常适合此任务：

  • 我们定义一个事件发布者（NTFSEventPublisher）
  • 在我们的配置阶段（NTFSEventPublisher::configure()），我们读取用户配置，类似于 Linux file_events 表：
1
2
3
4
5
6

{
  "ntfs_journal_events": {
    "include": ["C:\\Windows\\System32\\*.dll", "D:\\Important\\"],
    "exclude": ["C:\\Windows\\Temp\\"]
  }
}
  • 配置给我们基本列表的卷以监控更改日志；我们为每个创建一个 USNJournalReader 并通过 Dispatcher::addService() 将它们添加为服务
  • 每个读取器进行自己的更改日志监控和事件收集，向发布者报告事件列表
  • 我们执行一些规范化，包括将“旧”和“新”重命名事件减少为单一的 NTFSEventRecords。我们还维护父 FRN 到目录名称的缓存，以避免错过由目录重命名引起的更改，并最小化我们发出的打开句柄请求的数量
  • 发布者 fire() 那些规范化的事件以供我们的订阅表使用：ntfs_journal_events

放在一起，这给了我们在上面屏幕截图中看到的基于事件的表。是查询时间了！

总结

ntfs_journal_events 表使 osquery 成为 Windows 上文件监控的一流选项，并进一步减少了 osquery 在 Windows 和 Linux/macOS 之间的功能差距（后者长期以来都有 file_events 表）。

您有 osquery 开发或部署需求吗？给我们留言！Trail of Bits 多年来一直处于 osquery 开发的核心，并致力于从核心到表开发再到新平台支持的一切。

如果您喜欢这篇文章，请分享： Twitter LinkedIn GitHub Mastodon Hacker News

页面内容 文件监控用于车队安全和管理目的 Windows 文件监控简要调查 Win32 APIs 过滤器驱动程序和微过滤器 日志监控 访问更改日志 解释更改记录缓冲区 注意事项 将更改日志引入 osquery 总结 最近的帖子 构建安全消息传递很难：关于 Bitchat 安全辩论的细致入微的看法 使用 Deptective 调查您的依赖项 系好安全带，Buttercup，AIxCC 的评分回合正在进行中！ 使您的智能合约超越私钥风险 Go 解析器中意外的安全隐患 © 2025 Trail of Bits. 使用 Hugo 和 Mainroad 主题生成。

comments powered by Disqus
© 2020 - 2025 qife
使用 Hugo 构建
主题 Stack 由 Jimmy 设计
本站总访问量次 本站访客数人次