您希望 osquery 能实现什么？- Trail of Bits 博客

欢迎阅读我们 osquery 系列文章的第三篇。截至目前，我们已经描述了五家企业安全团队如何使用 osquery，并回顾了他们遇到的问题。在第三篇文章中，我们将聚焦 osquery 的未来。我们向用户提问：“您希望 osquery 能实现什么？”收到的答案从小型请求到可能颠覆事件响应工具市场的重大进步不一而足。让我们首先深入探讨这些“超级功能”。

osquery 超级功能

一些用户的建议可能从根本上扩展 osquery 的角色，从一个事件检测工具转变为可能使其在预防和响应方面从商业工具中夺取显著市场份额的工具（我们在首篇博客文章中列举了其中一些）。这将是一个重大突破。一个免费开源工具，让安全团队能够访问通常仅限于昂贵付费服务客户的事件响应能力，对社区来说将是一笔意外之财。它可以民主化舰队安全，并增强整个社区对攻击者的防御能力。以下是可能将 osquery 提升到新水平的功能：

对终端的可写访问

是什么：目前，osquery 仅限于对终端进行只读访问。这种访问允许程序检测和报告其监控的操作系统中的变化。通过 osquery 扩展实现写访问将使其能够编辑操作系统中的注册表并改变终端的行为方式。它可以利用这种访问在整个舰队中执行安全策略。

为什么这很惊人：写访问将把 osquery 从检测工具提升到预防领域。与其仅仅用 osquery 观察系统问题，写访问将赋予您直接从 SQL 接口强化系统的能力。应用程序白名单和执行、管理许可证、分区防火墙设置等都可能实现。

我们如何构建它：如果构建不当，osquery 中的写访问可能弊大于利。写访问超出了 osquery 核心的范围。一些当前用户仅被允许在整个舰队中部署 osquery，因为它具有有限的只读权限。通过 osquery 核心授予写访问将带来更高的安全风险以及系统中断的潜在可能。实现这一功能的正确方式是使其可用于在初始化期间请求该功能的扩展，并最小化此功能对核心的影响。

实际证明：事实上，我们有一个等待批准的拉取请求，将支持通过扩展实现写访问！该代码启用扩展的写权限，但阻止核心内置表的写权限。

我们构建此功能是为了支持一个客户，该客户希望阻止恶意 IP 地址、域名和端口，用于预防和反应性用例。一旦此代码提交，我们的客户将能够下载我们的 osquery 防火墙扩展，使用 osquery 在整个舰队中分区防火墙设置。

事件触发响应

是什么：如果 osquery 读取指示攻击的日志条目，它可以自动响应操作，例如隔离受影响的终端。此超级功能将为 osquery 的能力添加自动预防和事件响应。

为什么这很惊人：这将把 osquery 的能力提升到商业漏洞检测/响应工具的水平，但它将是透明和可定制的。防御团队可以评估、定制并将 osquery 的事件响应能力与公司需求匹配，作为独立解决方案或作为另一个更通用响应套件的补充。

我们如何构建它：osquery 的自动事件响应可以灵活构建，以允许安全团队定义自己的事件指标和首选反应。用户可以从已知更新的数据库中选择：通过 VirusTotal 的 URL 声誉、通过 ReversingLabs 的文件声誉、通过 OpenDNS 的活动连接远程地址的 IP 声誉等。用户可以选择匹配标准类型（例如，精确、部分、特定模式等），并规定响应，例如增加日志频率、将关联的恶意 ID 添加到防火墙阻止列表，或调用外部程序采取行动。作为附加选项，将日志发送到外部分析工具的事件触发可以在不损害终端性能的情况下提供更复杂的响应。

实际证明：不仅多个受访者渴望此功能；一些团队已经开始构建其初步版本。如“团队目前如何使用 osquery？”中讨论的，我们与一个团队交谈，该团队通过将日志数据管道传输到 ElasticSearch 并使用 ElastAlert 在异常检测时自动生成 Jira 票证来构建事件警报。此示例未展示完整的响应能力，但说明了 osquery 如何实现及时的业务流程事件反应。如果 osquery 可以监控事件驱动的日志（FIM、进程审计等），基于检测到特定模式触发行动，并管理保护性响应，它可以提供一个有效的终端保护平台。

技术债务 overhaul

是什么：许多开源项目承担“技术债务”。也就是说，一些代码工程为短期目标构建有效，但不适合长期程序架构。分布式开发者社区各自为略有不同的需求增强技术加剧了这个问题。解决此问题需要昂贵的协调和多个社区成员的努力来重建和标准化系统。

为什么这很惊人：减少 osquery 的技术债务将把程序升级到一个可被更广泛安全团队采用的标准。在我们关于 osquery 痛点的研究中，用户引用性能影响和可靠性作为组织领导采用 osquery 的主要关注点。最终，我们采访的团队赢得了争论，但可能有许多团队未获得使用 osquery 的绿灯。

我们如何构建它：在一个组织内处理技术债务已经足够困难。在分布式社区中可能更困难。除非开发者有特定动机处理非常困难的高价值低效问题，解决问题的自然回报偏向于较小的努力。为了对抗这一点，社区领导者可以倾倒和排序所有技术债务问题沿价值和时间矩阵，将所有高价值/低时间问题留给个人开源开发者，并汇集社区资源以解决更难的问题作为完整的开发项目。

实际证明：我们知道汇集社区资源处理技术债务是有效的。我们已经这样做了一年多。Trail of Bits 已被多家公司委托构建对开源社区来说太大的功能和修复。我们利用此模型将 osquery 移植到 Windows，增强 FIM 和进程审计，以及更多我们兴奋地在未来几个月与公众分享的内容。通常，多个客户对构建相同的东西感兴趣。我们能够汇集资源，使项目对每个参与者来说更便宜，同时整个社区受益。

用户想要的其他功能

osquery 显示出超越终端监控的巨大增长潜力。然而，我们采访的企业安全团队和开发者表示，该开源工具有改进空间。以下是我们从用户那里听到的其他一些请求：

• 查询的防护栏和规则：目前，格式错误的查询或实践可能妨碍用户的工作流程。受访者希望有关定位正确数据、在正确间隔查询、从推荐表收集以及为不同环境定制推荐的指导。
• 增强部署选项：用户寻求更好的工具来在整个舰队中部署并保持这些实现更新。除了推荐的 QueryPacks，管理员希望能够定义和选择跨多平台终端的平台特定配置。自动检测和部署独特系统和软件的配置是另一个期望的功能。
• 集成测试、调试和诊断：除了当前的调试工具，用户希望更多资源用于测试和诊断问题。新工具应帮助提高可靠性和可预测性，避免性能问题，并使 osquery 更易于使用。
• 增强事件驱动数据收集：osquery 通过 FIM、进程审计和其他表支持基于事件的数据收集。然而，这些数据源受日志实现问题影响，并非在所有平台上受支持。更好的事件处理配置、发布的最佳实践和数据收集的防护栏将大有帮助。
• 增强性能功能：用户希望 osquery 用更少资源做更多事。这将导致整体性能增强，或允许 osquery 在低资源配置文件或关键任务性能要求的终端上操作。
• 更好的配置管理：增强功能如自定义表和 osqueryd 计划查询为不同的终端环境将使 osquery 在增长的舰队上更易于部署和维护。
• 支持离线终端日志记录：用户报告希望取证数据可用性以支持远程终端。这将要求离线终端本地存储数据——包括失败查询的存储——并在重新连接时推送到服务器。
• 支持常见平台：Facebook 为其基于 macOS 和 Linux 的终端舰队构建了 osquery。PC 系统管理员直到我们去年的 Windows 移植才幸运。由于开发社区的努力，对其他操作系统的支持一直在稳步增长。然而，仍然存在限制。将此视为一个总体功能请求：支持所有操作系统上的所有功能。

列表不断增长

对当前和潜在的 osquery 用户来说不幸的是，Facebook 无法满足所有这些请求。他们通过开源 osquery 分享了一份巨大的礼物。现在由社区来推动平台前进。

好消息：这些功能请求都不是不可行的。自定义工程只是对个别组织来说投资不经济。

在本系列的最后一篇文章中，我们将提出一个 osquery 用户共享开发成本的策略。受益的公司可以汇集资源并共同瞄准特定功能。

这将加速公司淘汰其他更昂贵、更不灵活和更不透明的全套工具的速度。

如果任何这些项目与您的团队需求产生共鸣，或者如果您目前使用 osquery 并有另一个请求要添加到列表中，请告诉我们。

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

页面内容 osquery 超级功能 对终端的可写访问 事件触发响应 技术债务 overhaul 用户想要的其他功能 列表不断增长 最近帖子 用 Deptective 调查您的依赖项 系好安全带，Buttercup，AIxCC 的评分回合正在进行中！ 使您的智能合约超越私钥风险成熟化 Go 解析器中意外的安全陷阱 我们审查首批 DKL 的收获 23 个来自 Silence Laboratories 的库 © 2025 Trail of Bits。 使用 Hugo 和 Mainroad 主题生成。