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 查詢與使用者載入網頁、串流影片或存取銀行應用程式。查詢會直接傳送到外部的 DoH 解析器——Google 的 8.8.8.8、Cloudflare 的 1.1.1.1 或其他任何解析器——透過您的 DNS 過濾器無法檢查的加密通道。 結果呢？您精心設定的 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 伺服器無關緊要。您的連接埠 53 攔截規則無關緊要。Firefox 在連接埠 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。它在連接埠 853 上運作，使用 TLS 加密 DNS 查詢，而不是將它們包裝在 HTTPS 中。它比 DoH 更容易封鎖，因為它使用專用連接埠，但在啟用私人 DNS 的 Android 裝置上越來越常見。您的緩解策略需要同時解決這兩者。 現在讓我們談談為什麼這不僅僅是一個技術好奇心，而是一個合規性和營運風險。 根據 GDPR，如果您的可接受使用政策聲明您過濾某些類別的內容，而您的技術控制實際上並未強制執行該政策，那麼您聲明的資料保護和內容治理承諾與實際技術實施之間存在差距。如果您面臨監管調查或事件，這就是一個可辯護性問題。 根據英國的《線上安全法》，提供公共網路存取的場館營運商有義務保護使用者（尤其是未成年人）免受有害內容的侵害。如果 DoH 悄悄地繞過了您的內容過濾，您可能無法履行這些義務。 對於屬於 PCI DSS 範圍的場館（特別是那些支付卡資料流經與訪客 WiFi 相鄰網路的場館），PCI DSS 4.0 版要求您監控和控制 DNS 流量，作為網路安全控制的一部分。未受監控的 DoH 流量是該控制框架中的一個漏洞。 從純粹的安全角度來看，DoH 已被惡意軟體積極利用。威脅行為者將 DoH 用作命令與控制通道，因為它融入正常的 HTTPS 流量中。GodLua 後門使用 DoH 進行命令與控制通訊。PsiXBot 惡意軟體使用了 Google 的 DoH 服務。如果您的安全監控依賴於 DNS 可視性來偵測惡意活動，DoH 盲點是一個真正的威脅。 第三部分——實施建議。 好的，讓我們務實一點。有三種主要的緩解策略，在大多數場館部署中，您會希望結合實施這三種策略。 策略一：在防火牆封鎖已知的 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，但它確保任何回到連接埠 53 的 DNS 流量（因為 DoH 失敗或不可用）都會被捕獲和過濾。 結合從訪客 VLAN 封鎖傳出連接埠 853，以防止 DNS over TLS 繞過您的控制。 對於受管理的端點——企業裝置、員工裝置——您有一個額外的選項：群組原則或 MDM 設定，在瀏覽器和作業系統層級停用 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 層無線安全問題。它們是解決不同威脅向量的互補控制。 第六部分——投資報酬率與業務影響。 最後，讓我以適當處理此問題的商業案例作結。 不處理 DoH 的成本是不對稱的。單一事件——訪客在您的網路上存取非法內容、惡意軟體回呼因您的 DNS 監控存在盲點而未被偵測到、關於您的內容過濾合規性的監管調查——所產生的成本可能遠超過在適當緩解措施上的投資。 對於在 20 個物業營運的飯店集團，部署 DoH 緩解通常需要每個物業防火牆規則和 DNS 攔截設定的一次性設定工作，約兩到四個小時，加上維護解析器封鎖清單的持續營運開銷——如果您使用受管理的 DNS 過濾服務，這在很大程度上是自動化的。相對於降低的風險，總投資是適度的。 對於依據 PCI DSS 營運的零售連鎖店，合規效益是可直接量化的。證明您的網路安全控制包括 DoH 緩解，可降低 PCI DSS 稽核發現問題的風險以及相關的補救成本。 對於公共部門場館和依據《線上安全法》營運的場館，記錄的 DoH 緩解是您證據基礎的一部分，證明您已採取合理的技術步驟來執行內容過濾政策。 底線：DoH 不是未來的問題。它是當前的問題。Firefox、Chrome、Android 和 iOS 都在向您的訪客裝置推送支援 DoH 的設定。如果您在過去 12 個月內尚未稽核您的 DNS 過濾架構是否存在 DoH 繞過向量，那麼該稽核應列入您的近期路線圖。 總結今天簡報的關鍵要點。 一：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 管理層，以支援該部署。感謝收聽，我們下期再見。