減輕 RADIUS 安全漏洞：安全防護強化指南
本指南為負責餐旅、零售、活動和公共部門環境中企業 WiFi 基礎架構的 IT 經理、網路架構師和 CTO 提供全面且實用的參考。內容涵蓋 RADIUS 伺服器部署的完整攻擊面 - 從 MD5 碰撞漏洞和弱共享金鑰，到未加密的 UDP 傳輸和錯誤配置的 EAP 方法 - 並提供符合 IEEE 802.1X、PCI DSS 和 GDPR 要求的優先防護強化路徑。實施這些建議的組織將能實質減少遭受基於憑證的網路攻擊，滿足合規性義務，並為其訪客和企業 WiFi 基礎架構建立防禦性的安全姿態。
收聽此指南
查看播客逐字稿
核心系列的一部分：Enterprise WiFi Security Guide →
执行摘要
RADIUS (Remote Authentication Dial-In User Service) 仍然是企业 WiFi 部署中网络准入控制的主要协议，支持酒店、零售场所、体育场馆、会议中心和公共部门建筑的 802.1X 认证。然而，RADIUS 的架构可以追溯到 20 世纪 90 年代，其若干基础设计决策 - 依赖 MD5 哈希、无原生加密的 UDP 传输以及静态共享密钥 - 在当前威胁环境中已成为重大风险。
在 2024 年 7 月，BlastRADIUS 漏洞 (CVE-2024-3596) 表明，中间人攻击者可以通过利用 Access-Request 数据包中的 MD5 完整性漏洞，伪造 RADIUS Access-Accept 响应。该漏洞影响所有主要的 RADIUS 实现，包括 FreeRADIUS、Cisco ISE 和 Microsoft NPS。未打补丁的部署仍处于风险中。
本指南提供了一个优先的加固路线图，涵盖补丁管理、共享密钥卫生、EAP 方法选择、RadSec 部署、用于管理访问的多因素认证以及用于异常检测的 SIEM 集成。它是为需要在本季度（而非明年）做出可靠决策的 IT 专业人员编写的。
技术深度剖析
RADIUS 如何工作以及其薄弱环节
RADIUS 在网络接入服务器 (NAS) - 通常是 WiFi 接入点、交换机或 VPN 集中器 - 与 RADIUS 服务器之间作为客户端 - 服务器协议运行，RADIUS 服务器根据后端身份存储（如 Active Directory 或 LDAP）验证凭证。认证交换遵循 RFC 2865 中定义的请求 - 挑战 - 响应模型，计费则在 RFC 2866 下单独处理。
该协议通过 UDP 传输认证数据包，使用端口 1812 进行认证，端口 1813 进行计费。共享密钥 - 在 NAS 和 RADIUS 服务器上配置的预共享密钥 - 用于生成 Response Authenticator 字段，并通过基于 MD5 的 XOR 密码加密 User-Password 属性。这在任何现代意义上都不是加密；这完全取决于共享密钥的保密性和强度的混淆。
典型 RADIUS 部署中的五个主要漏洞类别如下。
MD5 碰撞和完整性漏洞。 BlastRADIUS 攻击 (CVE-2024-3596) 利用了 Access-Request 数据包缺乏完整性保护这一漏洞。由于许多配置默认不包含来自 NAS 的 Message-Authenticator 属性，处于中间人位置的攻击者可以在数据包到达 RADIUS 服务器之前注入精心构造的属性。利用 MD5 选择前缀碰撞技术，攻击者可以操纵数据包，使 RADIUS 服务器为修改后的数据包计算出有效的 Response Authenticator，从而对本应被拒绝的请求返回 Access-Accept。补救措施是在所有 Access-Request 数据包上强制执行 Message-Authenticator 属性，这可在整个数据包上提供 HMAC-MD5 完整性保护。这需要在 NAS 和 RADIUS 服务器上都进行配置更改，而不仅仅是服务器补丁。
弱或静态共享密钥。 共享密钥是 RADIUS 交换的加密锚点。如果密钥很短、可预测或从未轮换，捕获 RADIUS 流量的攻击者 (通过 ARP 欺骗或受损的网络设备即可实现) 就可以离线暴力破解 User-Password 属性。NIST SP 800-63B 关于记住的密钥指南在此处适用：密钥应至少为 20 个字符、随机生成，并存储在密钥管理系统中。对于拥有数十或数百万台 NAS 设备的大型网络，手动轮换在操作上是不可行的；通过 HashiCorp Vault 或类似的密钥管理器进行自动化才是正确的方法。
未加密的 UDP 传输。 基于 UDP 的标准 RADIUS 不提供传输层机密性。User-Password 属性被混淆但未加密。其他所有属性 - 包括用户名、NAS IP 和会话元数据 - 都以明文形式传输。RadSec (RADIUS over TLS) 在 RFC 6614 中定义并在 RFC 7360 中更新，它通过在 TCP 端口 2083 上的 TLS 隧道中包装 RADIUS 协议，建立 TLS 1.2 或 TLS 1.3 会话来解决此问题。RadSec 在 NAS 和 RADIUS 服务器之间提供双向证书认证、全载荷加密和防重放保护。它是任何跨越非受信网络边界的 RADIUS 流量的正确传输方式。
EAP 方法选择。 可扩展身份验证协议 (EAP) 定义了在 802.1X 框架内使用的内部身份验证方法。EAP-MD5 已弃用，应立即从所有部署中移除 - 它不提供双向认证，也不提供对凭据收集攻击的抵御能力。PEAP (Protected EAP) 和 EAP-TTLS 在传输凭据之前使用服务器证书建立 TLS 隧道，提供双向认证并保护内部方法免受窃听。EAP-TLS 完全消除了密码，要求在服务器和客户端上都使用 X.509 证书。它对网络钓鱼和暴力破解攻击具有免疫力，是高安全环境的推荐方法。 日志记录和监控不足。 RADIUS 计费记录了每一次认证事件 - 成功、失败、会话开始、会话结束。这些数据在运营上对于容量规划非常宝贵，在商业上对于 WiFi Analytics 也极具价值，同时它也是安全遥测的关键来源。失败认证风暴、来自未知 MAC 地址的认证以及非工作时间访问模式，都可以从 RADIUS 计费日志中检测出来。大多数组织并未将这些数据引入 SIEM，而引入了这些数据的组织也极少配置任何告警阈值。
BlastRADIUS 攻击细节
BlastRADIUS 于 2024 年 7 月由波士顿大学和加州大学圣地亚哥分校的研究人员披露。该攻击需要在 NAS 和 RADIUS 服务器之间处于中间人位置 - 可通过共享网络段上的 ARP 欺骗、受损的路由器或具有网络访问权限的恶意内部人员来实现。
攻击过程如下：攻击者拦截来自 NAS 的 Access-Request 数据包。由于该数据包缺少 Message-Authenticator 属性（许多配置中的默认设置），攻击者可以自由修改该数据包的属性列表。利用 MD5 选择前缀冲突，攻击者构建了一个修改后的数据包，RADIUS 服务器将为其计算与原始数据包相同的 Response Authenticator。因此，服务器针对包含攻击者控制的属性的请求返回 Access-Accept - 其中包括授权完全网络访问的 Administrative Service-Type。
该攻击对使用 MSCHAPv2 作为内部方法的 PEAP 和 EAP-TTLS 部署有效。它不影响 EAP-TLS 部署，因为基于证书的双向认证提供了 MD5 无法破坏的完整性保护。
对于同时运行 Guest WiFi 和企业级 802.1X 的组织，访客网络的 RADIUS 实例也必须进行补丁修复，即使它使用的是 MAC Authentication Bypass 而不是 EAP。共享密钥安全规范和 Message-Authenticator 要求同样适用。
实施指南
阶段 1：立即补救（第 1 - 2 周）
补丁修复是第一步。FreeRADIUS 3.2.5 和 3.0.27 包含了 BlastRADIUS 修复程序，并默认强制执行 Message-Authenticator。Cisco ISE 3.1 Patch 8、3.2 Patch 4 和 3.3 Patch 1 解决了该漏洞。Microsoft 于 2024 年 7 月发布了针对 Windows Server 2022 NPS 的 KB5040434。请验证您当前的版本，并在下一个计划的变更窗口内应用这些补丁。
同时，审计您的 NAS 设备固件。只有当 NAS 也发送该属性时，Message-Authenticator 强制执行才会生效。检查您的接入点和交换机供应商公告 - Aruba、Ruckus、Cisco 和 Juniper 均已针对 BlastRADIUS 发布了固件更新。如果您正在运行 Ruckus 硬件， wireless access point Ruckus guide 提供了相关的固件管理背景信息。
关于解决打补丁后可能出现的 troubleshooting Windows 11 802.1X authentication issues ，最常见的原因是 NPS 服务器拒绝不包含 Message-Authenticator 的客户端连接 - 这是正确的安全行为，可能需要对较旧的 Windows 客户端进行 supplicant 重新配置。
第 2 阶段：共享密钥卫生（第 2 - 4 周）
导出注册在 RADIUS 服务器上的完整 NAS 客户端列表。记录每个条目的共享密钥长度以及上次更改的日期。任何低于 20 个字符或超过 24 个月未更改的密钥都应立即轮换。
对于新密钥，请使用密码学随机生成器 - openssl rand -base64 32 可生成一个 44 字符的 base64 字符串，非常适合用作 RADIUS 共享密钥。将所有密钥存储在密钥管理系统中。实施轮换计划：低风险 NAS 设备每年轮换一次，处于 PCI DSS 范围内的 NAS 设备每六个月轮换一次。
第 3 阶段：EAP 方法合理化（第 1 - 2 个月）
审计您的 RADIUS 服务器允许的 EAP 方法。禁用 EAP-MD5。如果您正在运行 PEAP-MSCHAPv2，请验证所有 supplicant 是否都强制执行服务器证书验证 - 接受任何服务器证书的配置错误的 supplicant 容易受到流氓 RADIUS 服务器攻击。对于处于 PCI DSS 范围内的环境，推荐使用 EAP-TLS。如果您目前没有现成的证书基础设施，请开始 PKI 规划。
对于 securing guest WiFi networks，请注意访客网络通常使用 Captive Portal 认证而非 802.1X，因此 EAP 方法加固主要适用于企业和员工 SSID。
第 4 阶段：RadSec 部署（第 2 - 3 个月）
识别跨越不信任网络边界的每个 RADIUS 流量路径。常见场景包括通过互联网为远程酒店提供服务的中央 RADIUS 服务器；连接到云 RADIUS 服务的本地 NAS 设备；以及流量穿过多个网络域的 RADIUS 代理链。
针对每个识别出的路径配置 RadSec。在 FreeRADIUS 上，这意味着启用端口 2083 上的 tls 监听器，并使用来自您 PKI 的证书配置双向 TLS。在 Cisco ISE 上，RadSec 在 Administration > Network Devices 下进行配置。确保至少使用 TLS 1.2；明确禁用 TLS 1.0 和 1.1。
第 5 阶段：管理访问的多因素身份验证（第 2 - 3 个月）
RADIUS 服务器的管理界面是一个高价值的目标。攻击者如果攻破 RADIUS 服务器，就可以修改身份验证策略、提取共享密钥并重定向身份验证流量。对所有 RADIUS 服务器及其底层操作系统的管理员登录强制执行 MFA。将管理访问限制在专用的带外管理 VLAN。实施基于角色的访问控制：网络工程师不应拥有与安全管理员相同的权限。
阶段 6：SIEM 集成与告警（第 3 - 4 个月）
配置您的 RADIUS 服务器，将计费日志实时转发到您的 SIEM。定义以下基线告警阈值：
| 告警 | 阈值 | 严重级别 |
|---|---|---|
| 单个 MAC 地址多次身份验证失败 | 60 秒内 >5 次 | 高 |
| 访问拒绝（Access-Reject）率激增 | 超过 7 天基线的 200% | 中 |
| 企业 SSID 上来自新 MAC 地址的身份验证 | 首次出现 | 中 |
| RADIUS 服务器证书即将过期 | 90 / 30 / 7 天 | 高 / 紧急 / 紧急 |
| 共享密钥不匹配错误 | 任何一次出现 | 高 |
對於您的特定設置有任何疑問嗎？
我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話，我們將向您展示其他與您相似的用戶是如何解決此問題的。
最佳实践
以下建议综合了 IEEE 802.1X、NIST SP 800-63B、PCI-DSS v4.0 以及厂商安全公告的共识。
证书管理。 任何使用 EAP-TLS 或 RadSec 的部署在其身份验证路径中都有 X.509 证书。在企业 WiFi 部署中，证书过期是导致突然、完全身份验证失败的最常见单一原因。实施自动化的证书生命周期管理。在过期前 90、30 和 7 天设置监控告警。对于 RADIUS 服务器证书，请使用至少 2048 位 RSA 或 256 位 ECDSA 密钥，以及 SHA-256 或更强的签名算法。请勿使用 SHA-1。
网络分段。 RADIUS 服务器应位于专用的管理网段，与访客和常规企业网络隔离。应通过防火墙 ACL 将对 RADIUS 端口（RadSec 的 UDP 1812、1813 和 TCP 2083）的访问限制在已注册 NAS 设备的特定 IP 地址。不允许从互联网直接访问 RADIUS 端口。
冗余和高可用性。 单个 RADIUS 服务器是您整个网络访问控制基础设施的单点故障。以主备（active-passive）或双活（active-active）配置部署至少两个 RADIUS 服务器。对于有 24/7 访客连接需求的 酒店 部署，RADIUS 服务器停机将直接转化为访客 WiFi 停机 - 这是一种声誉和商业风险。WPA3 和 802.1X。 WPA3-Enterprise 采用 192 位安全模式，是政府和高安全性部署的必备要求，其强制使用 AES-256-GCMP 进行数据加密，并使用 HMAC-SHA-384 进行身份验证。对于大多数企业部署而言，WPA3-Enterprise 结合标准 128 位安全保护，相较于 WPA2-Enterprise 已经有了显著的提升，尤其是在与 EAP-TLS 结合使用时。处理卡片支付的 零售 环境应将采用 WPA3-Enterprise 视为一项降低 PCI-DSS 风险的措施。
厂商补丁节奏。 订阅来自您的 RADIUS 服务器厂商和 NAS 设备厂商的安全公告。FreeRADIUS、Cisco、Microsoft、Aruba 和 Ruckus 都会发布 CVE 通知。将这些信息输入到您的漏洞管理程序中，并定义明确的 SLA：严重漏洞 (CVSS ≥ 9.0) 在 72 小时内修复；高危漏洞 (CVSS 7.0 - 8.9) 在 14 天内修复。
故障排查与风险缓解
常见故障模式
打补丁后身份验证失败。 在应用 BlastRADIUS 补丁后，如果某些 NAS 设备的固件不支持 Message-Authenticator，可能会导致身份验证失败。症状：Access-Reject 响应突然增加，而用户凭据没有发生变化。诊断：启用 RADIUS 调试日志，并检查是否存在 "Message-Authenticator required but not present"（需要 Message-Authenticator 但不存在）的错误。解决方法：更新 NAS 固件，或作为临时措施，在计划固件更新期间，将 RADIUS 服务器配置为接受来自特定 NAS IP 且不带 Message-Authenticator 的请求。
EAP-TLS 中的证书验证失败。 症状：客户端收到 "authentication failed"（身份验证失败）提示，但 RADIUS 日志中没有相应的 Access-Reject。诊断：检查 RADIUS 服务器的证书链 - 颁发 CA 是否受客户端请求者信任？服务器证书是否在有效期内？解决方法：确保在 RADIUS 服务器上配置了完整的证书链（叶证书 + 中间证书 + 根证书）。通过 MDM 或组策略将根 CA 证书推送到客户端设备。
RadSec TLS 握手失败。 症状：配置更改后，NAS 设备无法建立 RadSec 连接。诊断：检查 TLS 版本兼容性 - 较旧的 NAS 固件可能不支持 TLS 1.2。检查双向证书验证 - 双方必须信任彼此的 CA。解决方法：在 NAS 固件发布说明中验证 TLS 版本支持情况；确保 NAS 设备证书由 RADIUS 服务器信任的同一 CA 颁发。
共享密钥不匹配。 症状：来自某一特定 NAS 的每次身份验证都失败，并出现 "invalid authenticator"（无效验证器）错误。诊断：NAS 配置与 RADIUS 服务器的客户端条目之间的共享密钥不匹配。解决方法：在两端重新输入共享密钥，检查是否存在尾随空格或字符编码问题。从您的密钥管理器中复制并粘贴，以避免誊录错误。
风险登记表
| 风险 | 可能性 | 影响 | 缓解控制措施 |
|---|---|---|---|
| BlastRADIUS 漏洞利用 | 高（若未修补） | 严重 | 修补程序 + 强制执行 Message-Authenticator |
| 共享密钥暴力破解 | 中 | 高 | 32 位随机字符密钥，每年轮换 |
| 恶意 RADIUS 服务器 | 中 | 高 | EAP-TLS 双向身份验证，证书绑定 |
| RADIUS 服务器证书过期 | 高 | 严重 | 自动监控，提前 90 天告警 |
| 通过 802.1X 的凭据填充攻击 | 中 | 高 | 账户锁定策略，SIEM 告警 |
| RADIUS 服务器入侵 | 低 | 严重 | 管理员访问 MFA，网络隔离 |
投资回报率（ROI）与业务影响
量化风险
在考量数据泄露成本时，RADIUS 加固的经济合理性最为清晰。2024 年英国数据泄露的平均成本为 358 万英镑，其中包括监管罚款、补救措施、法律费用和声誉损失。对于在 PCI-DSS 范围内的组织 - 实际上包括每一个通过 WiFi 接受刷卡支付的 Retail 和 Hospitality 运营商 - 暴露持卡人数据的网络访问控制泄露将引发强制性取证调查、潜在的卡计划罚款以及可能暂停刷卡处理权限。
对于 Healthcare 组织，通过受损的 RADIUS 服务器访问患者数据而导致违反 GDPR，根据第 83(5) 条规定，将面临最高达全球年营业额 4% 的罚款。ICO 的执法记录表明，网络安全漏洞被视为疏忽，而非技术上的不幸。
实施成本基准
以下成本估算基于拥有 500 台设备的网络：
| 加固活动 | 估算成本 | 时间线 |
|---|---|---|
| 修补程序（FreeRADIUS / NPS / ISE） | 仅限内部人工 | 1 - 2 周 |
| 共享密钥审计和轮换 | 内部人工 + 密钥管理器许可证（约 2,000 英镑/年） | 2 - 4 周 |
| EAP-TLS PKI 部署 | 15,000 - 30,000 英镑（工具 + 专业服务） | 2 - 3 个月 |
| RadSec 实施 | 内部人工 + 证书成本（约 1,500 英镑） | 4 - 6 周 |
| SIEM 集成与告警 | 取决于现有 SIEM；0 - 10,000 英镑 | 4 - 8 周 |
中型企业的总加固投资约为 20,000 - 45,000 英镑。相比 358 万英镑的泄露成本基准，即使在保守的泄露概率假设下，经风险调整后的 ROI 仍然非常引人瞩目。
安全之外的运营效益
加固后的 RADIUS 基础设施还能带来运营红利。可靠、监控良好的身份验证可减少与 WiFi 连接相关的服务台工单。当 RADIUS 计费数据与 WiFi Analytics 集成时，可提供有关网络使用模式、停留时间和设备类型的会话级可视化 - 这些数据对于 Hospitality 和 Transport 环境中的场所运营商具有直接的商业价值。
对于公共部门和 医疗保健 组织，一份记录在案的 RADIUS 加固计划为 Cyber Essentials Plus、ISO 27001 和 NHS DSPT 评估提供了技术控制证据 - 从而减少了审计工作量，并向监管机构展示了尽职调查。
關鍵定義
RADIUS (Remote Authentication Dial-In User Service)
RFC 2865 中定義的用戶端伺服器協定，為網路存取提供集中驗證、授權和帳務 (AAA)。RADIUS 伺服器會根據 Active Directory 或 LDAP 等後端身分識別儲存庫，驗證網路裝置 (NAS) 提交的認證。
IT 團隊會遇到 RADIUS 作為 802.1X WiFi、有線連接埠驗證、VPN 存取和網路裝置管理的驗證後端。它是決定誰可以進入網路的協定。
IEEE 802.1X
用於基於連接埠之網路存取控制的 IEEE 標準，定義了 LAN 上 EAP (EAPOL) 的封裝。它為有線和無線網路提供驗證框架，要求裝置在獲得網路存取權限之前先進行驗證。
802.1X 是讓企業 WiFi 驗證發揮作用的標準。當員工連接到企業 SSID 並被要求輸入認證時，802.1X 就是協調該交換的框架，並以 RADIUS 作為後端。
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
一種使用 X.509 憑證在用戶端與 RADIUS 伺服器之間進行雙向驗證的 EAP 方法。雙方都必須出示有效的憑證，從而完全消除驗證交換過程中的密碼。
EAP-TLS 是企業級 WiFi 驗證的黃金標準。它對憑證網路釣魚與暴力破解攻擊具有免疫力。其運作要求是需要有 PKI 基礎架構來發行和管理用戶端憑證。
RadSec (RADIUS over TLS)
RFC 6614 中定義的一種協定，透過 TCP 連接埠 2083 將 RADIUS 封包封裝在 TLS 工作階段中。它為 RADIUS 流量提供傳輸層加密、雙向憑證驗證和重放攻擊保護。
任何跨越不可信網路邊界（例如 WAN 鏈路、網際網路連線或共享網路基礎架構）的 RADIUS 流量都需要 RadSec。它是多站點部署中替代標準 RADIUS over UDP 的正確解決方案。
BlastRADIUS (CVE-2024-3596)
一項於 2024 年 7 月披露的中間人攻擊，它利用了 RADIUS Access-Request 封包缺乏完整性保護的漏洞。攻擊者可以使用 MD5 選擇前綴碰撞技術偽造 Access-Accept 回應，從而向未經驗證的使用者授予網路存取權限。
BlastRADIUS 影響所有主要的 RADIUS 實作，包括 FreeRADIUS、Cisco ISE 和 Microsoft NPS。尚未套用 2024 年 7 月發布之修補程式的組織仍暴露於此攻擊風險中。
Message-Authenticator
一個 RADIUS 屬性（Attribute 80），可對整個 RADIUS 封包提供 HMAC-MD5 完整性保護。當它存在於 Access-Request 中時，可防止在 BlastRADIUS 中使用的封包竄改攻擊。
在所有 Access-Request 封包上強制執行 Message-Authenticator 是修復 BlastRADIUS 的主要方法。必須同時在 RADIUS 伺服器（要求此屬性）和 NAS 裝置（在請求中包含此屬性）上進行設定。
NAS (Network Access Server)
在 RADIUS 術語中，NAS 是指網路裝置 - 通常是 WiFi 存取點、交換器或 VPN 集中器 - 作為 RADIUS 用戶端。它攔截來自終端裝置的連線請求，並將驗證請求轉發至 RADIUS 伺服器。
NAS 裝置是部署中的 RADIUS 用戶端。共享金鑰是針對每個 NAS 進行設定。修復 BlastRADIUS 需要更新 NAS 裝置上的韌體以及 RADIUS 伺服器上的修補程式。
PEAP (Protected Extensible Authentication Protocol)
一種 EAP 方法，在傳輸內部驗證方法（通常為 MSCHAPv2）之前，使用伺服器端憑證建立 TLS 通道。它提供雙向驗證，並防止認證資訊被竊聽。
PEAP-MSCHAPv2 是部署最廣泛的企業級 WiFi 驗證方法。它符合 PCI DSS 標準，且因不需要用戶端憑證而在運作上比 EAP-TLS 更簡單。然而，如果不強制執行用戶端憑證驗證，它很容易受到 Rogue RADIUS 伺服器攻擊。
Shared Secret
在 RADIUS 伺服器和每個 NAS 裝置上設定的預先共享金鑰。它用於產生 Response Authenticator 欄位並混淆 User-Password 屬性。它不是終端使用者的密碼 - 而是伺服器對伺服器的驗證認證資訊。
弱共享金鑰或靜態共享金鑰是最常見的 RADIUS 安全漏洞之一。擷取 RADIUS 流量的攻擊者可以對弱共享金鑰進行離線暴力破解攻擊。建議的最小長度為 32 個字元，且應隨機產生。
PCI DSS (Payment Card Industry Data Security Standard)
由主要卡片計畫（Visa、Mastercard、Amex）針對處理、儲存或傳輸持卡人資料之組織所強制執行的安全標準。2024 年 3 月生效的 4.0 版本包含對網路存取控制和強驗證的特定要求。
擁有 WiFi 連線 POS 終端機的零售和旅宿組織皆在 PCI DSS 的範圍內。可能導致未授權網路存取持卡人資料環境的 RADIUS 伺服器漏洞是直接的合規風險。
範例
一家擁有 12 家分店、共 350 間客房的飯店集團，在其總部資料中心託管了一台集中式 RADIUS 伺服器。每家分店皆透過共享的 MPLS WAN 進行連線。安全審計指出，跨 WAN 的 RADIUS 流量未加密，共享金鑰為五年前首次部署時設定的 8 字元字串，且 RADIUS 伺服器執行的是 FreeRADIUS 3.0.21。該集團在其餐廳和 SPA 設施中，透過連接 WiFi 的 POS 終端機處理刷卡付費。其修復優先級和實施順序為何？
修復順序應依風險嚴重程度和實施速度進行排序。步驟 1（立即，72 小時內）：將 FreeRADIUS 修補至 3.2.5 或 3.0.27。這能解決 BlastRADIUS 漏洞，並預設強制執行 Message-Authenticator。同時，檢查所有 12 家分店的無線基地台韌體版本，並為任何不支援 Message-Authenticator 的 NAS 設備安排韌體更新。步驟 2（第 1 - 2 週）：輪換所有共享金鑰。使用 openssl rand -base64 32 為 12 家分店的 NAS 註冊分別產生 32 字元的隨機金鑰。將其儲存在 HashiCorp Vault 或同等工具中，並記錄輪換日期。步驟 3（第 1 - 2 個月）：在 WAN 路徑上實施 RadSec。將 FreeRADIUS 伺服器配置為接受 TCP 2083 上的 RadSec 連線。從內部 CA 核發 TLS 憑證給每家分店的 NAS 設備。更新防火牆規則，以允許從分店 NAS IP 範圍到 RADIUS 伺服器的 TCP 2083 連線。確認 RadSec 正常運作後，停用來自面向 WAN 介面的 UDP 1812/1813。步驟 4（第 2 - 3 個月）：針對 PCI DSS 範圍內的 POS WiFi SSID，從 PEAP-MSCHAPv2 遷移至 EAP-TLS。部署內部 PKI（Microsoft ADCS 或 HashiCorp Vault PKI 引擎）。透過 MDM 核發用戶端憑證給 POS 終端機。更新 RADIUS 策略，要求 POS SSID 使用 EAP-TLS。步驟 5（第 3 個月）：將 RADIUS 記帳記錄整合至 SIEM。針對驗證失敗激增和憑證過期配置警示。
一家擁有 45 家門市的區域零售連鎖店，其員工 WiFi 使用 WPA2-Personal（預共用金鑰），並為顧客 WiFi 提供開放式網路。IT 總監希望將員工 WiFi 遷移至 802.1X 驗證，並使用與 Active Directory 整合的 Microsoft NPS 作為 RADIUS 伺服器。門市混用了 Aruba 與 Cisco 存取點。該連鎖店屬於 PCI DSS 範圍。他們應該部署什麼架構？關鍵的設定決策有哪些？
推薦的架構是使用 PEAP-MSCHAPv2 作為初始 EAP 方法的 802.1X，並制定遷移至 EAP-TLS 的已記錄藍圖。NPS 伺服器應在中央資料中心部署為備援對（主 + 備），並在存取點上設定 RADIUS 代理，以便自動進行容錯移轉。設定決策：(1) NPS 網路原則：建立一項與員工 SSID 相符的原則，使用 PEAP-MSCHAPv2，並要求具備 AD 安全性群組（例如「WiFi-Staff-Access」）的成員資格。將工作階段逾時設定為 8 小時，以強制重新驗證。(2) 憑證：從內部 Microsoft ADCS CA 部署 NPS 伺服器憑證。透過群組原則 (Windows) 和 MDM (iOS/Android) 將根 CA 憑證推送到所有員工裝置。(3) 請求方設定：透過群組原則（電腦設定 > Windows 設定 > 安全性設定 > 無線網路原則）設定 Windows 裝置。對於 iOS 和 Android 裝置，使用 MDM 設定檔。強制執行伺服器憑證驗證 - 不允許使用者接受任意憑證。(4) 存取點設定：在 Aruba 上，於 Authentication > Servers 下設定 RADIUS 伺服器。將共用秘密設定為 32 個字元的隨機字串。如果 Aruba 韌體支援（AOS 8.9+），請啟用 RadSec。在 Cisco 上，於 Security > AAA > RADIUS 下進行設定。(5) NPS 記錄：啟用將 NPS 帳務記錄寫入 SQL Server 資料庫。設定至少 90 天的記錄保留期，以符合 PCI DSS 合規性。(6) 遷移後：停用員工 SSID 上的 WPA2-Personal。僅保留其作為緊急備用 SSID，並在秘密管理器中儲存複雜的 PSK，僅在 NPS 無法使用時使用。
練習題
Q1. 您的組織執行一台 FreeRADIUS 3.0.21 伺服器，為單一校園內 800 台員工設備提供 802.1X 驗證。該 RADIUS 伺服器與所有存取點位於同一個管理 VLAN 上。滲透測試發現存取點在發送 Access-Request 封包時未包含 Message-Authenticator 屬性。安全團隊希望立即強制執行 Message-Authenticator，但網路營運團隊擔心會中斷這 800 名使用者的驗證。您該如何安排修補順序以將服務中斷降至最低？
提示：請考慮 RADIUS 伺服器要求 Message-Authenticator 與 NAS 設備發送該屬性之間的差異。這是兩個具有不同風險特徵的獨立設定變更。
查看標準答案
正確的順序是：(1) 首先，將 FreeRADIUS 升級至 3.2.5 版本。此版本預設強制執行 Message-Authenticator，但包含相容模式，只會記錄警告而不會直接拒絕缺少該屬性的封包。這樣一來，您就能在不立即中斷驗證的情況下完成修補。(2) 稽核存取點韌體版本。確認哪些型號和韌體版本支援在 Access-Request 封包中發送 Message-Authenticator。(3) 分批更新存取點韌體，先從 50 台設備的試點群組開始。在每批更新後驗證驗證功能是否持續正常運作。(4) 確認所有存取點均已發送 Message-Authenticator 後，在 FreeRADIUS 伺服器上啟用嚴格強制執行（在 clients.conf 中設定 require_message_authenticator = yes）。(5) 監控 RADIUS 記錄，查看是否仍有任何「Message-Authenticator 遺失」的警告，這代表有 NAS 設備漏掉了韌體更新。關鍵原則在於，您可以先修補伺服器而不會造成任何中斷，因為相容模式提供了一個過渡期。在伺服器上強制執行嚴格拒絕應該是最後一個步驟，必須在所有 NAS 設備都更新完畢後進行。
Q2. 一家會議中心營運商執行單一 RADIUS 伺服器，同時支援企業員工 SSID（使用 PEAP-MSCHAPv2 的 802.1X）和活動訪客 WiFi（使用 MAC Authentication Bypass 的 Captive Portal）。IT 經理詢問，鑑於訪客並非使用企業憑證進行驗證，訪客 WiFi 的 RADIUS 執行個體是否需要強化到與企業 RADIUS 執行個體相同的標準？您的建議是什麼？
提示：請考慮適用於 MAC Authentication Bypass 與基於 EAP 驗證的攻擊媒介，以及在訪客與企業 RADIUS 執行個體之間橫向移動的風險。
查看標準答案
訪客 WiFi RADIUS 執行個體需要進行強化，但具體控制措施與企業執行個體不同。BlastRADIUS 補丁同樣適用 - 無論用戶端使用何種身分驗證方法，該漏洞都會影響 RADIUS 伺服器。共享金鑰安全性同樣適用 - 訪客 Captive Portal 控制器與 RADIUS 伺服器之間弱共享金鑰不論是否使用 EAP 均可被利用。關鍵的額外風險是共享 RADIUS 伺服器：如果訪客和企業 SSID 身分驗證請求由同一個 RADIUS 伺服器處理程序處理，則訪客 RADIUS 路徑中的漏洞可用於轉移到企業身分驗證策略。建議的架構是為訪客和企業身分驗證執行個別的 RADIUS 執行個體 (或至少在 FreeRADIUS 內執行個別的虛擬伺服器)，並使用個別的共享金鑰和個別的策略集。這提供了隔離，使得訪客 RADIUS 路徑受損不會暴露企業憑證。特別是針對訪客執行個體：修補 BlastRADIUS、輪替共享金鑰，並確保訪客 RADIUS 執行個體無權存取企業 Active Directory。對於 Captive Portal 部署，EAP-TLS 和 RadSec 要求較不相關，但如果 Captive Portal 控制器與 RADIUS 伺服器位於不同的網路區段中，仍應考慮 RadSec。
Q3. 某個醫療保健信託機構計劃將其臨床 WiFi 從 WPA2-Personal 遷移到 802.1X 身分驗證。該信託機構擁有 1,200 台臨床設備，包括 Windows 筆記型電腦、iOS 平板電腦和 Android 手持設備。CISO 希望將 EAP-TLS 作為目標狀態。IT 總監擔心 PKI 部署的複雜性，並建議將 PEAP-MSCHAPv2 作為永久解決方案。您如何向 CISO 和 IT 總監提出建議，推薦的實施路徑是什麼？
提示：考慮醫療保健環境的特定威脅模型 - 憑證受損的後果是什麼？EAP-TLS 如何解決 PEAP-MSCHAPv2 無法解決的風險？
查看標準答案
CISO 的直覺是正確的，但 IT 總監的擔憂也是合理的。建議的方案是：現在先實施 PEAP-MSCHAPv2 作為過渡方案，並承諾在 12 個月內過渡到 EAP-TLS。在醫療保健領域不接受 PEAP-MSCHAPv2 作為永久解決方案的理由是：(1) 如果不強制執行用戶端憑證驗證，PEAP-MSCHAPv2 容易受到惡意 RADIUS 伺服器攻擊。在醫療人員可能會連接個人設備的醫療保健環境中，在 1,200 台設備上一致地強制執行 Supplicant 設定在營運上具有挑戰性。(2) 如果透過惡意 RADIUS 攻擊捕獲 MSCHAPv2 憑證，可以使用 hashcat 等工具進行離線破解。在醫療保健環境中，這些憑證可能也提供了臨床系統的存取權限。(3) NHS DSPT 和 CQC 評估越來越期望對臨床網路存取實施強大的身分驗證控制。EAP-TLS 提供了更強大的審計證據地位。實施路徑：第 1-2 個月：透過 MDM 設定檔在所有 1,200 台設備上部署強制執行伺服器憑證驗證的 PEAP-MSCHAPv2。第 3-6 個月：部署 Microsoft ADCS 作為 PKI 基礎架構。透過群組原則自動註冊 Windows 設備。第 6-9 個月：透過 MDM 憑證設定檔註冊 iOS 和 Android 設備。第 9-12 個月：將臨床 SSID 策略從 PEAP 遷移到 EAP-TLS。保留 PEAP 作為憑證註冊失敗的任何設備的後備方案，並加強監控。如需進一步了解臨床網路安全架構， WiFi in Hospitals guide 提供了相關的部署脈絡。
繼續閱讀本系列
當員工離職時如何撤銷 WiFi 存取權限
本指南向 IT 和場域營運團隊展示如何在員工離職時移除其員工 WiFi 存取權限，同時不影響其他員工的正常工作。本指南比較了基於憑證的 802.1X、身分專屬的 iPSK 和 SCIM 驅動的停用流程，並提供當天執行的工作手冊、測試方法和稽核憑證模型。
網路管理員指南：如何為訪客 WiFi 設定 RADIUS 驗證
為網路管理員提供部署訪客 WiFi RADIUS 驗證的全面技術參考。涵蓋架構、不限廠商的設定步驟、安全最佳實作，以及常見部署失敗的疑難排解。
安全 BYOD WiFi：Passpoint 憑證註冊對比 xPSK (iPSK)
針對 IT 團隊的全面技術指南，說明如何使用免設定的 Passpoint EAP-TLS 憑證與特定廠商的 xPSK (iPSK/easyPSK、DPSK、PPSK、MPSK) 來保護未託管的員工與學生裝置 (BYOD)。
對於您的特定設置有任何疑問嗎？
我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話，我們將向您展示其他與您相似的用戶是如何解決此問題的。