Nmap 扫出一台测试服务器开着 22、漏洞80、扫描443、工具3306 和 6379。漏洞前三个端口正常，扫描3306 是工具 MySQL，6379 是漏洞 Redis。问题出在最后两个——数据库端口直接暴露在公网，扫描Redis 甚至没设密码。工具这不是漏洞什么高深的漏洞，但每年因此被挖矿、扫描被勒索的工具案例一抓一大把。IP 漏洞扫描工具要解决的漏洞就是这类问题：在攻击者之前，把资产上不该开的扫描口子找出来。

扫描工具的工具核心逻辑不复杂。给定一个 IP 段，先做存活探测，判断哪些主机在线；再对在线主机做端口扫描，看哪些端口开放；拿到开放端口后，识别服务类型和版本；最后拿版本信息去比对已知漏洞库，输出风险列表。Nmap 负责前三步，配合 NSE 脚本或 OpenVAS、Nessus 这类工具完成漏洞匹配。整个链条里，端口扫描是最耗时也最容易触发告警的环节，所以实际使用中通常会调整扫描速率，或者避开业务高峰期。

我自己的习惯是用 Masscan 做第一轮快速探测。它异步发包，扫一个 B 段也就几分钟。拿到开放端口列表后，再用 Nmap 做精细识别。两者配合的好处是效率高，缺点是 Masscan 的准确率受网络质量影响大，丢包会导致漏报。有一次扫一个云厂商的 IP 段，Masscan 报开放 8080 的主机有 37 台，Nmap 复核后实际只有 29 台，剩下 8 台是中间设备回了伪造的 SYN-ACK。这种误报在跨运营商链路里更常见，所以扫描结果一定要复核，不能直接拿去改防火墙策略。

漏洞匹配环节坑更多。版本比对依赖指纹的准确性，而很多服务会故意隐藏或篡改 banner。比如某些改过的 SSH 会返回一个不存在的版本号，扫描器查不到对应 CVE，就标记为“未知服务”。这时候得手动抓包看协议特征，或者用 nmap -sV --version-intensity 9 提高探测强度。但强度调太高，又可能把老旧设备打挂——我见过一台工控网关，Nmap 的版本探测直接把它 CPU 跑满，业务中断了十几分钟。所以扫描策略得看目标环境，生产网里最好先做被动流量分析，再决定要不要主动扫。

扫描频率也是个实际问题。很多团队一年扫一次，扫完出一份报告就归档。这基本没用——新漏洞每周都在出，临时开的端口可能第二天就忘了关。比较合理的做法是：核心资产每周扫一次，非核心资产每月一次，新上线的主机在入网前强制扫一遍。扫描结果要能自动同步到 CMDB 或工单系统，发现高危漏洞直接触发修复流程，而不是躺在邮箱里没人看。

工具选型上，Nessus 和 OpenVAS 功能全但重，适合有专职安全团队的场景。小团队用 Nmap + Nuclei 的组合更轻便。Nuclei 的模板机制很灵活，写个 YAML 就能自定义检测逻辑，比如检测某个内部 API 的未授权访问。我见过一个案例：某公司用 Nuclei 扫内网，发现一个测试用的 Swagger 接口没鉴权，能直接调用用户查询功能，返回了十几万条手机号。这个接口不在任何资产清单里，是开发随手部署后忘了下线。传统扫描器不一定能发现这种逻辑漏洞，但自定义模板可以。

最后说个容易被忽略的点：扫描工具本身也是攻击面。Nessus 的历史漏洞不少，OpenVAS 的管理接口如果暴露公网，等于给攻击者送了一个内网跳板。所以扫描器要部署在独立的管理网段，访问严格控制，扫描结果加密存储。别光顾着扫别人，自己先被人扫了。