nmap不支持的指纹识别方法

1.Passive Fingerprinting
被动指纹识别使用与Nmap执行的活动指纹识别相同的大部分技术。不同之处在于，被动系统只是嗅探网络，在主机观察其流量时机会性地对主机进行分类。这比主动指纹识别更困难，因为您必须接受任何通信发生而不是设计自己的自定义探测器。这是一种有价值的技术，但不属于Nmap等主动探测的工具。 幸运的是，Michal Zalewski编写了优秀的p0f被动操作系统指纹识别工具。 他还设计了几个当前的Nmap OS指纹测试。 另一种选择是由GomoR提供的SinFP，它支持主动和被动指纹识别。

2.Exploit Chronology
TCP / IP指纹识别适用于区分不同的操作系统，但检测同一操作系统的不同版本可能很麻烦。 公司必须以某种我们可以区分的方式改变他们的堆栈。幸运的是，许多操作系统供应商会定期更新其系统以符合最新标准。 但那些不这样做的人呢？他们中的大多数最终至少可以解决可利用的堆栈错误。 这些修复程序很容易远程检测到。 首先发送exp，无论land attack, teardrop, ping of death, SYN flood, or WinNuke。 一次发送一次攻击，然后立即尝试再次连接系统。如果它突然没有响应，那么您已将操作系统缩小到未附带修复程序的版本。
如果将拒绝服务（DoS）漏洞利用作为操作系统检测套件的一部分，请记住最后执行这些测试

3.Retransmission Times
TCP实现在重新传输数据包之前确切地等待多长时间具有很大的余地。概念验证工具Ring和Cron-OS可以利用它。它们将SYN数据包发送到开放端口，然后忽略它们收到的SYN / ACK，而不是用ACK（完成连接）或RST（杀死它）来确认它。目标主机将重新发送SYN / ACK几次，这些工具会跟踪等待的每个亚秒。虽然可以从这种技术中收集到一些信息，但有几个原因我没有将补丁纳入Nmap：
它通常需要修改源主机防火墙规则，以防止系统使用RST数据包回复它收到的SYN / ACK。这很难以便携的方式进行。即使很容易，许多用户也不喜欢使用防火墙规则的应用程序。
它可能很慢。重传可以持续几分钟。这是一个等待测试的很长时间，该测试首先没有提供所有那么多信息。
它可能是不准确的，因为数据包丢失和延迟（您必须在实际环境中预期）可能导致虚假结果。

我在这里列举了这些原因，因为它们也适用于其他一些OS检测方法。我很想添加新的测试，但它们必须快速并且需要很少的数据包。与主机防火墙混淆是不可接受的。我尽量避免为堆栈指纹识别创建完整的TCP连接，尽管这是作为版本扫描系统的一部分进行操作系统检测。

4.IP Fragmentation
IP分段是一个复杂的方案，实现充满了错误和不一致。可能的测试可以检查重叠片段的组装方式或碎片整理超时的时间。Nmap避免了这些测试，因为许多防火墙和其他内联设备对网关的流量会对进行分段整理。 因此，Nmap可能最终指向防火墙而不是真正的目标主机。此外，在某些操作系统上很难发送片段。Linux 2.6内核倾向于在传输之前对您尝试发送的片段进行排队并自行组装。
5.Open Port Patterns
通常可以通过查看打开的端口来猜测目标主机OS。 Microsoft Windows计算机通常打开TCP端口135和139。Windows 2000和更新版本也在端口445上侦听。同时，在端口22（ssh）和631（Internet打印协议）上运行服务的机器可能正在运行Unix。

虽然这种启发式方法通常很有用，但它对Nmap来说还不够可靠。防火墙规则可以掩盖端口的组合，并且大多数主流协议可在多个平台上使用。 OpenSSH服务器可以在Windows上运行，“Windows SMB”端口可以由在Unix机器上运行的Samba提供服务。端口转发进一步覆盖了这个问题。 似乎运行Microsoft IIS的计算机可能是Unix防火墙，只是因为将端口80转发到Windows计算机。

由于这些原因，Nmap在TCP / IP堆栈指纹识别期间不考虑开放端口号。但是，Nmap可以使用版本检测信息来分别发现操作系统和设备类型信息。通过将OS检测和版本检测发现的OS检测结果分开，Nmap可以优雅地处理使用TCP端口转发到Windows Web服务器的Checkpoint防火墙。堆栈指纹结果应该是“Checkpoint Firewall-1”，而版本检测应该建议操作系统是Windows。请记住，只有一小部分版本检测签名包括操作系统和设备类型信息 - 我们只能在应用程序泄露信息时或仅在一个操作系统或设备类型上运行时填充这些字段。

6.Retired Tests
有些测试曾经由Nmap执行过，但已经退役，因为它们被发现无助于区分操作系统并且只占用数据库中的空间。删除了IE行中的两个测试：DLI检查返回数据包中数据有效负载的长度，SI检查ICMP序列号。因为从未发现它们与发送的值不同。在U1行中，RUL测试检查返回的UDP数据包的长度。它与1700多个案例中仅发送的案例不同。这些测试于2009年3月删除。

其他测试被删除，因为他们太有辨别力; 它们导致测量误差，损害了检测精度。这两者都与响应中的TOS（服务类型）字段有关。TOS为U1探测器做了这个，而TOSI为IE做了这个。 尽管测试值在操作系统之间确实存在合理差异，但由于TOS被中间主机修改，因此通常会记录错误差异。当这些测试在2008年10月被删除时，总体上取得了更好的结果