内容摘要：凌晨两点，安全告警群弹出一条消息：某台对外服务的机器在十分钟内发起了四万次SSH登录尝试。我连上跳板机，看了下日志来源IP，分布在全球十几个国家。这不是误报，是有人在拿字典跑我们的端口。 扫描服务器漏

凌晨两点，扫描安全告警群弹出一条消息：某台对外服务的服务机器在十分钟内发起了四万次SSH登录尝试。我连上跳板机，器漏看了下日志来源IP，扫描分布在全球十几个国家。服务这不是器漏误报，是扫描有人在拿字典跑我们的端口。

扫描服务器漏洞这件事，服务很多人以为就是器漏装个Nessus或者OpenVAS，点一下开始，扫描等报告出来。服务真干过的器漏人知道，工具扫出来的扫描东西，一半是服务噪音，另一半需要你手动去验证。器漏上周我用nmap对一台新上架的测试机做全端口扫描，发现8080端口开着，返回一个JSON接口，没有任何认证。访问/api/v1/users，直接吐出了三百多条用户记录，包括手机号和邮箱。这台机器是开发同学临时开的，防火墙规则没配，安全组放行了所有入站流量。

漏洞扫描的核心不是“扫”，是“比”。你得知道正常的基线长什么样。比如一台Web服务器，正常应该只开80和443，SSH限制内网访问。你扫出来多了3306或者6379，那就是问题。我习惯先跑一遍nmap -sS -p- --min-rate 5000，快速摸清攻击面。开放端口列表拿到之后，再针对每个端口跑对应的脚本：HTTP服务用http-enum和http-vuln-*系列，数据库用mysql-info和redis-info。这一步经常能发现弱口令——Redis没设密码，MySQL的root密码是“123456”，这种事每年都能碰上几回。

Web层面的扫描更琐碎。AWVS和Xray能帮你跑出SQL注入、XSS、目录遍历这些常见问题，但误报率不低。我遇到过Xray报了一个“CRLF注入”，手动复现发现只是响应头里带了换行符，实际不可利用。也遇到过它漏报的——某个参数在POST body里，工具没爬到。所以扫描器只是辅助，关键还是看你怎么构造Payload，怎么观察响应差异。

说个具体的。去年帮一个朋友看他的小电商站，用WPScan扫WordPress，发现一个插件版本是2.1.3，CVE库里显示存在任意文件上传。我试着上传了一个php文件，果然拿到webshell。整个过程不到五分钟。但同样的站，用另一款商业扫描器跑，只报了个“中等风险：WordPress版本泄露”。工具之间的差距，有时候比人和狗之间的差距都大。

扫描频率也很讲究。生产环境不能随便扫，尤其是全端口扫描，容易触发IDS告警或者把老旧服务打挂。我一般选在业务低峰期，先扫非核心节点，确认没问题再扩大范围。有次同事在白天对一台老Windows Server跑了漏洞扫描，SMB协议直接把机器扫蓝屏了。后来我们定了个规矩：扫描前必须确认目标系统能否承受，不确定的就先做被动指纹识别。

还有一点，扫描结果要落到工单系统里，不能扫完就完。我见过太多团队，报告生成PDF往群里一扔，没人跟进。漏洞不会自己消失，只会被利用。每一条高危漏洞，都得有明确的修复责任人和截止时间。修完之后，再扫一遍验证。这个闭环不做，扫描就是白费电。

最后说个观察。很多入侵事件追溯回去，入口都是一个不起眼的未授权访问接口，或者一个忘了删的测试账号。扫描服务器漏洞，本质上是在跟自己的懒惰和侥幸心理作斗争。工具再强，也救不了一个不想改配置的人。