osquery 的当前痛点是什么？ - 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