问为什么UDP端口扫描比TCP端口扫描更复杂？

EN

实际上，您不能真正进行UDP端口扫描。虽然打开的TCP端口通常响应简单的SYN探测，但UDP没有套接字连接的概念。简单地说，没有单独的探测消息来查看UDP端口是否在监听。

因此，您可能不会从打开的UDP端口获得任何答复，除非您猜到它背后的正确应用程序协议，并且它选择回复( DNS服务器回复DNS请求，SNTP服务器回复SNTP请求，等等)。如果没有回复，您将不知道某个端口是否关闭，防火墙是否过滤了数据包，或者应用程序是否只是选择忽略您的请求。

基本上，您只能探测您知道或猜测应用程序层协议的UDP端口，并且可以将其转换为应答。这比发送通用TCP SYN要复杂得多。

当然，您可以尝试简单地检查关闭端口的ICMP目标端口不可访问的消息，但是这些消息通常是在开放的Internet和许多其他情况下被过滤(或根本不发送)。

对于TCP，有一个标准化的连接设置过程，它由操作系统实现并应用，不管使用的是什么应用程序协议。因此，您可以发送"syn“数据包作为探测，并根据响应确定端口是否”打开“(服务器继续进行连接设置过程中的下一步，发送"syn-ack")、”关闭“(连接被ICMP错误拒绝)或”筛选“(根本没有响应，这很可能表明通信被防火墙阻塞)。

另一方面，对于UDP，“封闭”端口将触发来自操作系统的响应，但对于打开的端口，操作系统将简单地将数据包传递给服务器应用程序，而不会生成它自己的任何响应。UDP服务器应用程序通常不会向他们不理解的数据包发送响应。

因此，当您发送UDP探测包而没有得到响应时，您无法知道您的数据包是否被防火墙过滤，或者它是否成功地传递到没有响应的应用程序(因为它不能解释数据包，或者因为它自己的内部策略)。

为了进一步说明扫描UDP所面临的挑战，这里有一些关于如何在nmap中实现该功能的详细信息，它可能仍然是当今最流行的端口扫描器：

UDP扫描通过向每个目标端口发送UDP数据包来工作。对于一些公共端口，如53和161，发送协议特定的有效负载以提高响应速率，但对于大多数端口，除非指定了-数据、-数据字符串或-数据长度选项，否则数据包是空的。如果返回ICMP端口无法访问的错误(类型3，代码3)，则端口将关闭。其他无法访问的ICMP错误(类型3，代码0、1、2、9、10或13)将端口标记为已筛选。偶尔，一个服务会响应一个UDP数据包，证明它是开放的。如果在重新传输后没有收到响应，则将端口分类为open_筛选。这意味着端口可能是开放的，或者可能是数据包过滤器阻塞了通信。版本检测(-sV)可以帮助区分真正打开的端口和过滤的端口。

和：

UDP扫描的一个大挑战是快速完成它。打开和过滤的端口很少发送任何响应，留下Nmap超时，然后在探测或响应丢失的情况下进行重传。关闭港口往往是一个更大的问题。他们通常发送一个ICMP端口无法到达的错误。但与关闭的TCP端口响应SYN或connect扫描而发送的RST数据包不同，许多主机的速率在默认情况下限制ICMP端口不可访问的消息。Linux和Solaris对此特别严格。例如，Linux2.4.20内核将不可访问的目标消息限制为每秒一条(在net/ipv4 4/icmp.c中)。

最后一段必须过时，不能确定当前的实现。

Nmap检测速率限制并相应地减慢，以避免将目标机器丢弃的无用数据包淹没网络。不幸的是，Linux格式的每秒一个数据包的限制使得65,536端口扫描需要超过18个小时.加速UDP扫描的想法包括并行扫描更多的主机，首先快速扫描流行的端口，从防火墙后面扫描，以及使用主机超时跳过慢主机。

来源：nmap -端口扫描技术

我似乎记得很久以前，Unicorn扫描仪有自己的方式扫描UDP，但现在找不到细节。因为每个端口扫描仪都有自己的方法来区分一个开放端口和一个封闭端口，它可能猜错了，结果可能会有所不同。最好的方法是使用像斯卡皮这样的工具来自己制作包并自己解释响应。