RadSec: Absicherung des RADIUS-Authentifizierungsverkehrs mit TLS

RadSec: Absicherung des RADIUS-Authentifizierungsverkehrs mit TLS. Ein technisches Briefing von Purple. Einführung und Kontext. Willkommen zu diesem technischen Briefing von Purple. Ich werde Sie durch RadSec – RADIUS über TLS – führen: was es ist, warum es gerade jetzt wichtig ist und wie Sie es tatsächlich bereitstellen. Dies richtet sich direkt an Netzwerkarchitekten und Sicherheitsingenieure, die entweder bereits Cloud-RADIUS nutzen oder planen, dorthin zu wechseln. Wenn Sie immer noch On-Premise-RADIUS-Server mit UDP und einem Shared Secret betreiben, ist dieses Briefing genau das Richtige für Sie. Lassen Sie uns die Ausgangslage betrachten. RADIUS ist seit über dreißig Jahren das Rückgrat der Netzwerkauthentifizierung. Es bildet die Grundlage für 802.1X, WPA2-Enterprise, WPA3-Enterprise und praktisch jedes Captive Portal-System, das heute im Einsatz ist. Das Protokoll selbst, definiert in RFC 2865, wurde in einer Ära entwickelt, in der das Internet noch ein ganz anderer Ort war. Der Authentifizierungsverkehr zwischen Ihren NAS-Geräten – Ihren Access Points, Switches und Controllern – und Ihrem RADIUS-Server lief über UDP, Port 1812 für die Authentifizierung, Port 1813 für das Accounting. Und dieser Verkehr? Größtenteils unverschlüsselt. Der einzige Schutz war ein Shared Secret, das zur Verschleierung des Benutzerpasswort-Attributs verwendet wurde, und selbst das weist bekannte Schwachstellen auf. Jahrelang war dies akzeptabel, da der RADIUS-Verkehr in privaten, kontrollierten Netzwerken verblieb. Ihre NAS-Geräte und Ihr RADIUS-Server befanden sich im selben LAN oder waren über eine dedizierte MPLS-Leitung verbunden. Die Angriffsfläche war überschaubar. Aber die Welt hat sich verändert. Cloud-native Infrastrukturen, verteilte Standorte, SD-WAN-Overlays und der Wechsel zu Cloud-RADIUS-Diensten haben das Bedrohungsmodell grundlegend verändert. Ihr Authentifizierungsverkehr durchquert nun das öffentliche Internet oder bestenfalls eine gemeinsam genutzte Infrastruktur, die Sie nicht vollständig kontrollieren. Genau hier kommt RadSec ins Spiel. Technischer Deep-Dive. RadSec, formal definiert in RFC 6614, ist RADIUS über TLS. Das Konzept ist einfach: Anstatt RADIUS-Pakete über UDP zu senden, kapseln Sie diese in einer TLS-Verbindung über TCP. Das Ergebnis ist, dass der gesamte Authentifizierungs- und Accounting-Verkehr zwischen Ihrem NAS und Ihrem RADIUS-Server vollständig verschlüsselt, gegenseitig authentifiziert und vor Manipulationen geschützt ist. RFC 7360 erweitert dies auf DTLS – Datagram TLS über UDP –, wodurch einige der Latenzeigenschaften des ursprünglichen UDP-Transports beibehalten und gleichzeitig eine Verschlüsselung hinzugefügt wird. Für die meisten Unternehmensbereitstellungen ist TLS über TCP die richtige Wahl. DTLS ist in Umgebungen mit hohem Durchsatz und hoher Latenzempfindlichkeit wie großen Stadion-Bereitstellungen eine Überlegung wert. Lassen Sie uns über die Funktionsweise sprechen. RadSec läuft auf dem TCP-Port 2083, dem von der IANA für dieses Protokoll zugewiesenen Port. Wenn ein NAS-Gerät eine RadSec-Verbindung initiiert, öffnet es eine TCP-Verbindung zum RADIUS-Server auf Port 2083 und führt einen TLS-Handshake durch. Dieser Handshake erfolgt gegenseitig (mutual) – sowohl der Client, also Ihr NAS, als auch der Server präsentieren X.509-Zertifikate. Das Zertifikat des Servers wird mit einer vertrauenswürdigen CA abgeglichen. Das Client-Zertifikat identifiziert das NAS gegenüber dem RADIUS-Server. Sobald die TLS-Sitzung etabliert ist, fließen die RADIUS-Pakete innerhalb dieses verschlüsselten Tunnels genau so, wie sie es über UDP tun würden, jedoch jetzt mit vollständiger Vertraulichkeit, Integrität und Schutz vor Replay-Angriffen. Dies unterscheidet sich in drei wichtigen Punkten erheblich vom herkömmlichen RADIUS. Erstens ist das Transportprotokoll TCP und nicht UDP. Das bedeutet, dass Sie eine zuverlässige, geordnete Zustellung erhalten. Verlorene Pakete werden automatisch erneut gesendet. Zweitens basiert die Authentifizierung beider Endpunkte auf Zertifikaten und nicht auf Shared Secrets. Dadurch wird eine ganze Klasse von Angriffen eliminiert, die auf schwachen oder kompromittierten Shared Secrets beruhen. Drittens wird das gesamte RADIUS-Paket verschlüsselt, nicht nur das Passwort-Attribut. Das bedeutet, dass Benutzernamen, Sitzungs-IDs und alle RADIUS-Attribute während der Übertragung geschützt sind. Aus Sicht der Zertifikatsverwaltung benötigen Sie eine PKI – eine Public Key Infrastructure –, um Zertifikate sowohl für Ihren RADIUS-Server als auch für Ihre NAS-Geräte auszustellen und zu verwalten. In der Praxis übernehmen die meisten Cloud-RADIUS-Anbieter, einschließlich der Cloud-nativen Authentifizierungsinfrastruktur von Purple, die serverseitige Zertifikatsverwaltung für Sie. Ihre Aufgabe besteht darin, Client-Zertifikate auf Ihren NAS-Geräten bereitzustellen. Bei großen Bereitstellungen wird dies in der Regel über Ihre Netzwerkmanagement-Plattform oder ein dediziertes Zertifikatsverwaltungssystem abgewickelt. Zertifikate sollten mindestens RSA 2048-Bit oder ECDSA P-256 verwenden, mit einer Gültigkeitsdauer, die den betrieblichen Aufwand mit der Sicherheitshygiene in Einklang bringt – zwölf Monate sind ein sinnvoller Standard. Lassen Sie uns nun den Vergleich mit dem alternativen Ansatz ziehen, den viele Unternehmen heute nutzen: IPsec-Tunnel oder VPN-Overlays zum Schutz des RADIUS-Verkehrs. IPsec ist ein absolut valider Ansatz, arbeitet jedoch auf einer anderen Ebene. Sie verschlüsseln den gesamten Datenverkehr zwischen zwei Endpunkten, was die Komplexität erhöht – Sie müssen IKE, Pre-Shared Keys oder Zertifikate für den Tunnel selbst verwalten, und der betriebliche Aufwand für die Aufrechterhaltung des Tunnelstatus über potenziell Hunderte von Standorten hinweg ist hoch. RadSec ist zielgerichteter. Es verschlüsselt speziell den RADIUS-Protokollverkehr, arbeitet auf der Anwendungsebene und lässt sich direkt in Ihre RADIUS-Infrastruktur integrieren. Für Cloud-RADIUS-Bereitstellungen, bei denen Sie viele NAS-Geräte an verteilten Standorten mit einem zentralen Cloud-Server verbinden, ist RadSec architektonisch sauberer und betrieblich einfacher. Ich möchte Ihnen zeigen, wie eine Multi-Site-Bereitstellung in der Praxis aussieht. Sie haben einen Cloud-RADIUS-Server – sagen wir, die Plattform von Purple – mit einem gültigen TLS-Zertifikat einer vertrauenswürdigen CA. Sie haben drei Standorttypen: ein Hotel, ein Einzelhandelsgeschäft und ein Konferenzzentrum. Jedes verfügt über NAS-Geräte – Access Points, Switches oder Wireless-LAN-Controller. Jedes NAS-Gerät muss mit der RadSec-Serveradresse, Port 2083 und einem Client-Zertifikat konfiguriert werden. Das NAS initiiert die TLS-Verbindung, der gegenseitige Handshake wird abgeschlossen, und ab diesem Zeitpunkt fließt der gesamte 802.1X-Authentifizierungsverkehr für Gäste und Mitarbeiter an diesem Standort verschlüsselt zum Cloud-RADIUS-Server. Wenn die TLS-Verbindung abbricht – beispielsweise aufgrund einer Netzwerkunterbrechung –, baut das NAS sie automatisch wieder auf. Dieses persistente Verbindungsmodell ist bei hohem Datenaufkommen tatsächlich effizienter als UDP, da der Overhead der Verarbeitung pro Paket entfällt. Auf der Firewall-Seite müssen Sie ausgehenden TCP-Verkehr auf Port 2083 von Ihrem NAS-Managementnetzwerk zur IP-Adresse oder zum FQDN Ihres RADIUS-Servers zulassen. Wenn Sie eine strenge Egress-Richtlinie anwenden, müssen Sie auch den Rückverkehr zulassen. Dies ist einfacher als die Verwaltung von IPsec-Firewall-Regeln, die oft ESP-Protokollausnahmen und IKE auf UDP 500 und 4500 erfordern. Implementierungsempfehlungen und Fallstricke. Lassen Sie uns darüber sprechen, was bei RadSec-Bereitstellungen tatsächlich schiefgehen kann, denn es gibt einige typische Fehlermuster, die ich in Unternehmen immer wieder sehe. Das erste und häufigste Problem sind Fehler bei der Validierung der Zertifikatskette. Ihr NAS-Gerät muss der CA vertrauen, die das Zertifikat des RADIUS-Servers signiert hat. Wenn Sie einen Cloud-RADIUS-Anbieter mit einem Zertifikat einer bekannten öffentlichen CA – DigiCert, Let's Encrypt, Sectigo – verwenden, vertrauen die meisten modernen NAS-Geräte diesem standardmäßig. Wenn Sie jedoch eine interne CA verwenden, müssen Sie das CA-Zertifikat auf jedes NAS-Gerät übertragen. Dies wird bei der Erstbereitstellung oft übersehen und äußert sich dann in TLS-Handshake-Fehlern, die wie Verbindungsprobleme aussehen. Der zweite Fallstrick ist der Ablauf von Zertifikaten. Im Gegensatz zu Shared Secrets, die nicht ablaufen, haben Zertifikate eine definierte Gültigkeitsdauer. Wenn das Zertifikat Ihres RADIUS-Servers abläuft, schlägt die Authentifizierung auf jedem NAS-Gerät in Ihrer Infrastruktur gleichzeitig fehl. Sie benötigen ein Zertifikats-Lifecycle-Management – eine automatisierte Verlängerung, wo immer möglich, sowie eine Überwachung mit Warnmeldungen lange vor dem Ablaufdatum. Eine Vorankündigung von 90 Tagen ist das Minimum; 30 Tage sind besser. Das dritte Problem ist die Kompatibilität der NAS-Geräte. Nicht alle NAS-Geräte unterstützen RadSec nativ. Ältere Cisco IOS-Versionen, einige veraltete Aruba-Controller und bestimmte Consumer-Access-Points bieten keine RadSec-Unterstützung. Bevor Sie sich für eine RadSec-Bereitstellung entscheiden, sollten Sie Ihre NAS-Infrastruktur auf Kompatibilität prüfen. Cisco IOS-XE 16.x und neuer, Aruba AOS-CX, Ruckus SmartZone und die Juniper EX-Serie bieten alle eine solide RadSec-Unterstützung. Für Geräte, die RadSec nicht nativ unterstützen, kann ein RadSec-Proxy – eine Open-Source-Option wie radsecproxy – die Lücke schließen, indem er UDP-RADIUS von veralteten Geräten empfängt und über TLS an den Cloud-RADIUS-Server weiterleitet. Der vierte Aspekt sind Verbindungspersistenz und Keepalives. RadSec nutzt persistente TCP-Verbindungen, aber Firewalls und NAT-Geräte mit aggressiven Timeout-Richtlinien können inaktive Verbindungen unbemerkt trennen. Konfigurieren Sie TCP-Keepalives für Ihre RadSec-Verbindungen – in der Regel reicht ein Keepalive-Intervall von 60 Sekunden aus, um einen vorzeitigen Verbindungsabbau zu verhindern. Die meisten RADIUS-Server-Implementierungen und NAS-Geräte unterstützen diese Konfiguration. Für Cisco IOS-XE sieht die RadSec-Konfiguration wie folgt aus. Sie definieren einen RADIUS-Server mit der address Ihres Cloud-RADIUS-Endpunkts, geben TLS als Transportprotokoll an, verweisen auf Ihren Trustpoint – also den Zertifikatsspeicher auf dem Gerät – und setzen den Zielport auf 2083. Anschließend verweisen Sie in Ihrer AAA-Servergruppenkonfiguration auf diesen Server. Die Details variieren je nach Plattformversion, aber die logische Struktur ist herstellerübergreifend konsistent. Für Aruba-Controller mit AOS konfigurieren Sie den RADIUS-Server mit aktivierter RadSec-Option, geben das CA-Zertifikat für die Servervalidierung an und konfigurieren optional ein Client-Zertifikat für Mutual TLS. Die Implementierung von Aruba ist ausgereift und gut dokumentiert. Schnelle Fragen und Antworten. Lassen Sie uns die Fragen durchgehen, die mir zu RadSec am häufigsten gestellt werden. Erzeugt RadSec zusätzliche Latenz? Der TLS-Handshake verursacht beim ersten Verbindungsaufbau einen geringen Overhead – in der Regel unter 100 Millisekunden. Sobald die Verbindung steht, ist der Overhead pro Paket vernachlässigbar. Für die 802.1X-Authentifizierung, bei der der Handshake einmal pro Sitzung stattfindet, ist dies kein nennenswertes Problem. Kann ich RadSec parallel zu herkömmlichem UDP-RADIUS betreiben? Ja. Die meisten RADIUS-Server unterstützen beides gleichzeitig. Während einer Migration können Sie RadSec für Standorte ausführen, die es unterstützen, und für veraltete Standorte auf UDP zurückgreifen. Dies ist der empfohlene Migrationsansatz. Ist RadSec für die PCI-DSS-Compliance erforderlich? PCI DSS Version 4.0 verlangt, dass der Authentifizierungsverkehr während der Übertragung geschützt wird. RadSec ist einer der direktesten Wege, um diese Anforderung für eine RADIUS-basierte Authentifizierung zu erfüllen. Wenn Sie Kartenzahlungen über ein Netzwerk abwickeln, das RADIUS-Authentifizierung nutzt, sollte RadSec auf Ihrer Compliance-Roadmap stehen. Funktioniert RadSec mit EAP? Ja. EAP – Extensible Authentication Protocol – wird in RADIUS gekapselt, sodass EAP-TLS, PEAP und EAP-TTLS alle transparent über RadSec funktionieren. Der EAP-Austausch selbst bleibt davon unberührt. Wie sieht es mit RADIUS-Accounting aus? RFC 6614 deckt sowohl den Authentifizierungs- als auch den Accounting-Verkehr ab. Ihre Accounting-Daten – Sitzungsstart, -stopp und Zwischenaktualisierungen – werden ebenfalls über dieselbe TLS-Verbindung auf Port 2083 verschlüsselt. Zusammenfassung und nächste Schritte. Zusammenfassend lässt sich sagen: RadSec is die richtige Transportschicht für RADIUS in jeder Bereitstellung, bei der der Authentifizierungsverkehr über eine Infrastruktur läuft, die Sie nicht vollständig kontrollieren. Das betrifft Cloud-RADIUS, Multi-Site-Bereitstellungen, SD-WAN-Umgebungen und jedes Szenario, in dem der RADIUS-Verkehr das öffentliche Internet oder eine gemeinsam genutzte Carrier-Infrastruktur durchquert. Die wichtigsten Maßnahmen für Ihr Team sind: Erstens, prüfen Sie Ihre NAS-Infrastruktur auf RadSec-Kompatibilität und identifizieren Sie alle Geräte, die einen Proxy benötigen. Zweitens, sprechen Sie mit Ihrem Cloud-RADIUS-Anbieter – oder evaluieren Sie Anbieter, die RadSec nativ unterstützen – und machen Sie sich mit deren Ansatz zur Zertifikatsverwaltung vertraut. Drittens, etablieren Sie vor dem Go-Live einen Prozess für das Zertifikats-Lifecycle-Management. Viertens, aktualisieren Sie Ihre Firewall-Regeln, um ausgehenden TCP-Verkehr auf Port 2083 aus Ihrem NAS-Managementnetzwerk zuzulassen. Fünftens, testen Sie Ihre RadSec-Konfiguration in einer Staging-Umgebung, bevor Sie sie in der Produktion einführen, und achten Sie dabei besonders auf die Validierung der Zertifikatskette und die Verbindungspersistenz unter Last. Für Unternehmen, die die Plattform von Purple für Gäste-WiFi und die Authentifizierung an verteilten Standorten nutzen, ist RadSec der empfohlene Transportweg für die Cloud-RADIUS-Anbindung. Es fügt sich nahtlos in die Cloud-native Architektur von Purple ein und stellt sicher, dass die zwischen Ihren Standorten und der Plattform fließenden Authentifizierungsdaten vollständig geschützt sind – was sowohl für Ihre Sicherheitslage als auch für Ihre Compliance-Verpflichtungen gemäß GDPR und PCI DSS von Bedeutung ist. Wenn Sie eine Bereitstellung planen oder Ihre spezifische Architektur besprechen möchten, ist das Team von Purple der richtige Ansprechpartner. Dies war ein technisches Briefing von Purple zu RadSec. Vielen Dank fürs Zuhören.