RadSec：使用 TLS 保護 RADIUS 驗證流量

RadSec：使用 TLS 保護 RADIUS 驗證流量。Purple 技術簡報。 簡介與背景。 歡迎收聽 Purple 技術簡報。我將帶您了解 RadSec——基於 TLS 的 RADIUS——它是什麼、為何此刻重要，以及您如何實際部署它。這是專門針對網路架構師和安全工程師，他們可能正在運行雲端 RADIUS，或正計劃轉移。如果您仍然使用 UDP 和共享金鑰運行內部部署的 RADIUS 伺服器，本簡報適合您。 讓我們設定場景。RADIUS 三十年來一直是網路驗證的骨幹。它支撐著 802.1X、WPA2-Enterprise、WPA3-Enterprise，以及當今生產環境中幾乎所有 Captive Portal 系統。該協定本身定義於 RFC 2865，設計於一個網際網路截然不同的時代。您的 NAS 裝置（存取點、交換器和控制器）與 RADIUS 伺服器之間的驗證流量透過 UDP 傳輸，驗證使用連接埠 1812，計費使用連接埠 1813。而這些流量？大部分未加密。唯一的保護是使用共享金鑰來混淆使用者密碼屬性，即使如此，也存在著眾所周知的弱點。 多年來，這被認為是可接受的，因為 RADIUS 流量保持在私有、受控的網路上。您的 NAS 裝置和 RADIUS 伺服器位於相同的 LAN 上，或透過專用 MPLS 電路連接。攻擊面是可管理的。但世界已改變。雲端原生基礎設施、分散式據點部署、SD-WAN 覆蓋，以及向雲端 RADIUS 服務的轉移，已根本改變了威脅模型。您的驗證流量現在正在穿越公共網際網路，或充其量是您無法完全控制的共享基礎設施。這就是 RadSec 發揮作用的地方。 技術深入探討。 RadSec，正式定義於 RFC 6614，是基於 TLS 的 RADIUS。概念很直接：不是透過 UDP 發送 RADIUS 封包，而是將它們封裝在透過 TCP 的 TLS 連線中。結果是，您的 NAS 和 RADIUS 伺服器之間的所有驗證和計費流量都被完全加密、相互驗證且完整性受到保護。RFC 7360 將此擴展到 DTLS——基於 UDP 的資料包 TLS——它在添加加密的同時，保留了原始 UDP 傳輸的一些延遲特性。對於大多數企業部署，基於 TCP 的 TLS 是正確的選擇。在大型體育場部署等高吞吐量、延遲敏感的環境中，DTLS 值得考慮。 讓我們談談機制。RadSec 在 TCP 連接埠 2083 上運行，這是 IANA 為此協定分配的連接埠。當 NAS 裝置啟動 RadSec 連線時，它會向 RADIUS 伺服器的連接埠 2083 打開一個 TCP 連線，並執行 TLS 交握。此交握是相互的——用戶端（即您的 NAS）和伺服器都出示 X.509 憑證。伺服器的憑證會根據受信任的 CA 進行驗證。用戶端憑證則向 RADIUS 伺服器識別 NAS。一旦 TLS 工作階段建立，RADIUS 封包就會在該加密通道內流動，如同透過 UDP 一樣，但現在具有完整的機密性、完整性和重送防護。 這與傳統 RADIUS 有三個重要的不同點。首先，傳輸層是 TCP，而非 UDP。這意味著您獲得可靠、有序的傳遞。遺失的封包會自動重傳。其次，兩個端點的驗證是基於憑證，而非共享金鑰。這消除了基於弱或洩漏共享金鑰的整個攻擊類別。第三，整個 RADIUS 封包都被加密，而不僅僅是密碼屬性。這意味著使用者名稱、工作階段識別碼和所有 RADIUS 屬性在傳輸過程中都受到保護。 從憑證管理角度來看，您需要一個 PKI——公開金鑰基礎設施——來核發和管理 RADIUS 伺服器及 NAS 裝置的憑證。實務上，大多數雲端 RADIUS 提供者，包括 Purple 的雲端原生驗證基礎設施，會為您處理伺服器端的憑證管理。您的責任是為 NAS 裝置佈建用戶端憑證。對於大規模部署，這通常透過您的網路管理平台或專用憑證管理系統來處理。憑證應至少使用 RSA 2048 位元或 ECDSA P-256，有效期限應在營運負擔與安全衛生之間取得平衡——十二個月是合理的預設值。 現在，讓我們討論與許多組織今天使用的替代方法的比較：IPsec 通道或 VPN 覆蓋來保護 RADIUS 流量。IPsec 是一種完全有效的方法，但它運作在不同的層級。您正在加密兩個端點之間的所有流量，這增加了複雜性——您需要管理 IKE、通道本身的預共享金鑰或憑證，以及可能在數百個站點間維護通道狀態的營運負擔。RadSec 更具針對性。它專門加密 RADIUS 協定流量，在應用層運作，並直接與您的 RADIUS 基礎設施整合。對於雲端 RADIUS 部署，您需要將分散式據點的許多 NAS 裝置連接到集中式雲端伺服器，RadSec 在架構上更簡潔，營運上更簡單。 讓我帶您看看多據點部署在實務中的樣貌。您有一個雲端 RADIUS 伺服器——假設是 Purple 的平台——具有來自受信任 CA 的有效 TLS 憑證。您有三種場所類型：一家飯店物業、一家零售商店和一個會議中心。每個都有 NAS 裝置——存取點、交換器或無線 LAN 控制器。每個 NAS 裝置都需要設定 RadSec 伺服器位址、連接埠 2083 和用戶端憑證。NAS 啟動 TLS 連線，相互交握完成，從那時起，該場所的所有 802.1X 訪客和員工驗證流量都會加密流向雲端 RADIUS 伺服器。如果 TLS 連線中斷——例如，由於網路中斷——NAS 會自動重新建立。這種持久連線模式實際上比 UDP 更有效率，適用於高流量部署，因為您避免了每個封包的處理負擔。 在防火牆方面，您需要允許從 NAS 管理網路到 RADIUS 伺服器 IP 位址或 FQDN 的 TCP 連接埠 2083 出口流量。如果您執行嚴格的出口政策，您也會希望允許回傳流量。這比管理 IPsec 防火牆規則更簡單，後者通常需要例外允許 ESP 協定和 UDP 500 及 4500 上的 IKE。 實作建議與陷阱。 讓我們談談 RadSec 部署中實際出錯的地方，因為我在各組織中看到一些一致的失敗模式。 第一個也是最常見的問題是憑證鏈驗證失敗。您的 NAS 裝置需要信任簽署 RADIUS 伺服器憑證的 CA。如果您使用雲端 RADIUS 提供者，其憑證來自知名的公共 CA——DigiCert、Let's Encrypt、Sectigo——大多數現代 NAS 裝置會預設信任它。但如果您使用內部 CA，您需要將 CA 憑證推播到每個 NAS 裝置。這在初始部署期間經常被忽略，並以看似連線問題的 TLS 交握失敗呈現。 第二個陷阱是憑證到期。與不會到期的共享金鑰不同，憑證有定義的有效期限。如果您的 RADIUS 伺服器憑證到期，您環境中的每個 NAS 裝置都會同時無法驗證。您需要憑證生命週期管理——盡可能自動化續約，並在到期前提前監控與警報。九十天通知是最低限度；三十天更好。 第三個問題是 NAS 裝置相容性。並非所有 NAS 裝置都原生支援 RadSec。較舊的 Cisco IOS 版本、某些舊版 Aruba 控制器和某些消費級存取點不具備 RadSec 支援。在承諾部署 RadSec 之前，請稽核您的 NAS 環境的相容性。Cisco IOS-XE 16.x 及更高版本、Aruba AOS-CX、Ruckus SmartZone 和 Juniper EX 系列都有穩定的 RadSec 支援。對於不原生支援 RadSec 的裝置，一個 RadSec 代理——像是 radsecproxy 這樣的開源選項——可以橋接差距，接受來自舊版裝置的 UDP RADIUS，並透過 TLS 將其轉發到雲端 RADIUS 伺服器。 第四個考量是連線持久性和存活機制。RadSec 使用持久的 TCP 連線，但具有積極逾時政策的防火牆和 NAT 裝置可能會無聲地中斷閒置連線。在您的 RadSec 連線上設定 TCP 存活機制——通常六十秒的存活間隔足以防止連線過早拆除。大多數 RADIUS 伺服器實作和 NAS 裝置都支援此設定。 對於 Cisco IOS-XE，RadSec 設定如下所示。您定義一個 RADIUS 伺服器，位址為您的雲端 RADIUS 端點，指定 TLS 作為傳輸，參考您的信任點——這是裝置上的憑證存放區——並將目的地連接埠設為 2083。然後，您在 AAA 伺服器群組設定中引用此伺服器。具體語法因平台版本而異，但邏輯結構在各供應商間是一致的。 對於執行 AOS 的 Aruba 控制器，您設定 RADIUS 伺服器並啟用 RadSec 選項，指定用於伺服器驗證的 CA 憑證，並可選擇性地設定用於相互 TLS 的用戶端憑證。Aruba 的實作成熟且文件齊全。 快速問答。 讓我回答我最常被問到關於 RadSec 的問題。 RadSec 會增加延遲嗎？TLS 交握在初始連線建立時增加少量負擔——通常低於 100 毫秒。一旦連線建立，每個封包的負擔可以忽略不計。對於每個工作階段進行一次交握的 802.1X 驗證，這不是一個值得擔憂的問題。 我可以同時運行 RadSec 和傳統 UDP RADIUS 嗎？可以。大多數 RADIUS 伺服器同時支援兩者。在遷移過程中，您可以為支援 RadSec 的站點運行 RadSec，並為舊版站點回退到 UDP。這是建議的遷移方法。 RadSec 是 PCI DSS 合規所必需的嗎？PCI DSS 4.0 版本要求在傳輸過程中保護驗證流量。RadSec 是滿足此要求的最直接方式之一，適用於基於 RADIUS 的驗證。如果您在處理信用卡付款的網路上使用 RADIUS 驗證，RadSec 應列入您的合規路線圖。 RadSec 能與 EAP 一起使用嗎？可以。EAP——可延伸驗證協定——被封裝在 RADIUS 內，因此 EAP-TLS、PEAP、EAP-TTLS 都能在 RadSec 上透明地運行。EAP 交換本身不受影響。 RADIUS 計費呢？RFC 6614 涵蓋驗證和計費流量。您的計費資料——工作階段開始、停止和中期更新記錄——也會在連接埠 2083 的相同 TLS 連線上加密。 摘要與後續步驟。 總結來說：在驗證流量穿越您無法完全控制的基礎設施的任何部署中，RadSec 都是合適的傳輸層。這意味著雲端 RADIUS、多據點部署、SD-WAN 環境，以及 RADIUS 流量穿越公共網際網路或共享電信商基礎設施的任何情境。 您的團隊的關鍵行動是：首先，稽核您的 NAS 環境的 RadSec 相容性，並識別任何需要代理的裝置。其次，與您的雲端 RADIUS 提供者接洽——或評估原生支援 RadSec 的提供者——並了解他們的憑證管理方法。第三，在上線前建立憑證生命週期管理流程。第四，更新您的防火牆規則，允許從 NAS 管理網路出口 TCP 2083。第五，在推出至生產環境之前，在預備環境中測試您的 RadSec 設定，特別注意憑證鏈驗證和負載下的連線持久性。 對於在分散式據點運行 Purple 平台進行訪客 WiFi 和驗證的組織，RadSec 是雲端 RADIUS 連線的建議傳輸方式。它與 Purple 的雲端原生架構一致，確保在您的據點和平台之間流動的驗證資料受到完全保護——這對您的安全態勢和 GDPR 及 PCI DSS 下的合規義務都很重要。 如果您正在規劃部署或想討論您的特定架構，Purple 團隊是正確的起點。這是 Purple 關於 RadSec 的技術簡報。感謝收聽。