RadSec: RADIUS over TLS 如何提升 WiFi 身份验证安全性

RadSec: RADIUS over TLS 如何提升 WiFi 认证安全 Purple 企业级 WiFi 智能简报 预计阅读时间：10 分钟 --- [引言与背景 - 约 1 分钟] 欢迎收看 Purple 企业级 WiFi 智能系列。我是你们的主持人。今天，我们将探讨一个处于网络安全与运营风险交汇处的课题：RadSec - 在 RFC 6614 中正式定义。如果它还没有出现在您的基础设施路线图中，那么现在应该将其纳入其中。 如果您是 IT 经理、网络架构师或 CTO，负责酒店集团、零售物业、体育场馆或公共部门园区的企业级 WiFi，那么本次简报正是为您量身打造。我们将介绍什么是 RadSec、为什么传统的 RADIUS 协议会让您面临安全风险、如何在真实环境中部署 RadSec，以及团队经常遇到的陷阱。不讲空洞的理论 - 只提供您在本季度做出决策所需的信息。 让我们开始吧。 --- [技术深度解析 - 约 5 分钟] 首先，让我们来看看问题所在。RADIUS - 远程用户拨号认证服务 - 自 20 世纪 90 年代以来，一直是企业级 WiFi 认证的支柱。当用户或设备连接到您的企业或访客 WiFi 时，接入点充当 RADIUS 客户端，将认证请求转发给 RADIUS 服务器。服务器在您的目录 - 如 Active Directory、LDAP 或云身份提供商 - 中验证凭据，然后授予或拒绝访问。这就是支撑 WPA2-Enterprise 和 WPA3-Enterprise 网络的 802.1X 认证模型。 问题在于，传统的 RADIUS 是为另一个时代设计的。它在端口 1812 和 1813 上通过 UDP（用户数据报协议）运行。UDP 是无连接的，这意味着没有握手，没有会话状态，而且至关重要的是，没有原生加密。您的接入点和 RADIUS 服务器之间唯一的保护是一个共享密钥 - 实质上是一个密码 - 用于在传输过程中使用 MD5 哈希算法混淆用户密码。大多数人都知道，MD5 在密码学上已经被破解。它已经被破解很多年了。 这在实践中意味着什么？这意味着，在攻击者可以拦截 RADIUS 流量的任何网络段上 - 包括被攻破的交换机、管理 VLAN 上的恶意设备，或者远程接入点与云端托管 RADIUS 服务器之间的任何位置 - 他们都有可能捕获认证交换，对共享密钥进行离线字典攻击，在某些配置下，甚至会完全暴露用户凭据。 对于在 200 家酒店中运行访客 WiFi 的酒店集团，或者在每家门店都部署了接入点并通过公共互联网回传到中央 RADIUS 服务器的零售连锁店来说，这绝非理论上的风险。这是一个真实存在的攻击面。 这正是 RadSec 解决的问题。RadSec（由 RFC 6614 定义并经 RFC 7360 更新）将 RADIUS 流量封装在 TLS 隧道中。它在 2083 端口上使用 TCP，而不是 UDP。它不使用共享密钥和 MD5，而是使用带有 X.509 证书的双向 TLS 身份验证。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 服务器之间。接入点通过本地网络将标准 RADIUS over UDP 发送到该代理。代理终止该连接，将 RADIUS 流量重新封装到 TLS 隧道中，然后通过 TCP 2083 将其转发到上游 RADIUS 服务器。这种方法允许您将 RadSec 添加到现有基础设施中，而无需更换 RADIUS 服务器，当您的 RADIUS 服务器托管在云端或通过公共互联网访问时，这种方法特别有用。 证书管理是您需要规划的运营复杂性所在。您需要一个 PKI - 公钥基础设施 - 来签发和管理用于双向 TLS 的 X.509 证书。这意味着需要一个证书颁发机构、为每个 RADIUS 客户端和服务器签发证书、以及在过期前进行证书轮换的流程。未被注意到的过期证书会同时中断您网络上每个用户的身份验证 - 这是您需要避免发生的情况。建议使用 ACME 或您 CA 的 API 自动进行证书更新，并在到期日之前很久就设置监控告警。 --- [实施建议与陷阱 - 约 2 分钟] 下面我给大家一些实用的建议。 第一：在部署前进行审计。梳理您环境中的每个 RADIUS 客户端（接入点、VPN 集中器、运行 802.1X 的交换机）和每个 RADIUS 服务器。了解哪些原生支持 RadSec，哪些需要代理。这种审计通常会发现完全不支持 TLS 的传统设备，这些设备需要列入您的更换路线图中。 第二：从风险最高的流量开始。如果您有 RADIUS 流量正在穿越公共互联网 - 远程站点、云端托管的 RADIUS、多物业酒店集团 - 那就是您的首要任务。在划分良好的管理 VLAN 上的本地 RADIUS 流量风险较低，但它仍应列入路线图中。 第三：在上线前彻底测试双向 TLS。RadSec 部署中最常见的失败模式是证书验证错误 - 通用名称（Common Name）不匹配、中间证书过期或客户端不信任签署服务器证书的 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 - 基于 DTLS 的 RADIUS 呢？” RFC 7360 定义了基于 DTLS 的 RADIUS，它使用 UDP 而非 TCP，在增加加密的同时保留了传统 RADIUS 的一些无连接特性。它的部署广泛程度不如基于 TLS 的 RadSec，但如果在高吞吐量环境中延迟是一个令人担忧的问题，它值得评估。 “这如何影响漫游性能？” RadSec 的 TCP 连接是持久的，通过减少后续认证请求的连接建立开销，它实际上可以提高联盟环境中的漫游性能。 --- [总结与后续步骤 - 约 1 分钟] 总结一下：RadSec 是针对传统 RADIUS 真实安全漏洞的成熟、基于标准的解决方案。如果您正在大规模运行企业级 WiFi - 跨越多个站点、通过互联网，或者在受 PCI-DSS 或 GDPR 约束的环境中 - 问题不在于是否部署 RadSec，而是在于何时以及如何部署。 您的后续步骤：本周审计您的 RADIUS 基础设施。识别您风险最高的流量。检查您的 RADIUS 服务器和接入点厂商文档以获取原生 RadSec 支持信息。如果您运行的是 FreeRADIUS，您可以在一天内运行一个测试 RadSec 部署。如果您使用的是 Microsoft NPS，请开始评估代理或迁移到支持 RadSec 的服务器的路径。 Purple 的平台旨在与企业 RADIUS 基础设施集成，为企业和访客 WiFi 环境提供安全的认证流程。如果您想了解 RadSec 如何融入您的特定部署，Purple 团队可以为您详细讲解。 感谢收听。下期再见。 --- 脚本结束