RadSec: Wie RADIUS over TLS die Sicherheit der WiFi-Authentifizierung verbessert

RadSec: Wie RADIUS over TLS die Sicherheit der WiFi Authentifizierung verbessert Ein Briefing von Purple Enterprise WiFi Intelligence Ungefähre Dauer: 10 Minuten --- [EINFÜHRUNG & KONTEXT - ca. 1 Minute] Willkommen zur Reihe Purple Enterprise WiFi Intelligence. Ich bin Ihr Gastgeber, und heute befassen wir uns mit einem Thema, das genau an der Schnittstelle von Netzwerksicherheit und operativem Risiko liegt: RadSec - offiziell definiert in RFC 6614 - und warum es auf Ihrer Infrastruktur-Roadmap stehen sollte, falls es das nicht ohnehin schon tut. Wenn Sie als IT-Manager, Netzwerkarchitekt oder CTO für das Enterprise WiFi einer Hotelgruppe, eines Einzelhandelsunternehmens, eines Stadions oder eines Campus im öffentlichen Sektor verantwortlich sind, ist dieses Briefing genau das Richtige für Sie. Wir werden klären, was RadSec eigentlich ist, warum das herkömmliche RADIUS Protokoll Sie Sicherheitsrisiken aussetzt, wie Sie RadSec in einer realen Umgebung bereitstellen und welche Fallstricke Teams immer wieder behindern. Keine reine Theorie - sondern genau die Informationen, die Sie benötigen, um in diesem Quartal eine Entscheidung zu treffen. Legen wir los. --- [TECHNISCHER DEEP-DIVE - ca. 5 Minuten] Beginnen wir also mit dem Problem. RADIUS - Remote Authentication Dial-In User Service - ist seit den 1990er Jahren das Rückgrat der Enterprise WiFi Authentifizierung. Wenn sich ein Benutzer oder ein Gerät mit Ihrem Unternehmens- oder Gäste-WiFi verbindet, fungiert der Access Point als RADIUS Client und leitet Authentifizierungsanfragen an einen RADIUS Server weiter. Dieser gleicht die Anmeldedaten mit Ihrem Verzeichnis ab - Active Directory, LDAP oder einem Cloud-Identity-Provider - und gewährt oder verweigert den Zugriff. Dies ist das 802.1X Authentifizierungsmodell, das WPA2-Enterprise und WPA3-Enterprise Netzwerken zugrunde liegt. Das Problem ist, dass das traditionelle RADIUS für eine andere Ära entwickelt wurde. Es läuft über UDP - User Datagram Protocol - auf den Ports 1812 und 1813. UDP ist verbindungslos, was bedeutet, dass es keinen Handshake, keinen Sitzungsstatus und vor allem keine native Verschlüsselung gibt. Der einzige Schutz zwischen Ihrem Access Point und Ihrem RADIUS Server ist ein Shared Secret - im Grunde ein Passwort -, das verwendet wird, um das Passwort des Benutzers bei der Übertragung mittels MD5-Hashing zu verschleiern. MD5 ist, wie die meisten von Ihnen wissen werden, kryptografisch unbrauchbar geworden. Und das schon seit Jahren. Was bedeutet das in der Praxis? Es bedeutet, dass auf jedem Netzwerksegment, auf dem ein Angreifer RADIUS Traffic abfangen kann - und dazu gehören kompromittierte Switches, unbefugte Geräte in Ihrem Management-VLAN oder jeder Punkt zwischen einem Remote Access Point und einem in der Cloud gehosteten RADIUS Server -, Authentifizierungsdaten abgefangen, Offline-Dictionary-Attacks gegen das Shared Secret durchgeführt und in manchen Konfigurationen Benutzer-Anmeldedaten vollständig offengelegt werden können. Für eine Hotelgruppe, die Gäste-WiFi in 200 Hotels betreibt, oder eine Einzelhandelskette mit Access Points in jeder Filiale, die über das öffentliche Internet mit einem zentralen RADIUS Server verbunden sind, ist dies kein theoretisches Risiko. Es ist eine reale Angriffsfläche.Genau hier setzt RadSec an. RadSec - definiert in RFC 6614 und aktualisiert durch RFC 7360 - verpackt den RADIUS-Verkehr in einen TLS-Tunnel. Anstelle von UDP verwendet es TCP auf Port 2083. Anstelle eines Shared Secret und MD5 nutzt es eine gegenseitige TLS-Authentifizierung mit X.509-Zertifikaten. Sowohl der RADIUS-Client als auch der RADIUS-Server weisen Zertifikate vor, überprüfen gegenseitig ihre Identität und bauen eine verschlüsselte Sitzung auf, bevor Authentifizierungsdaten ausgetauscht werden. TLS 1.3 ist die derzeit empfohlene Version, die Forward Secrecy bietet und eine Reihe von Schwachstellen älterer Verschlüsselungsverfahren ausschließt. Der praktische Effekt ist erheblich. Anmeldedaten, Benutzerattribute und Sitzungs-Token werden durchgängig verschlüsselt zwischen dem Access Point - oder einem RadSec-Proxy - und dem RADIUS-Server übertragen. Ein Angreifer, der den Datenverkehr auf der Leitung abfängt, sieht nur verschlüsselte TLS-Datensätze. Das Shared Secret ist aus Gründen der Abwärtskompatibilität zwar immer noch vorhanden, übernimmt aber keine wesentliche Sicherheitsfunktion mehr - TLS trägt die Hauptlast. Hier gibt es noch eine weitere Dimension, die zunehmend an Bedeutung gewinnt: Roaming. Die Eduroam-Federation, die von Universitäten und Forschungseinrichtungen in ganz Europa und darüber hinaus genutzt wird, betreibt RadSec seit Jahren als Teil ihrer institutionenübergreifenden Roaming-Infrastruktur. Seit Kurzem schreibt der OpenRoaming-Standard der Wi-Fi Alliance - der ein nahtloses WiFi-Roaming in allen teilnehmenden Veranstaltungsorten ermöglicht - RadSec für den gesamten Föderationsverkehr vor. Wenn Sie eine OpenRoaming-fähige Infrastruktur bereitstellen, ist RadSec nicht optional, sondern eine Voraussetzung. Purple unterstützt OpenRoaming im Rahmen seiner Connect-Lizenz und agiert als Identitätsanbieter innerhalb der Föderation, wobei RadSec eine zentrale Rolle für die Funktionsweise dieser sicheren Roaming-Struktur spielt. Aus Compliance-Sicht wird RadSec immer relevanter für PCI DSS 4.0, wodurch die Anforderungen an den Schutz von Authentifizierungsdaten bei der Übertragung verschärft werden. Wenn Ihre WiFi-Infrastruktur mit Zahlungskartenumgebungen in Berührung kommt - was im Einzelhandel und im Gastgewerbe häufig der Fall ist -, ist die Verschlüsselungslücke bei herkömmlichem RADIUS ein potenzielles Sicherheitsrisiko, das nur darauf wartet, entdeckt zu werden. Die GDPR verlangt in ähnlicher Weise angemessene technische Maßnahmen zum Schutz personenbezogener Daten. Benutzeranmeldedaten und Sitzungs-Metadaten, die unverschlüsselt durch Ihr Netzwerk fließen, lassen sich bei einer Datenschutzprüfung nur schwer verteidigen. Kommen wir nun zur Architektur. Es gibt zwei primäre Bereitstellungsmuster für RadSec. Das erste ist die native RadSec-Unterstützung auf Ihrem RADIUS-Server und Ihren Access Points. FreeRADIUS 3.0 und höher unterstützt RadSec nativ. Microsoft NPS unterstützt RadSec in den aktuellen Versionen nicht nativ, was für Unternehmen mit Windows-zentrierter Infrastruktur eine erhebliche Einschränkung darstellt. Cisco ISE unterstützt RadSec. Aruba ClearPass unterstützt RadSec. Wenn sowohl Ihr RADIUS-Server als auch Ihr Access-Point-Anbieter RadSec nativ unterstützen, ist dies der sauberste Weg - konfigurieren Sie TLS-Zertifikate auf beiden Seiten, öffnen Sie TCP 2083 auf Ihrer Firewall und Sie verschlüsseln den RADIUS-Verkehr durchgehend.Das zweite Muster ist ein RadSec-Proxy. Dies ist in der Praxis die häufigere Bereitstellungsform, insbesondere für Organisationen mit älterer RADIUS-Infrastruktur oder Umgebungen mit verschiedenen Herstellern. Ein RadSec-Proxy - radsecproxy ist die am weitesten verbreitete Open-Source-Implementierung - sitzt zwischen Ihren Access Points und Ihrem RADIUS-Server. Die Access Points senden Standard-RADIUS über UDP an den Proxy im lokalen Netzwerk. Der Proxy beendet diese Verbindung, kapselt den RADIUS-Datenverkehr erneut in einen TLS-Tunnel und leitet ihn über TCP 2083 an den vorgeschalteten RADIUS-Server weiter. Dieser Ansatz ermöglicht es Ihnen, RadSec zu einer bestehenden Infrastruktur hinzuzufügen, ohne Ihren RADIUS-Server zu ersetzen. Dies ist besonders nützlich, wenn Ihr RADIUS-Server in der Cloud gehostet wird oder über das öffentliche Internet aufgerufen wird. Das Zertifikatsmanagement ist die betriebliche Komplexität, die Sie einplanen müssen. Sie benötigen eine PKI - Public Key Infrastructure - um die für Mutual TLS verwendeten X.509-Zertifikate auszustellen und zu verwalten. Das bedeutet eine Zertifizierungsstelle (CA), eine Zertifikatsausstellung für jeden RADIUS-Client und -Server sowie ein Verfahren zur Zertifikatsrotation vor dem Ablaufdatum. Zertifikate, die unbemerkt ablaufen, unterbrechen die Authentifizierung für jeden Benutzer in Ihrem Netzwerk gleichzeitig - und das ist ein Szenario, das Sie vermeiden wollen. Automatisieren Sie die Zertifikatsverlängerung mithilfe von ACME oder der API Ihrer CA und richten Sie Überwachungsalarme lange vor den Ablaufdaten ein. --- [IMPLEMENTIERUNGSEMPFEHLUNGEN & PHÄNOMENE - ca. 2 Minuten] Lassen Sie mich Ihnen die praktischen Empfehlungen geben. Erstens: Auditieren Sie vor der Bereitstellung. Erfassen Sie jeden RADIUS-Client - Access Points, VPN-Konzentratoren, Switches mit 802.1X - und jeden RADIUS-Server in Ihrer Umgebung. Verstehen Sie, welche RadSec nativ unterstützen und welche einen Proxy benötigen. Dieses Audit bringt in der Regel ältere Geräte zum Vorschein, die TLS überhaupt nicht unterstützen, und diese müssen auf Ihre Roadmap für den Austausch gesetzt werden. Zweitens: Beginnen Sie mit dem Datenverkehr mit dem höchsten Risiko. Wenn Sie RADIUS-Datenverkehr haben, der das öffentliche Internet durchquert - Remote-Standorte, in der Cloud gehostetes RADIUS, Hotelgruppen mit mehreren Standorten - hat dies oberste Priorität. Lokaler RADIUS-Datenverkehr auf einem gut segmentierten Management-VLAN ist mit einem geringeren Risiko verbunden, sollte aber dennoch auf der Roadmap stehen. Drittens: Testen Sie Mutual TLS vor dem Go-Live gründlich. Der häufigste Fehlermodus bei RadSec-Bereitstellungen sind Zertifikatsvalidierungsfehler - nicht übereinstimmende Common Names, abgelaufene Zwischenzertifikate oder Clients, die der CA, die das Serverzertifikat signiert hat, nicht vertrauen. Verwenden Sie openssl s_client, um TLS-Handshakes zu testen, bevor Sie den Produktionsdatenverkehr umstellen. Viertens: Vernachlässigen Sie das Monitoring nicht. RadSec fügt eine TCP-Verbindungsschicht hinzu, die herkömmliches RADIUS nicht hat. TCP-Verbindungsfehler, TLS-Handshake-Timeouts und Zertifikatsfehler äußern sich für Ihre Benutzer als Authentifizierungsfehler. Stellen Sie sicher, dass Ihre RADIUS-Server-Logs und Ihre Proxy-Logs in Ihr SIEM oder Ihre Monitoring-Plattform einfließen, damit Sie ein RadSec-Konnektivitätsproblem von einem Problem mit der Authentifizierungsrichtlinie unterscheiden können. Der Fallstrick, den ich am häufigsten sehe, ist, dass Unternehmen RadSec auf der Serverseite bereitstellen, aber vergessen, ihre Firewall-Regeln zu aktualisieren. TCP 2083 muss zwischen jedem RADIUS-Client und dem RADIUS-Server oder Proxy geöffnet sein. Wenn Sie es gewohnt sind, UDP 1812-Regeln zu verwalten, kann TCP 2083 im Änderungsprozess der Firewall leicht übersehen werden. - - - [SCHNELLES Q&A - ca. 1 Minute] Lassen Sie mich ein paar Fragen durchgehen, die ich regelmäßig höre. "Ersetzt RadSec 802.1X?" Nein. RadSec sichert die Transportschicht zwischen dem Access Point und dem RADIUS-Server. 802.1X ist das Authentifizierungs-Framework zwischen dem Client-Gerät und dem Access Point. Sie arbeiten auf verschiedenen Schichten und ergänzen sich. "Wird RadSec von allen Access Point-Herstellern unterstützt?" Nicht universell. Cisco, Aruba, Ruckus und Meraki weisen alle unterschiedliche Stufen der RadSec-Unterstützung auf - überprüfen Sie Ihre spezifische Firmware-Version. Wenn keine native Unterstützung vorhanden ist, ist ein RadSec-Proxy Ihre Lösung. "Was ist mit DTLS - RADIUS über DTLS?" RFC 7360 definiert RADIUS über DTLS, das UDP anstelle von TCP verwendet und so einige der verbindungslosen Eigenschaften von herkömmlichem RADIUS beibehält, während es gleichzeitig eine Verschlüsselung hinzufügt. Es wird weniger häufig eingesetzt als RadSec über TLS, ist aber eine Evaluierung wert, wenn Latenzzeiten in Umgebungen mit hohem Durchsatz eine Rolle spielen. "Wie wirkt sich das auf die Roaming-Leistung aus?" Die TCP-Verbindung von RadSec ist persistent, was die Roaming-Leistung in föderierten Umgebungen tatsächlich verbessern kann, da der Aufwand für den Verbindungsaufbau bei nachfolgenden Authentifizierungsanfragen verringert wird. - - - [ZUSAMMENFASSUNG & NÄCHSTE SCHRITTE - ca. 1 Minute] Zusammenfassend lässt sich sagen: RadSec ist die ausgereifte, auf Standards basierende Antwort auf eine echte Sicherheitslücke im traditionellen RADIUS. Wenn Sie ein Enterprise WiFi in großem Umfang betreiben - über mehrere Standorte hinweg, über das Internet oder in Umgebungen, die PCI-DSS oder GDPR unterliegen - stellt sich nicht die Frage, ob Sie RadSec bereitstellen sollten, sondern wann und wie. Ihre nächsten Schritte: Überprüfen Sie diese Woche Ihre RADIUS-Infrastruktur. Identifizieren Sie Ihre Datenströme mit dem höchsten Risiko. Prüfen Sie die Dokumentation Ihres RADIUS-Servers und des Access Point-Herstellers auf native RadSec-Unterstützung. Wenn Sie FreeRADIUS verwenden, können Sie innerhalb eines Tages eine Test-RadSec-Bereitstellung in Betrieb nehmen. Wenn Sie Microsoft NPS nutzen, beginnen Sie mit der Evaluierung eines Proxys oder eines Migrationspfads zu einem RadSec-fähigen Server. Die Plattform von Purple ist so konzipiert, dass sie sich in Enterprise RADIUS-Infrastrukturen integrieren lässt und sichere Authentifizierungsabläufe sowohl für Unternehmens- als auch für Gast-WiFi-Umgebungen unterstützt. Wenn Sie verstehen möchten, wie RadSec in Ihre spezifische Bereitstellung passt, kann das Team von Purple Sie gerne durch den Prozess führen. Vielen Dank fürs Zuhören. Bis zum nächsten Mal. - - - ENDE DES SKRIPTS