📄 一句话概括
漏洞诊断（漏洞诊断）包含三种层次不同的做法：端口扫描（端口扫描）看"有哪些门开着"，漏洞扫描看"这些门后面有没有已知的锁坏着"，渗透测试看"攻击者真能靠它做到什么"——前两种是"广度优先"，第三种是"深度优先"，它们的成本和作用完全不同，不能互相替代。
📝 本节和前面几节的关系
前面八节讲的都是"已经知道是什么漏洞、该怎么办"，这一节回答一个更前置的问题：我怎么知道自己有没有漏洞？
它也是 4-1 和 4-13 的中间环节：4-1 讲了漏洞怎么分类（哪些值得先修），4-13 讲了漏洞怎么量化排序，而这一节讲的是"这些清单从哪里来"——没有盘点，后面两步都无从谈起。
一、先看清"暴露面"是什么
漏洞诊断的第一步不是"找漏洞"，而是"看清你有哪些东西暴露在外面"。这一步的产物是一张"暴露面清单"。一次端口扫描的结果大概长这样：
| 端口 | 服务 | 版本 | 风险点 |
|---|---|---|---|
| 22 | SSH | OpenSSH 7.4 | 版本已停更，存在多个已知漏洞 |
| 80 | HTTP | nginx 1.14 | 未强制跳转 HTTPS |
| 443 | HTTPS | nginx 1.14 | TLS 1.0/1.1 仍启用 |
| 3306 | MySQL | 5.7 | 直接对公网开放 |
| 8080 | Tomcat | 9.0.30 | 管理页可访问 |
| 6379 | Redis | 5.0 | 无认证，可写任意键 |
| 9200 | Elasticsearch | 7.6 | 未启用鉴权，可读全部索引 |
| 3389 | RDP | Windows | 暴露在公网，易被暴力破解 |
| 21 | FTP | vsftpd | 明文协议，账号密码可被嗅探 |
| 27017 | MongoDB | 4.4 | 无认证，数据库可被直接导出 |
这张表里有 4 个端口属于"根本不该对公网开放"的那一类（数据库和服务中间件）。一个很值得注意的事实是：这类信息"被动侦察"就能拿到——攻击者甚至不需要碰你的系统，只要用公开的搜索引擎查一下域名或 IP 就行。其中被索引的联网设备里，有超过 1500 万台仍在跑已终止支持的软件。
所以"暴露面盘点"的价值不在"发现了多少问题"，而在"发现有多少东西本来就不该出现在那里"。
二、三种做法：广度与深度的分工
| 做法 | 谁在干 | 广/深 | 典型工具 |
|---|---|---|---|
| 端口扫描 | 任何技术人员 | 广/浅 | Nmap、Masscan |
| 漏洞扫描 | IT 运维即可 | 广/浅 | Nessus、OpenVAS、Qualys |
| 渗透测试 | 专业测试人员 | 窄/深 | Metasploit、Burp Suite、ZAP |
三者的分工可以这样理解：
- 端口扫描：只回答"哪些门开着"。它不判断门后面有没有问题——但它是最便宜、最快、信息量最大的一步。
- 漏洞扫描：拿着"门的类型和版本"去比对漏洞库，回答"这扇门后面有没有已知的锁坏着"。它是自动化的、可以天天跑的。
- 渗透测试：由人来尝试"真的打进去"，回答"这些漏洞连起来能造成什么后果"。它贵、慢、覆盖窄，但它是唯一能回答"业务影响"的做法。
教材把"渗透测试"和"漏洞诊断"并列，而不是让它们互相替代，正是因为这两件事回答的是不同的问题：扫描告诉你"有一堆可能的问题"，渗透测试告诉你"哪几个真的能用、用了能拿到什么"。
三、动手 Demo：扫描器的结果要打七折看
下面这段脚本把"扫描器输出"和"真实相关性"放在一起看，并算出实际要处理的量：
# 一次扫描产出 1000 条发现
findings = 1000
relevant = 0.73 # 流行扫描器给出的结果里约 73% 是相关的
print("1000 条发现里，约", int(findings * (1 - relevant)), "条是噪音")
print("72% 的安全人员说误报正在损害团队效率")
实跑输出：
一、先看一眼暴露面长什么样（端口扫描结果）
端口 服务 版本 风险点
----------------------------------------------------------------------------------------------
22 SSH OpenSSH 7.4 版本已停更，存在多个已知漏洞
80 HTTP nginx 1.14 未强制跳转 HTTPS
443 HTTPS nginx 1.14 TLS 1.0/1.1 仍启用
3306 MySQL 5.7 【直接对公网开放】
8080 Tomcat 9.0.30 管理页可访问
6379 Redis 5.0 【无认证，可写任意键】
9200 Elasticsearch 7.6 【未启用鉴权，可读全部索引】
3389 RDP Windows 暴露在公网，易被暴力破解
21 FTP vsftpd 明文协议，账号密码可被嗅探
27017 MongoDB 4.4 【无认证，数据库可被直接导出】
→ 10 个端口里 4 个属于【根本不该对公网开放】的那一类。
这类信息被动侦察就能拿到：Shodan 一类的搜索引擎索引了
超过 1500 万台仍在跑【已终止支持软件】的联网设备。
二、漏洞诊断的三种做法
做法 谁在干 广/深 典型工具
----------------------------------------------------------------------------------------------
端口扫描 任何技术人员 广/浅 Nmap、Masscan
漏洞扫描 IT 运维即可 广/浅 Nessus、OpenVAS、Qualys
渗透测试 专业测试人员 窄/深 Metasploit、Burp Suite、ZAP
三、扫描器不是万能的（这组数字要记住）
流行扫描器给出的结果里，只有 73% 是相关的
→ 1000 条发现里，约 270 条是噪音
72% 的安全人员说：误报正在损害团队效率
→ 扫描器告诉你【可能有什么问题】；
渗透测试告诉你【攻击者到底能用它做到什么】。
读这个输出：
- 第一张表里最值得记住的不是那些"有问题的端口"，而是"这几类端口为什么会被扫到"。数据库、缓存、搜索中间件对公网开放，属于"配置层面就能避免"的问题——也就是说，这一类问题的修复成本几乎为零，但它是被利用得最多的一类（4-11 里"顽固弱点"讲的就是这种"年年提、年年有"的问题）。
- 第三部分的两个数字是这一节最实用的判断依据："流行扫描器的结果里只有 73% 是相关的"意味着"1000 条发现里约 270 条是噪音"；而"72% 的安全人员说误报正在损害团队效率"说明了它的代价。这两个数字合起来的结论是：扫描器是"发现问题的工具"，不是"决定做什么的工具"——它给出的是一份待审清单，而不是一份待办事项。
- 第三部分最后那句话是这一节的落点：扫描器回答"可能有什么问题"，渗透测试回答"攻击者能用它做到什么"。这个区别在真实工作中决定了资源往哪儿投：扫描是"每天都要跑"的例行动作，渗透测试是"重要节点做一次"的深度检验。
四、⚠️ 2026 现状
- 【误报问题没有好转，而且开始被当成"工具选型"的核心指标】。 2026 年有一组很具体的观测：在一项对 20 个测试容器的分析中，流行扫描器报了超过 450 条"高危"发现，其中大量是误判（这与"只有 73% 相关"的口径互相印证）。同时"72% 的安全人员表示误报损害了团队效率"这个数字说明：误报不只是"麻烦"，它直接消耗了本该用在修复上的时间。所以今天评估扫描工具，重点已经不只是"能查多少漏洞"，而是"信噪比有多高"。
- 【"主动侦察"和"被动侦察"的边界变得很重要】。 被动侦察（用公开搜索引擎收集暴露面）完全不接触目标系统，因此几乎无法被发现、也不涉及法律风险；主动扫描（真的去连端口、发探测包）会在对方的日志里留下痕迹，而且未经授权的扫描在很多地区是违法的。 2026 年这个区分变得更重要，因为它和"授权范围"直接挂钩——这也是下一段要讲的渗透测试的前提。
- 【对 Web 应用的测试已经有成体系的公开标准】。 渗透测试不再是"找一个高手随便试试"：国际上通行的框架包括 PTES（渗透测试执行标准）、OSSTMM（开源安全测试方法手册）、NIST SP 800-115（技术安全测试指南），针对 Web 应用的还有 OWASP 的测试指南（WSTG）。这些标准的共同作用是：把"测试到什么深度算完成"这件事变成一个可约定、可验收的东西——这也让渗透测试从"手艺"变成了"服务"。
- 【扫描的品类在扩张：从"端口"到"云配置"到"代码与依赖"】。 2026 年的一个明显趋势是，扫描这件事被拆成了好几条独立的流水线：基础设施层面（暴露面、配置错误）、应用层面（Web 与 API）、代码层面（静态分析）、依赖层面（软件成分分析与软件物料清单）。OWASP Top 10:2025 里把"软件供应链失效"新增为一个独立的高位类别（4-12），正是这个趋势的体现：你要盘点的已经不只是"我的服务器"，还包括"我用的每一个组件"。
30 秒实验
今天做两个动作，各 15 秒：
- 用"外部视角"查一下你自己或你公司的域名暴露了什么。最简单的做法：在搜索引擎里搜你的域名，看有没有不该出现的设备管理页、目录列表、调试接口被索引到。这一步不动目标系统一下，属于被动侦察——如果连公开可查的部分都有一堆不该有的东西，那说明暴露面管理这件事还没开始。
- 想清楚一个问题：你上一次"盘点自己有哪些机器、跑什么版本"是什么时候。如果答不上来，今天先做一件最基本的事：列出对外提供服务的所有系统（域名、IP、用途、负责人）。这张表用不着很全，哪怕只有五条也是进步——因为后面所有的漏洞管理动作（打补丁、排序、验证）都要以这张表为基础（4-2 讲的"知道自己在跑哪个版本"就是这一步）。
这一节要带走的一句是：先看清有哪些门开着（端口扫描），再查那些门的锁有没有坏（漏洞扫描），最后请人来试试能不能真进来（渗透测试）——顺序不能颠倒，也不能跳步。
常见误区
- 错误：装了漏洞扫描器，天天扫，就等于做好了漏洞管理。——纠正：扫描只是这条链上的第三个环节（发现），它既不负责"盘点"也不负责"修复和验证"。而且扫描器给出的结果需要人来判断："只有 73% 相关"意味着 1000 条发现里约 270 条是噪音，而且它判断"有没有漏洞"靠的是"版本号比对"，所以经常出现"版本对了但配置已经改过"或"版本对了但那个功能没启用"这种误判。 完整的链是四步： ① 盘点资产（我有哪些东西）→ ② 发现漏洞（自动化扫描）→ ③ 定优先级（4-13）→ ④ 修复并验证生效。少了任意一步，扫描出来的清单都会停在文件夹里。
- 错误：渗透测试能代替漏洞扫描。——纠正：两者是"深"和"广"的分工，不能互相替代。渗透测试的核心价值恰恰在于"窄而深"——它由人挑一个切入点，追到底，看能拿到什么，所以它必然覆盖不了全部资产。 反过来说，漏洞扫描"广而浅"——它能天天跑、覆盖全部机器，但它不会告诉你"这几个漏洞连起来能干什么"。 正确的用法是"扫描做底、渗透做尖"：日常靠扫描保持覆盖面，在重要节点（新系统上线、重大变更后、合规要求时）做一次渗透测试，用它的结论去校准扫描的排序。
- 错误：扫描自己的系统不算攻击，随时可以做。——纠正："扫自己的机器"这个前提在实际中经常不成立。你在公司网络里扫，扫到的可能不只是你自己的机器（同网段的其他人、共享的中间件、云上的其他租户）；你用的云主机，条款里通常明确禁止"对非本账号资源做端口扫描"；而未经授权扫描第三方系统，在多数地区属于违法行为。 所以正确的流程是： ① 明确范围（哪些 IP、哪些域名）→ ② 拿到书面授权（自己公司的也要）→ ③ 约定时间窗口（避免影响业务）。这不是形式主义——渗透测试的行业标准（PTES 等）都把"授权"列为第一阶段，正是因为越界扫描的后果很实际。
- 错误：扫描结果显示"无高危漏洞"，就说明系统安全。——纠正：扫描器的能力边界很明确，它只能发现"它认识的、有特征可匹配的问题"。它完全看不到的东西至少有三类：① 业务逻辑漏洞（比如"下单接口没校验数量，可以下负数"）；② 需要多步组合才能触发的漏洞链；③ 零日（4-3）。这也解释了为什么 4-10 会专门讲"WAF 挡不住业务逻辑漏洞"。所以"扫描无高危"的正确读法是： "在自动化能覆盖的范围内，没有发现已知问题"——这是一句有边界的话，不是一句保证。
自测三问（点开对答案）
1. 端口扫描、漏洞扫描、渗透测试，三者的关系用一句话怎么说清？ —— **端口扫描回答"有哪些门开着"，漏洞扫描回答"这些门后面有没有已知的坏锁"，渗透测试回答"攻击者真能进来并拿到什么"**。**前两种是"广度优先"（自动化、能天天跑、覆盖全部资产），第三种是"深度优先"（靠人、慢、覆盖窄、但能给出业务后果）**。**三者是递进关系，不是替代关系**：**端口扫描是漏洞扫描的输入（不知道开什么服务就没法比对漏洞库），而漏洞扫描的结果是渗透测试的输入（测试人员会优先试那些扫描出来的问题）。** **跳过前两步直接做渗透测试，等于让高手去猜你有哪些机器。** 2. 为什么说"扫描器给出的是一份待审清单，而不是一份待办事项"？ —— **因为它的相关性只有约 73%，也就是每 1000 条里约 270 条是噪音**，**而这些噪音会直接消耗处理时间**（**72% 的安全人员明确表示误报损害效率**）。**更根本的原因是：扫描器判断"有没有漏洞"靠的是"版本号 + 特征"，它不知道你的实际配置和业务上下文**——**同一个组件，在一个系统里是关键暴露面，在另一个系统里可能根本没启用相关功能。** **所以扫描结果必须经过"人 + 优先级"这一道处理**：**先按"是否已被实际利用（KEV）""是否暴露在公网"筛一遍，再决定谁今天修、谁排期修**（4-13）。**把扫描结果直接当待办清单，是漏洞管理最常见的失败方式。** 3. "暴露面盘点"为什么应该排在"找漏洞"之前？ —— **因为一个"根本不该存在的暴露"比一百个"需要修的漏洞"更值得优先处理**。**本节 Demo 里那张端口表就是说明：10 个端口里有 4 个是"数据库／缓存／搜索中间件直接对公网开放"——这类问题的修复成本几乎为零（关掉或收到内网），但它是被实际利用最多的一类**。**而且它的思路完全不同**：**"修漏洞"是"在保留这个暴露面的前提下把它变安全"，"减少暴露面"是"让这个攻击面直接消失"**——**后者天然更彻底，也不需要等厂商出补丁。** **先盘点、减少暴露，再做漏洞管理，这个顺序能让后面所有工作的量级都下降一个档次。**- ☐ 下一节（4-10 防范针对 Web 应用的典型攻击手段）
相关笔记
- 内存缓冲区溢出的滥用 —— 上一篇：老代码 + 没加固的设备
- 防范针对 Web 应用的典型攻击手段 —— 下一篇：Web 应用防火墙
- 修正系统软件漏洞 —— 盘点是为了知道该打哪些补丁
- 对系统漏洞进行量化评估 —— 扫描出的清单怎么排序
- 🛡️ 网络与信息安全 · 索引 —— 全课路线图