RadSec: Sicherung des RADIUS-Authentifizierungsverkehrs mit TLS

RadSec: Sicherung 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 lokale RADIUS-Server mit UDP und einem Shared Secret betreiben, ist dieses Briefing genau das Richtige für Sie. Betrachten wir zunächst die Ausgangslage. 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 ganz anders aussah. 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? Weitgehend unverschlüsselt. Der einzige Schutz war ein Shared Secret, das zur Verschleierung des Benutzerpasswort-Attributs verwendet wurde, und selbst das weist gut dokumentierte 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 Bereitstellungen an Standorten, SD-WAN-Overlays und der Wechsel zu Cloud-RADIUS-Diensten haben das Bedrohungsmodell grundlegend verändert. Ihr Authentifizierungsverkehr durchquert nun das öffentliche Internet oder im besten Fall 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 –, was einige der Latenzmerkmale des ursprünglichen UDP-Transports beibehält und gleichzeitig eine Verschlüsselung hinzufügt. 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. Sprechen wir über die Funktionsweise. RadSec arbeitet auf dem TCP-Port 2083, dem von der IANA zugewiesenen Port für dieses Protokoll. 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 ist gegenseitig – 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 in diesem verschlüsselten Tunnel genau so, wie sie es über UDP tun würden, jedoch jetzt mit vollständiger Vertraulichkeit, Integrität und Schutz vor Replay-Angriffen. Dies ist in dreierlei Hinsicht eine erhebliche Abweichung 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 neu übertragen. Zweitens basiert die Authentifizierung beider Endpunkte auf Zertifikaten und nicht auf Shared Secrets. Dies eliminiert eine ganze Klasse von Angriffen, die auf schwachen oder kompromittierten Shared Secrets basieren. 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 des Zertifikatsmanagements benötigen Sie eine PKI – eine Public-Key-Infrastruktur –, 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-Native-Authentifizierungsinfrastruktur von Purple, das serverseitige Zertifikatsmanagement für Sie. Ihre Aufgabe besteht darin, Client-Zertifikate für Ihre NAS-Geräte bereitzustellen. Bei großen Bereitstellungen wird dies in der Regel über Ihre Netzwerkmanagement-Plattform oder ein dediziertes Zertifikatsmanagementsystem 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 angemessener Standardwert. Kommen wir nun zum Vergleich mit dem alternativen Ansatz, den viele Unternehmen heute verwenden: IPsec-Tunnel oder VPN-Overlays zum Schutz des RADIUS-Verkehrs. IPsec ist ein absolut valider Ansatz, arbeitet jedoch auf einer anderen Schicht. 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, ganz zu schweigen vom betrieblichen Aufwand für die Aufrechterhaltung des Tunnelstatus über potenziell Hunderte von Standorten hinweg. RadSec geht gezielter vor. 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. Lassen Sie mich Ihnen beschreiben, wie eine Bereitstellung an mehreren Standorten in der Praxis aussieht. Sie haben einen Cloud-RADIUS-Server – sagen wir, es ist 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. Jeder 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 –, stellt das NAS sie automatisch wieder her. Dieses persistente Verbindungsmodell ist bei hohem Aufkommen tatsächlich effizienter als UDP, da Sie den Overhead der Verarbeitung pro Paket vermeiden. Auf der Firewall-Seite müssen Sie ausgehendes TCP auf Port 2083 von Ihrem NAS-Management-Netzwerk zur IP-Adresse oder FQDN Ihres RADIUS-Servers zulassen. Wenn Sie eine strenge Egress-Richtlinie haben, sollten 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. Sprechen wir darüber, was bei RadSec-Bereitstellungen tatsächlich schiefgeht, denn es gibt einige typische Fehlermodi, die ich in Unternehmen immer wieder beobachte. 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 verwenden – DigiCert, Let's Encrypt, Sectigo –, 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 bei jedem einzelnen NAS-Gerät in Ihrer Umgebung gleichzeitig fehl. Sie benötigen ein Zertifikats-Lebenszyklus-Management – nach Möglichkeit eine automatisierte Verlängerung sowie eine Überwachung mit Alarmierung lange vor dem Ablauf. Eine Benachrichtigung 90 Tage im Voraus ist das Minimum; 30 Tage sind besser. Der dritte Punkt ist die Kompatibilität der NAS-Geräte. Nicht alle NAS-Geräte unterstützen RadSec nativ. Ältere Cisco IOS-Versionen, einige ältere Aruba-Controller und bestimmte Access Points für Endverbraucher 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 Legacy-Geräten empfängt und über TLS an den Cloud-RADIUS-Server weiterleitet. Der vierte Aspekt ist die Verbindungspersistenz und Keepalives. RadSec verwendet 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 sechzig 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 Adresse Ihres Cloud-RADIUS-Endpunkts, geben TLS als Transport an, verweisen auf Ihren Trustpoint – das ist der Zertifikatsspeicher auf dem Gerät – und setzen den Zielport auf 2083. Anschließend verweisen Sie in der Konfiguration Ihrer AAA-Servergruppe auf diesen Server. Die Details variieren je nach Plattformversion, aber die logische Struktur ist herstellerübergreifend konsistent. Bei Aruba-Controllern, auf denen AOS läuft, 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 gegenseitiges TLS. Die Implementierung von Aruba ist ausgereift und gut dokumentiert. Schnelle Fragen und Antworten. Gehen wir die Fragen durch, die mir zu RadSec am häufigsten gestellt werden. Verursacht RadSec zusätzliche Latenz? Der TLS-Handshake verursacht beim ersten Verbindungsaufbau einen geringen Overhead – typischerweise unter 100 Millisekunden. Sobald die Verbindung hergestellt ist, 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 Legacy-Standorte auf UDP zurückgreifen. Dies ist der empfohlene Migrationsansatz. Ist RadSec für die PCI-DSS-Compliance erforderlich? PCI-DSS Version 4.0 erfordert, dass der Authentifizierungsverkehr während der Übertragung geschützt wird. RadSec ist einer der direktesten Wege, um diese Anforderung für die RADIUS-basierte Authentifizierung zu erfüllen. Wenn Sie Kartenzahlungen über ein Netzwerk abwickeln, das die RADIUS-Authentifizierung verwendet, 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 Zwischenaktualisierungsdatensätze – werden ebenfalls über dieselbe TLS-Verbindung auf Port 2083 verschlüsselt. Zusammenfassung und nächste Schritte. Zusammenfassend lässt sich sagen: RadSec ist 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 für das Zertifikatsmanagement vertraut. Drittens, etablieren Sie vor dem Go-Live einen Prozess für das Zertifikats-Lebenszyklus-Management. Viertens, aktualisieren Sie Ihre Firewall-Regeln, um ausgehendes TCP 2083 aus Ihrem NAS-Management-Netzwerk 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 Authentifizierung an verteilten Standorten nutzen, RadSec ist der empfohlene Transport für die Cloud-RADIUS-Konnektivität. 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 im Rahmen von 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.