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 聯盟的 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 伺服器之間。存取點會透過本地網路上的 UDP 將標準 RADIUS 傳送至代理。代理會終止該連線，將 RADIUS 流量重新封裝至 TLS 通道內，並透過 TCP 2083 將其轉發至上游 RADIUS 伺服器。這種方法可讓您在不更換 RADIUS 伺服器的情況下將 RadSec 新增至現有的基礎架構中，當您的 RADIUS 伺服器代管於雲端或透過公開網際網路存取時，這點特別有用。 憑證管理是您需要規劃的營運複雜性。您需要一個 PKI - 公開金鑰基礎架構 - 來發行和管理用於雙向 TLS 的 X.509 憑證。這意味著需要憑證授權單位、為每個 RADIUS 用戶端和伺服器發行憑證，以及在過期前進行憑證輪替的流程。未被察覺而過期的憑證會同時中斷網路上每位使用者的驗證 - 這是您想要避免的情況。請使用 ACME 或您憑證授權單位的 API 來自動化憑證更新，並在過期日期前儘早設定監控警報。 [實作建議與陷阱 - 約 2 分鐘] 讓我給您一些實用的建議。 第一：在部署前進行稽核。規劃您環境中的每個 RADIUS 用戶端 - 存取點、VPN 集中器、執行 802.1X 的交換器 - 以及每個 RADIUS 伺服器。瞭解哪些原生支援 RadSec，哪些需要代理。這項稽核通常會顯現出完全不支援 TLS 的舊版裝置，而這些裝置需要列入您的汰換路線圖中。 第二：從風險最高的流量開始。如果您的 RADIUS 流量正在跨越公開網際網路 - 遠端站點、雲端代管的 RADIUS、多物業飯店集團 - 那就是您的首要任務。在分割良好的管理 VLAN 上的本地 RADIUS 流量風險較低，但它仍應列入路線圖中。 第三：在正式上線前徹底測試雙向 TLS。RadSec 部署中最常見的失敗模式是憑證驗證錯誤 - 通用名稱（Common Name）不符、中間憑證過期，或用戶端不信任簽署伺服器憑證的憑證授權單位。在切換生產流量之前，請使用 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 是保護存取點（access point）與 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 團隊可以為您進行詳細引導。 感謝您的收聽。我們下次見。 --- 腳本結束