去年秋天，线漏一个做电商的洞扫朋友半夜给我打电话，声音都在抖。线漏他说后台突然多出几百条异常订单，洞扫收货地址全是线漏乱码，付款方式清一色货到付款。洞扫他以为是线漏系统抽风，重启服务器之后才发现，洞扫数据库里多了一张从没见过的线漏表，表名就叫“readme_if_you_can”。洞扫

这就是线漏典型的漏洞被扫出来之后被人顺手薅了一把。他后来复盘，洞扫问题出在一个两年前就没再更新过的线漏Struts2组件上。攻击者根本没针对他，洞扫只是线漏用扫描器全网跑了一遍，谁没打补丁谁中招。

在线漏洞扫描这事，说白了就是拿工具去敲别人家的门，看哪扇没锁。只不过敲的是服务器端口、Web路径、参数拼接这些地方。工具本身不区分好坏，安全工程师用它做资产盘点，攻击者用它找入口。同一个Nmap，同一款AWVS，用法不同而已。

很多人以为扫描就是点一下“开始”然后等报告。实际操作里，第一步永远是确认目标范围。我见过有人把整个/16的网段丢进去扫，结果触发运营商流量清洗，自己先断了网。正经做法是先跑一遍存活探测，把不响应的IP剔掉，再对活着的机器做端口识别。这一步用Masscan比Nmap快得多，但Masscan的准确率你得心里有数，它为了速度会牺牲一部分可靠性。

端口开了不等于有漏洞。比如80端口开着，跑的是Nginx还是Tomcat，版本号是多少，这些信息决定了下一步往哪走。Nmap的版本探测脚本这时候就派上用场了，-sV参数加上--script=banner，能拿到不少指纹信息。但别全信，有些服务会伪装banner，我遇到过把SSH端口改成80的，banner显示是Apache，实际连上去是OpenSSH 7.4。

Web层面的扫描更琐碎。AWVS和AppScan这类工具会爬取整个站点，然后对每个参数注入测试payload。误报率不低，尤其是SQL注入检测，经常把普通的数字参数当成注入点。我习惯用sqlmap手动验证一遍，--level=3 --risk=2跑一下，确认了再写进报告。XSS的误报更离谱，反射型XSS有时候只是把参数原样输出在HTML里，没做转义但也没法执行脚本，工具照样标红。

有个细节容易被忽略：扫描器的请求特征太明显。User-Agent里带着Acunetix或者Netsparker的字样，WAF一眼就认出来。稍微讲究点的做法是改UA，或者挂代理池轮换IP。但改UA这事也有风险，有些WAF会专门拦截空UA或者伪造UA的请求，反而暴露自己。

扫描频率也是个问题。见过一家公司每周对生产环境做全量扫描，结果每次扫到一半数据库连接池就被打满，业务部门投诉不断。后来改成只扫测试环境，生产环境用被动流量分析，问题才消停。在线扫描对系统是有压力的，尤其是那些带爬虫功能的工具，并发请求一开高，小站点直接503。

报告出来之后才是真正费时间的环节。一个中等规模的Web应用，扫出几百条结果很正常，其中高危可能就几条，剩下全是信息泄露、Cookie未设HttpOnly、目录列表可访问这类低危项。甲方通常只看高危，但渗透测试的人知道，有些低危组合起来能变成利用链。比如一个phpinfo泄露了绝对路径，配合一个任意文件读取，就能把源码拖下来。

工具永远只是辅助。我见过扫描器完全没报的漏洞，手动测出来的。也见过扫描器报了一堆，实际全是误报的。最靠谱的方式还是把扫描结果当线索，一条条去验证。那个电商朋友后来买了商业扫描器，每季度扫一次，但真正帮他挡住下一次攻击的，是开发那边把Struts2升级到了最新版。

漏洞扫描不是银弹，它更像体检。查出来有问题不代表一定被攻破，查不出来也不代表安全。关键还是看人怎么用这些结果。