如果使用公共 Wi-Fi，為什麼要停用 LLMNR？

LLMNR 協定在 Microsoft 環境中並不常見。在以 Windows 為主的網路中，該協定預設為啟用。雖然它曾經很實用，但如今卻常常帶來麻煩而非幫助。因此，了解如何使用它是個好主意。 如何禁用 LLMNR 尤其是當我們使用公共 WiFi 網路時。

在做出任何決定之前，最好先了解它的作用以及為什麼建議要停用它。 好消息是禁用它很容易。 在 Windows（包括 Windows Server）和 Linux 上，可以透過原則、登錄、Intune 或透過調整 systemd-resolved。

什麼是 LLMNR？它是如何運作的？

LLMNR 是的首字母縮寫 鏈路本地多播名稱解析其目的是 無需依賴 DNS 伺服器即可解析本地網段內的主機名換句話說，如果一台機器無法透過 DNS 解析名稱，它可以嘗試使用多重播送查詢鄰居，看看是否有人「明白了」。

該機制使用連接埠 UDP 5355 並且設計用於在本地網路內運行。 查詢透過多播發送 到直接網絡，任何“識別”該名稱的計算機都會回應說“那就是我”。對於 DNS 不可用或沒有意義配置的小型或臨時環境，這是一種快速而簡單的方法。

實際上，LLMNR 查詢會傳送到本地段，並且監聽該流量的裝置如果認為它們是正確的目的地，則可以做出回應。 其範圍僅限於本地鏈接，因此當網路上沒有正式的名稱服務時，它的名字和其作為“補丁”的用途。

多年來，它被證明是有用的，特別是在較小的網路或臨時部署中。 如今，DNS 已經普及且價格低廉，用例已經縮小了很多，關閉 LLMNR 並更加平靜地生活幾乎總是有意義的。

LLMNR 真的有必要嗎？風險與背景

價值百萬美元的問題：我應該把它取下來還是保留它？在家庭環境中，最常見的答案是“是的，儘管取下來吧。” 在公司中，驗證影響很方便：如果環境的 DNS 設定正確且搜尋正常，LLMNR 將不會提供任何功能並會帶來不必要的風險。

最大的問題是 LLMNR 不包含針對冒充的保護您自己子網路中的攻擊者可以「冒充」目標設備，並提前或優先回應，從而重定向連接並造成混亂。這是一個經典的老式「中間人」（MitM）攻擊場景。

打個比方，它讓人想起 Wi-Fi WEP 標準，在該標準誕生時沒有考慮到現代攻擊，並且已經過時了。 LLMNR 也發生了類似的事情：它在過去很有用，但今天如果你把它留在公司網路上，它就為欺騙打開了大門。

此外，如果對手掌握了正確的工具，當他們認為自己正在與合法伺服器對話時，他們可以強迫您的電腦「唱出」敏感訊息，例如 NTLMv2 哈希值。 一旦攻擊者獲得這些哈希值，可以嘗試破解它們 - 成功率取決於策略和密碼複雜性 - 增加了真正入侵的風險。

何時禁用 LLMNR？

在絕大多數現代部署中，您可以停用它而不會破壞任何東西。 如果您的用戶端始終透過 DNS 解析 如果你不依賴本地網路上的“魔法”，LLMNR 就顯得多餘了。不過，在將策略推廣到整個組織之前，還是應該在關鍵環境中進行驗證。

請記住，該決策不僅僅是技術性的：它還可以降低您的營運和合規風險。 禁用 LLMNR 是一種簡單、可衡量且有效的增強控制。，這正是任何合理的安全框架所要求的。

在 Windows 中停用 LLMNR

以下是 Windows 中停用 LLMNR 的主要選項：

選項 1：本機群組原則編輯器（gpedit.msc）

在獨立電腦上或為了快速測試，您可以使用本機群組原則編輯器。 按 WIN + R，輸入 gpedit.msc 並接受開啟它。

然後，瀏覽： 電腦設定 > 管理範本 > 網路在某些版本中，該設定出現在 DNS客戶端. 找到條目“禁用多播名稱解析” （名稱可能略有不同）並將政策設為「已啟用」。

在 Windows 10 中，該文字通常會讀作「停用多播名稱解析」。 應用或接受變更並重新啟動電腦。 以確保團隊端設定正確應用。

選項 2：Windows 註冊表

如果您希望直接進入主題或需要可編寫腳本的方法，您可以在註冊表中建立策略值。 打開 CMD 或 PowerShell的 具有管理員權限 並執行：

REG ADD "HKLM\Software\Policies\Microsoft\Windows NT\DNSClient" /f
REG ADD "HKLM\Software\Policies\Microsoft\Windows NT\DNSClient" /v "EnableMulticast" /t REG_DWORD /d 0 /f

這樣，LLMNR 將在政策層面被禁用。 重新啟動電腦即可關閉循環 並防止先前狀態的進程保留在記憶體中。

使用域中的 GPO 停用 LLMNR

停用 LLMNR 的另一種方法是透過開啟群組原則管理控制台從網域控制器集中套用變更。 建立一個新的 GPO（例如“MY-GPO”） 並編輯它。

在編輯器中，請按照以下路徑操作： 電腦設定 > 管理範本 > 網路 > DNS 用戶端. 啟用「停用多播名稱解析」策略 並關閉編輯器進行儲存。然後，將 GPO 連結到相應的 OU，並強制策略刷新或等待正常複製。

搞定。現在，您擁有了一項持續削減 LLMNR 的網域策略。 請記住，調整的具體名稱可能會有所不同。 Windows Server 不同版本之間略有不同，但位置均如圖所示。

Intune：“已套用”，但 gpedit 顯示“未配置”

一個常見的問題是：您從 Intune 推送配置文件，它會告訴您它已正確應用，而當您打開 gpedit 時，您會看到該設定為「未配置」。 這並不一定意味著它不活躍。。 Intune 透過 CSP/登錄應用程式設定，但這些設定並不總是在本機編輯器中反映為「已配置」。

檢查這一點的可靠方法是查閱策略日誌： 如果存在且等於 0，則值 啟用多播 HKLM\軟體\策略\微軟\Windows NT\DNS客戶端，即使 gpedit 顯示“未配置”，LLMNR 也已停用。

如果您希望透過腳本來確保這一點（像 Intune 中的補救措施一樣有用），這裡有一個簡單的 PowerShell 腳本來建立值並驗證它：

New-Item -Path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient" -Force | Out-Null
New-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient" -Name "EnableMulticast" -PropertyType DWord -Value 0 -Force | Out-Null
(Get-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient").EnableMulticast

這涵蓋了 Intune 說已套用但您想要最大程度的確定性或排除「惡意」裝置故障的情況。 若要進行批次審計，請將腳本與清單工具結合使用 或使用 Intune/Defender for Endpoint 報告。

在 Linux 上停用 LLMNR（systemd-resolved）

在使用 systemd-resolved 的 Ubuntu 或 Debian 等發行版上，您可以直接「殺死」LLMNR。 編輯解析器設定 所以：

sudo nano /etc/systemd/resolved.conf

在文件中，設定相應的參數，使其無歧義。 例如：

[Resolve]
LLMNR=no

儲存並重新啟動服務或電腦： 重啟服務通常就足夠了，但如果對您來說更方便的話，重新啟動也是有效的。

sudo systemctl restart systemd-resolved

這樣，systemd-resolved 將停止使用 LLMNR。 如果您使用其他解決方案 （或其他發行版），檢查他們的文件：模式沒有太大差異，並且總是有一個等效的「開關」。

關於 NBT‑NS 和 Windows 防火牆

禁用 LLMNR 是成功的一半。 響應器和類似工具也利用 NetBIOS 名稱服務 (NBT‑NS)，它透過經典的 NetBIOS 連接埠（UDP 137/138 和 TCP 139）工作。這引發了許多人的問題：在防火牆中阻止連接埠是否足夠，還是必須明確停用 NBT-NS？

如果您在本地防火牆（入站和出站）上套用嚴格的規則，阻止 137/UDP、138/UDP 和 139/TCP，則可以大幅減少暴露。 但是，企業環境中的最佳做法是停用 TCP/IP 上的 NetBIOS。 在介面中，如果防火牆策略發生變化或被應用程式修改，則防止不必要的回應或廣告。

在 Windows 中，沒有像 LLMNR 那樣直接的「工廠」 GPO，但您可以透過 WMI 或註冊表來實現。 這個基於 WMI 的 PowerShell 在所有啟用 IP 的適配器上停用它:

Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter "IPEnabled=TRUE" | ForEach-Object { $_.SetTcpipNetbios(2) } 

如果您喜歡防火牆規則，請繼續，但請確保它們是雙向的和持久的。 區塊 137/UDP、138/UDP 和 139/TCP 並監控管理防火牆的其他 GPO 或 EDR/AV 解決方案中是否有衝突的規則。

驗證：如何檢查 LLMNR 和 NBT-NS 是否失效

對於 Windows 上的 LLMNR，請查看註冊表： HKLM\軟體\策略\微軟\Windows NT\DNSClient\EnableMulticast 必須存在且等於 0。 PowerShell 中的快速檢查 將：

(Get-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient").EnableMulticast

在流量層面，一個簡單的技巧是運行搜尋不存在的名稱，並使用 Wireshark 觀察沒有輸出 UDP 5355 封包。 如果你沒有看到多播到本地段，您走在正確的道路上。

在具有 systemd-resolved 的 Linux 上，使用 resolvectl 或 systemctl 檢查狀態： 確保 LLMNR 設定為“否” 在有效配置中且服務重新啟動時沒有出現錯誤。

對於 NBT‑NS，請確認您的防火牆規則封鎖了 137/UDP、138/UDP 和 139/TCP，或在適配器上停用了 NetBIOS。 你也可以嗅一下網絡 檢查廣播中沒有 NetBIOS 請求或廣告。

常見問題和實用細節

• 禁用 LLMNR 會破壞任何東西嗎？ 在 DNS 維護良好的網路中，通常不會出現這種情況。在特殊或傳統環境中，請先在試點小組中進行驗證，然後將變更告知支援人員。
• 為什麼即使 Intune 顯示“強制執行”，gpedit 仍顯示“未配置”？ 因為本機編輯器並不總是反映 MDM 或 CSP 所施加的狀態。真相存在於註冊表和實際結果中，而不是 gpedit 文本中。
• 如果我在防火牆上封鎖 NetBIOS，是否必須停用 NBT‑NS？ 如果阻斷措施全面且穩健，風險就會大大降低。不過，停用 TCP/IP 上的 NetBIOS 可以消除堆疊層級回應，並避免規則變更時發生意外情況，因此這是更佳的選擇。
• 是否有任何現成的腳本可以停用 LLMNR？ 是的，如您所見，透過登錄或 PowerShell 即可。對於 Intune，請將腳本打包為“修復”並添加合規性檢查。

關閉 LLMNR 可減少本地網路上的欺騙面，並可儘早阻止使用 Responder 等工具進行的雜湊抓取攻擊。 如果您也封鎖或停用 NBT‑NS 並注意您的 DNS您將擁有一個簡單而有效的安全組合：更少的噪音、更低的風險以及更適合日常使用的網路。