RadSec: RADIUS over TLS 如何提升 WiFi 认证安全性

RadSec：RADIUS over TLS 如何提升 WiFi 认证安全性 Purple 企业级 WiFi 智能简报 预计运行时间：10 分钟 --- [引言与背景 - 约 1 分钟] 欢迎来到 Purple 企业级 WiFi 智能系列。我是你们的主持人，今天我们要探讨一个正处于网络安全与运营风险交汇处的课题：RadSec - 正式定义为 RFC 6614 - 以及为什么如果它还没有在您的基础设施路线图上，现在就应该加入进去。 如果您是负责酒店集团、零售物业、体育场馆或公共部门园区的企业级 WiFi 的 IT 经理、网络架构师或 CTO，这份简报就是为您准备的。我们将涵盖 RadSec 的实际概念、传统 RADIUS 协议如何让您暴露在风险中、如何在实际环境中部署 RadSec，以及会让团队踩坑的陷阱。没有为了理论而理论的内容 - 只有您在本季度做出决策所需的信息。 让我们正式开始。 --- [技术深度探究 - 约 5 分钟] 那么，让我们从问题开始。RADIUS - 远程用户拨号认证服务 - 自 20 世纪 90 年代以来一直是企业级 WiFi 认证的骨干。当用户或设备连接到您的企业或访客 WiFi 时，接入点充当 RADIUS 客户端，将认证请求转发给 RADIUS 服务器，该服务器根据您的目录（Active Directory、LDAP 或云身份提供商）验证凭证，并允许或拒绝访问。这就是构成 WPA2 和 WPA3 企业级网络基础的 802.1X 认证模型。 问题在于，传统的 RADIUS 是为另一个时代设计的。它通过 UDP（用户数据报协议）运行在端口 1812 和 1813 上。UDP 是无连接的，这意味着没有握手、没有会话状态，且至关重要的是，没有原生加密。您的接入点和 RADIUS 服务器之间唯一的保护是一个共享密钥 - 本质上是一个密码 - 用于在传输过程中使用 MD5 哈希算法来混淆用户的密码。大多数人都知道，MD5 在密码学上已经被破解了。它已经失效很多年了。 这在实践中意味着什么？这意味着在攻击者可以拦截 RADIUS 流量的任何网络段上 - 这包括受损的交换机、管理 VLAN 上的流氓设备，或者远程接入点与云端托管的 RADIUS 服务器之间的任何点 - 他们都可能捕获认证交换过程，尝试对共享密钥进行离线字典攻击，并且在某些配置中，会使外部完全暴露用户的凭证。 对于在 200 个物业中运行访客 WiFi 的酒店集团，或在每家门店都拥有接入点并通过公共互联网回传到中央 RADIUS 服务器的零售连锁店来说，这绝非理论上的风险。这是一个现实存在的攻击面。 这正是 RadSec 所解决的问题。RadSec - 在 RFC 6614 中定义并由 RFC 7360 更新 - 将 RADIUS 流量包装在 TLS 隧道内。它在端口 2083 上使用 TCP，而不是 UDP。它使用带有 X.509 证书的双向 TLS 身份验证，而不是共享密钥和 MD5。RADIUS 客户端和 RADIUS 服务器都会出示证书，验证对方的身份，并在交换任何身份验证数据之前建立加密会话。TLS 1.3 是当前推荐的版本，可提供前向安全性并消除了一系列遗留的密码学漏洞。 实际效果非常显著。凭证数据、用户属性和会话令牌在接入点（或 RadSec 代理）与 RADIUS 服务器之间进行端到端加密。拦截线路上流量的攻击者只能看到加密的 TLS 记录。为了向后兼容，共享密钥仍然存在，但它不再承担任何实质性的安全工作 - 安全重任由 TLS 来承担。 这里还有另一个日益相关的维度：漫游。遍布欧洲及其他地区的大学和研究机构所使用的 Eduroam 联盟，多年来一直运行 RadSec 作为其机构间漫游基础设施的一部分。最近，Wi-Fi 联盟的 OpenRoaming 标准 - 支持在参与场馆之间实现无缝 WiFi 漫游 - 强制要求所有联盟流量使用 RadSec。如果您正在部署支持 OpenRoaming 的基础设施，RadSec 不是可选的，而是先决条件。Purple 在其 Connect 许可下支持 OpenRoaming，作为联盟内的身份提供商，而 RadSec 是该安全漫游架构运作的核心。 从合规性的角度来看，RadSec 与 PCI DSS 4.0 的关联性越来越强，该标准收紧了对传输中身份验证数据保护的要求。如果您的 WiFi 基础设施涉及支付卡环境（在零售和酒店业中经常如此），传统 RADIUS 中的加密漏洞将是一个迟早会被发现的安全隐患。GDPR 同样要求采取适当的技术措施来保护个人数据；在数据保护审计中，在网络中未加密流动的用户凭证和会话元数据是很难进行合规辩护的。 现在我们来谈谈架构。RadSec 有两种主要的部署模式。 第一种是在您的 RADIUS 服务器和接入点上原生支持 RadSec。FreeRADIUS 3.0 及以上版本原生支持 RadSec。截至当前版本，Microsoft NPS 原生不支持 RadSec，这对于运行以 Windows 为中心的基础设施的组织来说是一个重大限制。Cisco ISE 支持 RadSec。Aruba ClearPass 支持 RadSec。如果您的 RADIUS 服务器和您的接入点厂商都原生支持 RadSec，这是最干净的路径 - 在两端配置 TLS 证书，在防火墙上打开 TCP 2083，您就可以端到端加密 RADIUS 流量了。 第二种模式是 RadSec 代理。这是实际部署中更常见的方式，特别是对于拥有传统 RADIUS 基础设施或多厂商混合环境的企业。RadSec 代理（radsecproxy 是部署最广泛的开源实现）介于您的接入点和 RADIUS 服务器之间。接入点通过本地网络将标准的 UDP RADIUS 发送到代理。代理终止该连接，将 RADIUS 流量重新封装到 TLS 隧道中，然后通过 TCP 2083 将其转发到上游 RADIUS 服务器。这种方法使您无需更换 RADIUS 服务器即可将 RadSec 添加到现有基础设施中，当您的 RADIUS 服务器托管在云端或通过公共互联网访问时，这种方法尤其有用。 证书管理是您需要规划的运维难点。您需要一个 PKI - 公钥基础设施 - 来发行和管理用于双向 TLS 的 X.509 证书。这意味着需要一个证书颁发机构、为每个 RADIUS 客户端和服务器发行证书，以及在到期前进行证书轮换的流程。未被察觉的过期证书会同时中断您网络上每个用户的身份验证 - 这是您必须避免发生的情况。建议使用 ACME 或您 CA 的 API 自动进行证书更新，并在到期日之前很久就设置好监控告警。 - - - [实施建议与陷阱 - 约 2 分钟] 下面为您提供一些实用建议。 第一：在部署前进行审计。绘制您环境中的每个 RADIUS 客户端（接入点、VPN 集中器、进行 802.1X 的交换机）和每个 RADIUS 服务器。了解哪些原生支持 RadSec，哪些需要代理。这种审计通常会发现完全不支持 TLS 的传统设备，这些设备需要列入您的更换路线图中。 第二：从风险最高的流量开始。如果您有传输过公共互联网的 RADIUS 流量 - 如远程站点、云托管的 RADIUS、多物业酒店集团 - 那就是您的首要任务。在隔离良好的管理 VLAN 上的本地 RADIUS 流量风险较低，但也应该列入路线图。 第三：在上线前彻底测试双向 TLS。RadSec 部署中最常见的失败模式是证书验证错误 - 如通用名称（Common Names）不匹配、中间证书过期，或客户端不信任签署服务器证书的 CA。在切换生产环境流量之前，使用 openssl s_client 测试 TLS 握手。 第四：不要忽视监控。RadSec 增加了传统 RADIUS 所没有的 TCP 连接层。TCP 连接失败、TLS 握手超时和证书错误都会表现为用户的身份验证失败。确保您的 RADIUS 服务器日志和代理日志都接入了您的 SIEM 或监控平台，以便您能够将 RadSec 连接问题与身份验证策略问题区分开来。 我最常看到的陷阱是组织在服务器端部署了 RadSec，但忘记了更新其防火墙规则。每个 RADIUS 客户端与 RADIUS 服务器或代理之间都需要开放 TCP 2083 端口。如果您习惯了管理 UDP 1812 规则，那么在防火墙变更过程中很容易漏掉 TCP 2083 端口。 - [快速问答 — 约1分钟] 让我来解答几个我经常听到的问题。 “RadSec 是否取代了 802.1X？” 并不是。RadSec 保护的是接入点与 RADIUS 服务器之间的传输层。而 802.1X 是客户端设备与接入点之间的认证框架。它们运行在不同的层级，并且是互补的。 “所有接入点厂商都支持 RadSec 吗？” 并非普遍支持。Cisco、Aruba、Ruckus 和 Meraki 都有不同程度的 RadSec 支持 — 请检查您的具体固件版本。在缺乏原生支持的地方，使用 RadSec 代理就是您的解决方案。 “DTLS 呢 — RADIUS over DTLS？” RFC 7360 定义了 RADIUS over DTLS，它使用 UDP 而不是 TCP，在增加加密的同时，保留了传统 RADIUS 的某些无连接特性。它的部署范围不及 RadSec over TLS 广泛，但如果在高吞吐量环境中延迟是一个令人担忧的问题，那么它值得进行评估。 “这如何影响漫游性能？” RadSec 的 TCP 连接是持久的，通过减少后续认证请求的连接建立开销，实际上可以提高联合环境中的漫游性能。 - [总结与后续步骤 — 约1分钟] 总结一下：RadSec 是针对传统 RADIUS 中真实存在的安全漏洞成熟且基于标准的解决方案。如果您正在大规模运行企业级 WiFi — 跨多个站点、通过互联网，或者在受 PCI-DSS 或 GDPR 约束的环境中 — 问题不在于是否部署 RadSec，而在于何时以及如何部署。 您的下一步行动：在本周审计您的 RADIUS 基础设施。识别您风险最高的流量。检查您的 RADIUS 服务器和接入点厂商文档，以了解是否提供原生 RadSec 支持。如果您运行的是 FreeRADIUS，您可以在一天内运行一个测试版 RadSec 部署。如果您使用的是 Microsoft NPS，请开始评估代理或迁移到支持 RadSec 的服务器的路径。 Purple 的平台旨在与企业 RADIUS 基础设施集成，为企业和访客 WiFi 环境提供安全的认证流程。如果您想了解 RadSec 如何适合您的特定部署，Purple 团队可以引导您完成。 感谢收听。下期再见。 - 脚本结束