漏扫这件事最容易出现的结局是扫了三年报告存了一柜子漏洞一个没少。原因通常不是工具不行是三个环节都做偏了——扫的时候只做非认证扫描看到的全是表面现象、看报告时分不清哪些是真问题被误报淹了、推整改时没有可执行的依据研发问一句这个洞怎么触发的就答不上来。这篇按扫→看→改三段写每段给具体做法。工具用 Nessus 和 AWVS 举例但换成别的绿盟、Qualys、nuclei思路一样。内网那侧的暴露面怎么收看 内网安全怎么防横向移动漏洞从发现到闭环的流程看 漏洞管理闭环怎么建。一、扫描前必须做的三件事第一拿到书面授权写清范围。授权书里要有扫哪些网段/域名、什么时间段、用什么源 IP、允许的扫描强度、谁是对接人。没有源 IP 的授权等于没授权——出问题时你无法证明这个流量是你发的。第二确认限速别把生产扫挂。这是最容易出事的地方。一个中等规模的 Web 应用并发调到 20 就可能把数据库打满。起步参数建议并发线程 ≤5、每秒请求 ≤10、避开业务高峰。# nmap先做主机发现和常见端口别一上来全端口 nmap -sn 10.20.0.0/24 -oG alive.gnmap # 对存活主机做端口扫描限速并避开高峰 nmap -sS -Pn -p 21,22,23,80,443,445,1433,3306,3389,5432,6379,8080,9200 \ --max-rate 200 --max-retries 2 -iL alive.txt -oX ports.xml # 服务与版本识别比端口扫描更重单独跑、限速更低 nmap -sV -Pn --version-intensity 2 --max-rate 100 -iL alive.txt -oX svc.xml第三跟运维确认不能扫的东西。工业控制设备、老旧打印机、某些医疗设备、核心交易系统的主库——这些扫了可能直接宕机。让运维给一份排除清单比事后解释便宜得多。二、认证扫描和非认证扫描差距有多大这是漏扫里最关键的认知但很多人没在意。非认证扫描黑盒只能看到端口、服务版本、Web 层能探测到的漏洞。它看到的补丁缺失是根据版本号推测看不到系统内部的配置问题、账号问题、补丁实际状态。认证扫描白盒用管理员账号登录进去直接读系统信息。它能准确说出这台机器缺 KB5034441 补丁这个服务以 root 运行这个目录权限过宽。差距量级同一批机器非认证扫描可能报 40 个漏洞认证扫描报 400 个。不是后者更危险是前者根本没看见。项非认证扫描认证扫描补丁缺失按版本推测可能误报漏报精确到 KB 号本地配置看不到完整账号与权限看不到完整弱口令只能测常见组合可完整核查需谨慎Web 漏洞能测能测 可读代码配置对业务影响有主动发包较小以读信息为主所以正确做法是两种都做非认证扫描看外面能看到什么这是攻击者的视角必须有认证扫描看里面缺什么这是整改的依据。配认证扫描的成本主要是为扫描器建一个专用账号、给最小必要权限Windows 上通常是本地管理员 远程 WMI 权限Linux 上 sudo 受限以及在每台机器上开通对应端口。这件事听起来麻烦但它是漏扫有没有价值的分水岭。只做非认证扫描的团队实际上是在做端口扫描不是漏洞管理。三、扫描策略怎么配Nessus 的策略模板有十几个常用的三个模板适用注意Basic Network Scan内网服务器通用默认含认证配置入口最常用Advanced Scan需要精细控制时可关掉高风险插件如 DoS 类Web Application TestsWeb 应用需要填 URL 和登录方式比 AWVS 弱一定要关掉 DoS 类插件。默认策略里有一组拒绝服务测试插件会主动打各种洪泛和畸形包。在生产环境跑轻则告警满天重则真把服务打挂。位置在插件家族里把 Denial of Service 整族取消勾选。端口范围不要用 all。全端口扫一遍65535在单机上要几十分钟一个 /24 就是几天。实际做法是先扫 1000 个常见端口再对 HTTP 服务做 Web 检测只有对核心系统才做全端口。Web 扫描用 AWVS 更合适。Nessus 的 Web 检测偏配置与已知漏洞AWVS 的爬虫和漏洞验证更强。AWVS 的策略关键是爬虫深度默认 5 层太浅很多功能入口爬不到调到 10 层左右配合登录后的会话覆盖率明显提升。AWVS 有个容易忽略的设置排除退出登录链接。爬虫点到退出会掉会话后面所有页面都变成登录页扫出来一堆未授权访问的误报。四、报告怎么看先分清误报的五种来源漏扫报告的误报率高得离谱这不是工具质量问题是扫描器只能看到现象、看不到上下文。五类误报最常见误报类型典型表现怎么验证版本推测型检测到 OpenSSH 7.4存在 CVE-XXXX但发行版打了 backport 补丁实际不受影响配置理论型允许 TLS 1.0但该端口只对内网管理网开放路径不存在型发现 /admin/backup.php其实是 404 页面返回 200已修复未复测上次修了这次扫描用的是旧缓存手动复现一次蜜罐/软 WAF 干扰返回统一错误页被判定为注入成功看响应体和状态码差异验证一个漏洞只要三步找到原始请求报告里通常有、手工重放一遍、看响应是否符合漏洞特征。# 用 curl 复现报告里的请求重点看状态码和响应长度差异 curl -s -o /dev/null -w %{http_code} %{size_download}\n \ https://app.example.com/api/user?id1 curl -s -o /dev/null -w %{http_code} %{size_download}\n \ https://app.example.com/api/user?id1%27 # 两个都返回 200 且长度接近 - 大概率误报 # 一个 200 一个 500或长度差异明显 - 需要进一步看响应体第一步版本推测型是最多的处理办法是看发行版的补丁说明。RHEL/CentOS 系的openssh-7.4p1-21.el7_9这种版本号里带el7_9说明打了 backports同一个 CVE 在 CentOS 上可能已经修了而在原版上没有。判断依据不是版本号是rpm -q --changelog openssh | grep CVE。这也解释了一个现象为什么同一个漏洞在 Qualys 上不报、在 Nessus 上报——两个厂商的插件判断逻辑不同。五、防火墙那侧为什么有些洞扫不出来这是漏报比误报更危险因为它给你虚假的安全感。常见原因三个第一扫描器的源 IP 被防火墙拦了。常见于只放通了办公网段的情况。解决办法是把扫描器放在一个专门的安全管理网段并在防火墙上放通到被测网段。第二端口被策略挡住服务却真实存在。比如数据库端口只对内网应用服务器开放扫描器从别的网段扫看到的端口是关的。这类服务实际上是内网可达攻击者一旦进入内网就能用。所以内网扫描必须从内网发起不能只从管理网扫。第三WAF 拦掉了攻击探测包。WAF 把扫描特征拦了报告显示未发现注入但漏洞确实存在——只是被 WAF 挡住了。这种情形下漏洞和利用路径要分开评估漏洞该修WAF 只是临时缓解。对应的做法# 扫描前确认路径通畅从扫描器所在机器测试目标端口 for h in 10.20.1.31 10.20.1.32; do for p in 80 443 3306; do timeout 2 bash -c echo /dev/tcp/$h/$p 2/dev/null \ echo $h:$p 通 || echo $h:$p 不通 done done如果关键端口不通别急着当成安全——先确认是策略阻断还是服务未开。这两种情况的结论完全相反。六、从报告到整改三步把几千条变成几十条一份 /24 网段的扫描报告通常有几千条结果直接扔给研发结果一定是没人看。三步压缩第一步去重。同一个 CVE 在不同主机上重复出现合并成一条标注影响主机数。Nessus 报告里可以按 Plugin ID 聚合。第二步按可利用性重排不按 CVSS。一个 CVSS 9.8 但需要本地权限的漏洞实际风险低于一个 CVSS 7.5 但可远程未授权利用的洞。排序维度用三个能否远程利用、是否需要认证、资产是否对外暴露。第三步给每一类问题配一个标准修法。这是效率的关键问题类型标准修法责任人组件版本漏洞升级到指定版本写明版本号运维系统补丁缺失走补丁窗口附 KB 号运维Web 应用漏洞附复现请求 修复建议参数化查询/输出编码研发配置类TLS、端口附配置项与目标值运维弱口令强制改密 启用 MFA资产责任人有了标准修法这张表同一类问题可以用同一套话术推动不用每个洞都重新解释一遍。七、漏洞扫描后的复测别忘了这一步复测不是再扫一遍。再扫一遍会有两个问题一是扫描器缓存可能导致结果不变二是新扫出的问题会混进旧问题里看不出原来那些修没修。正确做法是按漏洞 ID 复测拿上次的清单逐条验证。组件类查版本号是否已到目标版本补丁类查补丁是否已安装Web 类重放原来的请求看是否还能触发配置类读配置项当前值复测通过率本身是个好指标。它低于 70% 说明前端的整改指导不到位研发不知道该怎么改而不是研发不配合。八、除了 Nessus还该有一个轻量扫描器Nessus 适合周期性全面体检但它有两个短板扫得慢一个网段几小时、规则偏重容易误报且不好定制。日常场景其实更需要一个分钟级、能随时跑的工具。nuclei 就是这个角色。它按模板扫一个模板对应一种漏洞或一类暴露面跑起来很快# 更新模板库每天一次即可 nuclei -update-templates # 快速扫一批 URL只跑中高危模板限速 50 nuclei -l urls.txt -severity high,critical -rate-limit 50 -o result.txt # 只跑某一类模板比如暴露的配置文件与备份文件 nuclei -l urls.txt -tags exposure,backup -o exposure.txt # 用自定义模板扫内部规范比如禁止返回 Server 版本号 nuclei -l urls.txt -t custom/server-header.yaml它的价值在于两种用法一是验证。Nessus 报了一条可疑的注入用 nuclei 对应模板跑一次几秒钟出结论比手工 curl 快。二是持续监控。把 nuclei 挂在 CI 或定时任务里每次发布后对预发环境跑一遍。这样新漏洞在上线前就能被发现而不是等下个月的例行扫描。两者配合的定位很清楚Nessus 做深度体检认证扫描、全量插件nuclei 做快速验证与持续卡点。不要指望一个工具覆盖两个场景。九、扫描频次怎么定每月一次全量是常见的做法但它既浪费又不够。合理的做法是按资产等级分资产类型全量扫描增量/快速扫描说明核心业务系统每季度每次发布前发布前用 nuclei 或轻量策略跑一遍重要系统每半年每月 nuclei全量成本高靠快速扫描补一般系统每年每季度合规底线对外暴露资产每月每周这类最容易被盯上新上线资产上线前上线后一周内新系统最容易带病上线这张表的意思不是少扫而是把扫描频次和风险匹配。对外暴露的资产每月全扫内部 OA 每年一次就够——把资源集中在真正会被打的地方。另外有一个动作比增加频次更有效新资产上线时必须扫一次。大量漏洞是从临时上线的测试环境忘了关业务自己搭的小程序里出来的这些资产不在例行扫描范围内。十、几个实操里踩出来的点Nessus 的授权是按 IP 数算的扫描范围超了会静默跳过。排查某些机器没扫到时先看这个别怀疑策略。AWVS 扫 HTTPS 站点证书自签名要先导入信任。否则爬虫会停在证书错误页扫出来全是未授权访问。扫描器自身的漏洞库要更新。离线环境最容易被忽略——装了三年没更新过插件报的全是老漏洞新出的一个没有。建议每次扫描前手动更新一次或者配好离线更新包。别用生产管理员账号做认证扫描。建专用账号权限给到能读系统信息就够。既避免误操作也让审计能追溯到这是扫描器在动。扫描结果的留存要按合规要求。报告里含完整漏洞清单本身就是敏感信息。存内部系统不要发到个人邮箱或网盘。别在业务高峰做认证扫描。认证扫描会调 WMI、读注册表、遍历文件系统对老机器的 CPU 和磁盘有可见影响。见过一台跑了八年的应用服务器认证扫描期间接口超时率从 0.1% 涨到 6%。约在凌晨做或者分批做。报告里的信息泄露类问题常被忽略其实很有用。比如响应头暴露了中间件版本错误页泄露了堆栈目录列表未关闭。单条看起来危害不大但它们是攻击者做信息收集的起点而且修起来都很简单适合作为第一批整改项先把信心做出来。十一、一句话总结漏扫的价值不在扫了多少次在扫出来的问题有多少被真正修掉。而这个转化率取决于三件事扫描是不是认证的看不看得见、报告是不是验证过的准不准、整改建议是不是可执行的改得动。三件事里最容易做却最少人做的是第二件——花两小时把报告里的高危逐条验证一遍。做完你会发现真正要改的可能只有二十条。
