osquery 的当前痛点是什么？ - The Trail of Bits 博客

您正在阅读我们关于 osquery 的四部分系列文章的第二篇。阅读第一篇以了解该工具的当前使用情况、其在企业安全团队中日益受欢迎的原因，以及它与商业替代品的对比。

osquery 显示出彻底改变端点监控市场的巨大潜力。（例如，它通过 Windows 可执行代码签名验证大大简化了签名恶意软件的检测。）然而，我们在本系列中采访的五家主要科技公司的团队和 osquery 开发人员表示，这款开源工具有改进的空间。

其中一些担忧与真正的限制有关。然而，我们也听到一些潜在用户和行业竞争对手最近的抱怨，这些抱怨与 osquery 的实际缺点不符。

与许多快速改进的开源项目一样，文档更新滞后于迅猛的开发进度可能是这些误解的原因。因此，在深入探讨 osquery 社区接下来应该解决哪些真正的痛点之前，让我们先澄清一些当前关于 osquery 限制的误解。

osquery 的神话式限制

“osquery 不支持容器”

哦，但它确实支持！像 Uptycs 这样的团队在过去一年中为这一备受要求的功能投入了大量开发支持。目前，osquery 可以在管理主机层执行容器内省（更高效），或者可以在每个容器中运行（更细粒度），而不会占用大量 CPU。

“osquery 无法实时操作”

osquery 处理 macOS 和 Linux 的文件完整性和进程审计。它还可以在选定的操作系统中监控用户访问、硬件事件和套接字事件。它通过与审计内核 API 的交互来执行这些任务。与其他基于拉取的查询不同，这些监控服务实时创建基于事件的日志，并确保 osquery 不会错过查询之间的重要事件。这些功能对于 osquery 在事件检测中的能力至关重要。

“osquery 开销高”

当正确部署和管理时，osquery 是一种轻量级解决方案。正如我们将在后文提到的，性能问题的主要原因来自配置错误：调度失控查询、在高流量文件路径上执行基于事件的查询，或在资源受限的环境中运行 osquery 而未实施 CPU 控制。事实上，实施了如 Cgroups 等保护措施的受访者对 osquery 的性能如此有信心，以至于他们在每个端点（包括生产服务器）上都部署了该工具。

osquery 的当前限制；事实

用户支持需求超过供应

对于一个开源项目，osquery 提供了大量用户支持：一个网站、一个活跃的 Slack 频道、广泛的文档和许多博客（比如这篇！）。话虽如此，社区可以做得更好。

文档更新未能跟上项目功能更新列表的增长速度，使用户不知道新功能或对其使用方法感到困惑。

困惑的用户涌向 osquery Slack 频道，提出类似的问题。专家们试图帮助这些人，而不是创建常见问题解答、编写全面的查询包和制作教程。

用户测试功能完整性

Facebook 在彻底审查新代码以及就如何最好地构建新功能进行富有成效的辩论方面做得非常出色。然而，对新功能效力的监督不足。到目前为止，这一直是用户的工作，他们向 Slack 频道或 GitHub 仓库报告边缘案例和意外行为。

这个问题的一个最近例子：开发人员和用户在 osquery 的文件完整性监控中看到了假阴性。审计后端包含多个导致不准确日志的错误。自 2015 年首次启用 FIM 以来，这一问题一直未被检查。幸运的是，我们自己的 Alessandro Gario 正在实施修复。

扩展问题

osquery 的这一关键组件一直给用户带来问题。问题源于开发过程中支持不足。osquery 当前的 SDK 仅提供与 osquery 集成所需的最低要求。文档和 API 也很有限。由于这些因素，许多扩展构建或维护不佳，因此引入了不可靠的结果。

幸运的是，社区已开始解决这些问题。Kolide 的 osquery-go 为开发人员提供了一个丰富的 SDK，用于使用 Go 创建 osquery 扩展。上周，我们解释了如何为 osquery 编写扩展。我们还发布了一个我们自己维护良好的 osquery 扩展仓库，用户可以从中获取（目前只有一个，但很快会有更多！）。我们打算帮助社区导航扩展构建过程，并创建一个可靠的更新扩展来源。

除 Linux 和 macOS 外的平台支持有限

用户渴望 osquery 支持更多平台并在所有端点上提供更好的内省。osquery 当前仅限于端点的子集，给用户的监控能力留下了漏洞。此外，他们指出一些受支持的平台缺乏重要功能。

例如，macOS 和 Linux 平台可以收集关于各种事件类型的可用实时数据。osquery for Windows 中的实时数据仅限于 Windows 事件日志，该日志仅暴露难以解析的系统数据流。我们采访的用户中没有人在其部署中成功实施或解析这些日志。

来自 Teddy Reed 和 Mitchell Grenier 在 2017 年 LISA 会议上的 osquery 演示

可读的实时监控是 osquery 事件检测能力的基础。虽然计划查询可能错过查询之间的系统事件，但基于事件的实时监控不太容易出现假阴性。Windows 端口中缺少此功能大大降低了 osquery 对于在其车队中运行 Windows 机器的用户的事件检测效用。

失控查询和指导

受访者对其缺乏对不良查询的保护措施保留了一些最严厉的批评，特别是那些意外拉取过多数据的查询。有时，这些失控查询给更大的车队带来重大问题，如端点系统性能下降和内存堵塞。此外，格式错误的查询可能淹没数据日志并覆盖收集的其他数据，导致其他事件未被检测到。

osquery 的看门狗功能确实通过杀死任何消耗过多 CPU 或内存的进程来防止一些性能问题。然而，这样做时没有考虑当时正在运行的内容。格式良好的基于审计的查询经常超过默认配额，不必要地杀死进程。因此，用户关闭了该功能以避免丢失基本数据。更好的解决方案是理解用户查询的规模并要求确认。

用户还希望更智能的查询。一位受访者希望获得关于不同类型系统数据的正确查询间隔的指导。他还希望节省因不同查询包中数据重叠而浪费的存储空间。尽管问题相对较小，但如果 osquery 能够去重这些数据，将会很有帮助。

大规模调试/诊断不足

用户在大规模部署 osquery 时遇到困难，主要原因是难以在其车队中调试和诊断查询问题。一家公司报告称，大约 15% 的查询节点因未知原因持续处于挂起状态。另一家公司报告称，某些端点偶尔会“从互联网上掉线”而没有任何明显原因。尽管用户可以使用详细设置重新启动 osquery 以打印有关每个执行操作的信息，但此选项主要是开发人员的工具，并不用户友好。

部署和维护问题

每家实施 osquery 的公司都以不同的方式应对这一持续的斗争。我们在上一篇文章中详细介绍了他们用于管理此问题的各种工具和技术。尽管支持和文档有所改进，问题仍然存在。一位用户报告在员工是管理员的端点上实施 osquery 版本更新时持续遇到麻烦。

结论

在阅读了所有这些痛点之后，您可能想知道为什么 osquery 今年赢得了多个产品奖项，以及为什么超过 1,100 名用户参与了开发社区的 Slack 频道和 GitHub 仓库。您可能想知道为什么我们为本系列调查的五家顶级科技公司团队报告称，他们比商业车队管理工具更喜欢 osquery。

这很简单。该工具吸引了一个充满活力的开发社区，投资于其成功。每一项新发展都使 osquery 更接近与竞争对手完全集成且价格更高的安全套件的等效组件实现功能对等。随着用户委托像 Trail of Bits 这样的公司进行这些改进，整个社区都会受益。

这将是本系列第三篇文章的主题：osquery 的开发请求。如果您今天使用 osquery 并有想要添加到我们研究中的请求，请告诉我们！我们很乐意听取您的意见。

您使用 osquery 的经验与本文中提到的痛点相比如何？您是否有其他投诉或问题希望在未来版本中解决？告诉我们！帮助我们引领改进 osquery 的开发和实施。

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

页面内容 osquery 的神话式限制 “osquery 不支持容器” “osquery 无法实时操作” “osquery 开销高” osquery 的当前限制；事实 用户支持需求超过供应 用户测试功能完整性 扩展问题 除 Linux 和 macOS 外的平台支持有限 失控查询和指导 大规模调试/诊断不足 部署和维护问题 结论 最近文章 使用 Deptective 调查您的依赖项 系好安全带，Buttercup，AIxCC 的评分回合正在进行中！ 使您的智能合约超越私钥风险成熟 Go 解析器中意想不到的安全隐患 我们从审查首批 DKLs 中学到了什么 Silence Laboratories 的 23 个库 © 2025 Trail of Bits。 使用 Hugo 和 Mainroad 主题生成。