CentOS 7 在 2024 年 6 月 30 日正式停止维护后，大量企业业务被迫迁移。迁移本身不是最难的，最难的是迁移过程中和迁移后的安全防护如何不出现空档。很多运维团队把精力全部放在系统替换和应用兼容性上，等业务跑起来才发现安全基线、访问控制、审计日志、内核防护全都断档了。CentOS 停服意味着不会再有任何安全补丁，哪怕是一个高危的内核漏洞，也不会有人给你修。所以在迁移窗口期内，防护策略必须跟着业务一起走，而不是迁移完成后再补。

迁移前的第一件事不是选系统，而是做资产和依赖梳理。把当前 CentOS 服务器上跑的服务、监听的端口、对外开放的接口、计划任务、系统用户、SSH 配置、防火墙规则、SELinux 状态、内核版本、已安装的安全组件全部列出来。很多服务器跑了好几年，上面到底开了哪些端口、有哪些测试账号、哪些临时放行的 iptables 规则，运维自己都说不清楚。迁移正好是一次强制清理的机会。建议用脚本批量采集，例如 

ss -tulnp && systemctl list-unit-files --state=enabled && crontab -l && awk -F: '$3>=1000 {print $1}' /etc/passwd
把关键信息导出成清单。这个清单不仅是迁移的依据，也是后续安全基线重建的对照表。

目标系统的选择直接决定后续防护的可持续性。CentOS 停服后，主流的替代方向是 Rocky Linux、AlmaLinux、Ubuntu LTS、Debian 或者直接上 RHEL。如果业务对 RHEL 生态依赖很深，Rocky Linux 和 AlmaLinux 是二进制兼容的选择，迁移成本最低，安全工具和 SELinux 策略基本可以沿用。如果团队对 Debian 系更熟悉，Ubuntu LTS 的十年维护周期和及时的 CVE 修复也是稳妥选择。不要选那些小众发行版或者滚动更新版本，生产环境的安全维护需要的是稳定和可预期。选定系统后，第一时间配置好官方安全更新源，并启用自动安全更新，至少做到安全补丁自动下载通知，关键漏洞可以手动审批后快速安装。

迁移过程中的数据传输安全经常被忽略。很多团队用 rsync 或 scp 直接在内网传输数据，觉得内网就是安全的。但内网横向攻击恰恰是现在勒索病毒的主要传播路径。迁移数据量大时，建议使用加密通道传输，并且对传输的数据做完整性校验。例如用 rsync over SSH 并加上校验参数：

rsync -avz --checksum -e "ssh -p 22" /data/ user@目标IP:/data/
如果数据量特别大，需要临时开放网络策略，迁移完成后必须立即回收这些临时规则。迁移期间不要把目标服务器的 SSH 端口暴露在公网，所有远程操作通过堡垒机或跳板机完成。临时使用的迁移账号在迁移结束后必须禁用或删除，不能留在系统里变成后门。

系统迁移完成后，安全基线必须立即重建，而不是等业务稳定后再做。第一项是账户和认证策略。检查 /etc/passwd 中是否有异常 UID 为 0 的账户，禁用 root 直接 SSH 登录，统一使用密钥认证，密码认证要么关闭要么强制使用高强度密码策略。修改 SSH 默认端口不是安全手段，但可以减少大量自动化扫描噪音。更有效的是配置 fail2ban 或 sshguard，对暴力破解进行自动封禁。第二项是防火墙。CentOS 上很多人习惯用 iptables，迁移到新系统后如果换成了 firewalld 或 nftables，规则不能直接照搬，需要重新梳理放行策略。默认拒绝所有入站流量，只放行业务必须的端口，管理端口限制来源 IP。第三项是 SELinux 或 AppArmor。很多运维在 CentOS 上第一件事就是关 SELinux，迁移到新系统后如果继续关闭，等于放弃了内核级强制访问控制。建议在新系统上开启 SELinux 并设置为 enforcing 模式，业务如果因为 SELinux 策略报错，用 audit2allow 生成自定义策略，而不是直接关掉。

内核和系统加固是迁移后必须立即执行的动作。新系统安装后，内核参数默认值并不适合所有业务场景，但安全相关的参数需要优先调整。例如开启地址空间布局随机化、限制 core dump、开启 SYN cookie 防护、禁止 ICMP 重定向、记录 martian 报文等。这些可以通过 sysctl 配置实现：

net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.tcp_syncookies = 1
kernel.randomize_va_space = 2
fs.suid_dumpable = 0
同时检查系统中是否有不必要的 SUID 程序，尤其是 find、vim、less、awk 这类工具如果被设置了 SUID，就是提权漏洞的温床。用 
find / -perm -4000 -type f 2>/dev/null
列出所有 SUID 文件，逐个确认是否业务必需，不需要的用 chmod u-s 去掉。

日志和审计是迁移后安全防护中最容易被忽视的一环。CentOS 上很多人用 rsyslog 简单记录一下系统日志就完了，迁移后建议直接上 systemd-journald 配合 rsyslog 或 syslog-ng 做集中式日志收集。至少保证 auth.log、secure、kern.log、audit.log 这些关键日志被完整记录并且有异地备份。如果条件允许，部署 auditd 对关键文件和目录做审计规则，例如监控 /etc/passwd、/etc/shadow、/etc/sudoers、/etc/ssh/sshd_config 的修改，监控所有用户对 /root 和 /home 下敏感文件的访问。审计规则示例：

auditctl -w /etc/passwd -p wa -k identity_change
auditctl -w /etc/shadow -p wa -k identity_change
auditctl -w /etc/sudoers -p wa -k privilege_change
auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config_change
日志的价值在于出事后能回溯，但前提是日志本身没有被篡改或删除。集中式日志服务器和只读挂载是基本要求。

应用层的安全防护不能只靠系统层。迁移后要重新审视业务应用本身的配置。Web 服务要检查是否还在使用过时的 TLS 版本，证书是否在迁移过程中过期或泄露了私钥。数据库服务要确认监听地址是否仍然是对公网开放，迁移过程中是否有人为了方便调试把 bind-address 改成了 0.0.0.0。中间件和缓存服务如 Redis、Memcached 必须检查是否设置了认证，默认端口是否暴露。很多安全事件不是因为系统漏洞，而是因为 Redis 没设密码、MongoDB 没开认证、Elasticsearch 裸奔在公网上。迁移后做一次全端口扫描，对照业务清单逐个确认每个开放端口的必要性，关闭一切非必要服务。扫描可以用 nmap 完成：

nmap -sS -sV -p- 目标IP
把扫描结果和迁移前的资产清单做对比，任何多出来的端口都要查清楚来源。

备份和应急响应是安全防护的最后一道防线。迁移完成后，很多团队觉得系统是新的，备份可以缓一缓。但新系统上线初期恰恰是配置变更最频繁、最容易出错的阶段。建议在迁移完成后的第一时间就配置好自动化备份，至少覆盖系统配置文件、业务数据、数据库、日志关键目录。备份数据要加密存储，并且定期做恢复演练，确认备份真的能还原。同时准备一份应急响应手册，明确出现安全事件时的处理流程：如何隔离受感染主机、如何保留现场证据、如何从备份恢复、如何通知相关方。手册要具体到命令级别，而不是写一些“及时处理”的空话。

CentOS 迁移不是简单的系统重装，而是一次安全体系的重新构建。停服带来的风险不会因为换了一个新系统就自动消失，反而会因为迁移过程中的配置遗漏、临时放行、测试账号、关闭的安全功能而放大。真正稳妥的做法是把安全防护嵌入到迁移的每一个阶段：迁移前做资产清点和风险评估，迁移中做加密传输和最小权限控制，迁移后立即重建安全基线、开启内核防护、部署审计日志、验证备份恢复。只有把安全当成迁移的一部分来执行，业务才能在 CentOS 停服之后继续稳定运行，而不是从一个坑跳进另一个坑。