如何在 CentOS 7 上执行可重现的安全修补程序

如何在 CentOS 7 上执行可重现的安全修补程序

总结: 即使在修补活动结束之前有较新的安全更新可用,如何确保可以在许多服务器上以可重现的方式制作软件包更新列表?

在受到监管限制的公司中,服务器的安全更新需要以可重复的方式进行:确定关键 CVE 列表,从而生成要更新到特定版本的软件包列表。这些更新需要应用于许多服务器,从开发到准备和生产。

应用这些更新可能需要很长时间,并且即使其间有较新的安全更新可用,也必须确保在每台服务器上进行相同的更改。

我认为使用类似这样的命令来指定版本yum update package-version是行不通的,因为较新的软件包会替换 CentOS 存储库中的较旧软件包(至少对于安全更新而言)。因此我们可能不会始终应用完全相同的版本。

运营团队希望使用 Landesk,并在本地网络上实施 CentOS 存储库副本(供每台服务器使用,而不是普通的 CentOS 存储库),他们计划在该副本上制作某种软件包“快照”,存放在特定的带时间戳的存储库中(如“repo_xxx_20191019”)。为了应用安全更新,他们计划更新每台目标服务器的存储库配置以添加带时间戳的存储库,并以此方式更新软件包。

我认为它可以工作,但有什么需要注意的吗?或者有更简单的方法可以达到相同的效果?

答案1

系统而快速。

您的修补程序需要能够非常快速地应用更新来应对最严重的威胁。最坏的情况下,可能需要几个小时而不是几天的时间。攻击者不会等待您的文件,您可以在事后提交紧急变更控制。

假设您通常每月进行更新。第 1 周测试系统,第 2 周准备,第 4 周生产。每个月的更新包集在本地存储库中定义明确,并且效果很好。

第 2 周,发布了一个关键更新。CVSS 评分为 10,系统正在被恶意入侵。非常糟糕。必须尽快修补,不能等。

现在你需要做出选择。创建一个小型的临时包并将其安装在任何地方,或者将其添加到待处理的更新中并加速投入生产。


您可以通过几种方式暂存更新存储库。实际上,重要的是设置和测量主机未打补丁的时间长度指标。并且有一个在必要时快速采取行动的流程。

相关内容