DNS Over HTTPS (DoH)：对公共 WiFi 过滤的影响

欢迎来到 Purple 技术简报。我是今天会议的主持人。接下来我们将花十分钟讨论一个目前正在悄然破坏数千个公共 WiFi 部署内容过滤策略的问题 - 基于 HTTPS 的 DNS（即 DoH）。 如果您在酒店、零售物业、体育场馆或公共部门场所运行访客 WiFi，并且在您的网络架构中没有专门针对 DoH 进行处理，那么您的过滤策略极有可能存在重大漏洞。让我们来探讨一下这个漏洞到底是什么，它为什么重要，以及您可以采取什么措施。 第一部分 - 背景与问题陈述。 让我们先快速回顾一下传统 DNS 过滤的工作原理，因为了解绕过机制需要先了解被绕过的是什么。 当访客设备连接到您的 WiFi 并尝试访问某个网站时，它做的第一件事就是发送 DNS 查询 - 简单来说就是询问这个域名的 IP 地址是什么？该查询通过端口 53 上的 UDP 或 TCP 进行传输。您的网络基础设施会拦截该查询，将其路由到您选择的 DNS 解析器，该解析器会根据您的过滤策略检查该域名。如果该域名在黑名单上 - 无论是恶意软件、成人内容、赌博，还是您的可接受使用策略规定的任何内容 - 解析器都会拒绝返回 IP 地址，连接也就无法建立。 这是所有基于 DNS 的内容过滤部署的基础。它具有成本效益，不影响吞吐量，并且在过去近十年的时间里一直是场馆运营商的标准方法。 基于 HTTPS 的 DNS（DoH）打破了这一模式。原理如下。 DoH 将 DNS 查询封装在端口 443 上的标准 HTTPS 流量中。从您的网络角度来看，它与任何其他加密的网络流量完全相同。无法将 DoH 查询与用户加载网页、流式传输视频或访问银行应用程序区分开来。查询通过您的 DNS 过滤器无法检测的加密通道直接发送到外部 DoH 解析器 - 谷歌的 8.8.8.8、Cloudflare 的 1.1.1.1 或任何其他解析器。 结果如何？您精心配置的 DNS 过滤策略被完全绕过。设备直接解析域名，而您的解析器根本看不到该查询。 现在，这并不是您访客的故意攻击。在大多数情况下，这完全是被动的。自 2020 年以来，Firefox 已默认启用 DoH。如果配置的解析器支持，Chrome 会自动将 DNS 查询升级为 DoH。Android 9 及以上版本默认支持带有 DNS over TLS 的私有 DNS。自 iOS 14 以来，iOS 已支持 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，但可以确保由于 DoH 失败或不可用而回退到 53 端口的任何 DNS 流量都能够被捕获并过滤。 将此与阻止来自宾客 VLAN 的出站端口 853 相结合，以防止 DNS over TLS 绕过您的控制。 对于托管端点（企业设备、员工设备），您有一个额外的选择：通过组策略或 MDM 配置在浏览器和系统层级禁用 DoH。在 Firefox 中，将 network.trr.mode 首选项设置为 5 将完全禁用 DoH。在 Chrome 中，使用 disable-features equals 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 审计不合规的风险以及相关的整改成本。 对于公共场所场所以及在《在线安全法案》下运营的场所，记录在案的 DoH 缓解措施是您证明自己已采取合理技术步骤来执行内容过滤政策的证据链的一部分。 底线是：DoH 不是未来的问题。它是眼前的现实。Firefox、Chrome、Android 和 iOS 目前都正在向您访客的设备推送具备 DoH 功能的配置。如果您在过去 12 个月内没有针对 DoH 规避载体审计过您的 DNS 过滤架构，那么该审计应该列入您的近期规划路线图中。 总结一下今天简报的关键要点。 第一点：DoH 将 DNS 查询加密在端口 443 的 HTTPS 中，使其对传统的端口 53 DNS 过滤不可见。这在主流浏览器和操作系统上正在默认发生。 第二点：三层缓解策略 - 阻断已知的 DoH 解析服务器 IP、在您的下一代防火墙上实施 TLS 检测、以及执行端口 53 拦截 - 为托管和非托管的访客设备提供了深度防御覆盖。 第三点：这是一个合规性问题，而不仅仅是技术问题。GDPR、《在线安全法案》和 PCI-DSS 都对那些 DoH 正在默默规避内容过滤政策的场所产生影响。 第四：最常见的部署失败原因是 Port 53 拦截不彻底。请进行测试。进行验证。不要想当然地认为它在正常运行。 第五：托管式 DNS 过滤服务（如 Cloudflare Gateway、Cisco Umbrella 及类似服务）越来越多地将 DoH 绕过检测作为一项托管功能包含在内，这减少了维护静态阻止列表的运维开销。 以上就是今天 Purple 技术简报的全部内容。如果您正在寻求审计您当前的 DNS 过滤架构，或在您的场所资产中部署 DoH 缓解措施，Purple 平台可提供网络智能和客用 WiFi 管理层来支持该部署。感谢您的收听，我们下期再见。