去年冬天，服务我帮一家小电商公司做安全巡检。器漏他们的洞解服务器跑着某开源商城系统，版本号停留在两年前。服务我扫了一遍端口，器漏发现数据库的洞解3306直接暴露在公网，密码还是服务弱口令——admin123。当时我就跟老板说，器漏你这台机器，洞解被人拖库只是服务时间问题。他不信，器漏觉得小网站没人盯。洞解三天后，服务数据库里多了个勒索信。器漏

漏洞这东西，洞解从来不是“会不会被利用”，而是“什么时候被利用”。解决它的第一步，不是急着打补丁，而是搞清楚你手里到底有哪些资产在跑。很多团队连自己有多少台服务器、跑了什么服务、开了哪些端口都说不清。我见过一个运维，信誓旦旦说只开了80和443，结果nmap一扫，8080、9000、6379全在监听。Redis没设密码，直接写SSH公钥就能拿root。这种漏洞，扫描器报告里排第一页，但他从来不看。

资产清点之后，才是漏洞发现。别一上来就买商业扫描器，先把免费的用明白。Nmap扫端口，Nessus社区版或者OpenVAS扫系统层，Web层面用AWVS或者xray。我习惯先手动摸一遍：访问目标IP，看返回头里的Server字段，看robots.txt，看404页面是不是带着框架指纹。这些信息比扫描器报告更直接。有一次，一个站点的404页面返回了ThinkPHP的版本号，我直接搜对应版本的RCE，十分钟拿到shell。扫描器还没跑完。

发现漏洞之后，优先级怎么排？CVSS评分可以参考，但不能全信。一个CVSS 9.8的漏洞，如果利用条件苛刻——比如需要内网访问、需要特定配置——实际风险可能不如一个CVSS 7.5但公网可直接利用的。我的判断标准很简单：能不能从外网直接打进来？需不需要认证？利用复杂度高不高？三个问题下来，该先修哪个一目了然。那个电商公司的3306暴露，就是典型的“低分高危”——MySQL未授权访问的CVSS可能只有5.0，但实际危害是数据库全丢。

修补漏洞，最忌讳“一刀切”。生产环境不能随便重启，补丁不能随便打。我的做法是：先看官方有没有热修复方案，没有的话评估能否通过防火墙或者WAF临时拦截。比如Struts2的漏洞，官方补丁要重启Tomcat，那就先在WAF上加规则拦截OGNL表达式。等维护窗口再打补丁。但临时方案不能变成永久方案。我见过一个团队，WAF规则加了两年，补丁一直没打，结果WAF被绕过，照样出事。

有些漏洞，补丁打不上怎么办？比如老系统依赖的某个库，官方早就不维护了。这时候只能做隔离。把有漏洞的服务放到单独的VLAN，限制访问来源IP，关闭不必要的端口。能不用就不用，能下线就下线。我处理过一个案例：某台服务器跑着Windows Server 2003，因为业务软件只支持这个版本。补丁是没有的，那就把它关在内网，只允许特定几台机器访问特定端口，外面加一层跳板机。虽然麻烦，但比裸奔强。

最后说一个容易被忽略的点：漏洞修完了，得验证。不是重启完服务就完事。用同样的扫描器再扫一遍，手动复现一下利用过程，确认真的打不进去了。我见过太多“已修复”的漏洞，其实只是改了配置没重启，或者补丁打了一半。验证的时候，最好换个人来测。自己修的东西，自己测容易有盲区。

服务器漏洞这事，没有一劳永逸。今天修完，明天可能又爆出新的。关键是建立一套流程：定期扫描、及时评估、按优先级修补、验证闭环。别等出了事才想起来看日志。那个电商老板后来问我，能不能保证以后不出事。我说不能，但能保证出事的时候，你第一时间知道是哪个漏洞、影响范围多大、怎么止血。这比“绝对安全”实在得多。

(责任编辑：探索)