DNS Over HTTPS (DoH)：對公共 WiFi 過濾的影響

歡迎來到 Purple 技術簡報。我是今天會議的主持人，我們將在接下來的十分鐘內探討一個目前正悄悄削弱數千個公共 WiFi 部署中內容過濾策略的主題 - DNS over HTTPS（簡稱 DoH）。 如果您在飯店、零售物業、體育場或公共部門設施中運營訪客 WiFi，且未在網路架構中專門解決 DoH 問題，那麼您的過濾策略很有可能存在重大漏洞。讓我們仔細分析一下這個漏洞究竟是什麼、它為什麼重要，以及您可以採取哪些應對措施。 第一部分 - 背景與問題陳述。 讓我們首先快速回顧一下傳統 DNS 過濾的工作原理，因為要了解繞過機制，必須先了解被繞過的是什麼。 當訪客裝置連接到您的 WiFi 並嘗試造訪網站時，它做的第一件事就是發送 DNS 查詢 - 基本上是詢問此網域的 IP 位址是什麼？該查詢透過連接埠 53 上的 UDP 或 TCP 傳輸。您的網路基礎設施會攔截該查詢，將其路由到您選擇的 DNS 解析器，然後該解析器會根據您的過濾策略檢查該網域。如果該網域在阻止清單中（惡意軟體、成人內容、賭博，或任何您的可接受使用策略規定的內容），解析器就會拒絕傳回 IP 位址，連線也就不會發生。 這是所有基於 DNS 的內容過濾部署的基礎。它具備成本效益、不會影響吞吐量，並且在過去近十年間一直是場域營運商的標準方法。 而 DNS over HTTPS 打破了這種模式。運作方式如下。 DoH 將 DNS 查詢封裝在連接埠 443 上的標準 HTTPS 流量中。從您的網路角度來看，它與任何其他加密的網頁流量完全相同。您無法將 DoH 查詢與使用者載入網頁、串流影片或存取網路銀行應用程式區分開來。查詢會透過您 DNS 過濾器無法檢查的加密通道，直接發送到外部 DoH 解析器（例如 Google 的 8.8.8.8、Cloudflare 的 1.1.1.1 或其他許多解析器）。 結果呢？您精心設定的 DNS 過濾策略被完全繞過了。該裝置直接解析網域，而您的解析器甚至從未看到該查詢。 現在，這並不是您的訪客故意發起的攻擊。在大多數情況下，這完全是被動的。Firefox 自 2020 年起就預設啟用了 DoH。如果設定的解析器支援，Chrome 會自動將 DNS 查詢升級為 DoH。Android 9 及以上版本預設支援使用 DNS over TLS 的私密 DNS。iOS 自 iOS 14 起就支援 DoH 設定檔。這些是主流的消費性裝置正在執行其製造商預期的功能。您的訪客並非試圖繞過您的過濾，他們的裝置只是在自動執行此操作。 第二部分 - 技術深入探討。 讓我們進入機制層面。您在實際環境中會遇到兩種主要的 DoH 實施模式。 第一種是應用程式層級的 DoH，其中應用程式 - 通常是瀏覽器 - 會獨立於作業系統的 DNS 設定，自行維護其 DoH 設定。Firefox 就是一個典型範例。當安裝 Firefox 且啟用 DoH 時，它會完全忽略系統 DNS 解析器，並將其所有 DNS 查詢傳送到其設定的 DoH 供應商（預設為 Cloudflare）。您透過 DHCP 分配的 DNS 伺服器將失去作用，您的 port 53 攔截規則也失去作用。Firefox 正在透過您無法看見的 port 443 進行完全獨立的 DNS 對話。 第二種模式是作業系統層級的 DoH，由作業系統本身處理升級。Chrome 以及 Windows 10 和 11 採用這種方法。它們會檢查系統設定的 DNS 解析器（即您的 DHCP 伺服器分配的解析器）是否具有對應的 DoH 端點。如果有，它們會自動升級到 DoH。這稱為機會性 DoH。如果您將 8.8.8.8 分配為您的訪客 DNS 伺服器，Chrome 將自動使用 Google 的 DoH 端點。如果您分配 1.1.1.1，它將使用 Cloudflare 的 DoH 端點。 這種區別對您的防護策略至關重要，我們稍後會詳細說明。 還有第三種值得提及的途徑：DNS over TLS，或稱 DoT。這在 port 853 上運作，並使用 TLS 加密 DNS 查詢，而不是將其封裝在 HTTPS 中。因為它使用專用 port，所以比 DoH 更容易阻擋，但在啟用了 Private DNS 的 Android 裝置上，這種方式正變得越來越普遍。您的防護策略需要同時解決這兩者。 現在，讓我們來談談為什麼這是一個合規性與營運風險，而不僅僅是技術上的好奇心。 在 GDPR 規範下，如果您的可接受使用政策聲明您會過濾特定類別的內容，而您的技術控制措施實際上並未執行該政策，那麼您在聲明的資料保護與內容治理承諾與實際技術實現之間就存在落差。如果您面臨監管審查或安全事件，這將成為一個難以辯護的問題。 根據英國的《線上安全法》（Online Safety Act），提供公共網際網路存取服務的場所營運商有義務保護使用者 - 特別是未成年人 - 免受有害內容的侵害。如果 DoH 在背景悄悄繞過您的內容過濾，您可能無法履行這些義務。 對於屬於 PCI-DSS 範圍內的場所 - 特別是付款卡資料在與訪客 WiFi 相鄰的網路中傳輸的場所 - PCI-DSS 4.0 版本要求您監視並控制 DNS 流量，以此作為網路安全控制措施的一部分。未經監視的 DoH 流量是該控制框架中的一個漏洞。 而從純粹的安全角度來看，DoH 已被惡意軟體主動利用。威脅入侵者已將 DoH 用作命令與控制通道，因為它會融入正常的 HTTPS 流量中。GodLua 後門曾使用 DoH 進行命令與控制通訊。PsiXBot 惡意軟體曾使用 Google 的 DoH 服務。如果您的安全監控依賴 DNS 可見性來偵測惡意活動，那麼 DoH 盲點就是一個實實在在的威脅。 第 3 節 - 導入建議。 好，讓我們切入實際面。主要有三種防護策略，而在大多數的場域部署中，您會希望結合這三種策略一起使用。 策略一：在防火牆端封鎖已知的 DoH 解析器端點。 這是您的第一道防線，也是最能立即部署的選項。維護一份已知 DoH 解析器 IP 地址與網域的封鎖清單（包括 Google、Cloudflare、Quad9、NextDNS、AdGuard 等），並拒絕從您的訪客 VLAN 發送到這些端點的輸出 HTTPS 流量。IETF 和各家安全廠商都有發布並維護這些清單。GitHub 上的 curl 專案也維護了一份詳盡的已知 DoH 解析器清單，是一個很好的起步點。 這個方法可以處理大部分的 DoH 流量，因為卡內基美隆大學軟體工程研究所的研究指出，大多數 DoH 流量都流向少數幾個眾所周知的解析器。對 DNS 足夠了解並會去設定自訂 DoH 解析器的使用者僅佔極少數。 此方法的限制在於它是一份封鎖清單，而封鎖清單需要維護。新的 DoH 解析器會定期出現。但結合其他策略，它能提供堅實的防護網。 策略二：在您的下一代防火牆上進行 TLS 檢測。 來自 Palo Alto Networks、Fortinet、Check Point 和 Cisco Firepower 等廠商的下一代防火牆都支援 TLS 檢測（也稱為 SSL 檢測或深層封包檢測）。啟用時，防火牆會充當 HTTPS 流量的中間人，對其進行解密、檢測承載內容，並在轉發前重新加密。這能讓防火牆在 DoH 流量即使流向未知解析器時，也能將其識別出來。 Palo Alto 的 App-ID 可以專門識別 DoH 流量並對其套用原則。Fortinet 的 FortiGate 也有類似的功能。關鍵的設定步驟是確保您的訪客 VLAN 流量有被路由通過該檢測原則。 這裡在營運上需要考量的是憑證信任。為了讓 TLS 檢測在訪客裝置上運作，這些裝置必須信任您的檢測憑證。在受管的企業裝置上，這很簡單，您只需透過 MDM 推送憑證即可。但在不受管的訪客裝置上，這就比較複雜了。對於訪客 WiFi 的實際做法是，利用 Captive Portal 的同意流程來告知使用者，為了內容過濾的目的可能會對流量進行檢測，並依賴 DoH 解析器封鎖與 DNS 攔截的組合動作作為主要控制措施，並將 TLS 檢測作為高風險環境的輔助防線。 策略三：強制進行 DNS 攔截與重新導向。 設定您的防火牆或無線控制器來攔截所有在 UDP 和 TCP 連接埠 53 上的輸出 DNS 流量，並將其重新導向到您合規的 DNS 解析器。這並不能阻止 DoH，但它能確保任何因 DoH 失敗或不可用而退回到連接埠 53 的 DNS 流量，都能被捕獲並過濾。 將此與阻止來自訪客 VLAN 的出站連接埠 853 結合使用，以防止 DNS over TLS 繞過您的控制。 對於託管端點（企業設備、員工設備），您有一個額外的選擇：透過群組原則或 MDM 設定在瀏覽器和 OS 層級停用 DoH。在 Firefox 中，將 network.trr.mode 偏好設定設為 5 可完全停用 DoH。在 Chrome 中，將 disable-features 設為 DnsOverHttps 旗標可達到相同效果。Windows 10 和 11 具有控制 DoH 行為的群組原則設定。這是託管設備最可靠的控制方式，但不適用於非託管的訪客設備。 第四部分 - 實作陷阱。 一些在實際應用中常見的錯誤。 最常見的故障模式是不完整的連接埠 53 攔截。團隊正確設定了其 DNS 過濾服務，但忘記新增重新導向所有出站連接埠 53 流量的防火牆規則。具有硬編碼 DNS 設定（8.8.8.8、1.1.1.1）的設備會完全繞過過濾器。請務必確認此規則已啟用，並透過為測試設備設定硬編碼 DNS 伺服器並確認過濾的網域仍被阻止來進行測試。 第二個常見錯誤是未考慮 IPv6。透過 IPv6 進行的 DNS 查詢越來越普遍，且許多防火牆規則僅針對 IPv4 編寫。請確保您的連接埠 53 攔截和 DoH 解析器封鎖清單同時涵蓋 IPv4 和 IPv6 位址。 第三：過時的 DoH 解析器封鎖清單。如果您維護的是靜態 DoH 解析器 IP 封鎖清單，它將會過期。請自動化更新程序，或使用為您維護此清單的 DNS 過濾服務。Cloudflare Gateway、Cisco Umbrella 及類似的企業級 DNS 服務均將 DoH 繞過偵測作為一項託管功能。 第四：過度依賴單一防禦層。DoH 緩解是一個深度防禦問題。單一控制措施是不夠的。封鎖已知的解析器可以處理大多數情況。TLS 檢測可以處理邊緣情況。DNS 攔截提供了一個安全網。應將這三者分層結合。 第五部分 - 快速問答。 DoH 緩解會破壞合法的隱私工具嗎？有可能，是的。如果使用者執行的是合法的隱私導向瀏覽器設定，您的 DoH 封鎖將迫使他們使用您的 DNS 解析器。您的可接受使用政策應明確指出，該場所的 DNS 解析器用於內容過濾目的。這是標準做法且在法律上是站得住腳的。 DoH 是否可用於從我的網路外洩數據？是的，這是一個真實的威脅媒介。透過 DoH 的 DNS 隧道已在實際環境中被證實。您新一代防火牆的 DoH 偵測功能應包括針對異常高查詢量或符合隧道特徵的查詢模式的異常偵測。 那使用 DoH 的行動應用程式呢？這是最棘手的情況。自行實作 DoH 堆疊（而非使用作業系統 DNS 設定）的行動應用程式在沒有 TLS 檢測的情況下很難控制。您最佳的緩解措施是結合已知解析器阻擋與 TLS 檢測。 WPA3 在這裡有用嗎？WPA3 改善了空中加密並提供前向安全性，這對顧客隱私非常有用。但 WPA3 並不處理 DoH - 那是第 7 層應用程式協定問題，而非第 2 層無線安全問題。它們是針對不同威脅向量的互補控制措施。 第六部分 - ROI 與業務影響。 讓我以妥善處理此問題的商業案例來結束今天的內容。 不處理 DoH 的代價是不對稱的。單一事件 - 例如顧客在您的網路上存取非法內容、因您的 DNS 監控有盲點而導致惡意軟體回呼未被偵測、或是關於您的內容過濾法規遵循的監管查詢 - 其成本可能遠高於在適當緩解措施上的投資。 對於在 20 個據點營運的飯店集團而言，部署 DoH 緩解措施通常涉及每個據點兩到四個小時的一次性防火牆規則與 DNS 攔截設定工作，再加上維護解析器阻擋清單的持續營運開銷 - 如果您使用的是託管 DNS 過濾服務，這大部分是自動化的。相對於風險的降低，總投資是微不足道的。 對於在 PCI-DSS 規範下營運的零售連鎖店，其合規效益是直接可量化的。證明您的網路安全控制措施包含 DoH 緩解，可降低 PCI-DSS 稽核發現缺失的風險以及相關的補救成本。 對於公共部門場域以及在《線上安全法案》（Online Safety Act）規範下營運的機構，記錄在案的 DoH 緩解措施是您已採取合理技術步驟來執行內容過濾政策的證據基礎的一部分。 底線：DoH 不是未來的問題，而是眼前的問題。Firefox、Chrome、Android 和 iOS 目前都已向您顧客的裝置提供具備 DoH 功能的設定。如果您在過去 12 個月內尚未針對 DoH 規避向量稽核您的 DNS 過濾架構，那麼該稽核應列入您的近期規劃中。 總結今天簡報的關鍵重點。 第一：DoH 將連接埠 443 上 HTTPS 內的 DNS 查詢進行加密，使傳統連接埠 53 DNS 過濾對其無法察覺。這在主流瀏覽器和作業系統上已預設啟用。 第二：三層緩解策略 - 阻擋已知的 DoH 解析器 IP、在您的新世代防火牆上實作 TLS 檢測，以及強制執行連接埠 53 攔截 - 為受管和未受管的顧客裝置提供了縱深防禦覆蓋。 第三：這是一個合規性問題，而不僅僅是技術問題。GDPR、線上安全法案和 PCI-DSS 對於 DoH 正在默默規避內容過濾政策的場域皆有影響。 四：最常見的建置失敗是連接埠 53 攔截不完整。請進行測試，驗證它，不要假設它正常運作。 五：託管式 DNS 過濾服務（例如 Cloudflare Gateway、Cisco Umbrella 等）已越來越多將 DoH 規避偵測納入為託管功能，這減少了維護靜態阻擋清單的維運開銷。 今天的 Purple 技術簡報到此結束。如果您正在尋求稽核現有的 DNS 過濾架構，或是在您的場域物業中實施 DoH 緩解措施，Purple 平台可提供支援該部署的網路智慧與顧客 WiFi 管理層。感謝您的收聽，我們下期再見。