緩解 RADIUS 漏洞：安全強化指南
本指南為負責飯店、零售、活動和公共部門環境中企業 WiFi 基礎設施的 IT 經理、網路架構師和 CTO 提供全面且具體可行的參考。內容涵蓋 RADIUS 伺服器部署的完整攻擊面 — 從 MD5 碰撞漏洞和弱共享金鑰，到未加密的 UDP 傳輸和配置錯誤的 EAP 方法 — 並提供與 IEEE 802.1X、PCI DSS 和 GDPR 要求一致的優先強化路線圖。實施這些建議的組織將能實質減少面臨基於憑證的網路攻擊風險、滿足合規性義務，並為其訪客和企業 WiFi 基礎設施建立防禦性的安全態勢。
收聽此指南
查看播客逐字稿
執行摘要
RADIUS（遠端用戶撥入驗證服務）仍是企業 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 伺服器之間以用戶端-伺服器協定運作，後者負責對照 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 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 伺服器之間處於中間人 (Man-in-the-Middle) 位置 — 這可透過在共享網路區段上進行 ARP 欺騙、入侵路由器或具有網路存取權限的惡意內部人員來達成。
攻擊步驟如下：攻擊者攔截來自 NAS 的 Access-Request 封包。由於該封包缺少 Message-Authenticator 屬性（許多設定中的預設狀態），攻擊者便可自由修改封包的屬性列表。利用 MD5 選擇前綴碰撞 (Chosen-Prefix Collision)，攻擊者建構出一個修改後的封包，當 RADIUS 伺服器處理該封包時，會產生與原始封包相同的 Response Authenticator。因此，伺服器會針對包含攻擊者控制屬性的請求返回 Access-Accept — 其中包括 Administrative 的 Service-Type，這會授予完整的網路存取權限。
此攻擊對於內部方法使用 MSCHAPv2 的 PEAP 和 EAP-TTLS 部署非常有效。它不會影響 EAP-TLS 部署，因為基於憑證的雙向驗證提供了 MD5 無法破壞的完整性保護。
對於在企業 802.1X 旁運行 Guest WiFi 的組織，其訪客網路的 RADIUS 執行個體也必須進行修補，即使它使用的是 MAC 驗證繞過（MAB）而非 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 伺服器；由地端 NAS 裝置存取的雲端託管 RADIUS 服務；以及流量通過多個網路網域的 RADIUS 代理鏈。
針對每個識別出的路徑設定 RadSec。在 FreeRADIUS 上，這需要啟用連接埠 2083 上的 tls 接聽程式，並使用來自您 PKI 的憑證設定雙向 TLS。在 Cisco ISE 上，RadSec 是在「管理」>「網路裝置」下進行設定。請確保 TLS 1.2 為最低版本；明確停用 TLS 1.0 和 1.1。
階段 5：管理存取的 MFA（第 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 天 | 高 / 緊急 / 緊急 |
| 共用金鑰不相符錯誤 | 任何發生 | 高 |
最佳實踐
以下建議代表 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 伺服器，並採用主動-被動（active-passive）或主動-主動（active-active）配置。對於需要 24/7 全天候旅客連線需求的 旅宿業 部署而言，RADIUS 伺服器停機直接等同於旅客 WiFi 停機 — 這將帶來商譽與商業風險。
WPA3 與 802.1X。 WPA3-Enterprise 強制政府和高安全性部署使用 192 位元安全模式，要求使用 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 伺服器的憑證鏈 — 用戶端的 supplicant 是否信任發行該憑證的 CA？伺服器憑證是否在有效期內？解決方案：確保 RADIUS 伺服器上配置了完整的憑證鏈（分葉憑證 + 中介憑證 + 根憑證）。透過 MDM 或群組原則將根 CA 憑證推送到用戶端裝置。
RadSec TLS 握手失敗。 症狀：變更配置後，NAS 設備無法建立 RadSec 連線。診斷：檢查 TLS 版本相容性 — 較舊的 NAS 韌體可能不支援 TLS 1.2。檢查雙向憑證驗證 — 雙方必須信任彼此的 CA。解決方案：在 NAS 韌體版本說明中確認 TLS 版本支援情況；確保 NAS 設備憑證是由 RADIUS 伺服器所信任的同一 CA 所發行。
共用金鑰不符（Shared Secret Mismatch）。 症狀：來自特定 NAS 的所有驗證皆失敗，並顯示 "Invalid authenticator" 錯誤。診斷：NAS 設定與 RADIUS 伺服器用戶端項目之間的共用金鑰不符。解決方案：在雙邊重新輸入共用金鑰，確保沒有尾隨空格或字元編碼問題。建議從密碼管理器複製貼上，以避免手動輸入錯誤。
風險登記表
| 風險 | 可能性 | 影響 | 緩釋控制措施 |
|---|---|---|---|
| BlastRADIUS 漏洞利用 | 高（未修補） | 關鍵 | 修補程式 + 強制執行 Message-Authenticator |
| 共用金鑰暴力破解 | 中 | 高 | 32 字元隨機金鑰、年度輪替 |
| 惡意 RADIUS 伺服器 | 中 | 高 | EAP-TLS 雙向驗證、憑證固定（Certificate Pinning） |
| RADIUS 伺服器憑證過期 | 高 | 關鍵 | 自動化監控、90 天前警示 |
| 透過 802.1X 進行憑證填充攻擊 | 中 | 高 | 帳戶鎖定原則、SIEM 警示 |
| RADIUS 伺服器遭入侵 | 低 | 關鍵 | 管理員存取啟用多因素驗證（MFA）、網路隔離 |
投資報酬率（ROI）與業務影響
量化風險
若對照資料外洩成本，強化 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 萬英鎊的資料外洩基準成本，即使在外洩機率極低的預估下，經風險調整後的投資報酬率（ROI）依舊非常顯著。
安全性之外的營運效益
強化後的 RADIUS 基礎架構也能帶來營運效益。穩定且受到良好監控的驗證機制，能減少與 WiFi 連線相關的客服支援工單。當 RADIUS 計費數據與 WiFi Analytics 整合時，可提供網路使用模式、停留時間和裝置類型的會話級可視性 — 這些數據對於 Hospitality 和 Transport 環境的場域營運商而言，具有直接的商業價值。
對於公共部門和 Healthcare 機構，一份記錄完善的 RADIUS 強化計畫可為 Cyber Essentials Plus、ISO 27001 和 NHS DSPT 評估提供技術控制的證據 — 從而減少稽核開銷，並向監管機構證明已盡盡職調查職責。
關鍵定義
RADIUS (Remote Authentication Dial-In User Service)
RFC 2865 中定義的用戶端-伺服器協定，為網路存取提供集中式驗證、授權和計費 (AAA)。RADIUS 伺服器會根據 Active Directory 或 LDAP 等後端身分識別庫，驗證網路設備 (NAS) 提交的憑證。
IT 團隊在處理 802.1X WiFi、有線連接埠驗證、VPN 存取和網路設備管理時，會將 RADIUS 作為驗證後端。它是決定誰能存取網路的協定。
IEEE 802.1X
一種用於基於連接埠之網路存取控制的 IEEE 標準，定義了 LAN 上 EAP (EAPOL) 的封裝。它為有線和無線網路提供驗證框架，要求設備在獲得網路存取權限之前進行驗證。
802.1X 是讓企業級 WiFi 驗證運作的標準。當員工連接到企業 SSID 並被要求輸入憑證時，802.1X 就是協調該交換的框架，並以 RADIUS 作為後端。
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
一種 EAP 方法，使用 X.509 憑證在用戶端和 RADIUS 伺服器之間進行雙向驗證。雙方都必須出示有效的憑證，從而完全在驗證交換中免除密碼。
EAP-TLS 是企業級 WiFi 驗證的黃金標準。它能免疫憑證網路釣魚和暴力破解攻擊。營運上的要求是需要 PKI 架構來發行和管理用戶端憑證。
RadSec (RADIUS over TLS)
RFC 6614 中定義的協定，將 RADIUS 封包封裝在 TCP 連接埠 2083 上的 TLS 工作階段中。它為 RADIUS 流量提供傳輸層加密、雙向憑證驗證和重放攻擊防護。
任何跨越非信任網路邊界（WAN 連結、網際網路連線或共享網路基礎架構）的 RADIUS 流量都需要 RadSec。它是多站點部署中取代標準 UDP RADIUS 的正確方案。
BlastRADIUS (CVE-2024-3596)
2024 年 7 月披露的一種中間人攻擊，利用了 RADIUS Access-Request 封包上缺乏完整性保護的漏洞。攻擊者利用 MD5 選擇前綴碰撞技術，可以偽造 Access-Accept 回應，從而向未經驗證的使用者授予網路存取權限。
BlastRADIUS 影響所有主要的 RADIUS 實作，包括 FreeRADIUS、Cisco ISE 和 Microsoft NPS。未套用 2024 年 7 月發布之修補程式的組織仍暴露於此攻擊風險中。
Message-Authenticator
一種 RADIUS 屬性（屬性 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 更簡單，因為它不需要用戶端憑證。然而，如果未強制執行用戶端憑證驗證，它很容易受到惡意 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 設施中，透過連接 Wi-Fi 的 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 向每家分店的 NAS 裝置核發 TLS 憑證。更新防火牆規則，以允許從分店 NAS IP 範圍到 RADIUS 伺服器的 TCP 2083 流量。確認 RadSec 正常運作後，停用來自面向 WAN 介面的 UDP 1812/1813。步驟 4（第 2-3 個月）：針對 PCI DSS 範圍內的 POS Wi-Fi SSID，從 PEAP-MSCHAPv2 遷移至 EAP-TLS。部署內部 PKI（Microsoft ADCS 或 HashiCorp Vault PKI 引擎）。透過 MDM 向 POS 終端機核發用戶端憑證。更新 RADIUS 策略，要求 POS SSID 使用 EAP-TLS。步驟 5（第 3 個月）：將 RADIUS 帳務記錄整合至 SIEM 中。針對驗證失敗激增和憑證過期設定警示。
一家擁有 45 家門市的地區性零售連鎖店，員工 Wi-Fi 使用 WPA2-Personal（預共用金鑰），顧客 Wi-Fi 使用開放網路。IT 總監希望將員工 Wi-Fi 遷移至使用 Microsoft NPS 作為 RADIUS 伺服器的 802.1X 驗證，並與 Active Directory 整合。這些門市混合使用了 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) 用戶端 (Supplicant) 設定：透過群組原則（電腦設定 > 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。僅將其保留為備用 (break-glass) SSID，並將複雜的 PSK 儲存在金鑰管理器中，僅在 NPS 無法使用時使用。
練習題
Q1. 您的組織運行一台 FreeRADIUS 3.0.21 伺服器，為單一校區內的 800 台員工裝置提供 802.1X 驗證。該 RADIUS 伺服器與所有存取點（AP）處於同一個管理 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 missing」警告，這將指出漏掉韌體更新的 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 伺服器。共用金鑰（Shared secret）的衛生管理同樣適用——訪客 Captive Portal 控制器與 RADIUS 伺服器之間微弱的共用金鑰不論是否使用 EAP 都是可被利用的。關鍵的額外風險在於共用的 RADIUS 伺服器：如果訪客和企業 SSID 的驗證請求由同一個 RADIUS 伺服器程序處理，則訪客 RADIUS 路徑中的漏洞可能會被用作轉移到企業驗證原則的跳板。推薦的架構是為訪客和企業驗證運行獨立的 RADIUS 執行個體（或至少在 FreeRADIUS 內運行獨立的虛擬伺服器），並使用獨立的共用金鑰和獨立的原則集。這提供了隔離，使得訪客 RADIUS 路徑的入侵不會暴露企業憑證。具體針對訪客執行個體：修補 BlastRADIUS、輪替共用金鑰，並確保訪客 RADIUS 執行個體無法存取企業 Active Directory。EAP-TLS 和 RadSec 要求對於 Captive Portal 部署而言關聯性較低，但如果 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 提供了相關的部署背景。
繼續閱讀本系列
三大 SSID 搞定一切：訪客、員工與 IoT WiFi 設定指南
本權威技術參考指南提供實施三 SSID WiFi 架構的逐步藍圖。其中說明如何使用 Captive Portal、802.1X RADIUS 以及單一裝置預共用金鑰 (xPSK) 來區隔訪客、員工和 IoT 流量，以優化效能並確保符合 PCI DSS 規範。
CommScope Ruckus 與 Purple WiFi 整合：安裝與設定指南
本技術參考指南為 CommScope Ruckus 架構與 Purple WiFi 的整合提供了權威的設定指南。其中詳細介紹了使用 Guest WiFi Captive Portal、透過 802.1X 的安全員工 WiFi，以及使用 Ruckus Dynamic PSK 的多租戶網路隔離的逐步部署步驟。
Allied Telesis 基地台與 Purple WiFi 整合
本指南提供將 Allied Telesis TQ 系列基地台與 Purple WiFi 整合的完整設定指南。內容涵蓋外部 Captive Portal 重新導向、802.1X RADIUS 驗證，以及使用私有預共用金鑰 (PPSK) 進行動態 VLAN 導向，以實現安全的多租戶部署。