Linux系统漏洞修复：别让服务器裸奔在公网上

上个月某电商平台被入侵，统漏攻击者利用的洞修竟然是一个2019年就公布的Nginx漏洞。漏洞修补包早就发布了，统漏但运维团队觉得“不影响业务”就一直没打补丁。洞修结果数据库被拖库，统漏几百万用户信息泄露。洞修这不是统漏技术问题，是洞修态度问题。

Linux漏洞修复的统漏核心就一句话：及时打补丁，但别盲目打补丁。洞修你打开终端执行apt upgrade或者yum update，统漏看起来简单，洞修实际操作里全是统漏坑。

先说最基础的洞修——内核漏洞。这类漏洞最致命，统漏因为内核权限意味着一切。像脏牛（Dirty COW）、脏管道（Dirty Pipe），都是提权漏洞，普通用户直接拿root。修复方法通常需要重启服务器。很多运维不敢重启，怕业务中断。但你别忘了，不重启的代价可能是整个系统被控制。我见过一个金融公司，为了保持99.99%可用性，内核漏洞拖了半年没修，结果被黑客利用在内核里留了后门，最后花了三倍时间做应急响应。

对于内核漏洞，现在有kpatch和livepatch这类热补丁工具，可以不打重启直接修复。但热补丁不是万能药，它只能修补特定函数，如果漏洞涉及大范围逻辑变更，热补丁会失效。所以我的建议是：测试环境先验证热补丁，生产环境能重启就重启，不能重启才用热补丁兜底。

再说软件包漏洞。这类漏洞最容易被忽视，因为数量太多。你装了Nginx、MySQL、Redis、OpenSSL，每个都有CVE编号的漏洞。手动检查根本不现实。得用自动化工具，比如trivy、clair或者osv-scanner，扫描镜像和运行中的容器。扫描结果会告诉你哪些包有漏洞，以及修复版本。

但这里有个现实问题：漏洞扫描器报出来的“高危”不一定真的可利用。比如某个OpenSSL漏洞需要特定协议版本配合才触发，而你的服务根本没开那个协议。你不能全盘照搬扫描报告，得结合自己的业务场景判断。我处理过一个案例，扫描报告显示Redis有反序列化漏洞，但我们的Redis只监听内网，且配置了requirepass，攻击面极小。最后决定延期修复，把精力放在更紧急的Web应用漏洞上。

修复漏洞还有一个隐藏陷阱：依赖冲突。你用yum升级一个库，结果它依赖的另一个库版本太老，直接导致服务启动失败。这种事太常见了。所以生产环境升级前，一定要在staging环境做完整回归测试。别嫌麻烦，一次事故的代价远超测试成本。

还有个容易被忽略的点——配置漏洞。很多Linux默认配置并不安全。比如SSH允许root直接登录、开放了不必要的端口、/tmp目录没有做noexec挂载。这些不是传统意义上的“补丁”，但属于系统加固范围。我建议每个季度做一次配置审计，用lynis这类工具扫一遍，把评分从60分提到80分以上。

说点实际的。修复漏洞的流程应该是这样的：先做资产盘点，搞清楚你有哪些服务器、跑什么服务、用哪些版本。然后定期扫描（每周至少一次），把漏洞分为“可远程利用”“需要本地权限”“仅DoS”三级。可远程利用的必须在48小时内修复，需要本地权限的一周内修复，仅DoS的可以等月度维护窗口。修复过程要记录，谁改了什么、什么时候改的、影响什么服务，这些都得写清楚。

最后提醒一句：别把漏洞修复当一次性任务。新的CVE每天都有，你得建立持续监控机制。订阅NVD的RSS，关注CISA的已知被利用漏洞目录，这些是免费的。等黑客比你更早知道漏洞细节，你才动手，那就晚了。