上周帮一家电商公司处理了一次入侵事件。服务复攻击者利用的器漏是他们ERP系统里一个三个月前就该打上的Oracle WebLogic反序列化漏洞，直接拿到了服务器root权限。洞修整个事情很讽刺——漏洞公告早就发了，服务复补丁也下载了，器漏就是洞修没人愿意在业务高峰期重启那台机器。结果黑客替他们做了这个决定。服务复

修复服务器漏洞，器漏本质上就是洞修三件事：知道有什么在跑，知道哪里能进来，服务复然后堵上它。器漏别把它想得太玄乎。洞修

先说你最该干的服务复事——资产盘点。别笑，器漏我见过太多运维人员连自己服务器上开了哪些端口都说不全。洞修你连门都没数清楚，谈什么锁门？用nmap扫一遍全网段，把意外开放的端口列出来。比如一台数据库服务器，它只需要监听内网特定IP的3306端口，结果你发现它在0.0.0.0上监听，那这就是个定时炸弹。用防火墙规则把它绑死到内网，这是成本最低的修复。

再说补丁。很多企业总说“补丁会引发兼容性问题”，这话听着有理，但多数时候是懒的借口。真正该做的是建立分级打补丁的流程——测试环境验证，灰度环境试运行，最后才推生产。像Apache Struts2、Log4j这类高危组件，别等官方CVE公告，平时就得订阅安全预警。我认识一个运维老哥，他的习惯是每个季度抽一个周末，专门给所有服务器做一次yum update和apt upgrade，然后跑一遍核心业务自检脚本。繁琐，但有效。

配置加固这块最容易被忽视。默认密码、弱口令、多余的管理账号，这些不是漏洞，但比漏洞更致命。前阵子有个客户，服务器被挖矿程序盯上了，原因就是Redis没设密码，还以root权限运行。修复方法简单到离谱：给Redis加个强密码，改成用普通用户跑，再禁用危险命令。半小时搞定。但就是这半小时的事，人家拖到服务器CPU飙到100%才发现。

还有Web层面的漏洞，SQL注入和文件上传是重灾区。代码层面该用参数化查询，这个开发人员都懂，但总有人图省事拼字符串。如果你没权限改代码，至少先在WAF层面加规则拦截常见攻击payload。文件上传漏洞更麻烦——攻击者传个webshell上去，你整个服务器就裸奔了。修复思路是：上传目录禁止执行脚本，文件类型做白名单校验，文件名重命名成无规律字符串。这三板斧下去，大部分上传漏洞就被掐死了。

最后说点实在的。漏洞修复不是一次性工作，而是持续对抗。你得有日志监控，得有入侵检测系统，哪怕只是简单的fail2ban也能拦掉不少暴力破解。别迷信那些昂贵的安全设备，有时候一条iptables规则就能解决的事，非要上一套复杂系统，反而添乱。

说句得罪人的话——很多服务器漏洞根本不是技术问题，是管理问题。流程僵化、责任不清、怕担风险，导致补丁躺在那里没人打。你如果是个能拍板的人，就把修复漏洞当成修水管：漏水了别光拿桶接，赶紧关阀门换管子。虽然麻烦，但总比淹了强。