在进行端口扫描后，Nmap可以进一步探测出运行在端口上的服务类型及应用程序的版本。目前Nmap可以识别几千种服务程序的签名（Signature），覆盖了180多种应用协议。比如，端口扫描检测到80端口是开放的，可以通过服务与版本扫描来确定其实际运行的协议（正常情况下是HTTP）及Web服务器名称及版本（比如是Apache xxx.xxx或者Microsoft IIS等）。

1 简单引入

1.1 扫描原理

　　扫描原理是服务指纹（或称签名）对比匹配。Nmap内部包含了几千种常见服务指纹的数据库（nmap-service-probes），对目标端口进行连接通信，产生当前端口的服务指纹，再与指纹数据库对比，寻找出匹配的服务类型。

　　服务与版本侦测主要分为以下几个步骤：

1. 首先检查open与open|filtered状态的端口是否在排除端口列表内。如果在排除列表，将该端口剔除。

2. 如果是TCP端口，尝试建立TCP连接。尝试等待片刻（通常6秒或更多，具体时间可以查询文件nmap-services-probes中ProbeTCP NULL q||对应的totalwaitms）。通常在等待时间内，会接收到目标机发送的“Welcome Banner”信息。nmap将接收到的Banner与nmap-services-probes中NULLprobe中的签名进行对比。查找对应应用程序的名字与版本信息。

3. 如果通过“Welcome Banner”无法确定应用程序版本，那么nmap再尝试发送其他的探测包（即从nmap-services-probes中挑选合适的probe），将probe得到回复包与数据库中的签名进行对比。如果反复探测都无法得出具体应用，那么打印出应用返回报文，让用户自行进一步判定。

4. 如果是UDP端口，那么直接使用nmap-services-probes中探测包进行探测匹配。根据结果对比分析出UDP应用服务类型。

5. 如果探测到应用程序是SSL，那么调用openSSL进一步的侦查运行在SSL之上的具体的应用类型。

6. 如果探测到应用程序是SunRPC，那么调用brute-forceRPC grinder进一步探测具体服务。

1.2 服务扫描用法

版本侦测选项如下：

官方手册：http://nmap.org/book/man-version-detection.html

2 实现框架

下面先介绍服务与版本扫描涉及到的源文件与库、核心Class，然后介绍服务扫描的核心函数实现流程及流程的细节。

2.1 文件组织

service_scan.cc/service_scan.h

服务扫描的核心功能都在此两个文件中实现，文件结构清晰简洁，代码行数总共3000余行。与端口扫描部分类似，服务扫描也定义了不少类与接口函数。

nmap-service-probes

此文件是nmap服务扫描所需的数据库文件，包括定制的探测包及预期的回复包，及识别服务类型的具体匹配方式。

下面摘取其中片段，简单了解其结构。

第一行Probe关键字表示定义一个探测包，其类型为TCP，名字为NULL，探测字符串为空（q||）。以#开头为注释行，为读者提供参考信息。随后定义默认服务等待时间totalwaims 6000，即6秒钟。后面的match行，定义服务匹配的情况，即在此条件下认为此端口是运行的具体服务类型。match行的格式如下：

match []

service为服务名称，pattern为匹配的模式（正则表达式），versioninfo为该服务对应的版本信息。这里以match 1c-serverm|^S\xf5\xc6\x1a{| p/1C:Enterprise business management server/为例，当使用NULL探测包获取的返回包中包含：m|^S\xf5\xc6\x1a{|模式（该正则表达式含义：以字符S开头，紧随其后三个字符\xf5\xc6\x1a）时，并且从提取出厂商产品名字与1C:Enterprise businessmanagement server相符，那么判断该服务为1c-server。

其他的行与此类似，这里就不再赘述。

nsock library

服务与版本扫描部分用到nsock库，该库设计用于并发处理网络事件。在Nmap源码树下，有单独的nsock目录来管理nsock库。此处我们仅需要关注nsock.h文件中提供的API函数即可。

2.2 核心类分析

　　服务扫描过程中，主要构建了5个类，分别描述不同层次的数据类型。下面我们将以宏观到微观的思路，依次查看每个类的结构与用法。其中ServiceGroup从整理的角度管理服务扫描过程；ServiceNFO则具体的负责管理每一种服务扫描过程；AllProbes负责管理所有用于服务扫描的探测包；ServiceProbe则描述每一个进行服务探测的探测包细节（对应nmap-service-probes中描述的探测包）；ServiceProbeMatch则描述探测包的匹配类型（每一个ServiceProbe可能包含多种匹配类型）。

　　下面依次查看每个类的细节。

2.2.1ServiceGroup

　　ServiceGroup用于管理一组目标机进行服务扫描的信息。这个类非常重要，负责统一管理其他具体的信息：如单个服务扫描信息（ServiceNFO）、全部探测包信息（AllProbes）、服务探测包信息（ServiceProbe）等等。

　　该类主要包含以下具体内容：

1. 扫描完成的服务列表services_finished，记录目前已经扫描完毕的服务。
2. 正在扫描的服务列表services_in_progress。多个服务可能在同时并发地被探测，所以此处将当前正在扫描的服务全部记录在该列表中。
3. 剩余服务列表services_remaining，当前还没有开始探测的服务被放置在该列表中。在服务扫描初始化时，所有的服务的都被放置在列表中。
4. 最大的并发探测包ideal_parallelism，用于确定同时发送服务探测包的并发数量，此值取决于用户配置的时序参数和具体网卡的支持能力等因素。若配置时序为-T4，那么会将ideal_parallelism设置40。
5. 扫描进度测量器ScanProgressMeter，用于记录服务扫描的进度情况，以便能够实时地反馈给用户。在控制台界面按下普通按键（如按下空格键，不包括“vVdDp?”字符，这几个字符有特殊含义），Nmap会打印出当前的扫描进度。
6. 超时主机的数量，记录当前扫描超时的主机数量。

2.2.2ServiceNFO

　　ServiceNFO负责管理特定的服务的探测细节。上述的ServiceGroup中就是管理ServiceNFO对象组成的列表。

　　ServiceNFO类包含以下信息：

1. 服务指纹的管理（提供添加与获取等操作）
2. 服务扫描对应的主机（Target *target）
3. 服务探测匹配的信息（是否匹配、是否softmatch、ssl配置、产品、版本、CPE等信息）
4. 管理探测包（服务扫描过程可能需要发送多个探测包，在此对当前探测包、下一个探测包进行管理）
5. 管理回复包（提供添加与获取等操作）。
6. 服务扫描所需的全部探测包AllProbes *AP;

2.2.3AllProbes

　　AllProbes负责管理全部的服务探测包（Probes）。该类的对象从nmap-service-probes数据库文件中解析出探测包及匹配方式等信息，将之管理起来。在后续服务扫描时，在此对象中来按需取出探测包发送即可。

　　该类主要包含以下几个方面内容：

1. 探测包管理（探测包向量std::vectorprobes、NULL探测包等）
2. 编制回退数组（compileFallbacks），当回复包无法匹配当前字符串时，允许回退到上一次匹配字符串。
3. 管理排除端口列表。在nmap-service-probes中指定需排除的服务扫描，默认排除TCP的9100-9107端口，此类打印机服务会返回大量的无用信息。
4. 服务初始化接口与释放接口。

2.2.4ServiceProbe

　　ServiceProbe负责管理单个的服务探测包的详细信息。服务探测包具体的信息来自nmap-service-probes数据库文件，当AllProbes类在初始化时会读取该文件，并依据其每个探测信息创建ServiceProbe对象，放置在AllProbes内部的向量std::vectorprobes中。

　　该类主要包含以下内容：

1. 探测包名字，比如探测包名字叫NULL或GenericLines等等。
2. 探测包字符串及字符串长度。非NULL探测包都包含探测需要字符串，所以此处对该信息进行管理。例如，对于探测包：Probe TCP GenericLinesq|\r\n\r\n|，其探测字符串为\r\n\r\n。
3. 允许的端口及SSL端口。除NULL外，探测包通常只会针对特定的端口扫描才有效，所以此处即管理该探测包允许的扫描的端口。
4. 探测包的协议类型probeprotocol，只能是TCP或UDP。
5. 可被探测的服务类型detectedServices。与允许端口类似，探测包可能只能用于某些特定的服务的探测，所以此处统一管理能被探测的服务类型。
6. 服务探测包匹配管理。该类中使用向量std::vector matches来管理此服务探测包可能会匹配的情况，匹配情况对应到nmap-service-probes中的match与softmatch行。
7. 探测回退数组（fallback array）的管理，此对应到AllProbes中compileFallbacks()函数，此处管理具体的服务探测包进行回退的数组。数组结构：ServiceProbe*fallbacks[MAXFALLBACKS+1];
8. 测试是否匹配，此接口函数用于测试某个回复包是否与预期结果匹配。
9. 其他接口函数，管理其他普通信息。

2.2.5ServiceProbeMatch

　　ServiceProbeMatch用于管理特定的服务探测包的匹配信息（match）。nmap-service-probes文件中每一个match和softmatch行都对应到该类的对象。

该类信息比较丰富，以下仅简要描述：

1. 探测包匹配详细信息（版本、产品、CPE等等）
2. 探测匹配情况（匹配类型、匹配字符串、正则表达式等等）
3. 测试是否匹配接口函数。若匹配成功，返回详细的服务与版本信息。

2.3 代码流程

　　在nmap.cc文件的nmap_main()函数中，如果配置了服务扫描，那么调用service_scan()函数（位于service_scan.cc文件中）。服务扫描的内容主要在service_scan()函数中完成。

　　service_scan()函数比较简洁，只有120多行代码。因为服务扫描涉及到具体详细的操作都封装到类或其他的静态非成员函数中了，而并发处理网络事件部分调用nsock库来处理。

2.3.2流程解析

　　首先在nmap_main()中将扫描目标机传入service_scan()函数中，以便根据目标机端口状态来筛选需要扫描的服务。

　　然后，在AllProbes:: service_scan_init()读取nmap-service-probes文件，解析出被排除的端口、扫描过程需要的探测包、探测包匹配等详细信息。将信息存放在AllProbes对象内。

　　随后，根据Targets和AllProbes创建服务组对象（ServiceGroup），从Targets中解析出开放的端口与处于open|filtered状态的端口，创建对应的ServiceNFO对象，该服务等待被扫描。并创建扫描进度测量器，以便后续打印出扫描进度；确定最佳的扫描并发度ideal_parallelism。

　　然后，确定排除端口。默认情况下，排除nmap-service-probes中指定的端口Exclude T:9100-9107；而如果用户命令行指定--all-ports，那么不排除Exclude指定的端口。

为每个目标机设置超时时钟，获取当前时间。

　　然后开始进入关键环节，创建nsock pool，即nsock处理并发探测包的事件池。在创建nsock pool后，服务扫描才能使用nsock建立连接并注册事件。

根据用户需求，设置服务扫描的trace信息。

　　若配置了openssl时，将其速度设置为最大。因为对于服务扫描，仅关心端口的服务类型，不必在安全性花费过多时间。

　　然后开始启动少量的服务探测包（launchSomeServiceProbes）。根据前述步骤得出的服务探测包，创建nsock niod（io描述符，类似于文件描述符，管理输入输出），完成地址等信息配置，然后建立CP连接或UDP连接，在建立连接后向nsock pool注册事件。此后，该连接的事件将交给nsock loop来统一处理。

　　创建nsock主循环（nsock_loop），在此循环中来接收网络事件（例如接收到回复包），调用相应的处理函数对事件响应（函数servicescan_read_handler()、servicescan_write_handler()、servicescan_connect_handler()）。在处理函数中，扫描完成了某些服务后，会再调用launchSomeServiceProbes()函数加载剩余的服务进来扫描，以此整个服务扫描过程就被有序地连接起来了。

　　当nsock循环退出，检查是否有错，并删除nsock pool对象。

　　打印出调试信息，处理最终扫描结果。

3 源码注释