CentOS 6 如何在当下环境中安全有效地运行与维护

若您仍在与 CentOS 6 这位“老伙计”并肩作战，这份指南正是为您准备的，尽管官方支持已于 2020 年 11 月 30 日终止，不再提供安全更新或错误修复，但现实环境中仍有部分旧系统或应用因各种原因需要继续运行。理解其局限并掌握关键维护策略，是延续 CentOS 6 可用性的核心所在。

正视现实：CentOS 6 的核心挑战

• 安全真空： 这是最大的风险，官方仓库关闭，意味着新发现的漏洞将得不到修补,系统暴露在已知威胁面前的风险剧增。
• 软件过时： 内核、核心库（如 glibc、openssl）及大多数软件版本严重滞后，无法兼容或运行现代应用,并存在兼容性隐患。
• 依赖断裂：yum update 命令失效,无法通过标准途径获取软件或更新。

关键维护策略：让 CentOS 6 继续运转 面对挑战,可采取以下措施缓解风险：

1. 修复 Yum 源失效问题：

   • 使用 Vault 仓库： CentOS 官方将旧版本软件包移至 vault.centos.org，需修改现有仓库配置指向 Vault。

   • 操作示例（以 base 仓库为例）：

     # 备份原有 repo 文件
     sudo mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup
     # 创建新的指向 Vault 的 repo 文件
     sudo vi /etc/yum.repos.d/CentOS-Vault.repo

     添加以下内容（适用于 CentOS 6.10）：

     [base]
     name=CentOS-6.10 - Base (Vault)
     baseurl=http://vault.centos.org/6.10/os/$basearch/
     gpgcheck=1
     gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
     enabled=1

     类似地，需要配置 updates, extras 等仓库指向对应的 Vault 路径 (http://vault.centos.org/6.10/<repo_name>/)，完成后可尝试 yum clean all && yum makecache。

     

2. 寻求替代更新源 (谨慎评估风险)：

   • EPEL (Extra Packages for Enterprise Linux)： 虽然 EPEL 6 也已停止维护，但其历史仓库可能仍存有部分较新的软件包（同样不再更新），启用需添加 EPEL 仓库配置（通常安装 epel-release 包，但需确保其源指向 Vault 或有效镜像）。
   • 第三方仓库： 存在一些社区或商业公司维护的仓库（如个别云厂商的兼容源）。务必极其谨慎： 充分评估其信誉、维护状态和软件包来源，明确知晓引入未知或不受控软件包带来的巨大安全风险,这不是推荐的首选方案。

3. 强化系统安全防护：

   • 严格网络隔离： 将 CentOS 6 系统置于防火墙后的隔离网络区域，仅开放绝对必要的最小端口（如 SSH），并限制访问源 IP。这是重中之重！
   • 加固防火墙 (iptables)： CentOS 6 默认使用 iptables，制定严格的规则，默认阻止所有入站流量，仅允许特定服务和 IP。

     # 示例：清空现有规则，设置默认策略为 DROP (谨慎操作，确保留有管理端口)
     sudo iptables -F
     sudo iptables -X
     sudo iptables -P INPUT DROP
     sudo iptables -P FORWARD DROP
     sudo iptables -P OUTPUT ACCEPT
     # 允许已建立连接和本地回环
     sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
     sudo iptables -A INPUT -i lo -j ACCEPT
     # 允许特定端口 (SSH 22)
     sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
     # 保存规则 (通常需要安装 iptables-services 并配置保存)
     sudo service iptables save

   • 禁用非必要服务： 使用 chkconfig --list 和 service <servicename> stop 关闭所有不需要的服务（如 cups, avahi-daemon, bluetooth 等）。
   • 强化 SSH 安全：
     • 修改 /etc/ssh/sshd_config：

       Port 2222 # 更改默认端口 (可选)
       PermitRootLogin no # 禁止 root 直接登录
       PasswordAuthentication no # 强制使用密钥认证 (必须提前配置密钥)
       AllowUsers yourusername # 只允许特定用户登录

       重启 SSH 服务 service sshd restart。确保密钥已部署再禁用密码登录！

   • 定期审计： 使用 netstat -tulnp 检查监听端口，ps aux 查看进程，last 检查登录记录，grep 'Failed password' /var/log/secure 查看失败登录尝试,及时排查异常。

4. 维护关键服务与应用：

   • Web 服务 (Apache/Nginx)： 确保配置安全，限制目录权限，移除默认测试页面，若需运行旧版 PHP（如 5.3/5.4），同样面临巨大安全风险,应用代码需严格审查。
   • 数据库 (MySQL 5.1 / PostgreSQL 8.4)： 强化数据库账户权限，使用强密码，定期备份,这些版本存在已知且无法修复的漏洞。
   • 文件共享 (Samba)： 使用尽可能新的稳定版本（需从 Vault 或兼容源安装），关闭过时的协议（如 SMB1）,设置强共享密码和访问控制。
   • 备份！备份！备份！ 制定完善的备份策略（全量+增量），定期测试恢复流程，数据是最后的防线，考虑 rsync, tar, dump 或简单脚本备份到安全的离线或异地存储。

核心建议：终极出路是迁移 上述措施仅能有限地缓解风险，无法根本解决 CentOS 6 的安全和兼容性问题，长期运行 CentOS 6 如同在悬崖边行走。最负责任且可持续的方案是制定并执行迁移计划：

• 升级到受支持的系统： 迁移到 CentOS 7（支持至 2024 年 6 月）、CentOS Stream 8/9，或 RHEL 克隆版如 AlmaLinux、Rocky Linux（提供类似 CentOS 曾经的稳定体验和长支持周期）。
• 评估应用兼容性： 这是迁移的关键步骤，列出所有运行的应用和服务，逐一测试或寻找替代方案以兼容新操作系统，利用容器化（Docker）技术隔离旧应用有时是可行的过渡方案（但容器内 OS 用户空间仍需更新）。
• 硬件更新： CentOS 6 所运行的硬件往往也已老旧,迁移是进行硬件更新的合适时机。

作为经历过多次系统迁移周期的运维人员，我深知旧系统的惯性力量，也理解升级可能伴随的阵痛——应用适配的复杂性、短暂的业务调整期、迁移所需的时间投入，这些都是实实在在的挑战，深夜被漏洞利用告警惊醒，面对因核心库不兼容导致的关键业务中断，或是因数据泄露带来的严重后果，这些代价远非临时维护手段所能比拟，将资源投入到有未来的平台，不仅是技术上的必然选择，更是对业务稳定性和安全责任的坚守。