跳至主要内容

最佳 DNS filtering:面向企业用户的全面指南

本技术参考指南阐述了企业级 DNS filtering 如何通过在解析层(即在建立连接之前)拦截恶意域名来保障公共网络的安全。它为 IT 总监、网络架构师和场所运营团队提供了在酒店、零售和公共部门环境中保护宾客 WiFi 所需的部署架构、防火墙配置以及合规性背景信息。Purple Shield 在 DNS 级别为超过 80,000 个实时场所拦截恶意软件、僵尸网络和不当内容。

📖 8 分钟阅读📝 1,807 🔧 2 应用实例4 练习题📚 9 关键定义

收听本指南

查看播客转录
欢迎阅读 Purple 技术简报。今天我们来探讨企业网络安全的一个关键组成部分:DNS 过滤。 如果您是管理酒店、零售或大型场馆公共网络的 IT 总监或网络架构师,您就会知道提供 WiFi 是一项基本公用设施。就像电力或暖通空调(HVAC)一样,它是访客进入大楼那一刻就期望能够正常工作的服务。但从安全角度来看,这种公用设施创造了一个庞大且不受管理的攻击面。 当您提供开放的网络接入时,就等于邀请了未受管理的设备进入您的基础设施。您无法在访客的个人设备上安装终端防护。传统的安全边界已力不从心。这就是为什么 DNS 过滤已成为现代安全堆栈中最关键的层级。它将防御推向了数字化连接的第一步。 让我们开始技术深挖。DNS 过滤到底是如何工作的? 域名系统(Domain Name System,简称 DNS)是互联网的电话簿。当访客连接到您的 WiFi 并在此浏览器中输入网站地址时,其设备必须将该人类可读的域名转换为机器可读的 IP 地址。在标准设置中,此查询会发送到默认的解析器,通常由 ISP 提供。 在采用 DNS 过滤的安全架构中,DHCP 服务器会为访客设备分配一个特定的、安全的 DNS 解析器。当查询到达该过滤引擎时,它不仅会解析 IP 地址,还会根据实时威胁情报源和您特定的公司策略评估该域名。 如果该域名是无害的,则会返回 IP,连接继续。这在几毫秒内即可完成。但是,如果该域名被标记为恶意域名(例如已知的钓鱼网站或僵尸网络命令与控制服务器),或者违反了您的内容策略,引擎就会进行干预。它要么返回一个不可路由的 IP 地址(一种称为“落坑”的技术),要么将用户重定向到一个带有品牌标识的拦截页面。 为什么这种方法优于深度包检测(Deep Packet Inspection)或代理过滤等替代方案?这归结为性能和规模。 深度包检测要求网络硬件检查每个数据包的有效载荷。在体育场等拥有 50,000 个并发用户的密集环境中,DPI 会引入巨大的延迟,并且需要极其昂贵的硬件。相比之下,DNS 过滤运行在连接生命周期的最开始阶段。它评估的是轻量级的 UDP 数据包。一旦 DNS 解析完成,实际的数据传输就会直接在客户端和安全服务器之间进行。过滤引擎不需要处理繁重的数据载荷。这实现了几乎为零的延迟影响,通常小于两毫秒。此外,由于 DNS 过滤在连接建立之前运行,因此它完全独立于协议。无论应用程序是尝试使用 HTTP、HTTPS、FTP 还是自定义端口,它都会阻止连接。 现在让我们来看一个实际的例子。以一家拥有 500 间客房的豪华连锁酒店为例。由于非法流媒体播放,他们正面临着高带宽占用的问题,并且收到了关于在公共区域可以访问不当内容的投诉。他们的物业管理系统通过 VLAN 共享相同的物理基础设施。 正确的做法是部署基于云的 DNS 过滤解决方案,并专门为 Guest WiFi VLAN 配置 DHCP 作用域,以分配云 DNS IP。关键在于,您需要在网关上实施防火墙规则,以阻止从 Guest VLAN 发往除经批准的 DNS 服务器之外的任何外部 IP 的出站 UDP 和 TCP 端口 53 流量。然后,您创建一个阻止成人内容、盗版和恶意软件类别的策略。关键的架构决策是确保物业管理系统 VLAN 继续使用内部 DNS 服务器,从而将过滤策略完全隔离在访客网络中。 现在让我们来谈谈实施中的陷阱。 基础步骤是网络配置。您必须配置网关或 DHCP 服务器,以便向 Guest VLAN 上的所有客户端分发 DNS 过滤服务的 IP 地址。 但这里有一个关键的经验法则:阻止端口 53,否则形同虚设。 如果您只是通过 DHCP 分配 DNS 服务器,精通技术的用户或恶意应用程序可以通过硬编码自己的 DNS 设置(例如 Google 的 8.8.8.8 或 Cloudflare 的 1.1.1.1)来绕过过滤器。为了防止这种规避行为,您必须在网关处实施防火墙规则,阻止发往除您指定的过滤服务器之外的任何 IP 地址的端口 53(包括 UDP 和 TCP)的所有出站流量。 另一个主要陷阱涉及 Captive Portal。我们在零售和酒店部署中经常看到这种情况。某个场所实施了严格的 DNS 过滤,突然之间,访客无法登录了。为什么?因为 Captive Portal 依赖外部域名进行身份验证,例如用于社交登录的 OAuth 提供商。如果您的 DNS 过滤器在用户身份验证之前阻止了这些域名,就会造成恶性循环。用户无法访问互联网进行身份验证,也无法通过身份验证来访问互联网。 解决方案是确保您的 Walled Garden 得到正确配置。您必须在 DNS 过滤策略中明确将 Captive Portal 体验所需的域名列入白名单。 第二个实际应用场景:大型零售购物中心希望提供免费的公共 WiFi,并通过 Captive Portal 获取人口统计数据,同时遵守严格的家庭友好型企业政策。将 DNS 过滤与 Captive Portal 集成时,需要将身份验证域名(例如 Microsoft Entra ID 或 Google Workspace)添加到预身份验证白名单(allowlist)中。只有在用户成功进行身份验证后,才会应用内容过滤策略。这种方法将潜在的技术冲突转化为无缝的访客体验。 现在,让我们进入基于常见场景的快速问答环节。 问题一:我们可以在访客网络上使用透明 HTTPS 检测来代替 DNS 过滤吗? 不能。透明 HTTPS 检测需要向终端设备部署自定义根证书以解密流量。您无法向非托管的访客设备部署证书,这会破坏他们的浏览体验并弹出严重的安全警告。对于自带设备(BYOD)环境,DNS 过滤才是正确的方法。 问题二:DNS 过滤如何处理 DNS over HTTPS(即 DoH)? DoH 会加密 DNS 查询,这可以绕过传统的网络层拦截。最佳实践是在防火墙上识别并阻止已知 DoH 提供商的 IP 地址,从而强制客户端回退到标准的可过滤 DNS。 问题三:DNS 过滤有助于合规吗? 当然。对于 PCI-DSS 等框架,证明网络隔离和强大的访问控制是强制性的。虽然访客网络应始终与支付网络隔离,但防止恶意软件在访客网络上执行可以降低场所的整体风险。就 GDPR 而言,证明您已采取合理的技术措施来防止滥用网络是符合合规性的积极指标。 总结一下今天的简报。DNS 过滤不仅是安全最佳实践。它是企业公共网络的运营必需品。它提供了一种可扩展、低延迟的机制来阻止恶意威胁并执行可接受的使用策略。 关键要点如下。第一,DNS 过滤在建立连接之前拦截域名查询,增加的延迟不足两毫秒。第二,始终在防火墙上阻止出站 53 端口,以防止通过自定义 DNS 设置进行规避。第三,仔细配置您的 Walled Garden,以确保 Captive Portal 身份验证域名不被阻止。第四,使用 VLAN 隔离专门将过滤策略应用于访客流量,从而保护运营系统。第五,DNS 过滤通过展示强大的网络访问控制,支持符合 PCI-DSS 和 GDPR 的规范。 您的下一步行动:审计当前的访客网络 DNS 配置,验证出站 53 端口是否受到限制,并根据您启用的 DNS 过滤策略审查您的 Captive Portal Walled Garden。 感谢收听本次 Purple 技术简报。如需了解更详细的部署指南和架构模式,请访问 purple dot ai。

header_image.png

执行摘要

对于管理大规模公共网络的 IT 领导者而言,保障浏览环境的安全是一项运营指令,而非可有可无的选项。在酒店、零售和公共场所中, Guest WiFi 本质上是一个不可信的环境。如果缺乏强大的控制措施,它就会成为恶意软件传播、僵尸网络活动以及访问不当内容的媒介,进而损害品牌声誉并带来合规风险。

DNS 过滤是在网络边缘执行内容策略和阻止威胁最有效率的机制。与消耗大量资源的深度包检测 (DPI) 不同,DNS 过滤在交换任何数据负载之前就会拦截域名解析请求。它会根据实时威胁情报评估轻量级的 UDP 数据包,并返回有效的 IP 地址或防护坑洞 (Sinkhole),增加的延迟不足 2 毫秒。这使其成为为成千上万台并发未管理设备提供服务的高密度环境下,唯一可行且实用的内容控制方法。

本指南涵盖了在分布式企业场所部署 DNS 过滤所需的技术架构,包括 VLAN 隔离、53 端口强制执行、Captive Portal 集成以及防止 DNS over HTTPS (DoH) 规避。它还涉及与 PCI-DSS 和 GDPR 的合规性,并阐述了 Purple Shield 如何在不更换硬件的情况下,集成到 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme Networks 和 Fortinet 的现有硬件堆栈中。


技术深度剖析:DNS 过滤如何运行

域名系统 (DNS) 将人类可读的域名转换为机器可读的 IP 地址。每一次互联网连接都始于 DNS 解析请求。在标准网络中,设备会查询由 ISP 分配的默认解析器。在安全架构中,DHCP 服务器会将执行策略的 DNS 解析器分配给访客 VLAN 上的设备。

当设备查询此安全解析器时,过滤引擎会同时针对多个数据源评估该域名:实时威胁情报数据、类别黑名单(成人内容、赌博、盗版)以及僵尸网络命令与控制域名注册库。这一决策在毫秒内即可完成。

如果域名安全,引擎会返回正确的 IP 地址,连接正常进行。如果该域名被标记为恶意域名或违反了您的合理使用策略,引擎要么返回一个不可路由的 IP 地址(防护坑洞),要么将用户重定向到一个定制品牌的拦截页面。关键点在于:这种干预发生在设备与目标服务器之间进行任何数据负载交换之前。

dns_architecture_overview.png

性能与规模优势

在大密度公共环境中,DNS 过滤在架构上优于 DPI。DPI 需要网络硬件来检查每个数据包的负载。在一个拥有 50,000 个并发用户的场所(如体育场、会议中心或大型零售物业),DPI 会引入显著的延迟,并且在每个检查点都需要昂贵的专用硬件。

DNS 过滤在连接生命周期的开始阶段运行。它仅评估单个轻量级 UDP 数据包。解析完成后,数据直接在客户端和目标服务器之间传输。过滤引擎从不处理数据负载。无论并发用户数多少,延迟影响始终保持在 2 毫秒以下。

由于 DNS 过滤在连接建立之前运行,因此它与协议无关。无论应用程序使用的是 HTTP、HTTPS、FTP 还是自定义端口,它都能阻止连接。这相比基于 URL 的过滤具有显著优势,因为后者仅检查 HTTP/HTTPS 流量。

deployment_comparison_chart.png

提前 10 天的威胁检测优势

传统的 DNS 安全依赖于被动黑名单:一个域名被识别为恶意域名,报告给中央机构,添加到数据库中,并最终分发到您的过滤器 - 这一过程可能需要数天时间。现代恶意软件活动正是利用了这一滞后性。攻击者注册新域名,在 24 小时窗口内执行活动,并在该域名进入任何标准阻止列表之前将其放弃。

Purple Shield 使用 AI 驱动的威胁检测来实时分析域名注册模式、IP 声誉和加密签名。这种方法识别和阻止新兴零日威胁的速度比传统的被动提供商快多达 10 天(Purple 内部数据,2026 年)。在访客设备上的单个恶意链接就可能导致勒索软件的环境中,这一检测窗口在运营上具有重大意义。


实施指南:架构与部署

正确部署 DNS 过滤需要在三个层面上进行精确的网络配置:DHCP、防火墙和 Captive Portal。

步骤 1:VLAN 细分

对网络进行细分,使访客流量与业务系统隔离。将访客设备置于专用 VLAN(例如 VLAN 20)中,并将 POS 终端、物业管理系统和员工设备置于具有内部 DNS 解析器的独立 VLAN 中。这可确保您的 DNS 过滤策略仅应用于不可信的访客流量,而不会干扰业务系统。

这种细分还符合 PCI-DSS 要求 1.3,该要求强制规定持卡人数据环境必须与不可信网络隔离。访客 WiFi 绝不能与支付基础设施共享 VLAN。

步骤 2:DHCP 作用域配置

配置 Guest VLAN 的 DHCP 作用域,将您的云端 DNS 过滤服务的 IP 地址分配为主 DNS 服务器和次 DNS 服务器。这可确保加入 Guest 网络的所有设备自动获取正确的解析器。

步骤 3:在防火墙上强制执行端口 53 规则

仅靠 DHCP 分配是不够的。用户可以通过手动配置其设备来使用公共解析器(如 Google (8.8.8.8) 或 Cloudflare (1.1.1.1))来覆盖 DHCP 提供的 DNS 设置。恶意软件通常也会硬编码 DNS 设置以完全绕过网络控制。

您必须实施一条防火墙规则,丢弃从 Guest VLAN 到除您指定的过滤服务器之外的任何 IP 地址的端口 53(UDP 和 TCP)上的所有出站流量。这将使 DNS 过滤器从建议性控制转变为强制性控制。

步骤 4:缓解 DNS over HTTPS (DoH) 影响

现代浏览器和应用程序越来越多地使用 DoH,它将 DNS 查询加密在端口 443 上的标准 HTTPS 流量中。这完全绕过了端口 53 的拦截。为了保持防护覆盖,请配置您的防火墙以阻止主要 DoH 提供商的已知 IP 地址范围。这会强制客户端设备回退到标准的非加密 DNS,从而让您的过滤引擎可以进行检查。NIST SP 800-81r3(2026 年 3 月发布)专门将 DoH 作为企业 DNS 安全性考量进行了阐述。

步骤 5:Captive Portal 的 Walled Garden 配置

如果您运行用于访客认证的 Captive Portal,则必须在应用任何阻止策略之前配置 Walled Garden。Walled Garden 是设备在通过身份验证之前可以访问的域名列表。它必须包含 Captive Portal 运行所需的所有域名:您 Portal 自己的域名、任何身份提供商(Microsoft Entra ID、Okta、Google Workspace)以及任何社交登录 OAuth 端点。

如果这些域名在身份验证之前被阻止,用户将无法完成登录流程。这会导致上线体验中断,并让访客感到沮丧。请先配置 Walled Garden,然后仅将内容过滤策略应用于已认证的会话。

有关 SSID 架构以及 Guest WiFi、员工 WiFi 和物联网网络应如何构建的更多信息,请参阅 Three SSIDs to rule them all: guest, Passpoint, and IoT WiFi


最佳实践:策略设计与持续管理

基于类别的阻止

围绕内容类别(而不是单个域名黑名单)组织您的 DNS 过滤策略。类别通常包括:恶意软件和钓鱼网站、僵尸网络命令与控制、成人内容、赌博、非法流媒体以及对等文件共享(P2P)。基于类别的策略更易于维护,并能随着威胁情报的更新自动捕获新域名。

威胁情报更新频率

选择能实时或近乎实时更新威胁情报的 DNS 过滤服务商。每日更新的静态阻止列表不足以应对现代快速通量(fast-flux)恶意软件攻击。Purple Shield 持续更新其威胁情报,反映了相同的 AI 驱动检测,从而提供了比被动防御服务商领先 10 天的优势。

硬件无关的部署

Purple Shield 采用云端覆盖(cloud overlay)模式运行,这意味着它能与您现有的接入点基础设施集成,无需更换硬件。它与 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 兼容。过滤策略在 DNS 层应用,因此接入点硬件只需将 DNS 查询转发到正确的解析器即可。

分析与报告

DNS 过滤会生成详细的查询日志,提供对网络行为的可见性。利用这些日志可以识别趋势:来自特定接入点的已阻止网络钓鱼尝试激增可能表明存在针对性攻击。定期查看已阻止类别报告还有助于合规性审计,向 PCI DSS 评估员和 GDPR 审计员证明您已实施了主动控制措施。

Purple 的 WiFi Analytics 平台与 Shield 集成,为安全事件和网络性能提供统一的可见性。


故障排除与风险缓解

通过自定义 DNS 绕过过滤器

现象:用户报告可以访问本应被阻止的内容。防火墙日志显示来自访客 VLAN 的 DNS 查询指向 8.8.8.8 或 1.1.1.1。

原因:防火墙未阻止 53 端口。用户正在覆盖 DHCP 分配的 DNS 设置。

解决方法:实施防火墙规则,丢弃所有从访客 VLAN 发往除您的过滤引擎以外任何 IP 的出站 UDP/TCP 53 端口流量。

Captive Portal 认证失败

现象:访客无法完成登录流程。Captive Portal 页面加载失败,或社交登录按钮无响应。

原因:DNS 过滤器在认证前阻止了身份提供商域名。Microsoft Entra ID、Google Workspace 或您门户网站自身的域名在已阻止类别列表中。

解决方法:审计您的 Walled Garden(围墙花园)配置。将所有需要的认证域名添加到预认证白名单中。在部署策略更改之前,在过渡环境中测试完整的登录流程。

DoH 绕过

现象:尽管网络利用率很高,但 DNS 过滤器日志显示查询量很低。某些设备似乎完全绕过了过滤。

原因:浏览器或应用程序正在使用 DoH,通过 443 端口将加密的 DNS 查询路由到外部解析器。

解决方法:在防火墙处阻止主要 DoH 提供商的已知 IP 范围。通过监控指向已知 DoH 解析器 IP 的 HTTPS 连接来验证覆盖范围。

业务 VLAN 中断

现象:部署 DNS 过滤器后,POS 终端或物业管理系统失去连接。

原因:DNS 过滤策略应用到了错误的 VLAN,或者 DHCP 正在将云端 DNS 解析器分配给业务设备。

解决方法:验证所有交换机端口和接入点上的 VLAN 标记。确认业务设备 VLAN 已配置为仅使用内部 DNS 解析器。


投资回报率(ROI)与业务影响

DNS 过滤可在三个维度上带来可衡量的回报。

带宽回收:拦截非法流媒体、对等网络(P2P)共享和自动僵尸网络流量可释放大量带宽。在酒店环境中,这可以使访客 VLAN 利用率降低 20 - 40%,在无需升级线路的情况下提升合规用户的网络性能。

降低合规成本:证明具备主动的 DNS 级别控制可缩小 PCI DSS 评估的范围并降低相关成本。它还为 GDPR 第 32 条(确保数据安全的基建技术措施)提供了书面证据,并支持恶意软件防护的 Cyber Essentials 认证要求。

品牌与法律责任保护:在零售和酒店环境中执行适合家庭的浏览策略,可防止公开展示不当内容。在面向儿童的场所 - 购物中心、亲子酒店、体育馆 - 这在许多司法管辖区既是品牌基本要求,也是法律考量。

如需特定行业的部署指南,请参阅我们的行业页面: 酒店业零售业医疗保健业交通运输业

关键定义

DNS filtering

一种安全技术,用于拦截域名解析请求,并在允许或阻止连接之前,根据威胁情报源和内容策略对其进行评估。

针对公共网络上非托管宾客设备的主要内容控制方法。无需终端 Agent。

Sinkholing(域名沉洞)

在响应针对恶意域名的 DNS 查询时返回一个不可路由的 IP 地址(例如 0.0.0.0),从而阻止设备建立连接。

用于静默阻止僵尸网络命令与控制流量,而不会向恶意软件发出已被检测到的警报。

Walled Garden(围墙花园)

一个受限的预身份验证网络环境,允许用户在完成 captive portal 登录流程之前访问特定的已批准域名集。

必须包含所有身份提供商域名(Microsoft Entra ID、Google Workspace、Okta)和 captive portal 资源,以防止身份验证失败。

DNS over HTTPS (DoH)

一种在端口 443 的标准 HTTPS 流量内对 DNS 查询进行加密的协议,可对网络级检查隐藏目标域名。

在现代浏览器中默认使用的比例越来越高。需要在防火墙级别阻止 DoH 提供商的 IP 范围,以维持 DNS 过滤的覆盖率。

VLAN 隔离

使用 802.1Q 标记将单个物理网络划分为多个隔离的逻辑网络。

对于将访客流量与业务系统隔离至关重要。PCI DSS 要求 1.3 规定,持卡人数据环境必须与包括访客 WiFi 在内的非信任网络隔离开来。

Captive portal

设备在获得完整网络访问权限之前必须与其进行交互的网页,用于身份验证、接受服务条款以及第一方数据捕获。

需要仔细配置 Walled Garden,以便与 DNS 过滤协同正常工作。

深度包检测 (DPI)

一种网络过滤方法,在检查点检查数据包的完整载荷,从而实现内容感知过滤,但会带来显着的处理开销。

由于延迟和硬件成本,对于高密度访客网络来说并不实用。在非托管设备环境中,DNS 过滤是首选的替代方案。

威胁情报源

一个持续更新的已知恶意 IP 地址、域名和 URL 模式数据库,用于支持实时 DNS 过滤决策。

威胁情报源的质量和更新频率决定了 DNS 过滤器对新的零日威胁的响应速度。

零日域名

在恶意软件或网络钓鱼活动中使用的、尚未出现在任何标准阻止列表中的新注册域名。

现代攻击活动使用活跃时间不超过 24 小时的一次性域名。人工智能驱动的威胁检测通过分析注册模式来识别这些域名,而不是等待报告。

应用实例

一家拥有 400 间客房的连锁酒店正在 12 家分店部署宾客 WiFi。他们使用 Microsoft Entra ID 进行 Captive Portal 认证,且其物业管理系统 (PMS) 运行在相同的物理交换机基础设施上。启用 DNS filtering 后,有三家分店的宾客反馈无法完成登录流程。根本原因是什么,团队应该如何解决?

根本原因是 Walled Garden 配置不完整。DNS 过滤器在宾客进行身份验证之前拦截了 Microsoft Entra ID 认证域名,从而导致宾客无法加载登录页面的死循环。解决步骤:1. 在 DNS filtering 控制面板中,创建一个预认证策略,明确将所有 Microsoft Entra ID 域名(包括 login.microsoftonline.com、login.live.com 及任何租户专用域名)设为白名单。2. 验证 Captive Portal 自身的域名及其加载的任何 CDN 资产是否也已加入白名单。3. 确认 PMS VLAN (VLAN 10) 已配置为使用内部 DNS 解析器,而非云端过滤引擎。4. 仅将限制性内容拦截策略应用于宾客 VLAN (VLAN 20) 上的认证后会话。5. 在关闭事件前,测试每个受影响分店的完整登录流程。

考官评语: 这是酒店业中最为常见的 DNS filtering 部署失败案例。解决方法很简单,但需要理解 DNS filtering 适用于设备的所有 DNS 查询,包括在认证前进行的查询。必须在任何拦截策略生效前配置好 Walled Garden。PMS 隔离问题是一个次要但关键的发现 - 在同一个解析器上混用运营和宾客 DNS 策略会带来 PCI-DSS 要求 1.3 下的合规风险。

一家拥有 200 家门店的大型零售连锁店运营着宾客 WiFi 网络。其 IT 安全团队部署了云端 DNS 过滤器,并更新了所有宾客 VLAN 上的 DHCP 范围。两周后,一次渗透测试显示 18% 的宾客设备成功解析了已知的恶意域名。DNS 过滤器日志未显示来自这些设备的拦截记录。架构上的缺陷是什么,该如何修复?

缺陷在于防火墙未拦截 53 端口。这 18% 的设备通过使用硬编码的解析器(8.8.8.8、1.1.1.1)或使用 DNS over HTTPS,绕过了 DHCP 分配的 DNS 服务器。由于其 DNS 查询从未到达过滤引擎,因此日志中不会出现被拦截的查询。修复方案:1. 在宾客 VLAN 网关上实施防火墙规则,丢弃所有针对除已批准过滤引擎 IP 之外的任何 IP 的 53 端口出站 UDP 和 TCP 流量。2. 在防火墙处识别并拦截主要 DoH 提供商(Cloudflare、Google、NextDNS)的 IP 地址范围,以防加密绕过。3. 重新运行渗透测试以确认覆盖效果。4. 监控防火墙上 53 端口流量的丢弃日志,以验证规则是否生效。

考官评语: DHCP 只是一个建议,而不是强制执行机制。防火墙规则才是实际的强制执行层。这一区别至关重要,且在初期部署中经常被忽略。DoH 绕过是第二个攻击向量,需要单独的缓解措施。将这两项控制措施(拦截 53 端口和拦截 DoH 提供商 IP)结合使用,可以封闭主要的逃避路径。

练习题

Q1. 一家零售连锁店在 150 家门店部署了云 DNS 过滤器。他们更新了所有访客 VLAN 上的 DHCP 范围,以分配过滤引擎 IP。一周后,门店经理报告顾客仍然可以访问被阻止的内容类别。DNS 过滤器控制面板显示来自这些门店的查询量非常低。最可能的原因是什么,应该如何修复?

提示:考虑设备如何在不使用 DHCP 分配的服务器的情况下解析 DNS。

查看标准答案

最可能的原因是防火墙上没有阻止出站端口 53。设备使用硬编码的公共解析器覆盖了 DHCP 分配的 DNS 服务器。控制面板中较低的查询量证实了查询没有到达过滤引擎。解决方法是实施防火墙规则,丢弃从访客 VLAN 到除批准的过滤引擎 IP 之外的任何 IP 的端口 53 上的所有出站 UDP 和 TCP 流量。此外,阻止已知的 DoH 提供商 IP 范围,以防止绕过加密的 DNS。

Q2. 一个会议中心首次部署 DNS 过滤。他们在 Captive Portal 上使用 Google Workspace 进行参会者身份验证。在测试期间,参会者无法完成登录流程 - Google 登录页面无法加载。遗漏了哪个配置步骤,以及应如何纠正?

提示:身份验证发生在设备拥有完整互联网访问权限之前。在完成身份验证之前,哪些域名必须是可达的?

查看标准答案

在应用 DNS 过滤策略之前未配置 Walled Garden。DNS 过滤器在参会者进行身份验证之前阻止了 Google Workspace 身份验证域名(accounts.google.com、oauth2.googleapis.com)。解决方法是将所有必需的 Google Workspace OAuth 和身份验证域名添加到 DNS 过滤策略中的预身份验证白名单中。Captive Portal 的自身域名和任何 CDN 资产也必须加入白名单。仅对身份验证后的会话应用限制性内容策略。

Q3. 一个体育馆 IT 团队正在为其拥有 60,000 人容量的场馆评估 DNS 过滤与深层数据包检测(DPI)。网络团队担心高峰活动期间的延迟。哪种方法更合适,为什么?

提示:考虑在 60,000 个并发用户的规模下,每种方法带来的处理开销。

查看标准答案

DNS 过滤是合适的选择。它在解析层运行,在建立任何连接之前评估单个轻量级 UDP 数据包,无论并发用户数多少,增加的延迟均低于 2 毫秒。DPI 需要检测每个数据包的完整有效载荷,在 60,000 个并发用户的情况下,这会引入显著的延迟,并且在每个检测点都需要极其昂贵的硬件。DNS 过滤还与协议无关,可以阻止任何端口上的连接,而 DPI 通常仅限于 HTTP 和 HTTPS 流量。

Q4. 一家酒店集团的 IT 总监希望确认其 DNS 过滤部署是否符合 PCI DSS 要求。他们的支付终端位于 VLAN 10,而访客 WiFi 位于 VLAN 20。DNS 过滤器仅应用于 VLAN 20。他们应该为 PCI DSS 评估员记录哪些额外证据?

提示:PCI DSS 要求 1.3 涵盖了受信任网络与非受信任网络之间的网络访问控制。

查看标准答案

IT 总监应记录:1. 防火墙规则,确认无法从 VLAN 20(访客网络)访问 VLAN 10(持卡人数据环境),从而满足 PCI DSS 要求 1.3。2. DHCP 配置,显示 VLAN 10 设备使用内部 DNS 解析器,而不是云过滤引擎。3. 防火墙规则,阻止从 VLAN 20 到未授权 IP 的出站端口 53,以证明强制执行了 DNS 过滤。4. DNS 过滤器策略文档,显示 VLAN 20 上处于活动状态的恶意软件和僵尸网络拦截类别。5. DNS 过滤器日志,显示被阻止的查询事件,证明该控制措施处于活动状态并受到监控。