去年秋天，进行及版我帮一家做跨境电商的系统朋友看他们刚上线的服务器。他挺自信，服务说安全组配好了，本扫WAF也挂了，描渗应该没什么大问题。透测我扫了二十分钟，进行及版发现他跑着一台Redis 3.2.6，系统端口没对外，服务但同一内网里有台测试机开着6379，本扫而且没设密码。描渗这台测试机上还跑着Jenkins 2.73.1，透测有个已知的进行及版远程代码执行漏洞。后面的系统事不用细说——从Redis写SSH公钥到Jenkins拿shell，整条链路不到四十分钟就打通了。服务他全程盯着屏幕，一句话没说。

这就是系统服务及版本扫描的价值。不是拿到一个漏洞列表就完事，而是搞清楚目标机器上到底在跑什么、什么版本、这些版本背后藏着哪些已经被公开的利用路径。很多人把扫描当成一个孤立的步骤，扫完导出一份报告就交差。真正有用的扫描，是后续所有攻击动作的地基。

拿Nmap来说，-sV这个参数几乎人人都会用，但版本探测的强度等级很少有人调。默认的--version-intensity 7已经能识别大部分服务，可遇到改过banner的或者非标准端口上的服务，经常给出“unknown”或者误判。我习惯把强度拉到9，代价是扫描时间翻倍，但换来的是更准确的版本号。比如同样是8080端口，强度7可能只告诉你“http”，强度9会告诉你是“Apache Tomcat 9.0.30”。这个差别直接决定了你下一步是去找Tomcat的AJP漏洞还是去翻Spring的actuator端点。

服务识别只是第一步。版本号拿到之后，真正花时间的是做版本和漏洞的对应。Nmap自带的--script vuln能跑一些基础检测，但覆盖面有限，误报也不少。我的做法是把-sV的输出导入到Searchsploit里做本地匹配，再配合NVD的API查一遍。这个流程听起来笨，但比盲目信任扫描器的“漏洞标签”靠谱得多。上个月扫到一台对外服务器开着OpenSSH 7.4，Nmap的vuln脚本没报任何问题，但Searchsploit里有一条关于这个版本用户名枚举的利用，虽然不能直接拿shell，但配合弱密码爆破就是另一回事了。

还有一类服务容易被忽略：UDP。TCP扫描大家做得勤，UDP经常被跳过，因为慢、结果不确定。但SNMP跑在UDP 161上，如果community string是默认的“public”，能直接读出系统版本、网卡信息、甚至路由表。我遇到过一台路由器，SNMP没改默认配置，从里面读出了内网拓扑，然后顺着找到一台只开在内网的Zabbix，版本2.0，有个SQL注入。整个过程没有触发任何TCP层面的告警。

扫描的粒度也要看场景。外网扫描可以慢一点、全一点，反正目标不知道你在扫。内网横向的时候，速度要快，范围要窄，优先扫那些“高价值低防护”的服务——比如老版本的SMB、没加密的数据库端口、暴露的Docker API。有一次在内网里扫到一台机器开着2375端口，Docker API没做任何认证。直接docker -H tcp://target:2375 ps就能列出所有容器，然后起一个挂载宿主机根目录的容器，等于拿到root。这种服务，版本扫描甚至不需要太精确，端口开着本身就是问题。

工具选择上，Nmap是基础，但别只依赖它。Masscan做全网段快速发现，然后Nmap做精细识别，这个组合用了好几年。Windows环境下，我用过一阵Nessus，它的服务识别和漏洞关联做得不错，但太重，扫一台机器要等半天。后来换成Nmap加自定义NSE脚本，轻量，可控，输出格式也方便后续处理。

最后说一个细节：扫描结果的时间戳。很多人不注意这个，但版本信息是有时效性的。今天扫到Apache 2.4.49，明天管理员可能就升级了。如果你拿着三天前的扫描报告去跟客户讲“你们有路径穿越漏洞”，对方一句“我们已经修了”就能把你噎回去。我现在的习惯是，任何扫描结果超过24小时就重新跑一遍关键端口，确认版本没变再继续往下做。

扫描本身不复杂，复杂的是怎么把扫描结果转化成可执行的攻击路径。版本号是死的，但版本号背后的东西是活的。你得知道哪个版本对应哪个CVE，哪个CVE有公开的PoC，哪个PoC在目标环境下能跑通。这个判断力，比会敲几条Nmap命令重要得多。