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 伺服器之間。存取點在本地網路上透過 UDP 將標準 RADIUS 傳送到代理伺服器。代理伺服器終止該連線，將 RADIUS 流量重新封裝在 TLS 隧道中，並透過 TCP 2083 將其轉發到上游 RADIUS 伺服器。這種方法允許您在不更換 RADIUS 伺服器的情況下將 RadSec 新增到現有基礎架構中，當您的 RADIUS 伺服器託管在雲端或透過公用網際網路存取時，它特別有用。 憑證管理是您需要規劃的營運複雜性。您需要一個 PKI（公開金鑰基礎建設）來核發和管理用於雙向 TLS 的 X.509 憑證。這意味著需要一個憑證授權單位、為每個 RADIUS 用戶端和伺服器核發憑證，以及在過期前進行憑證輪換的流程。未被注意到的過期憑證會同時中斷網路上每個使用者的認證——這是您想要避免的情況。使用 ACME 或您 CA 的 API 自動進行憑證更新，並在過期日期之前很久就設定監控警報。 --- [實施建議與陷阱 — 約 2 分鐘] 讓我給您一些實用的建議。 第一：在部署前進行審計。繪製您環境中的每個 RADIUS 用戶端（存取點、運行 802.1X 的 VPN 集中器、交換器）和每個 RADIUS 伺服器。了解哪些原生支援 RadSec，哪些需要代理伺服器。這種審計通常會暴露出完全不支援 TLS 的舊版裝置，這些裝置需要列入您的更換藍圖中。 第二：從風險最高的流量開始。如果您的 RADIUS 流量正在傳輸公用網際網路（遠端站點、雲端託管的 RADIUS、多物業飯店集團），那是您的首要任務。在隔離良好的管理 VLAN 上的本地 RADIUS 流量風險較低，但仍應列入藍圖中。 第三：在正式上線前徹底測試雙向 TLS。RadSec 部署中最常見的失敗模式是憑證驗證錯誤——通用名稱（Common Name）不匹配、中繼憑證過期，或用戶端不信任簽署伺服器憑證的 CA。在切換生產流量之前，使用 openssl s_client 測試 TLS 握手。 第四：不要忽視監控。RadSec 增加了傳統 RADIUS 所沒有的 TCP 連線層。TCP 連線失敗、TLS 握手逾時和憑證錯誤將表現為使用者的認證失敗。確保您的 RADIUS 伺服器日誌和代理伺服器日誌正傳輸到您的 SIEM 或監控平台，以便您可以區分 RadSec 連線問題與認證策略問題。 我最常看到的陷阱是組織在伺服器端部署了 RadSec，但忘記更新其防火牆規則。TCP 2083 需要在每個 RADIUS 用戶端與 RADIUS 伺服器或代理伺服器之間開啟。如果您習慣於管理 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 團隊可以引導您完成。 感謝您的收聽。我們下次再見。 --- 腳本結束