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

RadSec: Wie RADIUS über 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 Host, und heute widmen wir uns einem Thema, das genau an der Schnittstelle zwischen Netzwerksicherheit und betrieblichem Risiko liegt: RadSec – formal definiert in RFC 6614 – und warum es auf Ihrer Infrastruktur-Roadmap stehen sollte, falls es das nicht bereits 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 traditionelle RADIUS-Protokoll Sie Sicherheitsrisiken aussetzt, wie Sie RadSec in einer realen Umgebung bereitstellen und welche Fallstricke Teams immer wieder einholen. 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 also 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. Er leitet Authentifizierungsanfragen an einen RADIUS-Server weiter, der die Anmeldedaten mit Ihrem Verzeichnis abgleicht – sei es Active Directory, LDAP oder ein Cloud-Identity-Provider – und den Zugriff entweder gewährt oder verweigert. 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 is 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 gebrochen. Und das schon seit Jahren. Was bedeutet das in der Praxis? Es bedeutet, dass Angreifer auf jedem Netzwerksegment, auf dem sie RADIUS-Datenverkehr abfangen können – 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 –, potenziell Authentifizierungsvorgänge mitschreiben, Offline-Wörterbuchangriffe gegen das Shared Secret durchführen und in einigen Konfigurationen Benutzeranmeldedaten vollständig offenlegen können. Für eine Hotelgruppe, die Gäste-WiFi in 200 Hotels betreibt, oder eine Einzelhandelskette mit Access Points in jeder Filiale, die ihre Authentifizierungsanfragen ü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-Datenverkehr in einem TLS-Tunnel. Anstelle von UDP nutzt es TCP auf Port 2083. Anstelle eines Shared Secrets und MD5 verwendet es Mutual-TLS-Authentifizierung mit X.509-Zertifikaten. Sowohl der RADIUS-Client als auch der RADIUS-Server weisen Zertifikate vor, überprüfen die Identität des jeweils anderen und bauen eine verschlüsselte Sitzung auf, noch bevor Authentifizierungsdaten ausgetauscht werden. TLS 1.3 ist die derzeit empfohlene Version, die Forward Secrecy bietet und eine Reihe von Schwachstellen älterer Verschlüsselungsverfahren eliminiert. Die praktischen Auswirkungen sind erheblich. Anmeldedaten, Benutzerattribute und Sitzungs-Token werden End-to-End zwischen dem Access Point – oder einem RadSec-Proxy – und dem RADIUS-Server verschlüsselt. Ein Angreifer, der den Datenverkehr auf der Leitung abfängt, sieht nur verschlüsselte TLS-Datensätze. Das Shared Secret ist zwar aus Gründen der Abwärtskompatibilität immer noch vorhanden, leistet aber keinen nennenswerten Sicherheitsbeitrag mehr – TLS übernimmt die gesamte Arbeit. Es gibt hier noch eine weitere Dimension, die zunehmend an Bedeutung gewinnt: Roaming. Die Eduroam-Föderation, die von Universitäten und Forschungseinrichtungen in ganz Europa und darüber hinaus genutzt wird, setzt RadSec seit Jahren als Teil ihrer einrichtungsü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 Föderationsdatenverkehr vor. Wenn Sie eine OpenRoaming-fähige Infrastruktur bereitstellen, ist RadSec nicht optional, sondern eine zwingende Voraussetzung. Purple unterstützt OpenRoaming im Rahmen seiner Connect-Lizenz und fungiert als Identity Provider innerhalb der Föderation. RadSec ist dabei das Herzstück für den Betrieb dieses sicheren Roaming-Netzwerks. Aus Compliance-Sicht wird RadSec für PCI-DSS 4.0 immer wichtiger, da hierdurch 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 im traditionellen RADIUS ein vorprogrammierter Audit-Mangel. Die GDPR verlangt in ähnlicher Weise geeignete technische Maßnahmen zum Schutz personenbezogener Daten. Benutzeranmeldedaten und Sitzungsmetadaten, die unverschlüsselt durch Ihr Netzwerk fließen, lassen sich bei einer Datenschutzprüfung nur schwer rechtfertigen. Sprechen wir nun über die Architektur. Es gibt im Wesentlichen zwei 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 eine erhebliche Einschränkung für Unternehmen darstellt, die eine Windows-zentrierte Infrastruktur betreiben. 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 sauberste Weg: Konfigurieren Sie TLS-Zertifikate auf beiden Seiten, öffnen Sie TCP 2083 auf Ihrer Firewall, und schon verschlüsseln Sie den RADIUS-Datenverkehr End-to-End. Das zweite Muster ist ein RadSec-Proxy. Dies ist in der Praxis die gängigere Bereitstellung, insbesondere für Unternehmen mit älterer RADIUS-Infrastruktur oder gemischten 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äßiges 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 Upstream-RADIUS-Server weiter. Dieser Ansatz ermöglicht es Ihnen, RadSec in eine bestehende Infrastruktur zu integrieren, ohne Ihren RADIUS-Server ersetzen zu müssen. Er ist besonders nützlich, wenn Ihr RADIUS-Server in der Cloud gehostet wird oder über das öffentliche Internet erreichbar ist. 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), die Zertifikatsausstellung für jeden RADIUS-Client und -Server sowie einen Prozess für die Zertifikatsrotation vor dem Ablaufdatum. Zertifikate, die unbemerkt ablaufen, führen dazu, dass die Authentifizierung für alle Benutzer in Ihrem Netzwerk gleichzeitig fehlschlägt – 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 ZUR 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. Dieses Audit bringt in der Regel ältere Geräte ans Licht, die TLS überhaupt nicht unterstützen. Diese sollten auf Ihre Austausch-Roadmap gesetzt werden. Zweitens: Beginnen Sie mit dem risikoreichsten Datenverkehr. Wenn Sie RADIUS-Datenverkehr haben, der über das öffentliche Internet läuft – Außenstellen, in der Cloud gehostetes RADIUS, Hotelgruppen mit mehreren Standorten –, hat dies oberste Priorität. Lokaler RADIUS-Datenverkehr in einem gut segmentierten Management-VLAN ist risikoärmer, sollte aber dennoch auf der Roadmap stehen. Drittens: Testen Sie Mutual TLS vor dem Go-Live gründlich. Die häufigste Fehlerursache 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 produktiven Datenverkehr umschalten. Viertens: Vernachlässigen Sie das Monitoring nicht. RadSec fügt eine TCP-Verbindungsschicht hinzu, die das traditionelle 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 Problem mit den Authentifizierungsrichtlinien 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 an die Verwaltung von UDP-1812-Regeln gewöhnt sind, TCP 2083 beim Firewall-Änderungsprozess leicht übersehen werden. --- [SCHNELLE FRAGERUNDE — ca. 1 Minute] Lassen uns 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 unterschiedlichen Schichten und ergänzen sich gegenseitig. „Wird RadSec von allen Access-Point-Herstellern unterstützt?“ Nicht universell. Cisco, Aruba, Ruckus und Meraki bieten alle unterschiedliche Stufen der RadSec-Unterstützung – prü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. Dadurch bleiben einige der verbindungslosen Eigenschaften des traditionellen RADIUS erhalten, während gleichzeitig eine Verschlüsselung hinzugefügt wird. Es ist weniger weit verbreitet als RadSec über TLS, aber eine Evaluierung wert, wenn die Latenz in Umgebungen mit hohem Durchsatz eine Rolle spielt. „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 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 traditionellen RADIUS. Wenn Sie Enterprise-WiFi in großem Stil 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: Führen Sie noch diese Woche ein Audit Ihrer RADIUS-Infrastruktur durch. Identifizieren Sie Ihre risikoreichsten Datenflüsse. 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 innerhalb eines Tages eine Testumgebung für RadSec einrichten. Wenn Sie Microsoft NPS verwenden, sollten Sie mit der Evaluierung eines Proxys oder eines Migrationspfads zu einem RadSec-fähigen Server beginnen. Die Plattform von Purple ist so konzipiert, dass sie sich nahtlos in die RADIUS-Infrastruktur 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 verstehen möchten, wie RadSec in Ihre spezifische Bereitstellung passt, führt Sie das Team von Purple gerne durch den Prozess. Vielen Dank fürs Zuhören. Bis zum nächsten Mal. --- ENDE DES SKRIPTS