对系统进行漏洞扫描

凌晨两点，对系洞扫我盯着屏幕上那条刺眼的统进红色告警——某台测试服务器开放了22端口，且允许root直接登录。行漏这是对系洞扫上周刚上线的新环境，运维同事拍胸脯保证“配置绝对没问题”。统进结果呢？行漏漏洞扫描器只用了几分钟就撕开了这个口子。

漏洞扫描这事，对系洞扫听着像高深的统进安全攻防，其实本质就是行漏给系统做一次“体检”。你总得知道哪里发炎、对系洞扫哪里化脓，统进才能对症下药。行漏扫描器干的对系洞扫事，就是统进拿着已知漏洞的指纹库，去敲系统的行漏门——看它是否响应了不该响应的端口，是否运行了带漏洞的服务版本，是否配置了过于宽松的访问权限。

我见过太多人把扫描当成例行公事。每个月跑一次报告，存个PDF，应付等保检查，然后束之高阁。这种“扫描仪式”毫无意义。真正的漏洞扫描应该像查房医生，带着怀疑的眼光审视每个角落。上周我扫描公司内部OA系统时，发现一个奇怪的现象：后台管理接口竟然对外开放，而且没有做IP白名单限制。扫描器标记为“中危”，但我知道，配合一个弱口令，这就能变成直接拿服务器的“高危”路径。

扫描的时机也很讲究。白天业务高峰期扫描，可能把数据库连接池打满，让前台页面卡成PPT。我习惯在凌晨两点到五点之间跑深度扫描，那时候业务流量小，即使误伤也能快速恢复。但凌晨扫描也有代价——如果出问题，你得半夜爬起来处理告警。上周我就因为扫描器误报，把一个正常业务端口当成了恶意服务，紧急封禁后导致财务系统无法对账，第二天被业务部门追着骂了半小时。

工具选择上，开源免费的OpenVAS和商业的Nessus我都用过。OpenVAS胜在灵活，能自定义很多检查项，但误报率偏高，需要人工二次验证。Nessus的报告更友好，风险分级清晰，但价格不菲，小公司未必舍得掏这笔钱。我现在的做法是双轨并行：用Nessus做月度全面扫描，用自己写的脚本每周针对关键资产做定向检查——比如检查SSL证书是否快过期、检查是否有新增的对外开放端口。这些“小动作”往往能发现扫描器忽略的细节。

扫描结果出来后的处理，才是真正的分水岭。有些人看到几十个漏洞就慌了，恨不得当天全补上。但修补漏洞也有优先级——暴露在公网的Web服务，比内网的文件服务器更需要紧急处理；能远程利用的漏洞，比需要本地权限的漏洞威胁更大。我一般会把漏洞分成三类：必须24小时内处理的“急性病”，比如已公开利用代码的RCE漏洞；一周内处理的“慢性病”，比如配置不当或版本过旧；以及记录在案、等下次升级时一并解决的“观察项”。

上周遇到一个典型案例：某台老旧的Windows Server 2012，系统已停止安全更新，扫描出一堆“不可修复”的漏洞。运维说“补丁打不上，只能裸奔”。我没跟他争论，而是建议把该服务器从公网隔离，只允许特定IP访问，并加上网络层ACL限制。扫描器依然会报漏洞，但实际攻击面已经大幅收窄。这比逼着运维强行打补丁导致系统崩溃要务实得多。

漏洞扫描不是一锤子买卖。系统在变，漏洞库在更新，攻击手法也在进化。我见过最离谱的案例是某公司一年前扫描时确认修复了Struts2漏洞，结果今年新上线的一个微服务，又依赖了旧版本的Struts2组件，把漏洞“带回来”了。所以，扫描得常态化，最好接入CI/CD流水线，每次代码提交都自动扫一遍依赖和基础镜像。别嫌麻烦，等被入侵后再追悔，那才叫真麻烦。

说到底，漏洞扫描是安全工作的起点，不是终点。它告诉你哪里有洞，但堵不堵、怎么堵，考验的是人的判断力和执行力。扫描器不会帮你思考攻击者会怎么利用这些漏洞，也不会替你在业务连续性和安全之间做权衡。这些，还得靠人。