针对 MSP 和多场地企业的 DNS 过滤

针对 MSP 和多站点场所的 DNS 过滤可在设备连接前，对照云端安全策略检查域名请求。它通过 Purple 与 SSID、Captive Portal 和分析功能进行集中管理，无需现场安装硬件。通过与 Cisco Meraki 和 HPE Aruba 等集成，Purple 在无需安装 Agent 的情况下，为超过 80,000 多个实时场所的网络提供保护。

什么是针对 MSP 和多站点场所的 DNS 过滤？

设备发起的每个连接都始于 DNS（域名系统）查找。设备请求解析器将诸如 example.com 之类的名称转换为 IP 地址。DNS 过滤（也称为保护性 DNS）会在回答前对照策略检查该名称。如果该域名包含恶意内容或不符合策略，解析器就会扣留真实地址。设备永远不会建立连接，因此不会下载任何内容，也不会加载任何页面。

对于单个场所来说，这是一项非常有用的控制措施。但对于托管服务提供商 (MSP) 或多站点 IT 团队而言，需求发生了改变。您需要管理数十个或数百个网络，这些网络属于不同的客户，拥有不同的规则，运行在不同的硬件上。这就提出了单站点过滤器很少能满足的三个要求：

• 按租户制定策略。 租户是指拥有自己独立规则的客户或业务单元。家庭酒店集团、连锁酒吧和诊所绝不应该共享同一套策略。
• 集中化管理。 您需要在一个地方查看和更改每个租户的策略，而无需登录到每个站点。
• 无需单站点硬件。 在每个位置运输、上架和打补丁设备无法在大规模网络中实现扩展。

Shield 是 Purple 的保护性 DNS 插件，与 SecurePass 和 Verify 协同工作。过滤功能运行在云端，并与您已为每个客户管理的 SSID（网络名称）、Captive Portal 和分析工具相绑定。Captive Portal 是访客在上网前看到的登录页面。

MSP 过滤与单站点部署有何不同

单站点过滤器只有一套策略、一个管理员和一个网络。而 MSP 网络具有层级结构。您可以为整个网络设置规则，按客户进行覆盖，然后按站点内的网络进一步调整。酒店的访客网络与前台后面的员工网络需要不同的规则。

独立的 DNS 过滤器通常通过为每个租户建立一个子组织来处理此问题，其配置与 WiFi 本身相互独立。最终，您必须为每个客户运行两个堆栈：一个用于网络和 Portal，另一个用于解析器。Shield 消除掉了第二个堆栈，因为过滤策略会直接跟随您在 Purple 中已经定义好的网络。

为什么 DNS 过滤对跨客户站点的网络规模至关重要？

三种压力推动过滤功能成为 MSP 的优先事项：关怀义务、威胁暴露和有限的带宽。

共享网络上的关怀义务

公共与访客 WiFi 承担着切实的合规义务。在英国，中小学和学院必须遵循教育部的过滤与监控标准，这些标准在《保持儿童教育安全》中有所引用。在美国，《儿童互联网保护法》(CIPA) 要求获得 E-rate 资金支持的学校和图书馆必须进行网络过滤。接待家庭顾客的酒店、咖啡馆和休闲中心如果发生儿童接触成人内容的情况，将面临声誉风险。英国的 Friendly WiFi 计划正是为此目的而设立。

当您为 40 个客户提供 WiFi 运营服务时，您就在分担这些合规责任。只要有一个网站未被过滤，就会导致您最不希望发生的客户沟通危机。

针对未托管设备的威胁

您无法在访客的手机上安装代理软件，也无法为其打补丁。网络钓鱼链接、恶意软件下载以及命令与控制 (C2) 回调都是从 DNS 查询开始的。这使得 DNS 查询成为您对网络上每一台设备进行控制的唯一切入点。

Shield 会在 DNS 查询阶段标记威胁，在连接建立之前阻止恶意请求。在整个设备网络中，威胁拦截指令会同时同步至每一个客户站点。要了解更广泛的市场信息，请参阅 网络钓鱼防护软件：共享 WiFi 的 10 种选择。

受限站点的带宽优化

许多场所的访客 WiFi 都运行在有限的回传链路上：加油站前场的 4G 路由器、酒吧的共享线路、火车站繁忙的电路。广告流量和不良网页内容会与其他所有正常业务争抢资源。在 DNS 层过滤广告和恶意域名可以减少网络数据消耗并提高加载速度。在拥堵的站点，节省出来的带宽将重新服务于访客真正需要的业务流量。

防火墙遗漏的漏洞

防火墙依然重要，但它的工作节点不同。它是在 DNS 已经给出响应之后才对连接进行检查。这会在多站点访客网络中留下四个漏洞：

1. 加密隐藏了目的地。 TLS 1.3 (RFC 8446) 对服务器证书进行了加密。作为 TLS 的 IETF 扩展，加密客户端 Hello (ECH) 还可以隐藏服务器名称。在没有解密的情况下，防火墙只能看到一个 IP 地址，而您又无法在访客设备上安装解密证书。
2. 共享 IP 地址模糊了规则。 内容分发网络 (CDN) 在相同的地址上托管多个域名。封锁该 IP 会破坏合法网站；允许该 IP 则会让恶意域名溜进来。
3. 单站点规则集偏离一致性。 经过多年建设的网络融合了多家防火墙厂商和固件版本。保持 60 个规则集完全一致是一项全职工作，而只要遗漏一个站点就会形成漏洞。
4. 拦截发生得太晚。 当防火墙采取行动时，设备已经解析了名称并尝试建立连接。DNS 过滤则可以在任何连接存在之前阻止请求。

DNS 过滤在无需解密、代理软件或单站点规则的情况下填补了这些漏洞。它并不会取代防火墙在网络隔离和端口控制方面的职责。

DNS 过滤如何在多租户环境中工作？

每次查询的执行流程

1. 访客连接客户的 WiFi，通常是通过 Captive Portal。
2. 设备请求一个域名，例如点击了钓鱼邮件中的链接。
3. Shield 会根据分配给该网络的策略对域名进行核查。
4. 如果域名被允许，设备将获取地址并正常连接。
5. 如果域名被拦截，查询不会返回真实地址，因此不会建立连接。

如何构建多租户策略

多租户内容过滤的最佳实践是采用一小套标准策略，而不是为每个站点制定定制的规则集。这种模式适用于住宿餐饮业、零售业和公共部门：

• 安全基线。 恶意软件、钓鱼网站和其他威胁类别会在每个网络上对每个租户进行拦截。任何人都不例外。
• 家庭访客。 在基线的基础上增加针对成人和不适合特定年龄内容的拦截。适合家庭酒店、图书馆、休闲中心、学校和医疗等待区。
• 成人访客。 在基线的基础上采用较宽松的内容规则。适合酒吧、夜间场所和商务酒店。
• 员工。 基线加上反映各客户可接受使用政策的规则。

为每个网络分配一个策略，然后仅在企业有特定需求时添加客户例外情况。酒店的营销团队可能需要社交平台，而学校则会拦截这些平台。相比 60 个手动构建的规则集，4 个策略加上一份简短的例外清单要容易审计得多。

由于 Shield 会将策略附加到您在 Purple 中运行的网络，因此站点的访客 SSID 和员工 SSID 可以搭载不同的策略。使用 IEEE 802.1X（基于端口的网络访问控制标准）的员工网络将保留其身份控制。Shield 则在顶层添加 DNS 层。

从单个仪表板管理整个网络集群

集中式的 DNS 策略管理只有在符合您既有工作流程时才能发挥最大价值。Shield 托管在运行各客户 SSID、Captive Portal 和分析数据的同一 Purple 平台中。您无需切换控制台即可更改过滤器，也无需维护第二个站点清单。

这对 MSP 带来了极具实用价值的优势：

• 客户入驻。 Purple 中的新客户站点无需单独的解析器账户。
• 变更控制。 修改一次策略，即可应用到为其分配的所有网络。
• 报告生成。 过滤活动与您已共享的连接分析数据放在一起，因此一份季度审查报告就能涵盖 WiFi 和安全性。

为什么无需寄送任何硬件设备

Shield 在云端进行过滤，因此无需为每个地点购买、配置、寄送或更换硬件设备。Purple 兼容各类硬件，并可作为云端叠加层运行在 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 之上。即使客户资产在收购后混合了多个厂商的设备，仍然可以运行同一套策略。具体设置因厂商而异，请参考 Purple 针对您硬件的文档支持。

Purple 目前已在 80,000 多个活跃场所运行，并在 2024 年记录了 4.4 亿次登录（Purple 数据）。

真实场景下的 DNS 过滤体验如何？

以下三种场景是根据常见的网络资产类型综合构建的。站点数量和硬件具备代表性；其结果则是每次变更在运维层面带来的实际效益。

场景 1：拥有 14 家酒店客户的 MSP

现状。 某 MSP 为 14 家酒店客户的 60 个站点提供访客和员工 WiFi 运营。客户组合包括独立酒店、包含 20 个站点的酒吧集团以及一个假日公园。WiFi 和 Captive Portal 已在 Purple 上运行。过滤功能此前在单独的 DNS 服务上运行，每个客户都拥有独立的账户和站点列表。

应对措施。 该 MSP 将过滤功能迁移至 Shield，并用四种标准策略替换了 14 个定制规则集。亲子酒店和假日公园采用了亲子访客策略；酒吧集团采用了成人访客策略。两家客户保留了简短的例外列表。

结果。 跨 60 个站点实现了零硬件出货和零现场巡检。该 MSP 注销了 14 个独立的过滤账户，现在直接从原有的 Purple 控制台统一管理所有客户。规则变更意味着仅需编辑四种策略之一，而不再需要修改多达 60 个站点条目。

场景 2：某议会的图书馆与休闲中心

现状。 某郡议会在 22 个图书馆和 5 个休闲中心提供公共 WiFi。放学后有儿童使用图书馆网络。两次采购使图书馆采用了 HPE Aruba，而休闲中心则采用了 Ubiquiti UniFi。IT 团队仅有三人。

应对措施。 议会对每个公共 SSID 应用了亲子访客策略，并对员工网络应用了员工策略。员工身份验证保持在带有 WPA3-Enterprise（当前的企业 WiFi 加密标准）的 802.1X 上。访客仍通过议会的 Captive Portal 连接。

结果。 所有 27 个站点在两个硬件厂商之间运行统一的公共策略，任何地方都不需要额外部署硬件设备。一次编辑即可覆盖所有 27 个站点。议会向审计人员展示的是单一策略和单一日志源，而不是 27 个本地配置。

场景 3：受限于回传带宽的 120 家门店零售商

现状。 某零售商在 120 家门店为购物者提供访客 WiFi，其中三分之一的门店使用 4G 回传。购物者的网页浏览与门店系统争夺带宽。持卡人数据环境已经与访客流量隔离开来，以确保其处于 PCI DSS 范围之外。

应对措施。 该零售商仅在访客 SSID 上启用了 Shield 的威胁防护和广告拦截功能。它首先在其最繁忙的 4G 站点进行了 10 家门店的试点。员工和门店系统网络保持在其各自的网段上。

结果。 试点项目评估了四周内的前后使用情况，证实了在受限连接下整体数据消耗有所降低。随后，该零售商通过一次变更将该策略推广到所有 120 家门店，期间无需任何到店实地操作。

DNS 过滤在您现有的运行架构中处于什么位置？

防护型 DNS 只是其中一个防护层。它与您可能已经拥有的控制措施协同工作时效果最佳。

• 细分网络。 VLAN（虚拟局域网，可将单个物理网络拆分为隔离的逻辑网络）可确保访客流量远离员工和支付系统。请参阅 如何为访客和员工设置网络细分。
• 身份验证。 结合 RADIUS（根据中央服务器核对凭据的协议）的 802.1X 可以决定谁能接入员工网络。SecurePass 配合 Microsoft Entra ID、Okta 或 Google Workspace 也是如此。Shield 则能在设备连接后决定其访问权限。
• 防火墙。 您的防火墙仍负责控制端口、协议以及网络段之间的流量。Shield 则能在查询阶段拦截已知的恶意目标。
• 隐私法律。 DNS 日志可能包含 IP 地址和设备标识符，GDPR 将其视为个人数据。Purple 完全符合 GDPR 要求，并已通过 ISO 27001 认证。

Shield 与 DNSFilter 及 Cisco Umbrella 的比较

DNSFilter 和 WebTitan 极大程度地针对 MSP，而 Cisco Umbrella 是许多 Cisco 环境下的默认选择。它们都在云端的 DNS 层进行过滤。区别在于由谁管理、管理内容以及管理地点。

评估标准	Purple Shield	DNSFilter	Cisco Umbrella
过滤发生位置	DNS 查询，在 Purple 的云端	DNS 查询，在 DNSFilter 的云端	DNS 查询，在 Cisco 的云端
单站点硬件要求	无	网络过滤无硬件要求	DNS 层防护无硬件要求
租户管理	在运行客户 WiFi 的 Purple 控制面板内部	包含子组织的独立 MSP 控制台	独立的多组织或 MSP 控制台
与 SSID、Captive Portal 和 WiFi 数据分析联动	是，原生集成于 WiFi 平台	否，需配置为独立的技术栈	与 Cisco Meraki 集成，在其专属控制台中管理
场外漫游设备	专为连接您运营的 WiFi 的设备打造	漫游客户端代理	Cisco Secure Client 漫游模块
硬件覆盖范围	Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme、Fortinet	任何能将 DNS 转发至其解析器的网络	任何能将 DNS 转发至其解析器的网络，在 Cisco 环境中集成度最高
最适合的场景	客户 WiFi 在 Purple 上运行的 MSP	为场内及场外托管端点提供保护的 MSP	基于 Cisco 安全标准打造的企业环境

在 Shield 未涉足的领域，替代方案表现强劲。DNSFilter 和 Cisco Umbrella 都为场外托管笔记本电脑提供漫游代理。Umbrella 还嵌入在 Cisco 更广泛的安全产品组合中。TitanHQ 的 WebTitan 也为 MSP 提供多租户云过滤。如果您的合同覆盖了员工无论移动到何处都要保护的企业端点，那么其中一种方案可能非常适合。

Shield 的优势更加明确，特别是对于以 WiFi 为主导的 MSP 而言，优势更为显著。如果您在 Purple 中管理每个客户的 SSID、Captive Portal 和分析数据，那么为每个租户单独配置一套解析器堆栈会带来额外的运维负担。有关详细信息，请阅读 Shield vs DNSFilter: a protective DNS comparison for WiFi operators 以及 Shield vs Cisco Umbrella: choosing protective DNS for guest WiFi。

您需要了解的 DNS 过滤局限性有哪些？

DNS 过滤仅作用于网络连接的一个节点，这也决定了它的局限性：

• 加密 DNS 可能会绕过过滤。 DNS over HTTPS (DoH, RFC 8484) 和 DNS over TLS (DoT, RFC 7858) 允许设备自行选择解析器。网络控制手段可以减轻非托管设备上的这种影响，但无法彻底消除。参见 DNS over HTTPS explained: privacy vs public WiFi filtering。
• VPN 会通过隧道绕过过滤。 使用个人 VPN 的访客会在隧道内部解析域名。您可以拦截已知的 VPN 域名，但无法拦截所有域名。
• 直接 IP 连接会跳过 DNS。 访问硬编码 IP 地址的恶意软件根本不会发起 DNS 查询。这种情况需要靠您的防火墙来拦截。
• 它只识别域名，不识别内容。 DNS 过滤是允许或拦截整个域名，而不是单独的页面或文件。
• 分类需要定期审核。 任何分类列表有时都会出现过度拦截或拦截不足的情况。请为每个客户提供指定的联系人以及申请变更的渠道。
• 日志需要合规治理。 在上线前与每个客户确认日志保留时间和访问权限，并记录在您的数据处理协议中。

下一步您应该怎么做？

1. 梳理您的租户。 列出所有客户、站点和网络，并标明其行业领域和合规义务，例如学校、图书馆、医疗机构和持牌场所。
2. 草拟标准策略。 从上述四种策略开始，并将安全基线设为强制执行。
3. 在有代表性的站点进行试点。 每个行业领域选择一个站点（包括一个处于受限回传链路上的站点），并测量实施前后的流量使用情况。
4. 按策略部署，而非按站点部署。 为每个客户的网络分配策略，并在 30 天后审查例外情况。
5. 定期汇报成果。 将过滤活动报告添加到您现有的 WiFi 运营总结中。

如果您客户的 WiFi 尚未运行在 Purple 上，请先了解 Guest WiFi，然后再添加 Shield。有关跨多区域保护网络安全的更多信息，请浏览 All guides。

常见问题解答

使用 DNS 过滤是否需要在每个客户站点安装硬件？

不需要。Shield 在云端的 DNS 层进行过滤，因此无需为任何位置购买、配置或邮寄硬件设备。Purple 可以作为云端叠加层，运行在客户已有的 AP 接入点上，包括 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet。不同厂商的配置有所不同，请参考 Purple 针对您网络中每种硬件类型的支持文档。

我能否为每个客户和每个网络设置不同的过滤策略？

是的。Shield 会将过滤策略与您已在 Purple 中运行的网络关联，因此每个客户以及站点内的每个 SSID 都可以执行各自的策略。酒店的访客网络可以屏蔽成人内容，而其员工网络则应用客户的合理使用规则。少量标准策略加上简短的例外列表，比针对每个站点定制规则更容易审核。

我能否从一个仪表板管理多个星罗棋布的站点的内容过滤？

是的。Shield 在运行客户 SSID、Captive Portal 和分析数据的同一 Purple 平台中进行管理，因此您无需切换控制台即可更改过滤设置。策略更改会应用于分配给该策略的每个网络（涵盖所有站点）。过滤活动与您现有的 WiFi 报告放在一起，因此一次客户审查就能同时涵盖连接性和安全性。

对于 MSP 而言，Shield 与 DNSFilter 相比如何？

Shield 适合那些客户的 WiFi 已经运行在 Purple 上的 MSP，而 DNSFilter 则适合保护现场和外出的托管笔记本电脑的 MSP。两者都在云端 DNS 层进行过滤，无需在每个站点部署硬件。DNSFilter 作为带有漫游 Agent 的独立多租户控制台运行。Shield 则运行在 WiFi 平台内部，与您已经管理的 SSID、Captive Portal 和分析数据紧密结合。

访客能否通过基于 HTTPS 的 DNS 或 VPN 绕过 DNS 过滤？

是的，刻意的访客确实可以做到。基于 HTTPS 的 DNS、基于 TLS 的 DNS 和个人 VPN 会将查询发送到您的解析器之外。网络控制措施可以减少这种情况，例如通过屏蔽已知的 VPN 和公共 DoH 端点，但没有哪个 DNS 过滤器能完全控制未托管的设备。请将 DNS 过滤视为使用网络 DNS 的每个设备的默认保护措施，并与网络分段和防火墙配合使用。

DNS 过滤能否帮助学校和图书馆满足过滤要求？

它涵盖了过滤要素，但仅凭过滤并不能满足全部要求。在英格兰，英国教育部 (Department for Education) 的过滤与监控标准要求同时具备过滤和监控功能，并明确责任人和定期审查。在美国，CIPA 要求获得 E-rate 资助的学校和图书馆在互联网安全策略范围内使用技术保护措施。请将跨站点的预设过滤与您的监控和安全保障流程结合起来。

在 GDPR 下，DNS 查询日志是如何处理的？

Purple 符合 GDPR 并拥有 ISO 27001 认证。DNS 日志可能包含 IP 地址和设备标识符，GDPR 将其视为个人数据。在上线前与每个客户就保留期限、访问权限和使用目的达成一致，并将这些条款记录在您的数据处理协议中。作为 MSP，您通常充当客户的数据处理者，因此请明确记录谁控制每个区域的日志。

对于多站点区域，Shield 如何计费？

Shield 是 Purple 平台的一款安全附加组件，与 SecurePass 和 Verify 并列，因此您可以将其添加到已在 Purple 上运行的站点。无需单站点硬件，因此没有任何设备、运输或更换成本需要测算。请向 Purple 询问基于您的客户和站点数量的定价，并包含您计划今年接入的所有站点。