1991年，发生了两个不相关的事件，每个事件都预示了两种截然不同的自由：冷战的结束和Linux的诞生。实时修补内核
的可能性出现在2008年，当时Linux还很年轻。既然Linux内核即将达到30个内核，那么实时补丁程序也已经成熟，并且有可能贬低其作为“非常有用”的可选附件的声誉。 有两个原因。首先是Linux作为经济，多功能Web托管的首选平台的主导地位：超过一半
目前所有已知的网站都在Linux上运行。其次，人们认识到实时修补不仅仅是一种便利；这也是提高Linux系统安全性的一种有效且低成本的方法。
Ksplice是第一个实时Linux内核补丁解决方案，在发布后毫不费力地获得了丰厚的利润，直到2011年科技巨头甲骨文（Oracle）收购了Ksplice时，它的领导地位才得以增强。今天，它是为Linux提供自动化安全补丁服务的五个组织中最著名的。按字母顺序，这些是：
- 适用于Ubuntu的Canonical Livepatch服务。
- 适用于Ubuntu，Red Hat Enterprise Linux，Oracle Linux，Amazon Linux等的KernelCare。
- 用于Red Hat Enterprise Linux的Kpatch。
- 适用于Oracle Linux的Ksplice。
- 适用于SUSE Linux Enterprise的SUSE Linux Enterprise Live Patching。
每个公司都使用相同的样板关键字，相同的标准短语（不断重复）来推广其服务。我将为您提供最受欢迎的内容，以及您应该如何理解它们。
- 无重启：刷新Linux内核而不重启。
- 自动化：在没有观察者的情况下检查并安装内核安全更新。
- 易于安装：安装和设置非常简单或不必要。
- 完全支持：您无需自己编写补丁。（请参阅在Kpatch上编写补丁的手册，以了解为什么这很重要）
忽略这些令人眼花obvious乱的卖点，您会发现需要考虑的其他功能以及可用于将一项服务与另一项服务进行比较的其他因素。本文探索其中的一些内容，并对其进行了肯定和启发。但是首先，让我们回顾一下实时补丁是什么。
什么是实时Linux内核补丁？
Linux内核包含超过2000万行代码，这些代码大部分（大概）是由人类程序员编写的。与所有软件一样，它也有错误。在这个日益关注网络安全的时代，漏洞隐含着漏洞。为了解决此问题，Linux供应商试图尽快发布对其内核的更新。Linux系统管理员还试图通过安装这些更新来快速做出反应，从而使调度更加困难。这是因为没有检测漏洞的模式。原因如下：
- 在任何给定时间，都有许多不同版本的Linux内核正在使用。有些将需要修复；有些没有。
- , .
- Linux , .
- Linux . , , — .
还有很少被提及的一件事：这是系统管理员对停止机器的本能厌恶，导致不得不说：“服务器停机以进行维护。”
为什么要停止服务器？因为内核更新要等到重启后才能生效。如果您不重新启动-如果将其放在后面的刻录机上，或者忘记了它-您会陷入困境，因为没有最新补丁程序的服务器是不安全的。我们将在后面更详细地讨论此口头禅，但其实质是：
漏洞公开后，其利用也会发生同样的情况。
或者，换句话说，您有一个以前不知道的漏洞，但是现在知道了。还有其他所有人。
这种情况下的救星是实时修补。这不是更新整个Linux内核，而是仅更新其有问题的部分的方法。这样就无需停止进程或中断用户工作。
但是，有局限性。实时内核补丁无法修复各种错误。内核代码的压倒性的复杂性以及动态修改代码的技术挑战意味着，该技术仅用于解决通常与安全性相关的关键问题。
尽管如此，具有实时修补功能的系统比没有系统的系统更安全。以下是寻找实时修补解决方案时要问的几个问题：
1.补丁内部是什么（补丁背后是谁）？
当您注册实时补丁服务时，您所支付的不仅仅是软件本身。当您开始研究Linux内核源代码并意识到写得不好的补丁程序会如何损害整个Linux系统时，这一点就变得很清楚。
前面我提到过，内核是一项庞大的工作，似乎在活动和数量上都在扩展。请注意，Linux内核存储库的master分支中的代码行数有所增加。 （从每年的1月1日开始计数。仅计算C / C ++文件和标头，Python和Perl文件。）
拥有如此多的代码，为Linux内核编写补丁并不是一件容易的事。需要对内核体系结构和数据结构有深入的了解。需要具有Linux社区编码约定和质量标准的经验。并且需要特殊的才能来发明不影响功能，性能和稳定性的解决方案。
补丁供应商使用两种相反的方法来开发和交付内核补丁。我称它们为增量式和整体式。
增量补片（如口香糖球）彼此堆叠，每个补片都会改变前一个补片的行为。作为客户，您必须跟踪安装的补丁程序和不安装的补丁程序以及安装顺序。不注意这些问题可能会导致系统行为发生不可预测的变化。这种修补方法使供应商可以快速发布目标明确的小型修补程序。但是随着时间的流逝，系统可能会变得不稳定，以至于只有完整的内核更新才能还原它。
整体补丁是包含所有先前补丁的补丁。基本上，只有一个主补丁会替换活动的补丁，而不是添加到该补丁中。这种方法可使平台更稳定，从而显着增加服务器的正常运行时间，通常需要数千天来衡量。
2.等待下一个补丁需要多长时间？
报告漏洞和修复漏洞之间不可避免地会有延迟。分析内核错误和评估其影响需要花费时间。找到解决方案需要独创性和技巧，还需要进行大量测试来确保其有效。然后，作为Linux开发过程的一部分，必须对其进行强制审查和批准。
当Linux供应商用自己的社区严重等级替换时，会发生可避免的延迟。这意味着供应商可以使用更少的补丁来修复多个漏洞，但是由于这个原因，客户平均等待更长的时间来修复某些问题。
知道补丁程序发行不稳定的原因的Linux管理员所获得的收益不会比不知道这些收益的Linux管理员获得的收益更多。他们没有一个会感到安慰的，因为他们在等待补丁时，其系统比被发现之前更容易受到攻击。
原因如下：网络安全研究社区的成员喜欢宣布漏洞以及视觉用例。它们通常采用概念验证的形式，以及有关如何重现错误或使用漏洞利用程序的详细技术说明。这些描述是真诚的，可以帮助内核开发人员发现并修补漏洞。但是，通过在利用漏洞作为武器的竞赛中，为黑客提供了一条用于灾难的字面方法的捷径，他们还节省了许多时间和精力。
3.错误应该严重到什么程度？
几乎所有新发现的漏洞都被分配了CVE标识符。后来，经过安全研究人员的仔细检查，漏洞被评为严重性，即衡量其影响的标准。
一个重要的评估方案是常规系统漏洞评估（CVSS-通用漏洞评分系统） 。它用一组数字表示一个漏洞，每个数字都是特征的分数，例如：
- 复制（使用）有多容易。
- 修复它有多困难。
- 影响规模对服务器和服务的可用性。
- 开放数据的重要性或机密性。
全套包括更多类似的评估。该算法将这些分数组合成一个基线分数，一个简洁的数字代表漏洞的严重性，范围从0（低）到10（高）。第二个版本的CVSS将这些数字的范围划分为关键字LOW，MEDIUM和HIGH。 CVSS 3的新版本又增加了两个：NONE和CRITICAL。
因此，漏洞的数量不仅随月份和年份变化，而且随着严重性变化。
CVSS等漏洞评级机制使Linux供应商能够评估如何响应特定的内核漏洞。例如，他们可能想编写累积分数为7或更高的漏洞补丁程序。这意味着在CVSS v2中为HIGH，在CVSS v3中为HIGH或CRITICAL。声称针对关键漏洞的供应商只能在使用CVSS v3时引用严重等级为9和10的漏洞。
4.我可以回滚补丁吗？
在没有任何监督的情况下自动安装补丁对于许多系统管理员来说是一个可怕的主意。他们知道，即使经过全面测试的修复程序也可以改变系统的行为，从而以微妙且不完全明显的方式影响其性能或功能。发生这种情况时，如果服务器在安装补丁后的行为异常，则处理它的最快方法是删除补丁。
一些实时补丁服务可以删除补丁。这使确定最近的更新是否引起系统行为的更改变得更加容易。
5.我可以托管自己的补丁程序服务器吗？
修补软件代理会实时检查远程Patch服务器上的可用修补程序。它定期且可配置的间隔执行此操作，通常具有执行自定义检查的功能。如果有补丁，代理软件将下载并安装。但是，如果修补程序代理无法与供应商的修补程序存储修补程序的修补程序服务器进行通信，则不会进行实时修补。
要解决此问题，您需要创建自己的补丁程序服务器。这样的本地服务器会将修补程序广播到防火墙下您公司中的所有计算机。Copy Safe将下载修补程序，然后在检查修补程序文件的完整性之后将其通过防火墙分发。您可以通过使公司董事会放松一些来方便地管理和审核此过程。
还有其他好处：
- 您可以更好地控制服务器接收哪些补丁以及何时接收。
- 您可以为已知的补丁程序级别阻止大量服务器。
- 分离服务器群集以进行开发，测试，登台和生产更加容易。
动态修补需要本地代理和远程修补服务器。控制两者对于企业部署至关重要。
结论
醒来之前，这里还有三个问题要问一个潜在的补丁解决方案提供商：
- 我可以取消自动续约吗？有时候，您不想自动更新内核。
- 它在什么平台上工作？虽然您的服务器环境可能会排除选择实时修补解决方案的任何灵活性，但是最好是，您对服务的订阅不限制您需要使用的Linux变体。
- ? , Linux. . , .
它们在修补供应商产品说明中不那么突出的事实并不会使本文中描述的功能变得不那么重要。这些因素都会影响您与特定供应商联系的决定。所有这些都会直接影响解决方案对您的环境的有效性和相关性。由于服务器订阅费用从每月几十美元到每年数千美元不等，因此在选择Linux内核补丁解决方案时要格外小心。
阅读更多：
安装和配置AlienVault SIEM（OSSIM）
10个最佳实践，以保护Docker映像。第1部分
保护Docker映像的10个最佳实践。第2部分