盡管互聯網上大多數流行服務都基于 TCP 協議運行，但 UDP 服務也廣泛部署。DNS、SNMP 和 DHCP（注冊端口 53、161/162 和 67/68）是最常見的服務之一。

由于 UDP 掃描通常比 TCP 掃描更慢、更困難，一些安全審計人員可能會忽略這些端口。這是一個錯誤，因為可利用的 UDP 服務非常普遍，攻擊者也不會忽視整個協議。幸運的是，Nmap 可以幫助清查 UDP 端口。

通過 -sU 選項激活 UDP 掃描。它可以與 TCP 掃描類型（如 SYN 掃描 -sS）結合使用，在同一次運行中檢查兩種協議。

UDP 掃描通過向每個目標端口發送 UDP 數據包來工作。對于大多數端口，這個數據包將是空的（沒有負載），但對于一些更常見的端口，會發送特定于協議的負載。根據響應（或沒有響應），端口被分配到四種狀態之一，如下表所示。

表 1.1. Nmap 如何解釋 UDP 探測響應

探測響應	分配狀態
來自目標端口的任何 UDP 響應（不尋常）	open（開放）
沒有收到響應（即使經過重傳）	open|filtered（開放或被過濾）
ICMP 端口不可達錯誤（類型 3，代碼 3）	closed（關閉）
其他 ICMP 不可達錯誤（類型 3，代碼 1、2、9、10 或 13）	filtered（被過濾）

這個表格中最令人好奇的元素可能是 open|filtered 狀態。它是 UDP 掃描最大挑戰的癥狀：開放端口很少響應空探測。那些 Nmap 有特定協議負載的端口更有可能收到響應并被標記為 open，但對于其余端口，目標 TCP/IP 棧只是將空數據包傳遞給監聽應用程序，后者通常會立即丟棄它作為無效數據。如果所有其他狀態的端口都會響應，那么可以通過排除法推斷出開放端口。不幸的是，防火墻和過濾設備也已知會在沒有響應的情況下丟棄數據包。因此，當 Nmap 在多次嘗試后沒有收到響應時，它無法確定端口是 open 還是 filtered。

在 Nmap剛 發布時，過濾設備比較少見，以至于 Nmap 可以（并且確實）假設端口是 open。現在隨著互聯網更好的進行防護，所以 Nmap 在 2004 年（版本 3.70）改變為將無響應的 UDP 端口報告為 open|filtered。

?nmap -sU -v 192.168.1.123?Starting Nmap ( https://nmap.org )Nmap scan report for 192.168.1.123(The 997 ports scanned but not shown below are in state: closed)PORT ?  STATE ? ? ? ? SERVICE53/udp  open|filtered domain67/udp  open|filtered dhcpserver111/udp open|filtered rpcbindMAC Address: 00:02:E3:14:11:02 (Lite-on Communications)?Nmap done: 1 IP address (1 host up) scanned in 999.25 seconds

掃描展示了 open|filtered 模糊問題以及另一個問題：UDP 掃描可能很慢。

Nmap 提供了繞過這兩個問題的方法，如下兩節所述。

區分開放和被過濾的 UDP 端口

案例中，除了三個 open|filtered 端口外，其他所有端口都是 closed。因此，掃描成功地將可能開放的端口縮小到少數幾個。情況并非總是如此。如下展示了針對192.168.1.223的 UDP 掃描。

?krad# nmap -sU -T4 192.168.1.223?Starting Nmap ( https://nmap.org )All 1000 scanned ports on 192.168.1.223 are open|filtered?Nmap done: 1 IP address (1 host up) scanned in 5.50 seconds

在這種情況下，掃描并未縮小開放端口的范圍。所有 1000 個端口都是 open|filtered。需要新的策略。

表 1.1，“Nmap 如何解釋 UDP 探測響應” 顯示 open|filtered 狀態發生在 Nmap 向特定端口發送 UDP 探測后未收到任何響應時。它還顯示，當 Nmap 收到 open|filtered 端口的響應時，狀態將更改為 open。原因這些服務很少響應是因為 Nmap 發送的空數據包被認為是無效的。不幸的是，UDP 服務通常定義自己的數據包結構，而不是遵循 Nmap 可以始終發送的某種通用格式。一個 SNMP 數據包與 SunRPC、DHCP 或 DNS 請求數據包完全不同。

為了向每個流行的 UDP 服務發送正確的數據包，Nmap 需要一個大型數據庫來定義探測格式。幸運的是，Nmap 有 nmap-service-probes，這是服務和版本檢測子系統的一部分，將在第 7 章，“服務和應用程序版本檢測” 中描述。

當通過 -sV（或 -A）啟用版本掃描時，它將向每個 open|filtered 端口（以及已知的 open 端口）發送 UDP 探測。如果任何探測從 open|filtered 端口收到響應，狀態將更改為 open。在 192.168.1.123掃描中添加 -sV 的結果如下所示。

?krad# nmap -sUV -F 192.168.1.123?Starting Nmap ( https://nmap.org )Nmap scan report for 192.168.1.123Not shown: 997 closed portsPORT ?  STATE ? ? ? ? SERVICE ?  VERSION53/udp  open ? ? ? ?  domain ? ? ISC BIND 9.2.167/udp  open|filtered dhcpserver111/udp open ? ? ? ?  rpcbind ?  2 (rpc #100000)MAC Address: 00:02:E3:14:11:02 (Lite-on Communications)?Nmap done: 1 IP address (1 host up) scanned in 1037.57 seconds

這個新的掃描顯示端口 111 和 53 肯定是開放的。系統并不完美——端口 67 仍然是 open|filtered。

我們可以推測，端口是開放的，但 Nmap 沒有適用于 DHCP 的有效版本探測。

另一個棘手的服務是 SNMP，它通常只有在提供正確的Community（社區字符串）時才會響應。許多設備配置了社區字符串 public，但并非全部。雖然這些結果并不完美，但能夠確定兩個測試端口中的兩個的真實狀態仍然很有幫助。

而對于192.168.11.230，使用版本檢測改進 UDP 掃描結果：

?nmap -sUV -T4 192.168.11.230?Starting Nmap ( https://nmap.org )Nmap scan report for 192.168.11.230Not shown: 999 open|filtered portsPORT ? STATE SERVICE VERSION53/udp open  domain  ISC BIND 9.3.4?Nmap done: 1 IP address (1 host up) scanned in 3691.89 seconds

提示信息：

之前端口掃描192.168.11.230花費了5秒，使用版本檢測改進UDP掃描花費了1個小時。Nmap 版本 5.10BETA1 及更高版本有一個負載系統，如果選擇進行端口掃描或主機發現，它會向 30 多個知名的 UDP 端口發送正確的服務協議請求。雖然它不如版本檢測全面，但它會迅速識別192.168.11.230中的開放端口 53。

提高 UDP 掃描速度

UDP 掃描的另一個主要挑戰是提高其速度。開放和被過濾端口很少發送響應，導致 Nmap 超時并進行重傳，以確保數據包未丟失。關閉端口往往是一個更大的問題，它們通常會發送 ICMP 端口不可達錯誤。但與 TCP 中關閉端口對 SYN 或 connect 掃描發送 RST 數據包不同，許多主機默認對 ICMP 端口不可達消息進行速率限制。Linux 和 Solaris 在這方面尤為嚴格。例如，192.168.1.123上的 Linux 2.4.20 內核將目的地不可達消息限制為每秒一個（在 net/ipv4/icmp.c 中）。這解釋了為什么示例 5.4 中的掃描如此緩慢。

Nmap 檢測到速率限制并相應地降低速度，以避免發送網絡無法處理的無用數據包。然而，對于 Linux 風格的每秒一個數據包限制，掃描 65,536 個端口需要超過 18 小時。以下是一些提高 UDP 掃描性能的建議。此外，第 6 章“優化 Nmap 性能”中還提供了更詳細的討論和一般性建議。

• 增加主機并行性

如果 Nmap 從單個目標主機每秒僅收到一個端口不可達錯誤，它可以通過同時掃描多個主機（例如 100 個）來每秒接收 100 個響應。通過向 --min-hostgroup 傳遞大值（例如 100）來實現這一點。

• 先掃描常見端口

非常少的 UDP 端口號被廣泛使用。使用 -F 選項掃描最常見的 100 個 UDP 端口將快速完成。你可以在后臺啟動對網絡的多天 65K 端口掃描，同時處理這些結果。

在版本檢測掃描中添加 --version-intensity 0

如前所述，版本檢測（-sV）通常需要區分開放和被過濾的 UDP 端口。版本檢測相對緩慢，因為它涉及向每個 open 或 open|filtered 端口發送大量特定于應用程序協議的探測。指定 --version-intensity 0 可以指示 Nmap 僅嘗試最有可能對特定端口號有效的探測。它通過使用 nmap-service-probes 文件中的數據來實現這一點。這種選項的性能影響是顯著的，如本節后面的示例所示。

• 從防火墻內部掃描

與 TCP 一樣，包過濾器會顯著減慢掃描速度。許多現代防火墻使設置包速率限制變得容易。如果可以通過從防火墻內部而不是跨防火墻發起掃描來繞過此問題，請這樣做。

• 使用 --host-timeout 跳過慢速主機

受到 ICMP 速率限制的主機可能比那些對每個探測都快速響應的主機需要多個數量級的時間來掃描。指定最大掃描時間（例如 15m 表示 15 分鐘）會導致 Nmap 在超出該時間后放棄掃描單個主機。這使你可以快速掃描所有響應迅速的主機。你可以在后臺處理這些慢速主機。

• Use -v and chill out

啟用冗長輸出（-v）后，Nmap 會提供每個主機的預計掃描完成時間。無需密切監視它。去睡一覺，去你最喜歡的酒吧，看書，完成其他工作，或者以其他方式娛樂自己，同時讓 Nmap 不知疲倦地為你掃描。

一個完美的提高 UDP 掃描速度的例子是示例 如下，我們再次運行了該掃描。這次添加了 -F --version-intensity 0 選項，將一個小時的掃描時間縮短至 13 秒！然而，同樣的關鍵信息（53 端口上的 ISC Bind 守護進程）被檢測到。

?nmap -sUV -T4 -F --version-intensity 0 192.168.11.230?Starting Nmap ( https://nmap.org )Nmap scan report for 192.168.11.230Not shown: 99 open|filtered portsPORT ? STATE SERVICE VERSION53/udp open  domain  ISC BIND 9.3.4?Nmap done: 1 IP address (1 host up) scanned in 12.92 seconds