Linux 漏洞修复是闭环流程：发现、评估、测试、部署、验证、监控。需建立识别机制、分环境打补丁、无补丁时配置缓解或手动修复，并严格验证生效与业务影响。
Linux 系统漏洞修复不是“打个补丁就完事”，而是一套闭环流程：从发现、评估、测试、部署，到验证和监控。关键在于节奏可控、操作可逆、结果可验。
一、怎么知道系统有漏洞？主动识别是前提
不能等被攻击才响应。日常需建立三类识别机制：
- 运行命令快速筛查：Ubuntu/Debian 用 apt list –upgradable，RHEL/CentOS 用 yum check-update 或 dnf list updates，重点关注带 security 或 errata 标签的更新；
- 定期扫描：用 lynis audit system（轻量）或 openvas（企业级）做全系统基线检查，每月至少一次；
- 订阅预警：关注 CVE 官网、发行版安全邮件列表（如ubuntu-security-announce）、以及 NVD（NIST） 的 CVSS 评分，看到高危（≥7.0）且影响你版本的 CVE，立即标记跟进。
二、补丁怎么打？分环境、控节奏、留退路
生产环境严禁直接 yum update 或 apt upgrade。标准操作必须经过三步：
- 先在测试环境部署 ：同步生产 环境配置 后，执行
apt-get update && apt-get upgrade -s（模拟）→ 确认变更包无误 → 再真实安装 → 验证服务状态与日志； - 生产环境选维护窗口操作：内核更新必须重启，建议用
grubby --default-kernel检查默认启动项，并保留旧内核作为备选； - 每步必做备份与回滚准备：更新前用
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak备份关键配置；对重要服务，记录systemctl show --property=ExecStart等原始启动参数。
三、特殊场景怎么处理？没补丁≠没办法
有些漏洞官方暂未发布补丁，或软件是源码编译安装，此时需替代方案：
- 配置缓解：如 Shellshock（CVE-2014-6271）无及时补丁时，可临时禁用 CGI 相关模块，或限制
bash调用路径； - 运行时加固：启用 SELinux 或 AppArmor 策略，限制进程权限，缩小漏洞利用面；
- 手动补丁应用：对源码软件，下载对应 CVE 的官方 patch 文件，用
patch -p1 应用后重新编译安装，务必在测试环境完整回归验证。
四、打了补丁就安全了？验证才是最后防线
修复完成不等于风险清除，必须交叉验证：
- 确认补丁生效：查包版本（
dpkg -l | grep package或rpm -q package），比对是否达到修复所需版本号； - 复扫原漏洞：用 OpenVAS 或
lynis对指定 CVE 编号专项重扫，而非只看“整体风险下降”； - 业务功能回归：重启相关服务后，用
systemctl status和简单 curl / health check 接口确认核心功能可用； - 查日志异常：运行
journalctl -u service_name --since "1 hour ago"，排除因补丁引发的新报错或告警。
补丁管理不是一次性任务，而是持续运转的安全齿轮。建立更新日志表、归档每次补丁时间 / 版本 / 验证结果，半年复盘一次流程卡点，才能让修复真正落地、可靠、可追溯。
