減輕 RADIUS 安全漏洞：安全防護強化指南
本指南為負責餐旅、零售、活動和公共部門環境中企業 WiFi 基礎架構的 IT 經理、網路架構師和 CTO 提供全面且實用的參考。內容涵蓋 RADIUS 伺服器部署的完整攻擊面 - 從 MD5 碰撞漏洞和弱共享金鑰，到未加密的 UDP 傳輸和錯誤配置的 EAP 方法 - 並提供符合 IEEE 802.1X、PCI DSS 和 GDPR 要求的優先防護強化路徑。實施這些建議的組織將能實質減少遭受基於憑證的網路攻擊，滿足合規性義務，並為其訪客和企業 WiFi 基礎架構建立防禦性的安全姿態。
收聽此指南
查看播客逐字稿
執行摘要
RADIUS (Remote Authentication Dial-In User Service) 仍然是企業 WiFi 部署中網路存取控制的主要協定，為飯店、零售場所、體育場、會議中心和公共部門建築的 IEEE 802.1X 驗證奠定了基礎。然而，RADIUS 的架構可以追溯到 1990 年代，其幾項基本設計決策 - 依賴 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 和工作階段中繼資料 - 均以明文形式傳輸。在 RFC 6614 中定義並於 RFC 7360 中更新的 RadSec（RADIUS over TLS），透過將 RADIUS 協定封裝在 TCP 連接埠 2083 的 TLS 通道中來解決此問題，建立 TLS 1.2 或 TLS 1.3 工作階段。RadSec 在 NAS 與 RADIUS 伺服器之間提供雙向憑證驗證、完整的承載資料加密和重放防護。它是所有跨越非信任網路邊界的 RADIUS 流量的正確傳輸方式。
EAP 方法選擇。 可延伸驗證協定（EAP）定義了在 802.1X 架構內使用的內部驗證方法。EAP-MD5 已被淘汰，應立即從所有部署中移除 - 它不提供雙向驗證，且無法抵禦憑證竊取攻擊。PEAP（受保護的 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 驗證繞過而非 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 設備韌體。Message-Authenticator 強制執行只有在 NAS 也傳送該屬性時才有效。請檢查您的存取點和交換器廠商公告 - Aruba、Ruckus、Cisco 和 Juniper 均已針對 BlastRADIUS 發佈了韌體更新。如果您正在運行 Ruckus 硬體， 無線存取點 Ruckus 指南 提供了相關的韌體管理背景資訊。
關於 排除修補後可能出現的 Windows 11 802.1X 驗證問題 ，最常見的原因是 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。
關於 保護訪客 WiFi 網路安全 ，請注意訪客網路通常使用 Captive Portal 驗證，而非 802.1X，因此 EAP 方法強化主要適用於企業和員工 SSID。
階段 4：RadSec 部署（第 2 - 3 個月）
識別跨越未信任網路邊界的所有 RADIUS 流量路徑。常見場景包括中央 RADIUS 伺服器透過網際網路為遠端飯店提供服務、本地 NAS 設備存取雲端 RADIUS 服務，以及流量穿越多個網路網域的 RADIUS 代理鏈。
針對識別出的每條路徑設定 RadSec。在 FreeRADIUS 上，這代表在連接埠 2083 上啟用 tls 監聽器，並使用來自 PKI 的憑證設定雙向 TLS。在 Cisco ISE 上，RadSec 是在 [管理] > [網路設備] 下進行設定。請確保至少使用 TLS 1.2，並明確停用 TLS 1.0 和 1.1。
階段 5：管理員存取的多因素驗證（第 2 - 3 個月）
RADIUS 伺服器的管理介面是高價值目標。攻擊者一旦入侵 RADIUS 伺服器，即可修改身分驗證原則、擷取共用密鑰並重導身分驗證流量。請針對所有 RADIUS 伺服器及其底層作業系統的管理員登入強制執行多因素驗證（MFA）。將管理存取權限限制在專用的頻外（out-of-band）管理 VLAN。實施角色型存取控制：網路工程師不應擁有與安全性管理員相同的權限。
第 6 階段：SIEM 整合與警示（第 3-4 個月）
設定您的 RADIUS 伺服器，將記帳記錄即時轉發至您的 SIEM。定義以下基準警示閾值：
| 警示 | 閾值 | 嚴重性 |
|---|---|---|
| 單一 MAC 位址發生多次身分驗證失敗 | 60 秒內 >5 次 | 高 |
| Access-Reject 率暴增 | 高於 7 天基準值的 200% | 中 |
| 公司 SSID 上出現來自新 MAC 位址的身分驗證 | 首次發生 | 中 |
| RADIUS 伺服器憑證即將到期 | 90 / 30 / 7 天 | 高 / 嚴重 / 嚴重 |
| 共用密鑰不符錯誤 | 任何發生 | 高 |
最佳實踐
以下建議綜合了 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 伺服器應位於專用的管理分段中，與訪客和一般公司網路隔離。存取 RADIUS 連接埠（UDP 1812、1813，以及用於 RadSec 的 TCP 2083）應透過防火牆 ACL 限制為已登冊 NAS 裝置的特定 IP 位址。不允許直接從網際網路存取 RADIUS 連接埠。
備援與高可用性。 單一 RADIUS 伺服器是您整個網路存取控制基礎架構的單一故障點。請在主動 - 被動或主動 - 主動設定中部署至少兩台 RADIUS 伺服器。對於有 24/7 訪客連線需求的 Hospitality 部署，RADIUS 伺服器停機將直接導致訪客 WiFi 停機 - 這是一項商譽與商業風險。WPA3 與 802.1X. 政府和高安全等級部署所需的 192 位元安全模式 WPA3-Enterprise，強制要求使用 AES-256-GCMP 進行資料加密，並使用 HMAC-SHA-384 進行身份驗證。對於大多數企業部署而言，採用標準 128 位元安全性的 WPA3-Enterprise 相比 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 是否受用戶端 supplicant 信任？伺服器憑證是否在有效期內？解決方案：確保 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 雙向認證、憑證固定 (Certificate Pinning) |
| RADIUS 伺服器憑證過期 | 高 | 關鍵 | 自動化監控、90 天前提前警示 |
| 透過 802.1X 的憑證填充攻擊 | 中 | 高 | 帳號鎖定原則、SIEM 警示 |
| RADIUS 伺服器入侵 | 低 | 關鍵 | 管理員存取雙重驗證 (MFA)、網路分段 |
投資報酬率與業務影響
量化風險
將 RADIUS 強化與防範資料外洩成本進行對比時，其財務合理性最為顯著。2024 年英國資料外洩的平均成本為 358 萬英鎊，其中包含監管罰鍰、補救措施、訴訟費用以及商譽損失。對於納入 PCI DSS 範圍的組織 - 實際上包括所有透過 WiFi 接受卡片支付的 零售 和 餐飲旅宿 業者 - 導致持卡人資料外洩的網路存取控制安全漏洞會引發強制性的法識鑑識調查、潛在的卡片組織罰鍰，以及可能暫停卡片交易處理權限。
對於 醫療保健 組織，若因 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 萬英鎊的資料外洩基準成本，即使在保守的資料外洩機率假設下，經風險調整後的投資報酬率也極具吸引力。
安全之外的營運效益
經強化的 RADIUS 基礎架構也能帶來營運上的紅利。穩定且受到良好監控的驗證機制可減少與 WiFi 連線相關的技術支援中心工單。當 RADIUS 計費資料與 WiFi 分析 整合時，可提供網路使用模式、停留時間和設備類型的階段級可視性 - 這些數據對於 餐飲旅宿 和 交通運輸 環境的場域營運商而言具有直接的商業價值。 針對公共部門與 醫療保健 機構，一份經文件記錄的 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 提供了相關的部署脈絡。
繼續閱讀本系列
Fortinet FortiAP 與訪客 WiFi：使用 Purple 設定 captive portal
了解在 FortiCloud 中管理的 Fortinet FortiAP 基地台如何透過外部 captive portal、RADIUS 和 walled garden 來與 Purple 訪客 WiFi 協同工作，無需更換您既有的設備。
Huawei iMaster NCE (CloudCampus) 與訪客 WiFi：使用 Purple 設定 captive portal
了解 Purple 的雲端訪客 WiFi 如何在透過 iMaster NCE 管理的 Huawei AirEngine 基地台上運作，利用 portal 驗證和 RADIUS relay，以及在哪裡可以找到確切的設定步驟。
HPE Aruba Captive Portal：搭配 Purple 訪客 WiFi 進行設定
在 HPE Aruba Instant 基地台上，透過 Aruba Central 或 Virtual Controller，使用外部 Captive Portal、RADIUS 與允許清單來設定 Purple 訪客 Captive Portal。