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

RadSec: Wie RADIUS over TLS die Sicherheit der WiFi-Authentifizierung verbessert Ein Purple Enterprise WiFi Intelligence Briefing Ungefähre Laufzeit: 10 Minuten --- [EINFÜHRUNG & KONTEXT — ca. 1 Minute] Willkommen zur Purple Enterprise WiFi Intelligence-Reihe. Ich bin Ihr Moderator, und heute widmen wir sich einem Thema, das genau an der Schnittstelle zwischen Netzwerksicherheit und operativem Risiko liegt: RadSec – formal definiert in RFC 6614 – und warum es auf Ihrer Infrastruktur-Roadmap stehen sollte, falls es das nicht schon tut. Wenn Sie IT-Manager, Netzwerkarchitekt oder CTO sind und die Verantwortung für das Enterprise-WiFi einer Hotelgruppe, eines Einzelhandelsunternehmens, eines Stadions oder eines Campus im öffentlichen Sektor tragen, ist dieses Briefing genau das Richtige für Sie. Wir werden uns ansehen, was RadSec eigentlich ist, warum das herkömmliche RADIUS-Protokoll Sicherheitslücken hinterlässt, wie man RadSec in einer realen Umgebung implementiert und welche Fallstricke Teams immer wieder ausbremsen. Keine graue 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 mit dem Problem. RADIUS – Remote Authentication Dial-In User Service – ist seit den 1990er Jahren das Rückgrat der WiFi-Authentifizierung in Unternehmen. 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 herkömmliche 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 –, mit dem das Passwort des Benutzers bei der Übertragung mittels MD5-Hashing verschleiert wird. MD5 ist, wie die meisten von Ihnen wissen werden, kryptografisch gebrochen. Und das schon seit Jahren. Was bedeutet das in der Praxis? Es bedeutet, dass ein Angreifer auf jedem Netzwerksegment, auf dem er 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 –, Authentifizierungsvorgänge mitschreiben, Offline-Wörterbuchangriffe gegen das Shared Secret durchführen und in einigen Konfigurationen Benutzeranmeldedaten vollständig offenlegen kann. Für eine Hotelgruppe, die Gäste-WiFi in 200 Hotels betreibt, oder eine Einzelhandelskette mit Access Points in jeder Filiale, die Daten über das öffentliche Internet an einen zentralen RADIUS-Server zurücküberträgt, ist dies kein theoretisches Risiko. Es ist eine aktive Angriffsfläche. Genau dieses Problem löst RadSec. RadSec – definiert in RFC 6614 und aktualisiert durch RFC 7360 – kapselt den RADIUS-Traffic in einen TLS-Tunnel. Anstelle von UDP nutzt es TCP auf Port 2083. Anstelle eines Shared Secret und MD5 nutzt es Mutual-TLS-Authentifizierung mit X.509-Zertifikaten. Sowohl der RADIUS-Client als auch der RADIUS-Server legen Zertifikate vor, überprüfen die Identität des jeweils anderen und bauen eine verschlüsselte Sitzung auf, bevor Authentifizierungsdaten ausgetauscht werden. TLS 1.3 ist die derzeit empfohlene Version, die Perfect Forward Secrecy bietet und eine Reihe von Schwachstellen älterer Verschlüsselungsverfahren eliminiert. Der praktische Effekt ist enorm. Anmeldedaten, Benutzerattribute und Sitzungs-Token werden Ende-zu-Ende zwischen dem Access Point – oder einem RadSec-Proxy – und dem RADIUS-Server verschlüsselt. Ein Angreifer, der den Traffic auf der Leitung abfängt, sieht nur verschlüsselte TLS-Daten. Das Shared Secret ist aus Gründen der Abwärtskompatibilität zwar immer noch vorhanden, übernimmt aber keine Sicherheitsfunktion mehr – TLS trägt die gesamte Last. Es gibt noch eine weitere Dimension, die immer wichtiger wird: Roaming. Die Eduroam-Federation, die von Universitäten und Forschungseinrichtungen in Europa und darüber hinaus genutzt wird, setzt RadSec seit Jahren als Teil ihrer institutionenübergreifenden Roaming-Infrastruktur ein. Seit kurzem schreibt auch der OpenRoaming-Standard der Wi-Fi Alliance – der nahtloses WiFi-Roaming an teilnehmenden Standorten ermöglicht – RadSec für den gesamten Federation-Traffic vor. Wenn Sie eine OpenRoaming-fähige Infrastruktur aufbauen, ist RadSec nicht optional, sondern Voraussetzung. Purple unterstützt OpenRoaming im Rahmen seiner Connect-Lizenz und fungiert als Identity-Provider innerhalb der Federation. RadSec ist dabei das Herzstück dieses sicheren Roaming-Netzwerks. Aus Compliance-Sicht wird RadSec auch für PCI DSS 4.0 immer wichtiger, da dort die Anforderungen an den Schutz von Authentifizierungsdaten bei der Übertragung verschärft werden. Wenn Ihre WiFi-Infrastruktur mit Kreditkartendaten in Berührung kommt – was im Einzelhandel und im Gastgewerbe häufig der Fall ist –, ist die fehlende Verschlüsselung im herkömmlichen RADIUS ein Sicherheitsrisiko, das bei jedem Audit auffallen wird. Die GDPR verlangt ebenfalls angemessene technische Maßnahmen zum Schutz personenbezogener Daten; unverschlüsselt über Ihr Netzwerk fließende Benutzerdaten und Sitzungs-Metadaten lassen sich in einem Datenschutzaudit nur schwer rechtfertigen. Sprechen wir nun über die Architektur. Es gibt zwei primäre Bereitstellungsmodelle 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-basierter 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-Hersteller RadSec nativ unterstützen, ist dies der einfachste Weg: Konfigurieren Sie TLS-Zertifikate auf beiden Seiten, öffnen Sie TCP 2083 auf Ihrer Firewall, und schon verschlüsseln Sie den RADIUS-Traffic Ende-zu-Ende. Das zweite Modell ist ein RadSec-Proxy. Dies ist in der Praxis die häufigere Bereitstellung, insbesondere für Unternehmen mit älterer RADIUS-Infrastruktur oder heterogenen Herstellerumgebungen. 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 standardmäßigen RADIUS über UDP an den Proxy im lokalen Netzwerk. Der Proxy terminiert diese Verbindung, kapselt den RADIUS-Traffic in einen TLS-Tunnel und leitet ihn über TCP 2083 an den vorgelagerten RADIUS-Server weiter. Mit diesem Ansatz können Sie eine bestehende Infrastruktur um RadSec erweitern, ohne Ihren RADIUS-Server austauschen zu müssen. Das ist besonders nützlich, wenn Ihr RADIUS-Server in der Cloud gehostet wird oder über das öffentliche Internet erreichbar ist. Das Zertifikatsmanagement ist die operative Herausforderung, 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), die Zertifikatsausstellung für jeden RADIUS-Client und -Server sowie einen Prozess zur Zertifikatsrotation vor dem Ablaufdatum. Zertifikate, die unbemerkt ablaufen, blockieren die Authentifizierung für jeden Benutzer in Ihrem Netzwerk gleichzeitig – und das ist ein Szenario, das Sie unbedingt vermeiden wollen. Automatisieren Sie die Zertifikatsverlängerung über ACME oder die API Ihrer CA und richten Sie Überwachungswarnungen lange vor dem Ablaufdatum ein. --- [EMPFEHLUNGEN FÜR DIE IMPLEMENTIERUNG & FALLSTRICKE — ca. 2 Minuten] Lassen Sie mich Ihnen einige praktische Empfehlungen geben. Erstens: Führen Sie vor der Bereitstellung ein Audit durch. Erfassen Sie jeden RADIUS-Client – Access Points, VPN-Konzentratoren, Switches mit 802.1X – und jeden RADIUS-Server in Ihrer Umgebung. Finden Sie heraus, welche Geräte RadSec nativ unterstützen und welche einen Proxy benötigen. Bei diesem Audit stoßen Sie meist auf ältere Geräte, die TLS überhaupt nicht unterstützen und die auf Ihre Austauschliste gesetzt werden müssen. Zweitens: Beginnen Sie mit dem Traffic, der dem höchsten Risiko ausgesetzt ist. Wenn Sie RADIUS-Traffic haben, der das öffentliche Internet durchquert – Außenstellen, in der Cloud gehostetes RADIUS, Hotelgruppen mit mehreren Standorten –, hat dieser oberste Priorität. Lokaler RADIUS-Traffic in einem gut segmentierten Management-VLAN ist risikoärmer, sollte aber dennoch auf der Roadmap stehen. Drittens: Testen Sie Mutual TLS gründlich vor dem Go-Live. Die häufigste Fehlerquelle bei RadSec-Bereitstellungen sind Fehler bei der Zertifikatsvalidierung – 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 produktiven Traffic umschalten. Viertens: Vernachlässigen Sie das Monitoring nicht. RadSec fügt eine TCP-Verbindungsebene hinzu, die das herkömmliche 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- und Proxy-Protokolle in Ihr SIEM oder Ihre Monitoring-Plattform einfließen, damit Sie ein RadSec-Verbindungsproblem von einem Authentifizierungsrichtlinien-Problem unterscheiden können. Der Fallstrick, den ich am häufigsten sehe, ist, dass Unternehmen RadSec auf der Serverseite implementieren, aber vergessen, ihre Firewall-Regeln zu aktualisieren. TCP 2083 muss zwischen jedem RADIUS-Client und dem RADIUS-Server oder -Proxy geöffnet sein. Wenn man an die Verwaltung von UDP-1812-Regeln gewöhnt ist, kann TCP 2083 bei der Firewall-Änderung leicht vergessen werden. --- [SCHNELLES Q&A — ca. 1 Minute] Lassen Sie uns einige Fragen durchgehen, die mir regelmäßig gestellt werden. „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 Endgerät und dem Access Point. Sie arbeiten auf unterschiedlichen Ebenen und ergänzen sich. „Wird RadSec von allen Access-Point-Herstellern unterstützt?“ Nicht durchgängig. Cisco, Aruba, Ruckus und Meraki bieten unterschiedliche Stufen der RadSec-Unterstützung – prüfen Sie Ihre spezifische Firmware-Version. Wo keine native Unterstützung vorhanden ist, ist ein RadSec-Proxy die Lösung. „Was ist mit DTLS – RADIUS over DTLS?“ RFC 7360 definiert RADIUS over DTLS, das UDP anstelle von TCP verwendet und so einige der verbindungslosen Eigenschaften des herkömmlichen RADIUS beibehält, während es gleichzeitig Verschlüsselung hinzufügt. Es ist weniger weit verbreitet als RadSec over TLS, aber eine Überlegung wert, wenn die Latenz in Umgebungen mit sehr hohem Durchsatz eine Rolle spielt. „Wie wirkt sich das auf die Roaming-Performance aus?“ Die TCP-Verbindung von RadSec ist persistent, was die Roaming-Performance in Federation-Umgebungen tatsächlich verbessern kann, da der Aufwand für den Verbindungsaufbau bei nachfolgenden Authentifizierungsanfragen reduziert wird. --- [ZUSAMMENFASSUNG & NÄCHSTE SCHRITTE — ca. 1 Minute] Zusammenfassend lässt sich sagen: RadSec ist die ausgereifte, standardbasierte Antwort auf eine echte Sicherheitslücke im herkömmlichen RADIUS. Wenn Sie Enterprise-WiFi in größerem Umfang betreiben – über mehrere Standorte hinweg, über das Internet oder in Umgebungen, die PCI DSS oder der GDPR unterliegen –, stellt sich nicht die Frage, ob Sie RadSec implementieren, sondern wann und wie. Ihre nächsten Schritte: Analysieren Sie noch diese Woche Ihre RADIUS-Infrastruktur. Identifizieren Sie Ihre risikoreichsten Traffic-Ströme. Prüfen Sie die Dokumentation Ihres RADIUS-Servers und Ihres Access-Point-Herstellers auf native RadSec-Unterstützung. Wenn Sie FreeRADIUS nutzen, können Sie eine RadSec-Testumgebung an einem einzigen Tag einrichten. Wenn Sie Microsoft NPS nutzen, evaluieren Sie einen Proxy oder einen Migrationspfad zu einem RadSec-fähigen Server. Die Plattform von Purple ist so konzipiert, dass sie sich nahtlos in RADIUS-Infrastrukturen von Unternehmen integrieren lässt und sichere Authentifizierungsabläufe sowohl für Unternehmens- als auch für Gäste-WiFi-Umgebungen unterstützt. Wenn Sie wissen möchten, wie RadSec in Ihre spezifische Umgebung passt, unterstützt Sie das Purple-Team gerne dabei. Vielen Dank fürs Zuhören. Bis zum nächsten Mal. --- ENDE DES SKRIPTS