RadSec：使用 TLS 保护 RADIUS 认证流量

RadSec：使用 TLS 保护 RADIUS 认证流量。Purple 技术简报。 引言与背景。 欢迎收听本期 Purple 技术简报。我将为您介绍 RadSec——基于 TLS 的 RADIUS——它是什么，为什么现在如此重要，以及如何实际部署。本期内容面向正在运行或计划迁移到云 RADIUS 的网络架构师和安全工程师。如果您仍在使用 UDP 和共享秘密的本地 RADIUS 服务器，那么这期简报就是为您准备的。 让我们设定一下场景。RADIUS 作为网络认证的基石已有三十多年历史。它支撑着 802.1X、WPA2-Enterprise、WPA3-Enterprise 以及当今几乎所有的 Captive Portal 系统。该协议本身在 RFC 2865 中定义，设计于互联网截然不同的时代。您的 NAS 设备——接入点、交换机和控制器——与 RADIUS 服务器之间的认证流量通过 UDP 传输，认证端口 1812，计费端口 1813。而这些流量呢？大部分未加密。唯一的保护是用于混淆用户密码属性的共享秘密，而这本身也有已知的弱点。 多年来，这是可以接受的，因为 RADIUS 流量仅限于私有、受控网络。您的 NAS 设备和 RADIUS 服务器位于同一局域网，或通过专用 MPLS 电路连接。攻击面是可控的。但世界已经改变。云原生基础设施、分布式场所部署、SD-WAN 覆盖网络以及向云 RADIUS 服务的转变，从根本上改变了威胁模型。您的认证流量现在正穿越公共互联网，或充其量是您不完全控制的共享基础设施。这就是 RadSec 发挥作用的地方。 技术深度解析。 RadSec，正式定义于 RFC 6614，是基于 TLS 的 RADIUS。概念很简单：不是通过 UDP 发送 RADIUS 数据包，而是将它们封装在 TCP 上的 TLS 连接中。结果是，您的 NAS 与 RADIUS 服务器之间的所有认证和计费流量都经过完全加密、相互认证和完整性保护。RFC 7360 将此扩展到 DTLS——基于 UDP 的数据报 TLS——在保留原始 UDP 传输的一些延迟特性的同时增加了加密。对于大多数企业部署来说，基于 TCP 的 TLS 是正确的选择。在高吞吐量、延迟敏感的环境中（如大型体育场馆部署），DTLS 值得考虑。 让我们谈谈机制。RadSec 运行在 TCP 端口 2083 上，这是 IANA 为此协议分配的端口。当 NAS 设备发起 RadSec 连接时，它会打开一个到 RADIUS 服务器的 TCP 连接（端口 2083），并执行 TLS 握手。此握手是相互的——客户端（即您的 NAS）和服务器都出示 X.509 证书。服务器的证书根据受信任的 CA 进行验证。客户端证书向 RADIUS 服务器标识 NAS。一旦 TLS 会话建立，RADIUS 数据包就像通过 UDP 一样在该加密隧道内流动，但现在具有完整的机密性、完整性和重放保护。 这与传统 RADIUS 有三个重要区别。首先，传输层是 TCP，而不是 UDP。这意味着您获得可靠、有序的传递。丢失的数据包会自动重传。其次，两个端点的认证基于证书，而不是共享秘密。这消除了一整类基于弱共享秘密或被破解共享秘密的攻击。第三，整个 RADIUS 数据包都被加密，而不仅仅是密码属性。这意味着用户名、会话标识符和所有 RADIUS 属性在传输过程中都受到保护。 从证书管理的角度来看，您需要一个 PKI——公钥基础设施——来为您的 RADIUS 服务器和 NAS 设备颁发和管理证书。在实践中，大多数云 RADIUS 提供商，包括 Purple 的云原生认证基础设施，会为您处理服务器端的证书管理。您的责任是向 NAS 设备预配客户端证书。对于大规模部署，这通常通过网络管理平台或专用证书管理系统处理。证书应至少使用 RSA 2048 位或 ECDSA P-256，有效期应平衡操作开销与安全卫生——十二个月是一个合理的默认值。 现在，让我们讨论一下与许多组织目前使用的替代方法（IPsec 隧道或 VPN 覆盖网络保护 RADIUS 流量）的比较。IPsec 是一种完全有效的方法，但它运行在不同的层级。您加密两个端点之间的所有流量，这增加了复杂性——您需要管理 IKE、隧道的预共享密钥或证书，以及维护跨数百个站点隧道状态的操作开销。RadSec 更具针对性。它专门加密 RADIUS 协议流量，运行在应用层，并直接与您的 RADIUS 基础设施集成。对于您将许多 NAS 设备在分布式场所连接到集中式云服务器的云 RADIUS 部署，RadSec 在架构上更清晰，操作上更简单。 让我带您了解多站点部署在实践中是什么样的。您有一个云 RADIUS 服务器——假设是 Purple 的平台——拥有来自受信任 CA 的有效 TLS 证书。您有三种场所类型：酒店物业、零售店和会议中心。每个都有 NAS 设备——接入点、交换机或无线 LAN 控制器。每个 NAS 设备都需要配置 RadSec 服务器地址、端口 2083 和客户端证书。NAS 发起 TLS 连接，相互握手完成，从那时起，该场所所有客人和员工的 802.1X 认证流量都加密流向云 RADIUS 服务器。如果 TLS 连接断开（例如由于网络中断），NAS 会自动重新建立它。这种持久连接模型实际上比 UDP 对高容量部署更有效，因为您避免了每个数据包的处理开销。 在防火墙方面，您需要允许从 NAS 管理网络到 RADIUS 服务器 IP 地址或 FQDN 的 TCP 端口 2083 出站流量。如果您运行严格的出口策略，您还需要允许返回流量。这比管理 IPsec 防火墙规则更简单，后者通常需要 ESP 协议例外以及 UDP 500 和 4500 上的 IKE。 实施建议与陷阱。 让我们谈谈 RadSec 部署中真正出错的地方，因为我在组织中看到了一些一致的故障模式。 第一个也是最常见的问题是证书链验证失败。您的 NAS 设备需要信任签署 RADIUS 服务器证书的 CA。如果您使用云 RADIUS 提供商，其证书来自知名的公共 CA——DigiCert、Let's Encrypt、Sectigo——大多数现代 NAS 设备开箱即会信任。但如果您使用内部 CA，则需要将 CA 证书推送到每个 NAS 设备。这在初始部署期间经常被忽视，表现为看似连接问题的 TLS 握手失败。 第二个陷阱是证书过期。与不会过期的共享秘密不同，证书有明确的有效期。如果您的 RADIUS 服务器证书过期，您设施中的每个 NAS 设备将同时无法认证。您需要证书生命周期管理——尽可能实现自动续期，并在到期前提前监控和报警。九十天通知是最低要求；三十天更好。 第三个问题是 NAS 设备兼容性。并非所有 NAS 设备都原生支持 RadSec。较旧的 Cisco IOS 版本、一些传统 Aruba 控制器和某些消费级接入点不支持 RadSec。在承诺 RadSec 部署之前，请审查您的 NAS 设备兼容性。Cisco IOS-XE 16.x 及更高版本、Aruba AOS-CX、Ruckus SmartZone 和 Juniper EX 系列都有坚实的 RadSec 支持。对于不支持原生 RadSec 的设备，一个 RadSec 代理——如开源选项 radsecproxy——可以弥合差距，接受来自传统设备的 UDP RADIUS，并通过 TLS 转发到云 RADIUS 服务器。 第四个考虑因素是连接持久性和 keepalives。RadSec 使用持久 TCP 连接，但具有激进超时策略的防火墙和 NAT 设备可能会静默丢弃空闲连接。在您的 RadSec 连接上配置 TCP keepalives——通常 60 秒的 keepalive 间隔足以防止提前连接终止。大多数 RADIUS 服务器实现和 NAS 设备都支持此配置。 对于 Cisco IOS-XE，RadSec 配置如下所示。您定义一个 RADIUS 服务器，地址为您的云 RADIUS 端点，指定 TLS 作为传输协议，引用您的信任点——即设备上的证书存储——并将目标端口设置为 2083。然后，您在 AAA 服务器组配置中引用此服务器。具体细节因平台版本而异，但逻辑结构在不同供应商之间是一致的。 对于运行 AOS 的 Aruba 控制器，您配置带有 RadSec 选项的 RADIUS 服务器，指定用于服务器验证的 CA 证书，并可选择配置用于相互 TLS 的客户端证书。Aruba 的实施是成熟且有良好文档的。 快速问答。 让我过一遍我常被问到的关于 RadSec 的问题。 RadSec 会增加延迟吗？TLS 握手在初始连接建立时增加少量开销——通常低于 100 毫秒。一旦连接建立，每个数据包的开销可以忽略不计。对于 802.1X 认证，握手每个会话发生一次，这不是一个重要的担忧。 我可以同时运行 RadSec 和传统 UDP RADIUS 吗？可以。大多数 RADIUS 服务器同时支持两者。在迁移期间，您可以为支持 RadSec 的站点运行 RadSec，并为传统站点回退到 UDP。这是推荐的迁移方法。 PCI DSS 合规需要 RadSec 吗？PCI DSS 版本 4.0 要求保护传输中的认证流量。RadSec 是满足基于 RADIUS 认证的这一要求的最直接方式之一。如果您在网络上处理信用卡支付并使用 RADIUS 认证，RadSec 应在您的合规路线图上。 RadSec 与 EAP 兼容吗？是的。EAP——可扩展认证协议——封装在 RADIUS 中，因此 EAP-TLS、PEAP、EAP-TTLS 都可以通过 RadSec 透明工作。EAP 交换本身不受影响。 RADIUS 计费呢？RFC 6614 涵盖认证和计费流量。您的计费数据——会话开始、停止和中间更新记录——也在端口 2083 上的同一 TLS 连接中加密。 总结与后续步骤。 综上所述：对于认证流量穿越您不完全控制的基础设施的任何部署，RadSec 都是 RADIUS 的正确传输层。这意味着云 RADIUS、多站点部署、SD-WAN 环境以及 RADIUS 流量穿越公共互联网或共享运营商基础设施的任何场景。 您团队的关键行动是：首先，审查您的 NAS 设备兼容性，识别任何需要代理的设备。其次，与您的云 RADIUS 提供商接触——或评估原生支持 RadSec 的提供商——了解他们的证书管理方法。第三，在上线前建立证书生命周期管理流程。第四，更新防火墙规则，允许从 NAS 管理网络出站的 TCP 2083。第五，在部署到生产环境之前，在暂存环境中测试您的 RadSec 配置，特别关注证书链验证和负载下的连接持久性。 对于在分布式场所运行 Purple 平台进行 Guest WiFi 和认证的组织，RadSec 是云 RADIUS 连接的推荐传输方式。它符合 Purple 的云原生架构，确保您的场所和平台之间流动的认证数据得到完全保护——这对您的安全态势和 GDPR 及 PCI DSS 合规义务都至关重要。 如果您正在计划部署或想讨论您的特定架构，Purple 团队是正确的起点。本期关于 RadSec 的 Purple 技术简报到此结束。感谢收听。