linux漏洞补丁升级

上周三凌晨两点，洞补丁升我盯着监控大屏上那台CentOS 7跳出的洞补丁升内核崩溃告警，心里骂了一句。洞补丁升这台机器跑着公司内部的洞补丁升GitLab，补丁落后了整整四个月——运维同事觉得“稳定压倒一切”，洞补丁升结果一个本地提权漏洞（CVE-2023-32233）被扫描器逮到，洞补丁升攻击者没进来，洞补丁升但内核自己先崩了。洞补丁升补丁这事，洞补丁升拖不得，洞补丁升也乱不得。洞补丁升

Linux漏洞补丁升级，洞补丁升最怕的洞补丁升不是打补丁本身，而是洞补丁升打完之后系统起不来。我见过有人直接yum update一把梭，洞补丁升重启后网卡驱动没了，远程连不上，只能抱着键盘去机房。所以第一步永远是：搞清楚你在打什么补丁。内核漏洞、glibc漏洞、OpenSSL漏洞，处理方式完全不同。内核补丁通常需要重启，而用户态库的补丁可能只需要重启相关服务。用uname -r看当前内核，用rpm -qa | grep kernel看装了哪些版本，别急着敲命令。

拿CentOS/RHEL系来说，官方源里的补丁往往滞后于上游。比如那个CVE-2023-32233，Red Hat的修复包比主线内核晚了将近三周。这三周里，你的服务器就是裸奔状态。我的做法是：关键漏洞直接上ELRepo或编译主线稳定版内核。但别在生产环境直接编译，先在一台同配置的测试机上跑一周。测试什么？不是看它能不能启动——那是最低要求。要看的是：你的业务进程有没有因为内核ABI变化而崩溃，比如某些依赖特定syscall的Java应用，或者用了DPDK的网卡绑定。

Debian/Ubuntu系稍微省心一点，unattended-upgrades可以自动装安全补丁。但我关掉了自动重启。为什么？因为自动重启会打断正在跑的批处理任务。我改成：自动下载并安装补丁，但重启时间由我手动定在凌晨四点。具体配置在/etc/apt/apt.conf.d/50unattended-upgrades里，把Automatic-Reboot "false"，然后加一个cron任务在低峰期执行shutdown -r +5。这样补丁生效了，业务也没断。

有个坑我踩过两次：容器宿主机的内核补丁。你升级了宿主机内核，重启后Docker的overlay2存储驱动可能挂载失败，因为新内核改了某个模块的加载顺序。解决办法是在重启前，把/etc/docker/daemon.json里的存储驱动显式写成overlay2，并确认modprobe overlay能正常加载。别信“重启治百病”，容器环境里重启前先docker ps -a记下所有容器ID，万一挂了还能手动docker start。

补丁回滚这事，得提前准备。RHEL系用yum history能回滚，但内核回滚比较麻烦——你得在grub里选旧内核启动，然后yum remove新内核。我习惯在升级前用tar把/boot和/lib/modules/$(uname -r)备份到远程NFS。别用dd备份整个盘，太慢，恢复也麻烦。就备份这两个目录，出问题半小时内能还原。

最后说个真实教训。去年有个朋友的公司，运维用Ansible批量给200台服务器打内核补丁，结果playbook里忘了加--exclude=kernel*，把正在运行的NFS客户端内核模块给覆盖了。200台机器同时掉存储，数据库直接锁死。补丁策略里，灰度发布比什么都重要。先拿5%的机器试，观察24小时，看dmesg有没有异常，看sar的CPU和内存曲线有没有突变。没问题再推全量。别嫌慢，一次事故的代价够你灰度半年。

补丁不是越新越好，但已知的高危漏洞必须打。我的底线是：CVSS评分7.0以上的，两周内必须修复；5.0到7.0的，下个维护窗口处理；5.0以下的，攒着一起打。别让“稳定”变成“隐患”的借口。

本文地址：http://www.79wt.cn/news/746d1499239.html