CentOS停服后，漏洞修复的逻辑已经变了。以前是yum update一把梭，现在官方源不再更新，意味着新披露的CVE不会再有官方补丁推送到你的服务器上。很多运维人员还在用老思路等补丁，这恰恰是当前最大的风险点。正确做法是立即切换到一个可持续获取安全更新的软件源，同时建立一套不依赖官方支持的安全基线。
对于CentOS 7用户，最平滑的过渡方案是切换至OpenAnolis或AlmaLinux的兼容源。以OpenAnolis为例，它提供与CentOS 7二进制兼容的仓库，可以直接接管后续的安全更新。操作前务必先备份现有repo文件，然后执行替换。具体命令如下：
mkdir -p /etc/yum.repos.d/backup mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/ curl -o /etc/yum.repos.d/AnolisOS.repo https://mirrors.openanolis.cn/centos/7/anos7-repo yum clean all && yum makecache
切换后不要立即全量升级，先执行yum check-update查看可用更新列表，重点筛选标记为security的更新。全量升级可能引入不兼容的库版本，对于生产环境，建议先在与生产配置一致的测试机上验证。如果业务不允许停机，至少要对glibc、openssl、kernel这类基础组件做灰度升级。
对于CentOS 8用户，情况更紧迫，因为CentOS 8在2021年底就已停止维护。官方推荐的迁移路径是转换到CentOS Stream，但Stream属于滚动更新，稳定性不如传统发行版。生产环境更稳妥的选择是使用AlmaLinux的迁移脚本，它可以将CentOS 8原地转换为AlmaLinux 8，整个过程约10到20分钟，业务中断时间取决于重启速度。执行前必须对系统盘做快照或镜像备份。
curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh bash almalinux-deploy.sh reboot
迁移完成后检查/etc/redhat-release确认系统身份已变更，再执行dnf update完成安全更新。这里要强调一个容易被忽略的点：迁移后部分第三方软件源（如EPEL、Remi）的配置文件仍然指向CentOS，需要手动修改$releasever变量的解析结果，否则会出现依赖冲突或拉取到过期包的情况。
内核漏洞的独立修复策略很多安全公告涉及的漏洞位于内核模块中，而业务系统往往因为兼容性问题不能随意升级内核。这种情况下，需要区分对待：对于可以被独立修复的内核模块漏洞，优先使用kpatch或kexec工具进行热补丁修复，避免重启。CentOS环境下kpatch需要订阅红帽的补丁服务，但社区提供了kpatch-build工具，可以从源码构建热补丁。对于无法热修复的漏洞，比如涉及核心内存管理或调度器的缺陷，必须安排维护窗口进行内核升级。
内核升级后要特别注意驱动兼容性。很多服务器使用特定型号的RAID卡或网卡，新内核可能不再包含对应的闭源驱动。升级前用lsmod和lspci -k记录当前加载的驱动模块，升级后逐一比对。如果发现驱动丢失，优先从硬件厂商官网获取针对新内核版本的驱动包，而不是使用elrepo等第三方仓库中的通用驱动，后者在特定硬件上可能引发稳定性问题。
SSH暴露面收紧与访问控制CentOS服务器最常见的入侵入口就是SSH。默认配置下，22端口对所有IP开放，且允许密码登录，这给暴力破解留下了空间。第一层防护是修改SSH监听端口并禁用密码登录，强制使用密钥认证。修改/etc/ssh/sshd_config中的以下参数：
Port 22022 PasswordAuthentication no PermitRootLogin prohibit-password PubkeyAuthentication yes AllowUsers deployuser
修改后执行systemctl restart sshd使配置生效。但仅靠改端口和禁用密码还不够，因为端口扫描可以快速发现新端口。更有效的做法是结合防火墙做来源IP白名单。如果运维团队有固定的办公出口IP，直接在firewalld中添加rich rule，只允许这些IP访问SSH端口。对于没有固定IP的场景，可以考虑使用跳板机架构，所有SSH流量必须经过跳板机转发，服务器本身只信任跳板机的IP。
还有一个常被忽视的细节：SSH的MaxAuthTries参数默认是6，建议调整为3，同时设置LoginGraceTime为30秒，这样可以在暴力破解尝试时快速断开连接，降低日志噪音和资源消耗。对于需要对外开放SSH但又无法做IP白名单的服务器，可以部署fail2ban，但要注意fail2ban本身也会消耗资源，且在高并发攻击下可能误封正常用户，需要合理设置bantime和findtime。
系统服务最小化与权限收敛漏洞修复的另一个核心思路是减少攻击面。CentOS默认安装会启用一些不必要的服务，比如postfix、chronyd、firewalld之外的avahi-daemon、cups等。执行systemctl list-unit-files --type=service --state=enabled查看所有开机自启的服务，逐一确认其必要性。对于不需要的服务，执行systemctl disable --now 服务名将其停止并禁用。
权限收敛方面，重点检查/usr/bin/passwd、/usr/bin/su、/usr/bin/sudo等具有特殊权限位的文件。使用find / -perm -4000 -type f命令列出所有SUID文件，对不需要SUID权限的程序执行chmod u-s。特别是/usr/bin/pkexec，历史上出现过多个提权漏洞，如果业务不依赖polkit，直接移除该文件的SUID位。
文件系统层面，建议对/tmp目录单独挂载并添加noexec、nosuid挂载选项。很多攻击者会利用/tmp目录上传并执行恶意脚本，noexec可以阻断这一路径。修改/etc/fstab中/tmp对应的行，添加挂载选项后重新挂载：
mount -o remount,noexec,nosuid /tmp
对于/var/tmp和/dev/shm同样建议添加noexec选项。但要注意，部分应用程序（如某些Java应用、数据库临时文件操作）可能依赖这些目录的可执行权限，修改前需要在测试环境验证。
日志审计与入侵检测的常态化运行漏洞修复不是一次性动作，安全防护必须建立在持续的可见性之上。CentOS服务器至少需要配置三方面的日志：系统日志、安全日志、以及关键应用的访问日志。rsyslog默认配置下，安全相关日志写入/var/log/secure，但默认轮转策略可能很快覆盖历史记录。建议在/etc/logrotate.d/syslog中调整rotate保留份数到12以上，并启用压缩。
更关键的是日志的集中收集。单机日志在服务器被入侵后可能被攻击者清除，失去审计价值。部署一台独立的日志服务器，使用rsyslog的TCP或RELP协议将各服务器的日志实时转发过去。配置方法是在客户端/etc/rsyslog.conf中添加：
*.* @@日志服务器IP:514
日志服务器端需要配置相应的接收模块和存储策略。对于安全敏感的场景，还可以考虑使用auditd对关键文件（如/etc/passwd、/etc/shadow、/etc/sudoers）的访问和修改进行审计记录。
入侵检测方面，对于CentOS服务器，可以部署开源的文件完整性监控工具，比如AIDE或Tripwire。这类工具会对系统中的关键文件生成哈希基线，一旦文件被篡改就能及时发现。AIDE的配置相对简单，初始化数据库后设置cron定时任务每天检查一次，将结果发送到运维邮箱或集中日志平台。需要注意的是，系统正常更新会导致大量文件哈希变化，因此在每次执行yum update后需要重新初始化AIDE数据库，否则会产生大量误报。
防火墙策略的精细化配置很多CentOS服务器的防火墙只做了基本的端口开放，缺乏对连接状态和流量特征的过滤。firewalld默认的public区域允许所有入站连接到达已开放端口，但并没有对连接速率、来源地域等维度做限制。建议在firewalld中使用rich rule添加连接速率限制，例如对SSH端口：
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="0.0.0.0/0" port port="22022" protocol="tcp" limit value="5/m" accept'
这条规则限制每个来源IP每分钟最多建立5个新的SSH连接，超出后自动丢弃，能有效缓解暴力破解。对于Web服务，如果业务只面向国内用户，可以在防火墙层面屏蔽境外IP段。虽然IP地理库存在一定误差，但能过滤掉大部分来自海外的扫描和攻击流量。
出站流量的控制同样重要。很多攻击者在获取服务器权限后会尝试外联下载恶意工具或回传数据。默认情况下firewalld允许所有出站流量，建议改为白名单模式：先拒绝所有出站，再按需放行DNS（UDP 53）、HTTP（TCP 80）、HTTPS（TCP 443）以及业务必需的出站端口。这样即使服务器被攻破，攻击者的外联行为也会受到限制。
定期漏洞扫描与修复闭环常态化防护的核心是建立周期性的漏洞发现与修复流程。对于CentOS服务器，建议每周执行一次本地漏洞扫描。可以使用OpenSCAP工具配合SCAP安全基线进行合规检查，OpenSCAP能够根据CVE数据库比对系统已安装的软件包版本，输出缺失的安全更新列表。安装和执行命令如下：
yum install openscap-scanner scap-security-guide 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
扫描报告会以HTML格式展示，列出所有不符合安全基线要求的项目。修复时不要盲目按照报告全量处理，需要结合业务影响评估。对于高危漏洞，必须在24小时内完成修复或采取临时缓解措施；对于中低危漏洞，可以纳入下一个维护窗口统一处理。
修复完成后必须进行验证。验证方式包括：重新运行漏洞扫描确认问题已消除；检查相关服务的运行状态和日志，确保修复没有引入新的故障；对于Web应用，还需要进行回归测试。整个流程要形成文档记录，包括漏洞描述、影响范围、修复操作、验证结果，以便后续审计和经验积累。
CentOS服务器的安全防护没有终点。在官方支持停止后，运维团队需要承担起更多的安全责任。从切换到可持续更新的软件源，到内核与系统组件的独立修复，再到SSH加固、服务最小化、日志审计、防火墙精细化配置，以及周期性的漏洞扫描与修复闭环，这些措施共同构成了一套不依赖官方支持的常态化防护体系。关键在于把这些动作固化为日常运维流程，而不是等到漏洞被利用后才被动响应。
