CentOS服务器漏洞扫描与补丁修复周期

CentOS 7 的生命周期已于 2024 年 6 月 30 日正式终结，CentOS Stream 8 的维护窗口也将在 2024 年 5 月 31 日关闭。这意味着绝大多数运行 CentOS 的生产服务器，从这一刻起，已经进入了裸奔状态。继续使用这些系统，你将不再收到来自上游的安全补丁，内核漏洞、glibc 溢出、OpenSSL 心脏滴血等已知高危漏洞将永远无法通过官方 yum update 修复。这不是危言耸听，而是摆在每一位运维人员面前的严峻现实。你需要立刻建立一套脱离官方支持的漏洞扫描与补丁修复机制，否则服务器被攻破只是时间问题。

CentOS 官方源已经归档到 vault.centos.org，这个归档源不会再有任何更新。要让 yum 继续工作，必须将源地址指向 CentOS Vault 或第三方镜像。执行以下命令快速替换：

sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-*

但这一步仅仅恢复了软件安装能力，并没有解决补丁来源问题。Vault 里的 RPM 包是停更前的最后一个快照，CVE 漏洞依然存在。真正的补丁来源需要转向两个方向：一是 CentOS Stream 的持续更新源，如果你愿意承担滚动更新的风险；二是第三方长期支持项目，例如 CloudLinux 的 TuxCare、AlmaLinux 的 ELevate 迁移工具，或者直接购买红帽的 ELS 附加支持。对于无法迁移的关键业务，TuxCare 提供的 Extended Lifecycle Support 能直接为 CentOS 7 内核、glibc、OpenSSL 等核心组件推送修复补丁，且无需重启服务，这是目前最接近官方体验的修补方案。

OpenSCAP 是 Linux 漏洞评估的基线工具，但很多人只用它扫描就结束了，这远远不够。正确的做法是将 OpenSCAP 与 SCAP Security Guide 结合，针对 CentOS 系统生成定制化的检查清单。安装后执行：

yum install openscap-scanner scap-security-guide -y
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_standard \
--results scan-results.xml --report scan-report.html \
/usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml

这份报告会列出所有不符合基线配置的项目，但它的漏洞库依赖 CVE 字典的本地版本，更新频率滞后。你需要配合 vuls 或 trivy 这类主动扫描工具。vuls 的优势在于能直接读取目标服务器的包版本，与多个漏洞数据库交叉比对，且支持通过 SSH 无 Agent 扫描。部署 vuls 后，针对 CentOS 7 的扫描命令大致如下：

vuls scan centos7-server
vuls report -format-json -cvedb-path=/path/to/cve.sqlite3

trivy 则更轻量，一条命令就能扫出系统包和已安装应用的漏洞，还支持生成 HTML 报告方便归档：

trivy rootfs --scanners vuln / -f html -o centos7-report.html

这两款工具的关键在于漏洞数据库必须保持每日更新。vuls 依赖 go-cve-dictionary 拉取 NVD 数据，trivy 内置了自动更新机制。没有实时漏洞库的扫描等于白做。此外，对于无法安装第三方工具的极简生产环境，至少要用 rpm 结合 changelog 手动核查高危包版本，例如检查内核版本是否受 Dirty Pipe 漏洞影响：

rpm -q --changelog kernel | grep -i CVE-2022-0847

如果返回空，说明当前内核未包含该漏洞的修复记录，必须立即升级或打热补丁。

漏洞扫描完成后，面对几十上百个漏洞，不可能一次性全部修复，重启带来的业务中断风险往往比漏洞本身更可怕。你需要按照 CVSS 评分和服务暴露面来划分修复优先级。CVSS 9.0 以上且攻击向量为网络可达的漏洞，修复周期不应超过 24 小时。例如一个面向公网的 Nginx 反向代理服务器，如果扫描出 OpenSSL 的高危漏洞，必须立即执行热修复或服务切换，绝不能等到周末维护窗口。对于 CVSS 7.0 到 8.9 的漏洞，修复周期可以放宽到一周，但前提是攻击复杂度高或需要本地认证才能利用。CVSS 7.0 以下且攻击向量为本地访问的漏洞，可以合并到月度例行维护中处理。

修复手段上，传统 yum update 在 CentOS 停更后已经失效，你需要掌握三种替代方案。第一种是源码编译修复，从受影响的软件官方仓库拉取最新版本源码，在本地编译生成 RPM 包后安装。以修复 OpenSSH 为例：

yum install rpm-build gcc make openssl-devel pam-devel -y
wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.6p1.tar.gz
tar xzf openssh-9.6p1.tar.gz && cd openssh-9.6p1
./configure --with-pam --with-selinux
make && make install

这种方式能彻底解决漏洞，但编译依赖复杂，容易引入新的兼容性问题。第二种是热补丁技术，通过 ksplice 或 kpatch 将修复代码直接注入运行中的内核或用户态进程，完全避免重启。TuxCare 的 KernelCare 和用户态 LibCare 就是基于这个原理，对 CentOS 7 持续提供热补丁支持。第三种是容器化隔离，将受影响的服务迁移到 Docker 或 Podman 容器中，容器镜像使用仍在维护的发行版如 AlmaLinux 9，宿主机只保留最基础的内核和容器运行时。这样即使宿主机内核存在漏洞，攻击面也被极大压缩，而且容器镜像的补丁更新完全不受 CentOS 停更影响。

很多团队做完一轮扫描和修复后就认为高枕无忧了，这是最危险的错觉。新漏洞每天都会披露，上个月刚修复的 glibc 这个月可能又爆出新变种。你必须在服务器上部署持续监控组件，osquery 是目前最灵活的选择。它把操作系统抽象成 SQL 表，你可以编写定时查询来监控关键包的版本变化、监听端口、启动项等。例如监控内核版本是否低于修复 Dirty Pipe 的最低版本 3.10.0-1160.59.1：

SELECT version FROM kernel_info WHERE version < '3.10.0-1160.59.1.el7';

将 osquery 接入 ELK 或企业内部的安全信息平台，一旦发现不符合基线的情况立即告警。同时，用 AIDE 或 Tripwire 建立文件完整性监控，防止补丁文件被恶意替换。AIDE 初始化数据库后，任何对 /bin、/sbin、/lib 等关键目录的修改都会触发告警：

aide --init
mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
aide --check

这套监控体系配合每日自动运行的 trivy 或 vuls 扫描，才能形成漏洞发现、评估、修复、验证的完整闭环。扫描结果要自动推送到运维群组或工单系统，修复动作要记录到变更管理平台，修复后的验证扫描要自动比对前后漏洞数量，确保漏洞真正被消除而不是被掩盖。

所有针对 CentOS 停更的补救措施，本质上都是争取迁移时间的临时方案。热补丁有成本，源码编译有风险，容器化隔离无法解决所有问题。你的团队必须在执行上述应急措施的同时，启动向 AlmaLinux、Rocky Linux 或 Ubuntu LTS 的迁移评估。AlmaLinux 提供了 ELevate 工具，支持从 CentOS 7 就地升级到 AlmaLinux 8，整个过程中应用配置保持不变，这比传统的数据备份、重装系统、恢复数据流程快得多。迁移前务必在测试环境验证应用兼容性，特别是那些依赖特定 glibc 版本或内核模块的遗留系统。对于实在无法迁移的古董应用，考虑用虚拟机快照加网络隔离的方式将其封存在内网孤岛中，切断一切外部访问路径，让它以最小权限运行，直到业务生命周期结束。

漏洞管理从来不是一次性工程，尤其在 CentOS 失去官方支持的当下，它已经变成了需要每日关注的持续性运维任务。你投入的每一分精力，都是在为业务争取安全存活的时间窗口。立即行动，从切换软件源、部署扫描工具、建立分级修复机制开始，然后尽快把迁移提上日程。服务器安全没有侥幸，只有扎实的工程实践才能守住底线。