Nmap 常被介绍成一条寻找开放端口的命令，它的架构给出的承诺却更审慎：从一个网络位置发出经过设定的探询，对回应与沉默加以分类，再在后续阶段补充这些观察，最后报告现有证据能够推断什么，以及仍有哪些内容无法推断。这套设计之所以耐久，靠的是让观察、识别与确定程度各居其位，单个数据包技巧只占其中一环。

扫描结果一旦成为资产清单的证据，这项区分便直接关系到如何解读报告。open 端口表示扫描器从自身观察位置直接看见一个正在监听的服务；从端口号推断出的服务名称属于惯例；-sV 返回的产品与版本来自指纹匹配；-O 对操作系统的猜测则另行比对网络协议栈的行为；NSE 结果是代码对通信的解释。Nmap 能把这些内容汇入同一份报告，内部阶段仍会留下各自来源的清晰线索。[1]

封面照片中的 Gordon Lyon 是 Nmap 的创始人，摄于 2006 年 HOPE Number Six 大会。此时，项目早已超出 1997 年诞生时的端口扫描器形态，维护方式依然清楚可辨：一组职责明确的引擎，加上社区持续整理的数据库，与宣称掌握“网络真相”的黑箱设备有着清楚区别。[6][8]

一次扫描沿着流水线展开

Nmap 首先把目标表达式解析成地址，随后可依次执行主机发现、反向 DNS 解析、端口扫描、服务与版本检测、操作系统检测、路由跟踪、脚本扫描和结果输出。多个阶段都可省略，相应开关也显露出模块之间的分界：-sn 在发现主机后跳过端口扫描；-Pn 跳过发现阶段，直接把目标视为在线；-n 跳过 DNS；-sV 增加服务探测；-O 增加操作系统指纹识别；--traceroute 绘出路径；-sC 调用默认的 NSE 脚本集。[1]

这种安排关乎整个扫描过程，作用超出命令行整理。越靠后的阶段，问题越具体，成本通常也越高。发现阶段判断某个地址是否值得继续检查；端口扫描为端点分类；版本检测向有迹象的端点继续询问；操作系统检测把主机的协议行为与已知指纹相比较；脚本还能开展针对具体协议的对话。各阶段分开以后，操作人员可以依据前一阶段的证据决定后续投入。

这条流水线还解释了选项为何会改变结果含义，同时改变耗时。使用 -Pn 时，未使用的地址无法在发现阶段迅速退出，扫描会继续进入端口探测，并在没有回应时消耗时间。使用 -sn 得到的是可达性证据，结果没有涵盖服务是否存在。加入 -sV，轻量的状态调查会扩展为应用层交互。因此，保存结果时也应保存完整命令行；缺少命令记录，两份外观相近的报告实际可以来自不同实验。

端口状态取决于观察者

Nmap 定义了六种端口状态：open、closed、filtered、unfiltered、open|filtered 和 closed|filtered。项目文档中的要点在于，这些状态不属于端口自身固有的属性；它们描述的是 Nmap 如何看到端口。[2] 同一个 TCP 端口在内部网段上可以显示为开放，从互联网观察却显示为被过滤，两项发现即使发生在同一时刻也都成立。

含混状态把含混的原因留在报告里。UDP 扫描没有收到回应时，应用程序可以已经接收数据包而保持沉默，防火墙也可以丢弃数据包，途中还可以发生丢包。写成 open|filtered，这些解释都会继续可见。类似地，filtered 表示过滤措施阻断了探测，扫描器因而无法判断端口开放还是关闭。这个状态不等于“安全”“离线”或“没有服务”。

沉默也会增加成本。过滤设备若直接丢包，没有发出拒绝，计时引擎便要为丢包和重传留出时间，然后才能确定状态。大量受过滤的目标因此会比及时回应的目标耗时更久。这是如实分类带来的架构结果：立即返回的“closed”是一条信息，缺失的回应则要占用超时预算。[2]

对于周期性资产清单，实用的记录单元应从 host:port 扩展为 vantage point + target + protocol + scan type + time + reason。扫描器所在位置、源端路径、Nmap 版本、完整选项和时间戳都应保留。防火墙上线后，某个端口若从 open 变为 filtered，这些上下文能够区分访问控制变化与应用程序停止运行。

识别依据存放在数据中，端口号只提供线索

默认扫描依据 nmap-services 中的频率数据，优先检查 1,000 个 TCP 端口；端口旁最初显示的服务标签也来自这张表。它是一项有用的先验信息，仍不等同于证明。HTTP 可以监听在 80 以外的端口，443 上同样可以运行其他服务。[2]

版本检测划出了下一处分界。启用 -sV 后，Nmap 会把 open 或 open|filtered 端点交给并行运行的服务扫描子系统。nmap-service-probes 数据库以 Probe、match、softmatch、ports、sslports、rarity 和 fallback 等指令描述要发送的内容，以及如何识别回应。项目借助这套语法增补或改进识别规则，各种协议交互便可由数据库表达，扫描核心只处理通用流程。[3]

探测顺序带有明确条件。回应可以匹配某项产品特征；软匹配可以缩小后续探针的选择范围；检测到 TLS 后，还可以在加密连接内再次尝试。原本含混的 UDP 端点一旦对服务专用探针作出回应，状态就能转为 open。这个阶段把数据包证据转化成更具体的假设，工作远远超出扩充端口名称查找表。[3]

即便产品匹配度很高，推断仍有适用范围。横幅信息可以修改，中间设备可以终止连接，厂商也可以回移植安全修复，同时保留看起来与上游相同的版本字符串。Nmap 文档本身便警告，只有报告中的版本信息，无法证明漏洞存在。[3] service、product、version 与 CPE 字段只适合作为核对线索，应与软件包、设备或云资产清单相互印证；是否需要补丁仍要另行判断。

操作系统指纹识别由独立推断引擎完成

操作系统检测另起一套流程，以协议栈行为为依据。为 IPv4 建立指纹时，Nmap 最多会发送 16 个 TCP、UDP 和 ICMP 探针，测量 TCP 选项次序、窗口值、序列行为、IP ID 以及对异常输入的回应等细节，再把所得指纹与数据库比较。部分测试同时需要找到一个开放和一个关闭的 TCP 端口；缺少其中任意一种，现有证据都会减弱。[4]

这种拆分避免了常见的类别混淆。Web 服务器横幅描述面向应用的端点，操作系统指纹则描述回应探针的网络协议栈。反向代理、负载均衡器、防火墙、容器边界或端口转发会让两个层面的结果看起来不一致，因为相关数据包可以终止于不同组件。这样的差异本身便是有用的运维证据，值得原样保留。

NSE 扩展流水线，同时保持自身范围

Nmap Scripting Engine（Nmap 脚本引擎，NSE）内嵌 Lua，并开放 Nmap 专用的网络与结果 API。脚本可以在扫描前运行，也可以在主要脚本阶段针对主机或端口运行，还可以在常规工作结束后运行；输出会同时进入供人阅读的结果与 XML 结果。规则决定脚本是否适用，action 则执行协议专用工作。[5]

这是一个有意划定范围的扩展点。Lyon 在 USENIX 访谈中解释，贡献者掌握相关接口，便可把新想法写成脚本，各项功能也能留在 Lua 层；脚本出错时，故障可以停留在脚本层，不至于让整个扫描器崩溃。[6] 这条分界也让操作人员知道该管什么。--script 与通用的“更多细节”开关含义不同：脚本类别具有不同的安全与流量特征，自定义脚本运行时会直接执行代码。在整个设备群上安排定时运行前，应固定 Nmap 软件包版本，记录选定的脚本表达式与参数，审查本地提供的脚本，并在有代表性的系统上测试。

源代码公开，重新分发条款更窄

Nmap 在开放安全工具史上居于重要位置。项目发布源代码、接受社区贡献，也允许终端用户免费下载并使用扫描器。不过，当前的 Nmap Public Source License（NPSL）没有包含 Open Source Definition 所要求的重新分发权。项目法律声明指出，如未另行签订 OEM 协议，NPSL 不允许把 Nmap 置于商业软硬件产品中重新分发；它从 GPLv2 派生的条款也与部分开源许可证不兼容。[9]

这项限制之所以重要，在于 Open Source Definition 要求自由重新分发，同时禁止对特定使用领域加以歧视。[10] 工程师把 Nmap 作为经授权的内部工具运行，与厂商把 Nmap 引擎嵌入设备，面对的是不同的许可决策。公开可见的源代码和开放的贡献流程仍有重要技术价值，团队应以实际条款判断重新分发权，仓库可访问和 Nmap 过去的称谓都不足为据。采用某个版本与分发模式前，应查阅对应的 NPSL 及其捆绑组件条款。[9][10]

把扫描变成经得起核查的资产证据

当了解目标的操作人员从已知网络位置发起扫描并负责解释结果时，Nmap 适合用于一次性诊断。团队若加入可重复执行的条件，它也适合持续盘点暴露面：明确的目标清单、范围收窄的扫描配置、结构化 XML 输出、留存的命令与版本、至少两个有意义的观察位置，以及专门复核含混或变化结果的流程。

团队若期待一次未经身份验证的扫描就等同于完整资产事实，Nmap 只能成为薄弱的替代品。主机可以处于休眠状态，可以因自动扩缩容而暂时消失，也可以藏在网络地址转换之后、仅经另一种地址族到达，或被选定源位置之外的过滤规则挡住。服务指纹无法揭示所有已安装软件包，监听中的进程也不能证明业务负责人知晓该资产。应根据具体环境，将 Nmap 结果与云 API、DHCP/DNS 记录、端点管理、负载均衡器配置和经过身份验证的软件包数据相互核对。

扫描范围和运维成熟度同样重要。NIST 的测试指南把技术安全评估定义为一项包含规划、分析和缓解措施的流程，工具执行只是其中一部分。[7] 实际工作中，只扫描自己拥有或获准评估的系统；明确目标网段与排除项；与网络及服务负责人协调；设定可接受的流量时段；把结果作为敏感基础设施数据保管；明确由谁调查新出现的暴露。脆弱设备、限速服务与监控系统都会对主动探测作出反应。

评估采用效果时，可以检查团队能否解释一项结果的证据链：这个地址为何进入目标范围？哪一阶段产生了这项判断？哪一次回应或沉默导致这一状态？产品名称来自数据表还是探针匹配？运行过哪些脚本？扫描从哪里发起，又发生在何时？如果这些答案进入资产清单工作流后仍然完整，Nmap 就发挥了其架构最擅长的作用：把网络行为转成带有限定、可供检查的证据，同时让不确定性原样留存。

Sources

1. Nmap Project，“The Phases of an Nmap Scan”，涵盖目标枚举、发现、解析、扫描、信息补充、脚本运行和结果输出的顺序。
2. Nmap Project，“Port Scanning Overview”，涵盖依据经验数据选择端口、六种与观察者相关的状态、过滤、含混状态和重传成本。
3. Nmap Project，“Service and Application Version Detection”，涵盖并行探询、nmap-service-probes 语法、特征匹配、TLS 处理和版本判断的限度。
4. Nmap Project，“TCP/IP Fingerprinting Methods Supported by Nmap”，涵盖操作系统检测的探针集、所需端点证据、回应属性和指纹建立过程。
5. Nmap Project，“Nmap Scripting Engine”，涵盖 Lua 扩展模型、运行阶段、规则、action、API、并行执行和结果整合。
6. Rik Farrow，“Interview with Gordon Lyon”，USENIX ;login:，2016 年冬季刊；这篇独立访谈讨论 Nmap 的起源、指纹社区，以及核心与脚本扩展之间的分界。
7. Karen Scarfone 等，Technical Guide to Information Security Testing and Assessment，NIST SP 800-115，2008 年；涵盖技术测试的规划、执行、分析、限制与缓解措施。
8. Jacob Appelbaum，“Fyodor at HOPE Number Six”（2006 年 7 月），Wikimedia Commons；本文图片的档案照片来源。
9. Nmap Project，“Legal Notices”，涵盖 NPSL 赋予终端用户的权限、商业重新分发限制、许可证兼容性、捆绑组件条款和操作注意事项。
10. Open Source Initiative，“The Open Source Definition”，涵盖自由重新分发、派生作品和使用领域条款，这些标准用于区分 OSI 定义的开源软件与仅有源代码可见的软件。