对于Qemu虚拟化安全，为什么建议你实时打补丁？

系统管理员知道运行未打补丁的服务有什么风险。鉴于选择和无限资源，大多数勤奋的管理员将确保所有系统和服务都得到一致的补丁。但事情很少这么简单。技术资源有限，修补往往比乍一看更复杂。更糟糕的是，有些服务隐藏在后台，以至于它们不会出现在要修补的事物列表中。

QEMU 是那些往往会给修补带来困难的服务之一。它在后台运行，很容易被认为是理所当然的。此外，修补 QEMU 涉及重大的技术和实践挑战，同时需要大量资源。

在本文中，我们将解决与修补 QEMU 相关的一些困难，并指出一种解决方案，可以消除 QEMU 修补中最棘手的部分。

忽略 QEMU 补丁是一个很大的风险

如果您使用 QEMU（当然，简称 Quick EMUlator），您可能会知道它，因为 QEMU 将提供支持您的工作负载的关键虚拟化功能。也就是说，您可能没有意识到，就像主机操作系统、虚拟化操作系统和所有应用程序一样，QEMU 也需要定期更新——即使它在后台运行。

根据网络安全行业门户极牛网GEEKNB.COM的梳理，QEMU 已被证明与任何其他服务、库或组件一样容易受到攻击。例如，在 2015 年，QEMU 中的虚拟软盘控制器被发现存在漏洞：它被称为 Venom 漏洞，无论 QEMU 虚拟软盘是否在使用中都会影响系统。

同样，在 2019 年，使用 KVM/QEMU 管理程序运行 Linux 实例的组织处于安全漏洞的接收端，使无数系统面临风险。而且，就像任何其他常用软件一样，QEMU 中很可能会发现更多缺陷。

换句话说，如果您不打补丁，您的系统将面临风险。但是有一个问题：当涉及到 QEMU 时，修补并不简单，因为修补 QEMU 会影响底层虚拟化工作负载：当您停止重启 QEMU 时，虚拟工作负载也必须停止。

修补 QEMU 的选项

在单个系统上修补单个服务通常不是问题 – 假设您记得这样做 – 即使修补单个操作系统也没有那么难，因为您通常可以应对一次重启，但它仍然具有破坏性，因为每次应用程序重新启动。修补一组操作系统要困难得多，因为这可能意味着数以千计的重启和对无数应用程序的中断。

因为 QEMU 是一种虚拟化服务，所以修补比简单地修补另一个应用程序具有更大的影响。修补 QEMU，您必须重新启动在其上运行的底层操作系统。

在其他情况下，对单个服务（QEMU）应用补丁可能会导致数千个操作系统的强制重启。它大大增加了 QEMU 修补的复杂性——这可能意味着技术团队有时会推迟修补 QEMU，试图证明冒漏洞的风险是合理的，因为他们认为中断太大了。

然而，修补是必须的，而且在更新 QEMU 时当然有捷径 – 以及正确的方法。以下是您的一些选择。

快速但非常危险的方法

您最简单但最具破坏性的选择是简单地应用补丁，重新启动，然后看看会发生什么。如果它只是一台机器，你可能没问题——毕竟，你会意识到你将需要重新启动你的工作负载。

但是，如果您正在跨服务器群管理 QEMU，或者在外部涉众进化的环境中管理 QEMU，那么简单地在所有机器上打补丁和触发重启，毫无疑问会导致许多人心烦意乱。

明智的做法

大多数头脑清醒的系统管理员不会只是重新启动，而是会为上述过程添加更多计划。首先，您将通过设置有计划停机时间的计划维护窗口（例如提前一个月）通知所有受影响的人。当然，问题是您必须希望自己在那个月内不会被黑客入侵。

但是，在维护窗口期间，您将有机会在不打扰任何人的情况下进行修补，允许几个小时的无服务。一旦您重新启动 QEMU，所有虚拟机都应该重新启动，您可以通知利益相关者补丁已完成。

尽管如此，您可能会在重新启动后为自己安排一段相当长的时间进行故障排除，尽管您不会得到任何东西，但即使是计划内的维护窗口对所有相关人员来说也是具有挑战性的。在许多情况下，涉及实际停机时间的计划维护是不可接受的。

企业级方法

某些工作负载无法很好地处理操作系统重启造成的中断。在企业环境中，您将需要另一个计划。您将需要采用更复杂的方法：QEMU 工作负载的实时迁移。

根据网络安全行业门户极牛网GEEKNB.COM的梳理，只有当您的工作负载已经分布在多个主机上并且您在这些节点之间激活了高可用性时，您才能执行此操作。然后，您可以通过通知利益相关者维护窗口到期来启动修补程序，这将影响性能——但不应影响可用性。

依靠您的高可用性操作，您可以跨虚拟机迁移，然后停止 QEMU，修补它并重新启动它。重新启动后，您将虚拟机迁移回已修补的 QEMU 实例。

正确完成后，通过迁移修补可确保您的 QEMU 实例得到安全修补，而不会因真正的停机时间而使利益相关者感到不安。

QEMU 迁移的问题

我们已经讨论了修补 QEMU 的三种不同方法，毫无疑问，迁移路线是依赖 QEMU 驱动大型工作负载的组织的最佳选择。但即使是这种企业级方法也存在风险。您正在执行一个非常复杂的过程，就像所有复杂的过程一样，它总是会失败。

一些出错的事情包括：

• 迁移过程中性能可能会显着下降——这可能会影响利益相关者和用户的满意度，尤其是在迁移时间比预期更长的情况下。
• 协调维护窗口（由于可能的性能中断而需要）仍然具有挑战性和耗时 – 同时会给利益相关者带来一定程度的烦恼。
• 在迁移操作期间，通常应该容忍轻微的网络数据包丢失——但某些工作负载可能对此很敏感，这可能会导致重大问题。
• 您需要在迁移后进行测试和验证——您不能假设一切都已顺利迁移，您可能需要让利益相关者参与此测试过程。

通过迁移过程执行 QEMU 更新可以限制中断，但您的团队仍然需要在此过程中投入大量时间。出现问题的风险仍然存在——灾难性故障的风险很小。

因此，虽然您的利益相关者不太可能看到重大中断，但您的团队需要仔细规划。最后，值得考虑的是，迁移过程的任何不利结果（尽管风险很小）都会对您和您的团队产生负面影响。

实时修补作为替代方案

过去，打补丁总是依赖于停止、打补丁、重启的过程。是的，迁移有助于确保需要重新启动的实例可用。但是一种更新的方法变得越来越普遍：即时修补，而无需重新启动正在修补的软件。

根据网络安全行业门户极牛网GEEKNB.COM的梳理，这种方法称为实时修补，大大简化了修补过程。实时修补不需要重新启动，而是可以随时随地更新您的服务器或需要修补的服务。QEMU 实时补丁也是如此，您现在可以在其中安装 QEMU 的最新补丁——无需设置维护窗口，也无需执行和计划迁移。

这就是为什么QEMUCare，从TuxCare，是一个改变游戏规则的团队，运行的工作负载上QEMU。QEMUCare 不仅使更新和迁移过程更容易——它完全消除了它。您的 QEMU/KVM 实例会立即修补，而不会影响底层虚拟机。

选择实时修补路线会带来一系列优势：

• 一致的修补。一个好的实时补丁解决方案，例如 QEMUCare，将自动检测新补丁的发布并启动补丁过程。您的团队甚至不需要监控补丁发布：QEMUCare 只需照顾它。这意味着您的团队可以更一致地打补丁——降低您的 QEMU 实例容易受到新漏洞攻击的风险。
• 快乐的干系人。由于 QEMUCare 在后台运行，无需重启 QEMU 即可自动打补丁，您的利益相关者（包括内部用户和您的客户或客户）甚至不会知道您正在执行打补丁。这一切都可以无缝进行，无需计划的维护窗口。
• 消除工时。虽然您可以选择走捷径，但我们之前描述的企业级、迁移驱动的修补程序是您唯一现实的选择。然而，这是非常劳动密集型的，消耗您团队的大量时间——而QEMUCare消耗您团队的几乎零小时。
• 将出错的风险降至最低。因为您不必手动迁移您的工作负载，所以修补 QEMU 会给您带来重大问题的风险较小。无需担心迁移故障或网络错误——您和您的团队成员无需担心您的工作。

显然，实时修补极大地简化了保持 QEMU 实例最新的过程：它会自动发生，您无需担心出现任何问题——并且您无需投入大量时间来完成它。