DNS over HTTPS (DoH): 对公共 WiFi 过滤的影响

欢迎收听 Purple 技术简报。我是今天会议的主持人，在接下来的十分钟里，我们将讨论一个正在悄悄破坏数千个公共 WiFi 部署内容过滤策略的话题——DNS over HTTPS，简称 DoH。 如果您在酒店、零售物业、体育场馆或公共部门设施运行访客 WiFi，并且没有在网络架构中专门处理 DoH，那么您的过滤策略很可能存在重大漏洞。让我们详细分析这个漏洞是什么、为什么重要以及可以采取什么措施。 第一部分——背景和问题陈述。 首先快速回顾传统 DNS 过滤的工作原理，因为理解绕过机制需要理解被绕过的是什么。 当访客设备连接到您的 WiFi 并尝试访问网站时，它做的第一件事就是发送 DNS 查询——本质上是询问该域名的 IP 地址是什么？该查询通过 UDP 或 TCP 在端口 53 上传输。您的网络基础设施拦截该查询，将其路由到您选择的 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 会在检测到配置的解析器支持 DoH 时自动将 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 层无线安全问题。它们是针对不同威胁向量的互补控制。 第六部分——ROI 和业务影响。 让我以正确解决此问题的业务案例作为结束。 不解决 DoH 的成本是不对称的。一起单一事件——访客在您的网络上访问非法内容，由于 DNS 监控存在盲点而未检测到的恶意软件回拨，对内容过滤合规性的监管查询——可能比适当缓解的投资成本高出许多。 对于在 20 个物业运营的酒店集团，部署 DoH 缓解通常需要一次性的配置工作，每个物业需要两到四个小时进行防火墙规则和 DNS 拦截配置，加上维护解析器阻止列表的持续运营开销——如果您使用托管 DNS 过滤服务，这在很大程度上是自动化的。总投资相对于风险降低来说是适度的。 对于根据 PCI DSS 运营的零售连锁店，合规收益是直接可量化的。证明您的网络安全控制包括 DoH 缓解，会降低 PCI DSS 审计发现及相关补救成本的风险。 对于公共部门场馆和根据《在线安全法》运营的场馆，文档化的 DoH 缓解是您证据库的一部分，证明您已采取合理的技术步骤来执行内容过滤政策。 底线：DoH 不是未来的问题。它是当前的问题。Firefox、Chrome、Android 和 iOS 都正在向您的访客设备提供支持 DoH 的配置。如果您在过去 12 个月内没有审计过 DNS 过滤架构中的 DoH 绕过向量，那么该审计应列入您的近期路线图。 总结今天简报的关键要点。 第一：DoH 将 DNS 查询加密在端口 443 的 HTTPS 中，使其对传统的端口 53 DNS 过滤不可见。这正在主流浏览器和操作系统上默认发生。 第二：三层缓解策略——阻止已知 DoH 解析器 IP，在下一代防火墙上实施 TLS 检查，并强制端口 53 拦截——为受管理和不受管理的访客设备提供纵深防御覆盖。 第三：这是一个合规性问题，而不仅仅是技术问题。GDPR、《在线安全法》和 PCI DSS 都对 DoH 悄悄绕过内容过滤政策的场馆产生影响。 第四：最常见的实施失败是端口 53 拦截不完整。测试它。验证它。不要假设它在工作。 第五：托管 DNS 过滤服务——Cloudflare Gateway、Cisco Umbrella 等——越来越多地将 DoH 绕过检测作为托管功能，这减少了维护静态阻止列表的运营开销。 今天的 Purple 技术简报到此结束。如果您希望审计当前的 DNS 过滤架构或在您的场馆资产中实施 DoH 缓解，Purple 平台提供网络智能和访客 WiFi 管理层来支持该部署。感谢收听，我们下期再见。