CentOS 7 在 2024 年 6 月 30 日正式结束生命周期后，官方源已经停止更新。很多企业服务器仍然在运行 CentOS 7，运维团队面临的最大问题不是“要不要换系统”，而是“在迁移完成之前，漏洞库怎么更新、怎么堵住安全缺口”。如果直接放任不管，内核漏洞、OpenSSL 漏洞、glibc 漏洞会持续暴露在公网环境下。实际可行的做法是切换到 CentOS Vault 归档源，或者迁移到 Rocky Linux、AlmaLinux 的兼容源继续获取安全补丁，同时配合本地漏洞扫描和热修复工具做兜底。
先说最紧急的部分：CentOS 7 停止维护后，默认的 /etc/yum.repos.d/CentOS-Base.repo 里 mirrorlist 已经失效。很多运维发现 yum update 直接报 404 或者超时，就是因为官方把 7 的包从主镜像挪到了 vault.centos.org。要恢复更新能力，需要把 repo 文件里的 baseurl 改成归档地址。下面是一个可用的配置示例：
[base] name=CentOS-7 - Base baseurl=http://vault.centos.org/7.9.2009/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 enabled=1 [updates] name=CentOS-7 - Updates baseurl=http://vault.centos.org/7.9.2009/updates/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 enabled=1
但要注意，Vault 源里的 updates 目录在 2024 年 6 月 30 日之后不会再新增任何包。也就是说，你改完源能解决“历史补丁装不上”的问题，但解决不了“新漏洞没人修”的问题。对于还在跑生产业务的 CentOS 7 服务器，这个源只能作为过渡期的保底手段，不能当作长期安全方案。
更实际的长期方案是切换到 Rocky Linux 或 AlmaLinux 的兼容源
Rocky Linux 和 AlmaLinux 都提供了针对 CentOS 7 的迁移脚本和兼容仓库。以 Rocky Linux 为例，官方有 migrate2rocky 工具，可以在不重装系统的情况下把 CentOS 7 转换成 Rocky Linux 8 或 9。但很多生产环境不敢直接跑迁移，担心应用兼容性问题。折中办法是保留 CentOS 7 系统，只把 yum 源指向 AlmaLinux 的 CentOS 7 兼容仓库。AlmaLinux 在 2024 年之后仍然为 CentOS 7 用户提供了一段时间的安全更新，虽然覆盖范围有限，但至少内核和关键基础库的 CVE 补丁还能拿到。
具体操作是把 /etc/yum.repos.d/ 下的 CentOS-Base.repo 替换为 AlmaLinux 提供的 centos7 兼容源配置。核心 baseurl 格式如下：
[base] name=AlmaLinux $releasever - Base baseurl=https://repo.almalinux.org/almalinux/7/base/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux enabled=1 [updates] name=AlmaLinux $releasever - Updates baseurl=https://repo.almalinux.org/almalinux/7/updates/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux enabled=1
切换源之前一定要先备份原有 repo 文件，并且做一次完整的 rpm 数据库校验。切换后先执行 yum clean all 和 yum makecache，再跑 yum update --security 只装安全更新，避免一次性引入太多非安全类包导致业务异常。生产环境建议先在测试机上验证，确认应用没有因为 glibc 或 openssl 版本变化而崩溃，再灰度到正式服务器。
漏洞扫描和修复优先级不能只靠 yum update
很多运维以为 yum update 跑完就安全了，实际上 CentOS 7 的很多漏洞根本不在官方仓库的修复范围内。比如内核模块、第三方软件、Web 中间件、数据库、PHP 扩展这些，很多都是源码编译或者外部仓库安装的，yum 管不到。所以漏洞库更新必须配合漏洞扫描工具来做。ClamAV 只能查病毒，查 CVE 漏洞要用 OpenSCAP 或者商业扫描器。
OpenSCAP 在 CentOS 7 上可以直接用，配合 SCAP Security Guide 里的 OVAL 定义做合规扫描。安装命令：
yum install openscap-scanner scap-security-guide oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_standard --report /tmp/report.html /usr/share/xml/scap/ssg/content/ssg-centos7-xccdf.xml
扫描报告会列出系统里已知 CVE 对应的未修复包。关键是扫描完之后要建立修复优先级：高危远程代码执行漏洞优先处理，本地提权漏洞其次，信息泄露类漏洞最后处理。不要看到报告里几百个漏洞就慌，很多低危漏洞在特定网络环境下根本不会被利用，盲目打补丁反而可能把业务打挂。
内核漏洞是 CentOS 7 运维中最难处理的部分
CentOS 7 的默认内核是 3.10，这个内核版本在 2024 年之后基本不会再收到上游修复。像 Dirty Pipe、Dirty COW 这类内核级漏洞，如果系统还在跑老内核，即使 yum 源换了也没用。解决办法有两个：一是手动升级到 CentOS 7 最后一个可用内核版本 3.10.0-1160 系列，这个版本在 Vault 源里还能找到；二是启用 ELRepo 仓库安装更新的主线内核，比如 kernel-ml 5.4 或 6.x。但主线内核在生产环境风险较大，很多商业软件和驱动不兼容，只建议在测试环境验证后使用。
对于无法重启的内核漏洞修复，可以用 KernelCare 或者 ksplice 这类热补丁工具。KernelCare 对 CentOS 7 的支持在 EOL 后仍然持续了一段时间，可以在不重启服务器的情况下修复内核 CVE。但热补丁不是万能的，它只能修复特定类型的漏洞，而且商业授权费用不低。预算有限的团队可以考虑用 kpatch 自己做热补丁，但技术门槛较高，需要熟悉内核编译和补丁制作流程。
OpenSSL 和 glibc 的漏洞处理要格外谨慎
CentOS 7 自带的 OpenSSL 是 1.0.2k 版本，这个版本在 2024 年之后仍然有多个高危 CVE 被披露。由于 CentOS 7 已经停止维护，官方不会再发布 OpenSSL 1.0.2 的安全更新。运维团队如果继续使用系统自带的 OpenSSL，等于把 HTTPS 加密通道暴露在已知漏洞下。解决方案是编译安装 OpenSSL 1.1.1w 或 3.0.x 到 /usr/local/openssl 目录，然后让 Nginx、Apache、PHP 等应用链接到新版本。注意不要直接替换系统自带的 libssl.so，否则会导致 yum、ssh 等系统工具因为 ABI 不兼容而崩溃。
glibc 的情况类似，CentOS 7 的 glibc 2.17 已经非常老旧，很多 CVE 无法通过官方源修复。但 glibc 是系统最底层的库，手动升级风险极高，稍有不慎整个系统就起不来。对于 glibc 漏洞，更稳妥的做法是通过网络层防护来缓解，比如在防火墙或 WAF 上阻断针对 glibc 漏洞的攻击流量，同时加快系统迁移到 Rocky Linux 9 或 AlmaLinux 9 的进度。
日常运维中建立漏洞库更新机制比临时救火更重要
很多 CentOS 7 服务器出问题，不是因为运维技术不行，而是因为没有建立定期更新和扫描的制度。建议每周固定时间执行一次 yum update --security，每月做一次全量漏洞扫描，每季度做一次补丁回归测试。更新之前一定要做快照或者备份，尤其是数据库服务器和核心业务服务器。快照可以用 LVM 快照或者云平台自带的快照功能，确保更新失败能快速回滚。
另外要关注漏洞情报源。CentOS 7 停止维护后，Red Hat 不再发布 CentOS 7 的安全公告，但 Rocky Linux 和 AlmaLinux 会发布自己的安全公告。运维可以订阅这些发行版的 security-announce 邮件列表，或者关注 CVE 数据库的 RSS 源。一旦出现针对 Linux 3.10 内核或 OpenSSL 1.0.2 的新漏洞利用代码，要第一时间评估自己服务器是否受影响。
迁移到 Rocky Linux 或 AlmaLinux 是最终出路
无论怎么打补丁、换源、做热修复，CentOS 7 的基础架构已经停止演进。继续在上面运行生产业务，安全风险会随着时间推移越来越大。最彻底的解决方案是制定迁移计划，把 CentOS 7 服务器逐步迁移到 Rocky Linux 8/9 或 AlmaLinux 8/9。迁移方式有两种：一是原地迁移，用 migrate2rocky 或 almalinux-deploy 脚本直接转换系统；二是重新部署，在新系统上重新安装应用并迁移数据。原地迁移速度快，但可能遗留旧配置和旧依赖；重新部署更干净，但工作量大。对于核心业务，建议采用重新部署的方式，确保新系统从内核到应用层都是干净且受支持的。
迁移过程中要注意应用兼容性。CentOS 7 上的很多老软件依赖 Python 2、OpenSSL 1.0、glibc 2.17，这些在 Rocky Linux 9 上已经不存在。如果应用无法升级，可以考虑先用 Rocky Linux 8 过渡，因为 8 的兼容性比 9 更好，同时支持周期也更长。Rocky Linux 8 的维护周期到 2029 年，足够企业完成应用改造和升级。
CentOS 7 的漏洞库更新运维本质上是一个过渡期的安全管理工作。短期内靠 Vault 源和 AlmaLinux 兼容源续命，中期靠漏洞扫描和热补丁工具兜底，长期必须完成系统迁移。运维团队要做的不是纠结于“CentOS 7 还能不能用”，而是把每一台 CentOS 7 服务器都纳入明确的漏洞管理和迁移计划中，确保在过渡期内不出现重大安全事故。
