CloudLinux 提供到 2024 年的扩展支持，以保护您的 CentOS 6 服务器免受新的 OpenSSL 漏洞的影响。
OpenSSL 最近发布了一个安全补丁，用于影响任何运行 1.0.2 和 1.1.1 版本的服务器的高级发现。 不幸的是，OpenSSL 宣布它不会发布针对 CentOS 6 的补丁，只会发布 CentOS 7 和 CentOS 8。这使得任何运行未打补丁的 OpenSSL 的服务器（包括 CentOS 6 操作系统）都容易受到拒绝服务 (DoS) 的攻击，其中软件、关键服务、否则操作系统可能会崩溃。 然而，CloudLinux 将修补 OpenSSL 的当前版本、不受支持的 1.0.1 版本以及运行 CentOS 6 操作系统的服务器。
CVE-2020-1971 的漏洞详细信息
OpenSSL 有一个名为 GENERAL_NAME_cmp() 比较两个参数并执行以下两个操作：
- 将 X.509 证书与证书吊销列表 (CRL) 中的项目进行比较。
- 将响应令牌签名者的时间戳与授权名称的时间戳进行比较。
该功能在安全通信中很重要，可确保证书未被吊销。 证书颁发机构 (CA) 组织出于多种原因吊销证书。 如果服务器的私钥因泄露而被盗，CA 将吊销证书以保护通信的完整性。 吊销的其他原因包括证书滥用和必须发布新证书、CA 遭到破坏或 CA 在未经域所有者授权的情况下创建证书。 在任何这些情况下，攻击者都可以伪装成目标域并诱骗用户信任站点，这可能导致复杂的网络钓鱼攻击和敏感数据泄露。
如果攻击者可以控制传递给 GENERAL_NAME_cmp() 函数，如果两个参数属于同一类型，则将满足 DoS 条件。 发现该漏洞的 Google 研究人员能够通过向函数传递类型的两个参数来执行概念验证演示 EDIPartyName，在 OpenSSL 代码中定义。
漏洞的补丁，分配的 ID CVE-2020-1971，于 2020 年 12 月 8 日发布。对开源代码的更改可以在 OpenSSL 的 Github 上找到 存储库. 您可以在 OpenSSL 上阅读有关该漏洞的更多信息 公告 页。
如果 OpenSSL 未打补丁会发生什么？
虽然远程代码执行 (RCE) 不是问题，但未打补丁的服务器可能会受到 DoS 和潜在的分布式拒绝服务 (DDoS) 条件的影响，其中服务可能会脱机并且对用户不可用。 必须保持可用以提高业务生产力或必须在线以满足服务级别协议的关键服务器可能成为攻击者的目标。 CVE 将风险级别设置为“高”，这意味着它被视为组织的严重漏洞。 只有标记为“严重”的漏洞更为严重，这些漏洞大约每五年发生一次。
通过对 CentOS 6 和/或 KernelCare+ 的扩展支持进行缓解
CloudLinux Extended Support for CentOS 6 为其客户提供了这个安全补丁。 CentOS 6 的生命周期结束 (EOL) 是 2020 年 11 月，但 CloudLinux 提供延长支持到 2024 年，以确保服务器免受 openSSL 漏洞的影响，直到管理员可以升级到更新版本的操作系统。 要注册扩展支持，请填写此 形式.
KernelCare 还为 OpenSSL 以及其他几个提供实时修补支持 共享库.
为 CentOS 6 安装 CloudLinux 扩展支持
CloudLinux 扩展支持的安装只需要几个命令。
下载安装程序脚本：
wget https://repo.cloudlinux.com/centos6-els/install-centos6-els-repo.py运行安装程序脚本（请注意，您需要您的许可证密钥）：
python install-centos6-els-repo.py --license-key XXX-XXXXXXXXXXXX上面的命令将安装 centos-els-release 包含存储库 PGP 密钥的包。 您可以通过运行以下命令来确保安装完成：
rpm -q centos-els-release上述命令的输出应显示：
centos-els-release-6-6.10.1.el6.x86_64笔记： 截至 2020 年 12 月 1 日仍在运行 CentOS 的现有客户将自动转换为 EOL 支持。
安装 KernelCare+
KernelCare+ 就像安装 CloudLinux ES 一样简单。 要安装 KernelCare+，请运行以下命令之一：
curl -s -L https://kernelcare.com/installer | bash或者，
wget -qq -O - https://kernelcare.com/installer | bash有关安装 KernelCare+ 的更多信息，请参阅官方 文件.
结论
研究人员指出，这个 OpenSSL 漏洞更难利用，但这并不意味着您应该延迟修补服务器。 无论您打算手动执行此操作、升级到较新版本的 OpenSSL 还是选择通过 KernelCare+ 进行实时修补，请立即执行！ OpenSSL 仍然是最受软件攻击的技术之一，而且 DDoS 攻击比看起来更频繁。
相关阅读：
- 5 个内核实时修补工具，有助于在不重新启动的情况下运行 Linux 服务器
