RadSec：RADIUS over TLS 如何提升 WiFi 認證安全性

RadSec: RADIUS over TLS 如何提升 WiFi 驗證安全性 Purple 企業級 WiFi 情報簡報 預估閱讀時間：10 分鐘 --- [引言與背景 — 約 1 分鐘] 歡迎收看 Purple 企業級 WiFi 情報系列。我是您的主持人，今天我們要探討一個處於網路安全與營運風險交會處的主題：RadSec - RFC 6614 中正式定義的協定 - 以及為什麼如果它還不在您的基礎架構藍圖中，現在就應該納入。 如果您是負責飯店集團、零售物業、體育場館或公共部門園區之企業級 WiFi 的 IT 經理、網路架構師或 CTO，本簡報就是為您準備的。我們將介紹 RadSec 的實際定義、傳統 RADIUS 協定讓您暴露於哪些風險中、如何在實際環境中部署 RadSec，以及會讓團隊踩雷的陷阱。不談空洞的理論 - 只提供您在本季做出決策所需的資訊。 讓我們開始吧。 --- [技術深挖 — 約 5 分鐘] 首先，讓我們從問題開始。RADIUS - 遠端驗證撥入使用者服務 - 自 1990 年代以來一直是企業級 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。它使用與 X.509 憑證的雙向 TLS 驗證，而非共享金鑰與 MD5。RADIUS 用戶端與 RADIUS 伺服器雙方都會出示憑證、驗證彼此的身分，並在交換任何驗證資料之前建立加密工作階段。TLS 1.3 是目前推薦的版本，可提供正向保密並消除一系列舊版密碼演算法的漏洞。 其實際效果顯著。憑證資料、使用者屬性與工作階段權杖在存取點 - 或 RadSec 代理伺服器 - 與 RADIUS 伺服器之間進行端對端加密。攔截網路上實體流量的攻擊者只能看到加密的 TLS 記錄。共享金鑰仍因相容性而存在，但它已不再執行任何實質的安全工作 - TLS 承擔了這項重任。 這裡還有另一個日益重要的維度：漫遊。Eduroam 聯盟（歐洲及其他地區的大學與研究機構所使用）多年來一直執行 RadSec，作為其機構間漫遊基礎架構的一部分。近期，Wi-Fi Alliance 的 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 憑證。這意味著需要一個憑證授權單位（CA）、為每個 RADIUS 用戶端和伺服器核發憑證，以及在過期前進行憑證輪替的程序。未被注意到的過期憑證會同時中斷網路上每位使用者的身分驗證 - 這是您希望避免發生的情況。請使用 ACME 或您 CA 的 API 來自動化憑證更新，並在過期日之前很久就設定好監控警報。 --- [實作建議與陷阱 - 約 2 分鐘] 讓我給您一些實用的建議。 第一：在部署前進行稽核。對環境中的每個 RADIUS 用戶端（存取點、VPN 集中器、執行 802.1X 的交換器）和每個 RADIUS 伺服器進行對應。瞭解哪些原生支援 RadSec，哪些需要代理。這項稽核通常會找出完全不支援 TLS 的舊型裝置，而這些裝置需要納入您的更換藍圖中。 第二：從風險最高的流量開始。如果您有傳輸於公用網際網路的 RADIUS 流量 - 遠端站台、雲端託管的 RADIUS、多物業連鎖飯店 - 那就是您的首要任務。在分割良好的管理 VLAN 上的本地 RADIUS 流量風險較低，但仍應納入規劃藍圖中。 第三：在正式上線前徹底測試雙向 TLS。RadSec 部署中最常見的失敗模式是憑證驗證錯誤 - 通用名稱（Common Names）不符、中繼憑證過期，或用戶端不信任簽署伺服器憑證的 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 - RADIUS over DTLS 呢？」RFC 7360 定義了 RADIUS over DTLS，它使用 UDP 而非 TCP，在增加加密的同時保留了傳統 RADIUS 的部分無連線特性。它的部署範圍不如 RadSec over TLS 廣泛，但如果高吞吐量環境中對延遲有所顧慮，則值得進行評估。 「這會如何影響漫遊效能？」RadSec 的 TCP 連線是持續性的，這在同盟環境中實際上可以透過減少後續驗證請求的連線建立開銷，進而改善漫遊效能。 --- [總結與後續步驟 — 約 1 分鐘] 總結來說：RadSec 是為了解決傳統 RADIUS 真正安全性漏洞的成熟且基於標準的解答。如果您正在大規模運行企業級 WiFi - 跨多個站點、透過網際網路，或是在受 PCI-DSS 或 GDPR 規範的環境中 - 問題不在於是否部署 RadSec，而是何時以及如何部署。 您的後續步驟：在本週稽核您的 RADIUS 基礎架構。識別您風險最高的流量。檢查您的 RADIUS 伺服器和基地台廠商說明文件以確認是否提供原生 RadSec 支援。如果您使用的是 FreeRADIUS，您可以在一天內運行測試用的 RadSec 部署。如果您使用的是 Microsoft NPS，請開始評估代理伺服器或移轉到支援 RadSec 的伺服器。 Purple 的平台旨在與企業級 RADIUS 基礎架構整合，為企業和訪客 WiFi 環境提供支援安全的驗證流程。如果您想了解 RadSec 如何融入您特定的部署中，Purple 團隊可以為您進行詳細說明。 感謝您的收聽。我們下次再見。 --- 腳本結束