Minderung von RADIUS-Sicherheitslücken: Ein Leitfaden zur Sicherheits-Härtung

Dieser Leitfaden bietet eine umfassende, direkt anwendbare Referenz für IT-Manager, Netzwerkarchitekten und CTOs, die für die WiFi-Infrastruktur von Unternehmen in den Bereichen Gastgewerbe, Einzelhandel, Veranstaltungen und im öffentlichen Sektor verantwortlich sind. Er deckt die gesamte Angriffsfläche von RADIUS-Server-Bereitstellungen ab – von MD5-Kollisionsschwachstellen und schwachen Shared Secrets bis hin zu unverschlüsseltem UDP-Transport und fehlerhaft konfigurierten EAP-Methoden – und liefert eine priorisierte Roadmap zur Härtung, die an den Anforderungen von IEEE 802.1X, PCI DSS und GDPR ausgerichtet ist. Unternehmen, die diese Empfehlungen umsetzen, reduzieren ihr Risiko für auf Anmeldedaten basierende Netzwerkangriffe erheblich, erfüllen ihre Compliance-Verpflichtungen und bauen eine robuste Sicherheitsstruktur für ihre Gäste- und Unternehmens-WiFi-Infrastruktur auf.

📖 12 Min. Lesezeit📝 2,764 Wörter🔧 2 ausgearbeitete Beispiele❓ 3 Übungsfragen📚 10 Schlüsseldefinitionen

Diesen Leitfaden anhören

Podcast-Transkript ansehen

MINDERUNG VON RADIUS-SCHWACHSTELLEN: EIN LEITFADEN ZUR SICHERHEITSHÄRTUNG
Ein Purple WiFi Intelligence Briefing

[EINFÜHRUNG — ca. 1 Minute]

Willkommen. Ich bin Ihr Moderator für das heutige Briefing. In den nächsten zehn Minuten kommen wir direkt zum Kern eines Themas, das vielen Netzwerkarchitekten und IT-Managern schlaflose Nächte bereitet: die Sicherheit von RADIUS-Servern. Wenn Sie enterprise WiFi in einer Hotelgruppe, einer Einzelhandelskette, einem Stadion oder einem Gebäude des öffentlichen Sektors betreiben, ist Ihre RADIUS-Infrastruktur eine der kritischsten – und am häufigsten übersehenen – Komponenten Ihrer Sicherheitsarchitektur. Legen wir los.

[KONTEXT — ca. 1 Minute]

RADIUS — Remote Authentication Dial-In User Service — ist seit Mitte der Neunzigerjahre das Rückgrat der Netzwerkzugriffskontrolle. Es ist das Protokoll, das zwischen Ihren Access Points und Ihrem Identitätsverzeichnis sitzt und entscheidet, wer auf das Netzwerk zugreifen darf und wer nicht. IEEE 802.1X, das praktisch jeder enterprise WiFi- und kabelgebundenen Authentifizierungsimplementierung zugrunde liegt, basiert auf RADIUS.

Das Problem ist, dass RADIUS in einer Ära entwickelt wurde, in der die Bedrohungslage ganz anders aussah. Das Protokoll verwendet UDP, das verbindungslos und daher schwerer zu sichern ist. Sein Kernauthentifizierungsmechanismus basierte in der Vergangenheit auf MD5-Hashing – einem kryptografischen Algorithmus, der seit 2004 nachweislich geknackt ist. Und Shared Secrets, die Pre-Shared Keys, die Ihre Access Points gegenüber Ihrem RADIUS-Server authentifizieren, werden oft nur einmal eingerichtet und nie rotiert.

Im Jahr 2024 veröffentlichten Forscher einen praktischen Angriff auf RADIUS namens BlastRADIUS – einen Man-in-the-Middle-Angriff, der die MD5-Schwachstelle ausnutzt, um Authentifizierungsantworten zu fälschen. Das ist keine Theorie. Es ist ein realer, dokumentierter Angriffsvektor, der Installationen mit ungepatchtem FreeRADIUS, Cisco ISE und Microsoft NPS betrifft. Wenn Sie seit Mitte 2024 keine Patches eingespielt haben, sind Sie gefährdet.

Die geschäftlichen Risiken sind erheblich. Ein kompromittierter RADIUS-Server bedeutet nicht nur unbefugten WiFi-Zugang. Er bedeutet, dass ein Angreifer sich als beliebiger Benutzer in Ihrem Netzwerk authentifizieren, die Netzwerksegmentierung umgehen und potenziell auf Zahlungssysteme, Patientenakten oder Betriebstechnik zugreifen kann. Für Einzelhandelsumgebungen, die Kartenzahlungen verarbeiten, ist dies ein direkter Verstoß gegen PCI DSS. Für das Gesundheitswesen ist es ein GDPR- und Clinical-Governance-Problem. Für das Gastgewerbe bedeutet dies Imageschäden und potenzielle behördliche Geldbußen.

[TECHNISCHE TIEFENANALYSE — ca. 5 Minuten]

Gehen wir die Angriffsfläche systematisch durch.

Die erste Schwachstellenklasse ist das MD5-Kollisionsrisiko. RADIUS verwendet MD5, um das User-Password-Attribut zu schützen und das Response-Authenticator-Feld zu generieren. MD5 erzeugt einen 128-Bit-Hash, und Kollisionsangriffe – bei denen zwei verschiedene Eingaben denselben Hash erzeugen – sind seit 2004 möglich. Der BlastRADIUS-Angriff nutzt speziell den Mangel an Integritätsschutz bei Access-Request-Paketen aus. Ein Angreifer, der sich zwischen Ihrem NAS-Gerät – also Ihrem Network Access Server, in der Regel Ihrem Access Point oder Switch – und Ihrem RADIUS-Server befindet, kann ein manipuliertes Attribut in das Paket einschleusen und den Server zwingen, ein Access-Accept zurückzugeben, selbst bei ungültigen Anmeldedaten. Die Behebung ist hier zweifach: Patchen Sie Ihren RADIUS-Server auf die neueste Version und erzwingen Sie Message-Authenticator für alle Access-Request-Pakete. FreeRADIUS 3.2.5 und neuer erfordern dies standardmäßig.

Die zweite Schwachstellenklasse sind schwache oder statische Shared Secrets. Das Shared Secret ist der Pre-Shared Key zwischen Ihrem NAS und Ihrem RADIUS-Server. Wenn es kurz ist, über Wörterbuchangriffe geknackt werden kann oder seit Jahren nicht rotiert wurde, stellt es ein Sicherheitsrisiko dar. RADIUS verwendet dieses Geheimnis, um das User-Password-Attribut zu verschlüsseln und den Response Authenticator zu generieren. Ein schwaches Shared Secret bedeutet, dass ein Angreifer, der den RADIUS-Verkehr abfängt – was in einem bereits teilweise kompromittierten Netzwerk trivial ist –, das Passwort offline per Brute-Force-Angriff knacken kann. Best Practice ist eine Mindestlänge von 32 Zeichen, die zufällig generiert und mindestens einmal jährlich rotiert werden. Automatisieren Sie diese Rotation; die manuelle Durchführung in einer großen Infrastruktur ist fehleranfällig.

Die dritte Schwachstellenklasse ist der unverschlüsselte Transport. Standard-RADIUS läuft über UDP auf Port 1812 für die Authentifizierung und Port 1813 für das Accounting. UDP bietet keine Verschlüsselung auf Transportebene, keine Integritätsprüfung und keinen Replay-Schutz, der über das hinausgeht, was RADIUS selbst implementiert – was, wie wir festgestellt haben, unzureichend ist. RadSec, formell in RFC 6614 definiert, kapselt RADIUS in TLS 1.2 oder 1.3 über TCP-Port 2083. Dies bietet gegenseitige Authentifizierung über Zertifikate, vollständige Verschlüsselung der RADIUS-Nutzdaten und Replay-Schutz. Wenn Sie RADIUS über ein nicht vertrauenswürdiges Netzwerksegment betreiben – einschließlich einer WAN-Verbindung zwischen einem entfernten Standort und einem zentralen RADIUS-Server –, ist RadSec nicht optional. Es ist eine Voraussetzung.

Die vierte Schwachstellenklasse ist die EAP-Methodenauswahl. Nicht alle EAP-Methoden sind gleichwertig. EAP-MD5 sollte als veraltet betrachtet werden – es bietet keine gegenseitige Authentifizierung und keine Verschlüsselung des Authentifizierungsaustauschs. PEAP und EAP-TTLS sind für die meisten Unternehmensbereitstellungen akzeptabel, da sie vor der Übertragung von Anmeldedaten einen TLS-Tunnel aufbauen und eine gegenseitige Authentifizierung über Serverzertifikate unterstützen. EAP-TLS ist der Goldstandard: Es erfordert, dass sowohl der Server als auch der Client Zertifikate vorlegen, wodurch das Passwort vollständig aus dem Authentifizierungsaustausch eliminiert wird. Dies macht es immun gegen Phishing von Anmeldedaten und Brute-Force-Angriffe. Der betriebliche Aufwand für die Bereitstellung einer PKI zur Ausstellung von Client-Zertifikaten ist real, aber für Hochsicherheitsumgebungen – Gesundheitsnetzwerke, Zahlungsverarbeitungszonen, Back-of-House-Einzelhandelssysteme – ist es die richtige Entscheidung.

Die fünfte Schwachstellenklasse ist unzureichende Protokollierung und Überwachung. RADIUS-Accounting-Daten sind eine Goldgrube für die Bedrohungserkennung, und die meisten Unternehmen nutzen sie nicht. Jeder Authentifizierungsversuch, ob erfolgreich oder fehlgeschlagen, erzeugt einen Accounting-Datensatz. Muster von fehlgeschlagenen Authentifizierungen, Authentifizierungen von unerwarteten MAC-Adressen oder Authentifizierungen zu ungewöhnlichen Zeiten sind allesamt Indikatoren für eine Kompromittierung. Integrieren Sie Ihren RADIUS-Accounting-Stream in Ihr SIEM. Richten Sie Warnmeldungen für mehr als fünf fehlgeschlagene Authentifizierungen von einer einzelnen MAC-Adresse innerhalb von sechzig Sekunden ein. Überwachen Sie auf Access-Reject-Storms, die auf einen laufenden Credential-Stuffing-Angriff hinweisen können.

[IMPLEMENTIERUNGSEMPFEHLUNGEN UND FALLSTRICKE — ca. 2 Minuten]

Lassen Sie mich Ihnen eine praktische Abfolge für ein Hardening-Projekt vorstellen.

Beginnen Sie mit dem Patching. Dies ist nicht verhandelbar und sollte innerhalb Ihres nächsten Änderungsfensters erfolgen. FreeRADIUS, Cisco ISE und Microsoft NPS haben im Juli 2024 alle Patches für BlastRADIUS veröffentlicht. Überprüfen Sie Ihre Version, wenden Sie den Patch an und stellen Sie sicher, dass die Message-Authenticator-Erzwingung aktiv ist.

Führen Sie als Nächstes ein Audit Ihrer Shared Secrets durch. Rufen Sie die Liste aller an Ihrem RADIUS-Server registrierten NAS-Geräte ab. Überprüfen Sie für jedes Gerät die Länge und das Alter des Shared Secret. Alles unter 20 Zeichen oder älter als zwei Jahre sollte sofort rotiert werden. Verwenden Sie einen Passwort-Manager oder Secrets-Vault – HashiCorp Vault eignet sich hierfür hervorragend –, um diese programmatisch zu speichern und zu rotieren.

Drittens: Evaluieren Sie Ihre EAP-Methode. Wenn Sie irgendwo EAP-MD5 ausführen, migrieren Sie jetzt davon weg. PEAP-MSCHAPv2 ist ein angemessener Zwischenschritt für die meisten Unternehmensumgebungen. Wenn Sie über die PKI-Infrastruktur verfügen, ist EAP-TLS der Zielzustand.

Viertens: Implementieren Sie RadSec für jeglichen RADIUS-Verkehr, der nicht vertrauenswürdige Netzwerksegmente durchquert. Dies ist besonders relevant für Bereitstellungen an mehreren Standorten, bei denen ein zentraler RADIUS-Server entfernte Standorte über das Internet oder ein gemeinsam genutztes WAN bedient.

Fünftens: Aktivieren Sie die Multi-Faktor-Authentifizierung für den privilegierten Zugriff auf den RADIUS-Server selbst. Die Verwaltungsschnittstelle des Servers ist ein lohnendes Ziel. Erzwingen Sie MFA für alle administrativen Logins und beschränken Sie den Verwaltungszugriff auf ein dediziertes Out-of-Band-Management-Netzwerk.

Nun zu den Fallstricken. Der häufigste Fehler, den ich sehe, ist, dass Unternehmen den RADIUS-Server patchen, aber die NAS-Geräte auf alter Firmware belassen, die Message-Authenticator nicht unterstützt. Der Patch ist nur wirksam, wenn beide Seiten ihn erzwingen. Überprüfen Sie im Zuge desselben Projekts die Firmware Ihrer Access Points und Switches.

Der zweite häufige Fallstrick ist das Ablaufen von Zertifikaten. Wenn Sie EAP-TLS oder RadSec verwenden, sind Zertifikate im Spiel. Ein RADIUS-Server-Zertifikat, das unbemerkt abläuft, führt dazu, dass jede Authentifizierung in Ihrem Netzwerk gleichzeitig fehlschlägt. Integrieren Sie die Überwachung des Zertifikatsablaufs in Ihr betriebliches Handbuch. Richten Sie Warnmeldungen 90, 30 und 7 Tage vor dem Ablaufdatum ein.

Der dritte Fallstrick ist das übermäßige Vertrauen in die Netzwerkersegmentierung als kompensierende Maßnahme. Segmentierung ist wichtig, aber sie schützt nicht vor einem Angreifer, der sich bereits über einen kompromittierten RADIUS-Server authentifiziert hat. Defense-in-Depth bedeutet, dass Sie sowohl die RADIUS-Härtung als auch die Segmentierung benötigen.

[SCHNELLES Q&A — ca. 1 Minute]

Frage: Benötige ich RadSec, wenn sich mein RADIUS-Server im selben LAN wie meine Access Points befindet?

Antwort: Wenn sie sich im selben vertrauenswürdigen, segmentierten Management-VLAN ohne nicht vertrauenswürdige Geräte befinden, ist Standard-RADIUS über UDP für die Strecke vom NAS zum Server akzeptabel. Aber wenn die Möglichkeit besteht, dass sich ein kompromittiertes Gerät lateral in dieses VLAN hineinbewegt, bietet RadSec einen sinnvollen Schutz zu geringen Kosten.

Frage: Wir verwenden Microsoft NPS. Sind wir von BlastRADIUS betroffen?

Antwort: Ja. Microsoft hat im Juli 2024 einen Patch veröffentlicht. Wenden Sie diesen an. Erzwingen Sie außerdem den Registrierungsschlüssel RequireMessageAuthenticator auf Ihrem NPS-Server.

Frage: Wie gehe ich mit Gast-WiFi um? Gäste haben keine Zertifikate.

Antwort: Gast-WiFi nutzt in der Regel ein Captive Portal-Modell anstelle von 802.1X, sodass RADIUS anders eingesetzt wird – oft nur für den MAC-Authentifizierungs-Bypass oder das Accounting. Es gelten die gleichen Anforderungen an das Patchen und die Hygiene der Shared Secrets, aber EAP-TLS ist für den unauthentifizierten Gastzugang nicht relevant. Konzentrieren Sie sich darauf, die Gast-RADIUS-Instanz von Ihrer Unternehmens-RADIUS-Infrastruktur zu isolieren.

Frage: Wie sieht der ROI für eine vollständige EAP-TLS-Migration aus?

Antwort: Setzen Sie ihn ins Verhältnis zu Ihrem Sicherheitsrisiko. Eine einzige PCI-DSS-Sicherheitsverletzung kostet im Durchschnitt vier Millionen Pfund an Geldstrafen, Behebung und Reputationsschäden. Eine PKI-Bereitstellung für eine Infrastruktur mit 500 Geräten kostet etwa 15.000 bis 30.000 Pfund an Tools und professionellen Dienstleistungen. Die Rechnung ist eindeutig.

[ZUSAMMENFASSUNG UND NÄCHSTE SCHRITTE — ca. 1 Minute]

Ich möchte Ihnen fünf Aufgaben für dieses Quartal mitgeben.

Erstens: Patchen Sie Ihren RADIUS-Server und alle NAS-Geräte gegen BlastRADIUS. Tun Sie dies zuerst.

Zweitens: Überprüfen und rotieren Sie alle Shared Secrets. Automatisieren Sie die Rotation für die Zukunft.

Drittens: Erzwingen Sie den Message-Authenticator bei allen Access-Request-Paketen.

Viertens: Implementieren Sie RadSec für jeglichen RADIUS-Datenverkehr, der ungesicherte Netzwerkgrenzen überschreitet.

Fünftens: Integrieren Sie RADIUS-Accounting-Protokolle in Ihr SIEM und richten Sie Anomalie-Warnmeldungen ein.

RADIUS-Sicherheit ist nicht glamourös, aber sie ist grundlegend. Wenn Sie diese fünf Punkte richtig umsetzen, haben Sie die wichtigsten Angriffsvektoren auf Ihre Infrastruktur zur Netzwerkzugriffskontrolle geschlossen.

Vielen Dank fürs Zuhören. Weitere Informationen zur Sicherheitsarchitektur für Enterprise-WiFi finden Sie auf purple.ai. Dies war ein Purple WiFi Intelligence Briefing.

Wichtigste Erkenntnisse

✓Sofort patchen: BlastRADIUS (CVE-2024-3596) ist eine aktive, ausnutzbare Schwachstelle, die FreeRADIUS, Cisco ISE und Microsoft NPS betrifft — spielen Sie Hersteller-Patches ein und erzwingen Sie Message-Authenticator bei allen Access-Request-Paketen sowohl auf dem Server als auch auf den NAS-Geräten.
✓Hygiene bei Shared Secrets ist nicht verhandelbar: Rotieren Sie alle Secrets mit weniger als 20 Zeichen oder einem Alter von über 24 Monaten auf zufällig generierte Werte mit 32 Zeichen, die in einem Secrets Manager gespeichert und nach einem festgelegten Zeitplan rotiert werden.
✓Die Wahl der EAP-Methode bestimmt Ihre Angriffsfläche: Entfernen Sie EAP-MD5 sofort, nutzen Sie PEAP-MSCHAPv2 als akzeptablen Mindeststandard und streben Sie EAP-TLS für jede Umgebung im PCI DSS- oder Gesundheitswesen-Bereich an.
✓RadSec ist für jeglichen RADIUS-Verkehr erforderlich, der eine nicht vertrauenswürdige Netzwerkgrenze überschreitet — WAN-Verbindungen, Internet-Pfade oder von Dritten verwaltete Netzwerke fallen alle darunter; Standard-RADIUS über UDP auf diesen Pfaden entspricht der Übertragung von Zugangsdaten ohne Verschlüsselung.
✓Der Ablauf von Zertifikaten ist die häufigste Ursache für einen plötzlichen vollständigen Authentifizierungsausfall — richten Sie Überwachungswarnungen bei 90, 30 und 7 Tagen vor Ablauf für jedes Zertifikat im RADIUS-Authentifizierungspfad ein.
✓RADIUS-Accounting-Protokolle sind eine unterbewertete Quelle für Sicherheits-Telemetrie — integrieren Sie diese in Ihr SIEM und konfigurieren Sie Alarmschwellenwerte für Spitzen bei fehlgeschlagener Authentifizierung, unerwartete MAC-Adressen und Zugriffsmuster außerhalb der Geschäftszeiten.
✓Der ROI-Case ist eindeutig: Ein vollständiges RADIUS-Härtungsprogramm für einen Bestand von 500 Geräten kostet 20.000–45.000 £ gegenüber einer Schadensbasis von 3,58 Millionen £ bei einer Sicherheitsverletzung — die risikobereinigte Rendite ist selbst bei konservativen Schätzungen der Verletzungswahrscheinlichkeit überzeugend.

Executive Summary

RADIUS (Remote Authentication Dial-In User Service) bleibt das dominierende Protokoll für die Netzwerkzugriffskontrolle in Enterprise-WiFi-Umgebungen und bildet die Grundlage für die IEEE 802.1X-Authentifizierung in Hotels, Einzelhandelsflächen, Stadien, Konferenzzentren und Gebäuden des öffentlichen Sektors. RADIUS wurde jedoch in den 1990er Jahren entwickelt, und einige seiner grundlegenden Designentscheidungen – wie die Abhängigkeit von MD5-Hashing, UDP-Transport ohne native Verschlüsselung und statische Shared Secrets – sind in der heutigen Bedrohungslage zu erheblichen Sicherheitsrisiken geworden.

Im Juli 2024 zeigte die BlastRADIUS-Schwachstelle (CVE-2024-3596), dass ein Man-in-the-Middle-Angreifer RADIUS Access-Accept-Antworten fälschen kann, indem er die MD5-Integritätsschwäche in Access-Request-Paketen ausnutzt. Dies betrifft alle gängigen RADIUS-Implementierungen, einschließlich FreeRADIUS, Cisco ISE und Microsoft NPS. Ungepatchte Systeme sind weiterhin ungeschützt.

Dieser Leitfaden bietet eine priorisierte Roadmap zur Systemhärtung, die Patch-Management, Shared-Secret-Hygiene, die Auswahl von EAP-Methoden, die Bereitstellung von RadSec, Multi-Faktor-Authentifizierung für den administrativen Zugriff und die SIEM-Integration zur Erkennung von Anomalien umfasst. Er richtet sich an IT-Experten, die noch in diesem Quartal und nicht erst im nächsten Jahr fundierte Sicherheitsentscheidungen treffen müssen.

Technischer Deep-Dive

Wie RADIUS funktioniert und wo die Schwachstellen liegen

RADIUS arbeitet als Client-Server-Protokoll zwischen einem Network Access Server (NAS) – in der Regel ein WiFi-Zugriffspunkt, ein Switch oder ein VPN-Konzentrator – und einem RADIUS-Server, der die Anmeldedaten mit einem Backend-Identitätsspeicher wie Active Directory oder LDAP abgleicht. Der Authentifizierungsaustausch folgt einem in RFC 2865 definierten Request-Challenge-Response-Modell, wobei das Accounting separat nach RFC 2866 abgewickelt wird.

Das Protokoll überträgt Authentifizierungspakete über UDP, Port 1812 für die Authentifizierung und Port 1813 für das Accounting. Das Shared Secret – ein vorab freigegebener Schlüssel, der sowohl auf dem NAS als auch auf dem RADIUS-Server konfiguriert ist – wird verwendet, um das Feld „Response Authenticator“ zu generieren und das Attribut „User-Password“ über eine MD5-basierte XOR-Chiffre zu verschleiern. Dies ist keine Verschlüsselung im modernen Sinne, sondern eine Verschleierung, die vollständig von der Geheimhaltung und Stärke des Shared Secrets abhängt.

Die fünf primären Schwachstellenklassen in einer typischen RADIUS-Bereitstellung sind wie folgt. MD5-Kollisions- und Integritäts-Schwachstellen. Der BlastRADIUS-Angriff (CVE-2024-3596) nutzt das Fehlen eines Integritätsschutzes bei Access-Request-Paketen aus. Da der NAS in vielen Konfigurationen standardmäßig kein Message-Authenticator-Attribut enthält, kann ein Angreifer in einer Man-in-the-Middle-Position ein manipuliertes Attribut in das Paket einschleusen, bevor es den RADIUS-Server erreicht. Durch das Ausnutzen von MD5-Chosen-Prefix-Kollisionstechniken kann der Angreifer das Paket so manipulieren, dass der RADIUS-Server einen gültigen Response Authenticator für das modifizierte Paket berechnet und ein Access-Accept für eine Anfrage zurückgibt, die eigentlich hätte abgelehnt werden müssen. Die Behebung besteht darin, das Message-Authenticator-Attribut für alle Access-Request-Pakete zu erzwingen, was einen HMAC-MD5-Integritätsschutz für das gesamte Paket bietet. Dies ist eine Konfigurationsänderung sowohl auf dem NAS als auch auf dem RADIUS-Server, nicht nur ein Server-Patch.

Schwache oder statische Shared Secrets. Das Shared Secret ist der kryptografische Anker des RADIUS-Austauschs. Wenn es kurz, leicht zu erraten oder nicht rotiert worden ist, kann ein Angreifer, der den RADIUS-Verkehr abfängt – was über ARP-Spoofing oder ein kompromittiertes Netzwerkgerät möglich ist –, einen Offline-Brute-Force-Angriff auf das User-Password-Attribut durchführen. Hier gelten die Richtlinien der NIST SP 800-63B für gespeicherte Geheimnisse: Passwörter sollten mindestens 20 Zeichen lang sein, zufällig generiert und in einem Secrets-Management-System gespeichert werden. Bei großen Infrastrukturen mit Dutzenden oder Hunderten von NAS-Geräten ist eine manuelle Rotation betrieblich nicht machbar; eine Automatisierung über HashiCorp Vault oder einen vergleichbaren Secrets Manager ist der richtige Ansatz.

Unverschlüsselter UDP-Transport. Standard-RADIUS über UDP bietet keine Vertraulichkeit auf der Transportebene. Das User-Password-Attribut wird verschleiert, aber nicht verschlüsselt. Alle anderen Attribute – einschließlich Benutzername, NAS-IP und Sitzungs-Metadaten – werden im Klartext übertragen. RadSec (RADIUS über TLS), definiert in RFC 6614 und aktualisiert in RFC 7360, löst dieses Problem, indem es das RADIUS-Protokoll in eine TLS 1.2- oder TLS 1.3-Sitzung über TCP-Port 2083 verpackt. RadSec bietet eine gegenseitige Zertifikatsauthentifizierung zwischen dem NAS und dem RADIUS-Server, eine vollständige Verschlüsselung der Nutzdaten und einen Replay-Schutz. Es ist der richtige Transport für jeglichen RADIUS-Verkehr, der eine nicht vertrauenswürdige Netzwerkgrenze überschreitet.

EAP-Methodenauswahl. Das Extensible Authentication Protocol (EAP) definiert die interne Authentifizierungsmethode, die innerhalb des 802.1X-Frameworks verwendet wird. EAP-MD5 ist veraltet und sollte unverzüglich aus allen Bereitstellungen entfernt werden – es bietet keine gegenseitige Authentifizierung und keinen Schutz vor dem Abfangen von Zugangsdaten (Credential Harvesting). PEAP (Protected EAP) und EAP-TTLS bauen vor der Übertragung von Zugangsdaten einen TLS-Tunnel mithilfe eines Serverzertifikats auf, was eine gegenseitige Authentifizierung gewährleistet und die interne Methode vor Abhören schützt. EAP-TLS verzichtet vollständig auf Passwörter und erfordert, dass sowohl Server als auch Client ein X.509-Zertifikat vorlegen. Es ist immun gegen Phishing- und Brute-Force-Angriffe und ist die empfohlene Methode für Hochsicherheitsumgebungen.

Unzureichende Protokollierung und Überwachung. Die RADIUS-Erfassung (Accounting) protokolliert jedes Authentifizierungsereignis – Erfolg, Fehlschlag, Sitzungsstart, Sitzungsende. Diese Daten sind betrieblich wertvoll für die Kapazitätsplanung und kommerziell wertvoll für WiFi Analytics , aber sie sind auch eine kritische Quelle für Sicherheitstelemetrie. Häufungen von fehlgeschlagenen Authentifizierungen, Anmeldungen von unerwarteten MAC-Adressen und Zugriffsmuster außerhalb der Arbeitszeiten sind alle in den RADIUS-Accounting-Protokollen erkennbar. Die meisten Organisationen speisen diese Daten nicht in ein SIEM ein, und diejenigen, die es tun, haben oft keine Warnschwellenwerte konfiguriert.

Der BlastRADIUS-Angriff im Detail

BlastRADIUS wurde im Juli 2024 von Forschern der Boston University und der University of California San Diego offengelegt. Der Angriff erfordert eine Man-in-the-Middle-Position zwischen dem NAS und dem RADIUS-Server – realisierbar durch ARP-Spoofing in einem gemeinsamen Netzwerksegment, einen kompromittierten Router oder einen böswilligen Insider mit Netzwerkzugriff.

Der Angriff läuft wie folgt ab: Der Angreifer fängt ein Access-Request-Paket vom NAS ab. Da dem Paket das Attribut "Message-Authenticator" fehlt (der Standard in vielen Konfigurationen), kann der Angreifer die Attributliste des Pakets frei modifizieren. Mithilfe einer MD5-Chosen-Prefix-Kollision erstellt der Angreifer ein modifiziertes Paket, das bei der Verarbeitung durch den RADIUS-Server denselben Response Authenticator erzeugt wie das ursprüngliche Paket. Der Server gibt daher ein Access-Accept für eine Anfrage zurück, die vom Angreifer kontrollierte Attribute enthält – einschließlich eines Service-Type "Administrative", der vollen Netzwerkzugriff gewährt.

Der Angriff ist bei PEAP- und EAP-TTLS-Bereitstellungen anwendbar, bei denen die interne Methode MSCHAPv2 verwendet. EAP-TLS-Bereitstellungen sind davon nicht betroffen, da die zertifikatsbasierte gegenseitige Authentifizierung einen Integritätsschutz bietet, den MD5 nicht untergraben kann.

Für Organisationen, die Guest WiFi parallel zu Corporate 802.1X betreiben, muss auch die RADIUS-Instanz des Gastnetzwerks gepatcht werden, selbst wenn sie MAC-Authentication-Bypass anstelle von EAP nutzt. Die Anforderungen an die Sicherheit des Shared Secret und den Message-Authenticator gelten gleichermaßen.

Implementierungsleitfaden

Phase 1: Sofortige Behebung (Woche 1–2)

Die erste Priorität ist das Patchen. FreeRADIUS 3.2.5 und 3.0.27 enthalten den BlastRADIUS-Fix und erzwingen standardmäßig den Message-Authenticator. Cisco ISE 3.1 Patch 8, 3.2 Patch 4 und 3.3 Patch 1 beheben die Schwachstelle. Microsoft hat im Juli 2024 KB5040434 für Windows Server 2022 NPS veröffentlicht. Überprüfen Sie Ihre aktuellen Versionen und wenden Sie Patches innerhalb Ihres nächsten geplanten Änderungsfensters an.

Überprüfen Sie gleichzeitig die Firmware Ihrer NAS-Geräte. Die Durchsetzung des Message-Authenticators ist nur wirksam, wenn das NAS-Gerät das Attribut auch sendet. Prüfen Sie die Sicherheitshinweise Ihrer Access-Point- und Switch-Hersteller – Aruba, Ruckus, Cisco und Juniper haben alle Firmware-Updates zur Behebung von BlastRADIUS veröffentlicht. Wenn Sie Ruckus-Hardware verwenden, bietet der wireless access point Ruckus guide den entsprechenden Kontext zur Firmware-Verwaltung.

Bei der Behebung von Troubleshooting Windows 11 802.1X Authentication Issues , die nach dem Patch auftreten können, ist die häufigste Ursache, dass der NPS-Server Verbindungen von Clients ablehnt, die keinen Message-Authenticator enthalten – ein korrektes Sicherheitsverhalten, das bei älteren Windows-Clients möglicherweise eine Neukonfiguration des Supplicants erfordert.

Phase 2: Shared Secret Hygiene (Woche 2–4)

Exportieren Sie die vollständige Liste der auf Ihrem RADIUS-Server registrierten NAS-Clients. Erfassen Sie für jeden Eintrag die Länge des Shared Secret und das Datum der letzten Änderung. Jedes Geheimnis, das kürzer als 20 Zeichen ist oder seit mehr als 24 Monaten nicht geändert wurde, sollte sofort rotiert werden.

Verwenden Sie für neue Geheimnisse einen kryptografisch sicheren Zufallsgenerator – openssl rand -base64 32 erzeugt einen 44-stelligen Base64-String, der sich als RADIUS Shared Secret eignet. Speichern Sie alle Geheimnisse in einem Secrets-Management-System. Implementieren Sie einen Rotationsplan: jährlich für NAS-Geräte mit geringem Risiko, alle sechs Monate für NAS-Geräte im PCI-DSS-Scope.

Phase 3: EAP-Methoden-Rationalisierung (Monat 1–2)

Überprüfen Sie die zulässigen EAP-Methoden Ihres RADIUS-Servers. Deaktivieren Sie EAP-MD5. Wenn Sie PEAP-MSCHAPv2 ausführen, stellen Sie sicher, dass die Serverzertifikatsvalidierung auf allen Supplicants erzwungen wird – ein fehlkonfigurierter Supplicant, der jedes Serverzertifikat akzeptiert, ist anfällig für Angriffe durch betrügerische RADIUS-Server. Für Umgebungen im PCI-DSS-Scope ist EAP-TLS der empfohlene Weg. Beginnen Sie mit der PKI-Planung, falls Sie noch keine bestehende Zertifikatsinfrastruktur haben.

Hinweis für Securing Guest WiFi Networks : Gastnetzwerke verwenden in der Regel eine Captive Portal-Authentifizierung anstelle von 802.1X, sodass die Härtung der EAP-Methode in erster Linie für SSIDs von Unternehmen und Mitarbeitern gilt.

Phase 4: RadSec-Bereitstellung (Monat 2–3)

Identifizieren Sie alle RADIUS-Verkehrspfade, die unsichere Netzwerkgrenzen überschreiten. Typische Szenarien sind: ein zentraler RADIUS-Server, der entfernte Hotelobjekte über das Internet bedient; ein in der Cloud gehosteter RADIUS-Dienst, auf den von lokalen NAS-Geräten zugegriffen wird; und RADIUS-Proxy-Ketten, bei denen der Datenverkehr mehrere Netzwerkdomänen durchläuft.

Konfigurieren Sie RadSec für jeden identifizierten Pfad. Bei FreeRADIUS erfordert dies die Aktivierung des tls-Listeners auf Port 2083 und die Konfiguration von Mutual TLS mit Zertifikaten aus Ihrer PKI. Auf Cisco ISE wird RadSec unter Administration > Network Devices konfiguriert. Stellen Sie sicher, dass TLS 1.2 die Mindestversion ist; deaktivieren Sie TLS 1.0 und 1.1 explizit.

Phase 5: MFA für administrativen Zugriff (Monat 2–3)

Die Verwaltungsoberfläche des RADIUS-Servers ist ein lohnendes Ziel. Ein Angreifer, der den RADIUS-Server kompromittiert, kann Authentifizierungsrichtlinien ändern, Shared Secrets extrahieren und den Authentifizierungsverkehr umleiten. Erzwingen Sie MFA für alle administrativen Logins auf dem RADIUS-Server und dem zugrunde liegenden Betriebssystem. Beschränken Sie den Verwaltungszugriff auf ein dediziertes Out-of-Band-Management-VLAN. Implementieren Sie eine rollenbasierte Zugriffskontrolle: Netzwerktechniker sollten nicht dieselben Privilegien wie Sicherheitsadministratoren haben.

Phase 6: SIEM-Integration und Alarmierung (Monat 3–4)

Konfigurieren Sie Ihren RADIUS-Server so, dass er Accounting-Protokolle in Echtzeit an Ihr SIEM weiterleitet. Definieren Sie die folgenden Alarmschwellenwerte als Richtlinie:

Alarm	Schwellenwert	Dringlichkeit
Fehlgeschlagene Authentifizierungen von einzelner MAC	>5 in 60 Sekunden	Hoch
Spitzenwert bei Access-Reject-Rate	>200 % des 7-Tage-Richtwerts	Mittel
Authentifizierung von neuer MAC auf Firmen-SSID	Erstes Auftreten	Mittel
Ablauf des RADIUS-Serverzertifikats	90 / 30 / 7 Tage	Hoch / Kritisch / Kritisch
Fehler durch abweichende Shared Secrets	Jedes Auftreten	Hoch

Best Practices

Die folgenden Empfehlungen entsprechen dem Konsens von IEEE 802.1X, NIST SP 800-63B, PCI DSS v4.0 und Sicherheitsrichtlinien der Hersteller.

Zertifikatsverwaltung. Bei jeder Bereitstellung, die EAP-TLS oder RadSec nutzt, befinden sich X.509-Zertifikate im Authentifizierungspfad. Das Ablaufen von Zertifikaten ist die häufigste Ursache für plötzliche, vollständige Authentifizierungsausfälle in Enterprise WiFi-Umgebungen. Implementieren Sie ein automatisiertes Zertifikats-Lebenszyklusmanagement. Richten Sie Überwachungswarnungen 90, 30 und 7 Tage vor Ablauf ein. Verwenden Sie für RADIUS-Serverzertifikate eine Mindestschlüssellänge von 2048-Bit-RSA oder 256-Bit-ECDSA mit SHA-256 oder stärkeren Signaturalgorithmen. Verwenden Sie kein SHA-1.

Netzwerksegmentierung. Der RADIUS-Server sollte sich in einem dedizierten Management-Netzwerksegment befinden, das sowohl vom Gastnetzwerk als auch vom allgemeinen Unternehmensnetzwerk isoliert ist. Der Zugriff auf RADIUS-Ports (UDP 1812, 1813, TCP 2083 für RadSec) sollte per Firewall-ACL auf die spezifischen IP-Adressen registrierter NAS-Geräte beschränkt werden. Kein direkter Internetzugriff auf RADIUS-Ports. Redundanz und Hochverfügbarkeit. Ein einzelner RADIUS-Server stellt einen Single Point of Failure für Ihre gesamte Infrastruktur zur Netzwerkzugriffskontrolle dar. Implementieren Sie mindestens zwei RADIUS-Server in einer Aktiv-Passiv- oder Aktiv-Aktiv-Konfiguration. Bei Bereitstellungen im Bereich Hospitality mit Anforderungen an eine 24/7-Gästekonnektivität entspricht ein Ausfall des RADIUS-Servers direkt einem Ausfall des Gäste-WiFi – ein Reputations- und Geschäftsrisiko.

WPA3 und 802.1X. WPA3-Enterprise schreibt die Verwendung des 192-Bit-Sicherheitsmodus für Behörden und Hochsicherheitsumgebungen vor, was AES-256-GCMP für die Datenverschlüsselung und HMAC-SHA-384 für die Authentifizierung erfordert. Für die meisten Unternehmensumgebungen ist WPA3-Enterprise mit standardmäßiger 128-Bit-Sicherheit eine erhebliche Verbesserung gegenüber WPA2-Enterprise, insbesondere in Kombination mit EAP-TLS. Retail -Umgebungen, in denen Kartenzahlungen verarbeitet werden, sollten die Einführung von WPA3-Enterprise als Maßnahme zur Risikominderung gemäß PCI DSS betrachten.

Patch-Frequenz der Anbieter. Abonnieren Sie Sicherheitswarnungen von Ihrem RADIUS-Server-Anbieter und den Herstellern Ihrer NAS-Geräte. FreeRADIUS, Cisco, Microsoft, Aruba und Ruckus veröffentlichen alle CVE-Benachrichtigungen. Integrieren Sie diese in Ihr Schwachstellenmanagement-Programm mit einer definierten SLA: Kritische Schwachstellen (CVSS ≥ 9.0) werden innerhalb von 72 Stunden behoben, hohe Schwachstellen (CVSS 7.0–8.9) innerhalb von 14 Tagen.

Fehlerbehebung und Risikominderung

Häufige Fehlermuster

Authentifizierungsfehler nach Patches. Nach dem Einspielen von BlastRADIUS-Patches können einige NAS-Geräte die Authentifizierung verweigern, wenn ihre Firmware Message-Authenticator nicht unterstützt. Symptome: plötzlicher Anstieg von Access-Reject-Antworten ohne Änderung der Benutzeranmeldedaten. Diagnose: Aktivieren Sie das RADIUS-Debug-Logging und prüfen Sie auf den Fehler „Message-Authenticator required but not present“. Lösung: Aktualisieren Sie die NAS-Firmware oder konfigurieren Sie als Übergangsmaßnahme den RADIUS-Server so, dass er Anfragen ohne Message-Authenticator von bestimmten NAS-IPs akzeptiert, während Firmware-Updates geplant werden.

Zertifikatsvalidierungsfehler bei EAP-TLS. Symptome: Clients erhalten „Authentication Failed“ ohne entsprechenden Access-Reject in den RADIUS-Protokollen. Diagnose: Überprüfen Sie die Zertifikatskette des RADIUS-Servers – wird der ausstellenden Zertifizierungsstelle (CA) vom Supplicant des Clients vertraut? Befindet sich das Serverzertifikat innerhalb seines Gültigkeitszeitraums? Lösung: Stellen Sie sicher, dass die vollständige Zertifikatskette (Leaf + Intermediate + Root) auf dem RADIUS-Server konfiguriert ist. Verteilung des Root-CA-Zertifikats an Client-Geräte via MDM oder Gruppenrichtlinie.

RadSec-TLS-Handshake-Fehler. Symptome: NAS-Geräte können nach einer Konfigurationsänderung keine RadSec-Verbindungen aufbauen. Diagnose: TLS-Versionskompatibilität prüfen – ältere NAS-Firmware unterstützt möglicherweise kein TLS 1.2. Gegenseitige Zertifikatsauthentifizierung prüfen – beide Seiten müssen der CA des jeweils anderen vertrauen. Lösung: Überprüfen Sie die Unterstützung der TLS-Version in den Release Notes der NAS-Firmware; stellen Sie sicher, dass die Zertifikate der NAS-Geräte von derselben CA ausgestellt wurden, der auch der RADIUS-Server vertraut. Shared Secret Mismatch (Ungleicher gemeinsamer Schlüssel). Symptome: Alle Authentifizierungen von einem bestimmten NAS schlagen mit dem Fehler „Ungültiger Authentifikator“ fehl. Diagnose: Ungleicher gemeinsamer Schlüssel (Shared Secret) zwischen der NAS-Konfiguration und dem Client-Eintrag des RADIUS-Servers. Behebung: Geben Sie den gemeinsamen Schlüssel auf beiden Seiten erneut ein und stellen Sie sicher, dass keine nachfolgenden Leerzeichen oder Zeichenkodierungsprobleme vorliegen. Verwenden Sie Copy-Paste aus einem Secrets Manager, um Übertragungsfehler zu vermeiden.

Risikoregister

Risiko	Wahrscheinlichkeit	Auswirkung	Schadensbegrenzende Maßnahme
BlastRADIUS-Exploitation	Hoch (ohne Patch)	Kritisch	Patch + Erzwingen des Message-Authenticators
Shared-Secret-Brute-Force	Mittel	Hoch	Zufällige Schlüssel mit 32 Zeichen, jährliche Rotation
Nicht autorisierter RADIUS-Server	Mittel	Hoch	Gegenseitige EAP-TLS-Authentifizierung, Zertifikat-Pinning
Ablauf des RADIUS-Server-Zertifikats	Hoch	Kritisch	Automatisiertes Monitoring, Warnmeldungen 90 Tage vor Ablauf
Credential Stuffing via 802.1X	Mittel	Hoch	Kontosperrichtlinien, SIEM-Alarmierung
Kompromittierung des RADIUS-Servers	Niedrig	Kritisch	MFA für Admin-Zugriff, Netzwerksegmentierung

ROI und geschäftliche Auswirkungen

Quantifizierung des Risikos

Die finanzielle Argumentation für eine RADIUS-Härtung ist im Vergleich zu den Kosten einer Datenschutzverletzung offensichtlich. Die durchschnittlichen Kosten einer Datenschutzverletzung in Großbritannien beliefen sich im Jahr 2024 auf 3,58 Millionen £, einschließlich behördlicher Geldbußen, Behebungsmaßnahmen, Rechtskosten und Reputationsschäden. Für Unternehmen im Geltungsbereich von PCI DSS – wozu praktisch jeder Einzelhandels- und Gastronomie- Betreiber gehört, der Kartenzahlungen über WiFi abwickelt – löst eine Verletzung der Netzwerkzugriffskontrolle, bei der Karteninhaberdaten offengelegt werden, eine obligatorische forensische Untersuchung, potenzielle Geldstrafen von Kartensystemen und eine mögliche Aussetzung der Berechtigung zur Kartenverarbeitung aus.

Für Organisationen im Gesundheitswesen zieht eine GDPR-Verletzung, die Patientendaten betrifft, auf die über einen kompromittierten RADIUS-Server zugegriffen wurde, gemäß Artikel 83 Absatz 5 Geldbußen von bis zu 4 % des weltweiten Jahresumsatzes nach sich. Die Durchsetzungspraxis des ICO zeigt, dass Mängel in der Netzwerksicherheit als Fahrlässigkeit und nicht als technische Unfälle eingestuft werden.

Benchmarks für Implementierungskosten

Die folgenden Kostenschätzungen sind Richtwerte für ein Unternehmen mit 500 Geräten:

Härtungsmaßnahme	Geschätzte Kosten	Zeitrahmen
Patching (FreeRADIUS / NPS / ISE)	Nur interne Arbeitszeit	1–2 Wochen
Audit und Rotation von Shared Secrets	Interne Arbeitszeit + Lizenz für Secrets Manager (~2.000 £/Jahr)	2–4 Wochen
EAP-TLS PKI-Bereitstellung	15.000–30.000 £ (Tools + Professional Services)	2–3 Monate
RadSec-Implementierung	Interne Arbeitszeit + Zertifikatskosten (~1.500 £)	4–6 Wochen
SIEM-Integration und Alarmierung	Abhängig vom vorhandenen SIEM; 0–10.000 £	4–8 Wochen

Gesamtinvestition für die Härtung eines mittelgroßen Standorts: ca. 20.000–45.000 £. Verglichen mit den durchschnittlichen Kosten einer Datenschutzverletzung von 3,58 Millionen £ ist der risikobereinigte ROI selbst bei geringer Eintrittswahrscheinlichkeit überzeugend.

Betriebliche Vorteile über die Sicherheit hinaus

Eine gehärtete RADIUS-Infrastruktur bietet auch betriebliche Vorteile. Eine zuverlässige, gut überwachte Authentifizierung reduziert Helpdesk-Tickets im Zusammenhang mit der WiFi-Konnektivität. RADIUS-Accounting-Daten bieten in Kombination mit WiFi-Analysen Transparenz auf Sitzungsebene über Netzwerknutzungsmuster, Verweilzeiten und Gerätetypen – Daten, die einen direkten kommerziellen Wert für Standortbetreiber in den Bereichen Gastgewerbe und Transport haben.

Für Organisationen des öffentlichen Sektors und des Gesundheitswesens liefert ein dokumentiertes Programm zur RADIUS-Härtung den Nachweis technischer Kontrollen für Cyber Essentials Plus, ISO 27001- und NHS DSPT-Bewertungen – dies reduziert den Audit-Aufwand und belegt die gebotene Sorgfalt gegenüber den Aufsichtsbehörden.

Schlüsseldefinitionen

RADIUS (Remote Authentication Dial-In User Service)

Ein in RFC 2865 definiertes Client-Server-Protokoll, das eine zentrale Authentifizierung, Autorisierung und Benutzererfassung (AAA) für den Netzwerkzugriff bereitstellt. RADIUS-Server validieren von Netzwerkgeräten (NAS) übermittelte Anmeldedaten mit einem Identitätsspeicher im Backend wie Active Directory oder LDAP.

IT-Teams begegnen RADIUS als Authentifizierungs-Backend für 802.1X WiFi, kabelgebundene Port-Authentifizierung, VPN-Zugang und Netzwerkgeräteverwaltung. Es ist das Protokoll, das entscheidet, wer Zugriff auf das Netzwerk erhält.

IEEE 802.1X

Ein IEEE-Standard für portbasierte Netzwerkzugriffskontrolle, der die Kapselung von EAP über LAN (EAPOL) definiert. Er bietet ein Authentifizierungs-Framework für kabelgebundene und drahtlose Netzwerke, das vorschreibt, dass sich Geräte authentifizieren müssen, bevor ihnen Netzwerkzugriff gewährt wird.

802.1X ist der Standard, der die WiFi-Authentifizierung in Unternehmen ermöglicht. Wenn sich ein Mitarbeiter mit einer Unternehmens-SSID verbindet und zur Eingabe von Anmeldedaten aufgefordert wird, ist 802.1X das Framework, das diesen Austausch orchestriert, mit RADIUS als Backend.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

Eine EAP-Methode, die X.509-Zertifikate für die gegenseitige Authentifizierung zwischen dem Client und dem RADIUS-Server verwendet. Beide Parteien müssen gültige Zertifikate vorlegen, wodurch Passwörter vollständig aus dem Authentifizierungsprozess eliminiert werden.

EAP-TLS ist der Goldstandard für die WiFi-Authentifizierung in Unternehmen. Es ist immun gegen Phishing von Anmeldedaten und Brute-Force-Angriffe. Die betriebliche Voraussetzung ist eine PKI-Infrastruktur zur Ausstellung und Verwaltung von Client-Zertifikaten.

RadSec (RADIUS over TLS)

Ein in RFC 6614 definiertes Protokoll, das RADIUS-Pakete innerhalb einer TLS-Sitzung über TCP-Port 2083 kapselt. Es bietet Verschlüsselung auf Transportebene, gegenseitige Zertifikatsauthentifizierung und Replay-Schutz für den RADIUS-Datenverkehr.

RadSec ist für jeglichen RADIUS-Datenverkehr erforderlich, der eine unvertrauenswürdige Netzwerkgrenze überschreitet – WAN-Verbindungen, Internetverbindungen oder gemeinsam genutzte Netzwerkinfrastrukturen. Es ist der richtige Ersatz für Standard-RADIUS über UDP in Multi-Site-Bereitstellungen.

BlastRADIUS (CVE-2024-3596)

Ein im Juli 2024 veröffentlichter Man-in-the-Middle-Angriff, der das Fehlen eines Integritätsschutzes bei RADIUS-Access-Request-Paketen ausnutzt. Mithilfe von MD5-Chosen-Prefix-Kollisionstechniken kann ein Angreifer eine Access-Accept-Antwort fälschen und einem nicht authentifizierten Benutzer Netzwerkzugriff gewähren.

BlastRADIUS betrifft alle wichtigen RADIUS-Implementierungen, einschließlich FreeRADIUS, Cisco ISE und Microsoft NPS. Organisationen, die die im Juli 2024 veröffentlichten Patches nicht eingespielt haben, sind diesem Angriff weiterhin ausgesetzt.

Message-Authenticator

Ein RADIUS-Attribut (Attribut 80), das einen HMAC-MD5-Integritätsschutz für das gesamte RADIUS-Paket bietet. Wenn es in einem Access-Request vorhanden ist, verhindert es den Paketmodifikationsangriff, der bei BlastRADIUS verwendet wird.

Die Erzwingung von Message-Authenticator bei allen Access-Request-Paketen ist die primäre Maßnahme zur Behebung von BlastRADIUS. Dies muss sowohl auf dem RADIUS-Server (um das Attribut zu fordern) als auch auf dem NAS-Gerät (um das Attribut in Anfragen aufzunehmen) konfiguriert werden.

NAS (Network Access Server)

In der RADIUS-Terminologie ist das NAS das Netzwerkgerät – in der Regel ein WiFi-Access-Point, ein Switch oder ein VPN-Konzentrator –, das als RADIUS-Client fungiert. Es fängt Verbindungsanfragen von Endgeräten ab und leitet Authentifizierungsanfragen an den RADIUS-Server weiter.

NAS-Geräte sind die RADIUS-Clients in einer Bereitstellung. Shared Secrets werden pro NAS konfiguriert. Die Behebung von BlastRADIUS erfordert Firmware-Updates auf den NAS-Geräten sowie Patches auf dem RADIUS-Server.

PEAP (Protected Extensible Authentication Protocol)

Eine EAP-Methode, die einen TLS-Tunnel unter Verwendung eines serverseitigen Zertifikats aufbaut, bevor die interne Authentifizierungsmethode (in der Regel MSCHAPv2) übertragen wird. Sie bietet eine gegenseitige Authentifizierung und schützt Anmeldedaten vor dem Abhören.

PEAP-MSCHAPv2 ist die am weitesten verbreitete Methode zur WiFi-Authentifizierung in Unternehmen. Sie ist PCI DSS-konform und betrieblich einfacher als EAP-TLS, da sie keine Client-Zertifikate erfordert. Sie ist jedoch anfällig für Angriffe durch gefälschte RADIUS-Server, wenn die clientseitige Zertifikatsvalidierung nicht erzwungen wird.

Shared Secret

Ein vorab freigegebener Schlüssel, der sowohl auf dem RADIUS-Server als auch auf jedem NAS-Gerät konfiguriert ist. Er wird verwendet, um das Feld „Response Authenticator“ zu generieren und das Attribut „User-Password“ zu verschleiern. Es ist kein Passwort für Endbenutzer, sondern ein Berechtigungsnachweis zur Server-zu-Server-Authentifizierung.

Schwache oder statische Shared Secrets gehören zu den häufigsten RADIUS-Sicherheitslücken. Ein Angreifer, der RADIUS-Datenverkehr abfängt, kann einen Offline-Brute-Force-Angriff gegen ein schwaches Shared Secret durchführen. Die empfohlene Mindestlänge beträgt 32 zufällig generierte Zeichen.

PCI DSS (Payment Card Industry Data Security Standard)

Ein Satz von Sicherheitsstandards, die von den großen Kartenorganisationen (Visa, Mastercard, Amex) für Unternehmen vorgeschrieben werden, die Karteninhaberdaten verarbeiten, speichern oder übertragen. Version 4.0, gültig ab März 2024, enthält spezifische Anforderungen für Netzwerkzugriffskontrolle und starke Authentifizierung.

Einzelhandels- und Gastronomieunternehmen mit WiFi-verbundenen POS-Terminals fallen in den Geltungsbereich von PCI DSS. RADIUS-Server-Schachstellen, die unbefugten Netzwerkzugriff auf Karteninhaber-Datenumgebungen ermöglichen könnten, stellen ein direktes Compliance-Risiko dar.

Ausgearbeitete Beispiele

Eine Hotelgruppe mit 12 Standorten und insgesamt 350 Zimmern nutzt einen zentralisierten RADIUS-Server, der in ihrem Hauptsitz-Rechenzentrum gehostet wird. Jeder Standort ist über ein gemeinsam genutztes MPLS-WAN angebunden. Bei einem Sicherheitsaudit wurde bemängelt, dass der RADIUS-Datenverkehr über das WAN unverschlüsselt ist, die Shared Secrets 8-stellige Zeichenfolgen sind, die bei der Ersteinrichtung vor fünf Jahren festgelegt wurden, und auf dem RADIUS-Server FreeRADIUS 3.0.21 läuft. Die Gruppe verarbeitet Kartenzahlungen über WiFi-verbundene POS-Terminals in ihren Restaurant- und Wellnessbereichen. Wie sehen die Priorisierung der Behebung und die Implementierungsreihenfolge aus?

Die Reihenfolge der Behebung sollte nach der Schwere des Risikos und der Implementierungsgeschwindigkeit gestaffelt sein. Schritt 1 (sofort, innerhalb von 72 Stunden): Patchen Sie FreeRADIUS auf 3.2.5 oder 3.0.27. Dies behebt BlastRADIUS und erzwingt standardmäßig den Message-Authenticator. Überprüfen Sie gleichzeitig die Firmware-Versionen der Access Points an allen 12 Standorten und planen Sie Firmware-Updates für alle NAS-Geräte ein, die den Message-Authenticator nicht unterstützen. Schritt 2 (Woche 1–2): Rotieren Sie alle Shared Secrets. Generieren Sie zufällige 32-stellige Secrets mit openssl rand -base64 32 für jede der 12 NAS-Registrierungen der Standorte. Speichern Sie diese in HashiCorp Vault oder einer gleichwertigen Lösung. Dokumentieren Sie das Rotationsdatum. Schritt 3 (Monat 1–2): Implementieren Sie RadSec auf dem WAN-Pfad. Konfigurieren Sie den FreeRADIUS-Server so, dass er RadSec-Verbindungen auf TCP 2083 akzeptiert. Stellen Sie TLS-Zertifikate von einer internen CA für die NAS-Geräte der einzelnen Standorte aus. Aktualisieren Sie die Firewall-Regeln, um TCP 2083 aus den NAS-IP-Bereichen der Standorte zum RADIUS-Server zuzulassen. Deaktivieren Sie UDP 1812/1813 auf den WAN-Schnittstellen, sobald der Betrieb von RadSec bestätigt wurde. Schritt 4 (Monat 2–3): Migrieren Sie für die im PCI-DSS-Bereich liegende POS-WiFi-SSID von PEAP-MSCHAPv2 auf EAP-TLS. Stellen Sie eine interne PKI bereit (Microsoft ADCS oder HashiCorp Vault PKI-Engine). Stellen Sie Client-Zertifikate per MDM für die POS-Terminals aus. Aktualisieren Sie die RADIUS-Richtlinie so, dass EAP-TLS für die POS-SSID erforderlich ist. Schritt 5 (Monat 3): Integrieren Sie die RADIUS-Accounting-Logs in das SIEM. Konfigurieren Sie Warnmeldungen für Spitzenwerte bei fehlgeschlagenen Authentifizierungen und abgelaufene Zertifikate.

Kommentar des Prüfers: Dieses Szenario ist repräsentativ für die Mehrheit der Hospitality-Bereitstellungen an mehreren Standorten. Die wichtigste Erkenntnis ist, dass das MPLS-WAN, obwohl es sich nicht um das öffentliche Internet handelt, ein gemeinsam genutztes Netzwerk ist, das nicht als völlig vertrauenswürdig eingestuft werden kann – insbesondere in einer Hotelgruppe, in der das WAN von einem Drittanbieter verwaltet werden kann. RadSec ist daher nicht optional. Der PCI-DSS-Aspekt ist kritisch: Die POS-Terminals im WiFi fallen unter die PCI-DSS-Anforderung 8.3 (starke Authentifizierung) und Anforderung 4.2.1 (starke Kryptographie für Daten bei der Übertragung). EAP-TLS erfüllt beide Anforderungen. Die Sequenzierung priorisiert das Patchen an erster Stelle, da BlastRADIUS eine aktive, ausnutzbare Schwachstelle ist; die anderen Härtungsschritte sind wichtig, bergen jedoch nicht dasselbe unmittelbare Risiko. Ein alternativer Ansatz – die Migration zu einem cloudgehosteten RADIUS-as-a-SaaS – wurde zwar in Betracht gezogen, für dieses Szenario jedoch aufgrund der bestehenden MPLS-Investitionen der Gruppe und der Komplexität einer gleichzeitigen Migration von 12 Standorten verworfen.

Eine regionale Einzelhandelskette mit 45 Filialen nutzt WPA2-Personal (Pre-Shared Key) für das Mitarbeiter-WiFi und ein offenes Netzwerk für das Kunden-WiFi. Der IT-Leiter möchte das Mitarbeiter-WiFi auf 802.1X-Authentifizierung umstellen, wobei Microsoft NPS als RADIUS-Server in Active Directory integriert werden soll. Die Filialen verfügen über eine Mischung aus Aruba- und Cisco-Access-Points. Die Kette fällt in den PCI-DSS-Bereich. Welche Architektur sollte implementiert werden und was sind die wichtigsten Konfigurationsentscheidungen?

Die empfohlene Architektur ist 802.1X mit PEAP-MSCHAPv2 als anfängliche EAP-Methode, mit einer dokumentierten Roadmap für den Übergang zu EAP-TLS. Der NPS-Server sollte als redundantes Paar (primär + sekundär) im zentralen Rechenzentrum bereitgestellt werden, mit RADIUS-Proxy-Konfiguration auf den Access Points für ein automatisches Failover. Konfigurationsentscheidungen: (1) NPS-Netzwerkrichtlinie: Erstellen Sie eine Richtlinie, die mit der Mitarbeiter-SSID und PEAP-MSCHAPv2 übereinstimmt und die Gruppenmitgliedschaft in einer AD-Sicherheitsgruppe (z. B. „WiFi-Staff-Access“) erfordert. Setzen Sie das Sitzungstimeout auf 8 Stunden, um eine erneute Authentifizierung zu erzwingen. (2) Zertifikat: Stellen Sie ein NPS-Serverzertifikat von einer internen Microsoft ADCS CA bereit. Verteilen Sie das Root-CA-Zertifikat über Gruppenrichtlinien (Windows) und MDM (iOS/Android) an alle Mitarbeitergeräte. (3) Supplicant-Konfiguration: Konfigurieren Sie Windows-Geräte über Gruppenrichtlinien (Computerkonfiguration > Windows-Einstellungen > Sicherheitseinstellungen > Drahtlosnetzwerk-Richtlinien). Verwenden Sie für iOS- und Android-Geräte ein MDM-Profil. Erzwingen Sie die Validierung des Serverzertifikats – erlauben Sie Benutzern nicht, beliebige Zertifikate zu akzeptieren. (4) Access-Point-Konfiguration: Konfigurieren Sie auf Aruba den RADIUS-Server unter Authentifizierung > Server. Setzen Sie das Shared Secret auf eine zufällige 32-stellige Zeichenfolge. Aktivieren Sie RadSec, wenn die Aruba-Firmware dies unterstützt (AOS 8.9+). Konfigurieren Sie auf Cisco unter Sicherheit > AAA > RADIUS. (5) NPS-Protokollierung: Aktivieren Sie die NPS-Accounting-Protokollierung in einer SQL Server-Datenbank. Konfigurieren Sie eine Protokollaufbewahrungsfrist von mindestens 90 Tagen für die PCI-DSS-Compliance. (6) Nach der Migration: Deaktivieren Sie WPA2-Personal auf der Mitarbeiter-SSID. Behalten Sie es nur als Notfall-SSID mit einem komplexen PSK bei, der im Secrets-Manager gespeichert ist, um es nur dann zu verwenden, wenn der NPS nicht verfügbar ist.

Kommentar des Prüfers: Die Migration von WPA2-Personal zu 802.1X ist eines der häufigsten Security-Upgrade-Projekte in der Einzelhandels-IT. Das Hauptrisiko in diesem Szenario ist die gemischte Infrastruktur der Access Points – Aruba und Cisco verfügen über unterschiedliche Schnittstellen für die RADIUS-Client-Konfiguration, und der Prozess zur Rotation der Shared Secrets muss für jeden Hersteller separat verwaltet werden. Die Entscheidung, mit PEAP-MSCHAPv2 anstelle von EAP-TLS zu beginnen, ist pragmatisch: Sie vermeidet die Komplexität einer PKI-Bereitstellung und bietet gleichzeitig eine erhebliche Sicherheitsverbesserung gegenüber PSK. Die Roadmap für EAP-TLS sollte an den Zeitplan für den MDM-Rollout gekoppelt sein – die Bereitstellung von Client-Zertifikaten ist betrieblich erst dann sinnvoll, wenn alle Geräte im MDM registriert sind. Der PCI-DSS-Aspekt bekräftigt die Anforderung an die NPS-Protokollierung: Die PCI-DSS-Anforderung 10.2.1 schreibt die Protokollierung aller individuellen Benutzerzugriffe auf Karteninhaberdaten vor, was auch Netzwerkzugriffsereignisse einschließt.

Übungsfragen

Q1. Ihre Organisation betreibt einen FreeRADIUS 3.0.21-Server, der die 802.1X-Authentifizierung für 800 Mitarbeitergeräte an einem einzigen Standort unterstützt. Der RADIUS-Server befindet sich im selben Management-VLAN wie alle Access Points. Ein Penetrationstest hat ergeben, dass Access Points Access-Request-Pakete ohne das Message-Authenticator-Attribut senden. Das Sicherheitsteam möchte Message-Authenticator sofort erzwingen, aber das Netzwerkbetriebsteam befürchtet, dass die Authentifizierung für 800 Benutzer beeinträchtigt wird. Wie planen Sie die Reihenfolge der Behebung, um Serviceunterbrechungen zu minimieren?

Hinweis: Bedenken Sie den Unterschied zwischen dem RADIUS-Server, der Message-Authenticator erfordert, und den NAS-Geräten, die ihn senden. Dies sind zwei separate Konfigurationsänderungen mit unterschiedlichen Risikoprofilen.

Musterlösung anzeigen

Die richtige Reihenfolge ist: (1) Aktualisieren Sie FreeRADIUS zunächst auf Version 3.2.5. Diese Version erzwingt Message-Authenticator standardmäßig, enthält jedoch einen Kompatibilitätsmodus, der eine Warnung protokolliert, anstatt Pakete ohne das Attribut abzulehnen. Dies ermöglicht das Einspielen des Patches, ohne die Authentifizierung sofort zu unterbrechen. (2) Überprüfen Sie die Firmware-Versionen der Access Points. Identifizieren Sie, welche Modelle und Firmware-Versionen Message-Authenticator in Access-Request-Paketen unterstützen. (3) Aktualisieren Sie die Firmware der Access Points schrittweise, beginnend mit einer Pilotgruppe von 50 Geräten. Überprüfen Sie nach jedem Batch, ob die Authentifizierung weiterhin funktioniert. (4) Sobald bestätigt ist, dass alle Access Points Message-Authenticator senden, aktivieren Sie die strikte Durchsetzung auf dem FreeRADIUS-Server (require_message_authenticator = yes in clients.conf). (5) Überwachen Sie die RADIUS-Protokolle auf verbleibende Warnungen bezüglich fehlender Message-Authenticator, was auf NAS-Geräte hinweisen würde, bei denen das Firmware-Update vergessen wurde. Das Schlüsselprinzip besteht darin, dass Sie den Server zuerst patchen können, ohne den Betrieb zu stören, da der Kompatibilitätsmodus eine Übergangsphase ermöglicht. Die strikte Ablehnung auf dem Server zu erzwingen, sollte der letzte Schritt sein, nachdem alle NAS-Geräte aktualisiert wurden.

Q2. Ein Konferenzzentrum-Betreiber betreibt einen einzigen RADIUS-Server, der sowohl die SSID der Mitarbeiter (802.1X mit PEAP-MSCHAPv2) als auch das Event-Gast-WiFi (Captive Portal mit MAC Authentication Bypass) unterstützt. Der IT-Leiter fragt, ob die RADIUS-Instanz des Gast-WiFi nach demselben Standard wie die Unternehmens-RADIUS-Instanz gehärtet werden muss, da sich Gäste nicht mit Unternehmens-Anmeldedaten authentifizieren. Was ist Ihre Empfehlung?

Hinweis: Bedenken Sie die Angriffsvektoren für MAC Authentication Bypass im Vergleich zur EAP-basierten Authentifizierung sowie das Risiko einer lateralen Bewegung zwischen den Gast- und Unternehmens-RADIUS-Instanzen.

Musterlösung anzeigen

Die RADIUS-Instanz des Gast-WiFi erfordert eine Härtung, die spezifischen Kontrollen unterscheiden sich jedoch von der Unternehmensinstanz. Der BlastRADIUS-Patch gilt gleichermaßen – die Schwachstelle betrifft den RADIUS-Server unabhängig von der von den Clients verwendeten Authentifizierungsmethode. Die Hygiene gemeinsamer Passwörter (Shared Secrets) gilt gleichermaßen – ein schwaches Shared Secret zwischen dem Gast-Captive Portal-Controller und dem RADIUS-Server ist ausnutzbar, unabhängig davon, ob EAP verwendet wird. Das wesentliche zusätzliche Risiko ist der gemeinsam genutzte RADIUS-Server: Wenn die Authentifizierungsanfragen für Gast- und Unternehmens-SSID vom selben RADIUS-Serverprozess verarbeitet werden, könnte eine Schwachstelle im Pfad des Gast-RADIUS genutzt werden, um auf die Authentifizierungsrichtlinie des Unternehmens zuzugreifen. Die empfohlene Architektur besteht darin, separate RADIUS-Instanzen (oder mindestens separate virtuelle Server innerhalb von FreeRADIUS) für die Gast- und Unternehmensauthentifizierung mit separaten Shared Secrets und separaten Richtliniensätzen zu betreiben. Dies sorgt für eine Isolierung, sodass eine Kompromittierung des Gast-RADIUS-Pfads keine Unternehmens-Anmeldedaten offenlegt. Speziell für die Gast-Instanz: Patchen Sie gegen BlastRADIUS, rotieren Sie Shared Secrets und stellen Sie sicher, dass die Gast-RADIUS-Instanz keinen Zugriff auf das Active Directory des Unternehmens hat. Die EAP-TLS- und RadSec-Anforderungen sind für eine Captive Portal-Bereitstellung weniger relevant, RadSec sollte jedoch dennoch in Betracht gezogen werden, wenn sich der Captive Portal-Controller in einem anderen Netzwerksegment als der RADIUS-Server befindet.

Q3. Ein Gesundheitsnetzwerk plant, sein klinisches WiFi von WPA2-Personal auf eine 802.1X-Authentifizierung umzustellen. Das Netzwerk verfügt über 1.200 klinische Geräte, darunter Windows-Laptops, iOS-Tablets und Android-Handhelds. Der CISO wünscht sich EAP-TLS als Zielzustand. Der IT-Direktor ist besorgt über die Komplexität der PKI-Bereitstellung und schlägt PEAP-MSCHAPv2 als dauerhafte Lösung vor. Wie beraten Sie den CISO und den IT-Direktor, und was ist der empfohlene Implementierungspfad?

Hinweis: Bedenken Sie das spezifische Bedrohungsmodell für eine Gesundheitsumgebung – was sind die Folgen einer Kompromittierung von Anmeldedaten und wie adressiert EAP-TLS Risiken, die PEAP-MSCHAPv2 nicht abdeckt?

Musterlösung anzeigen

Das Gespür des CISOs ist richtig, aber die Sorge des IT-Direktors ist berechtigt. Die empfohlene Vorgehensweise lautet: Implementieren Sie PEAP-MSCHAPv2 jetzt als Zwischenlösung mit einer verbindlichen 12-Monats-Roadmap zu EAP-TLS. Die Gründe, PEAP-MSCHAPv2 im Gesundheitswesen nicht als dauerhafte Lösung zu akzeptieren, sind: (1) PEAP-MSCHAPv2 ist anfällig für Angriffe mit gefälschten RADIUS-Servern, wenn die clientseitige Zertifikatsvalidierung nicht erzwungen wird. In einer Gesundheitsumgebung, in der klinisches Personal persönliche Geräte verbinden kann, ist die konsistente Durchsetzung der Supplicant-Konfiguration auf 1.200 Geräten operativ anspruchsvoll. (2) Wenn MSCHAPv2-Anmeldedaten über einen gefälschten RADIUS-Angriff abgefangen werden, können sie offline mit Tools wie Hashcat geknackt werden. Im Gesundheitswesen bieten diese Anmeldedaten wahrscheinlich auch Zugriff auf klinische Systeme. (3) NHS DSPT- und CQC-Bewertungen erwarten zunehmend starke Authentifizierungskontrollen für den Zugriff auf klinische Netzwerke. EAP-TLS bietet eine stärkere Position für Audit-Nachweise. Der Implementierungspfad: Monat 1-2: Bereitstellung von PEAP-MSCHAPv2 mit erzwungener Serverzertifikatsvalidierung über MDM-Profile auf allen 1.200 Geräten. Monat 3-6: Bereitstellung von Microsoft ADCS als PKI-Infrastruktur. Registrierung von Windows-Geräten über Gruppenrichtlinien-Auto-Enrolment. Monat 6-9: Registrierung von iOS- und Android-Geräten über MDM-Zertifikatsprofile. Monat 9-12: Migration der klinischen SSID-Richtlinie von PEAP zu EAP-TLS. Beibehalten von PEAP als Fallback für Geräte, bei denen die Zertifikatsregistrierung fehlschlägt, mit erweitertem Monitoring. Weitere Informationen zur Sicherheitsarchitektur klinischer Netzwerke finden Sie im WiFi in Hospitals guide .

Weiterlesen in dieser Reihe

Drei SSIDs, um sie alle zu beherrschen: Einrichtungsleitfaden für Gäste-, Mitarbeiter- und IoT-WiFi

Dieser maßgebliche technische Leitfaden bietet einen schrittweisen Entwurf für die Implementierung einer Drei-SSID-WiFi-Architektur. Er erklärt, wie Sie Gäste-, Mitarbeiter- und IoT-Traffic mithilfe von Captive Portals, 802.1X RADIUS und gerätespezifischen PSK (xPSK) segmentieren, um die Leistung zu optimieren und die PCI-DSS-Compliance zu gewährleisten.

CommScope Ruckus Integration mit Purple WiFi: Einrichtungs- und Konfigurationshandbuch

Dieses technische Referenzhandbuch bietet einen maßgeblichen Konfigurationsleitfaden für die Integration von CommScope Ruckus-Architekturen mit Purple WiFi. Es beschreibt Schritt-für-Schritt-Bereitstellungen für Guest WiFi Captive Portals, sicheres Mitarbeiter-WiFi über 802.1X und mandantenfähige Netzwerkisolierung mithilfe von Ruckus Dynamic PSK.

Allied Telesis Access Points Integration mit Purple WiFi

Dieses Handbuch bietet eine umfassende Konfigurationsanleitung für die Integration von Allied Telesis Access Points der TQ-Serie mit Purple WiFi. Es behandelt die externe Captive Portal-Weiterleitung, die 802.1X-RADIUS-Authentifizierung und die dynamische VLAN-Steuerung mithilfe von Private Pre-Shared Keys (PPSK) für sichere Multi-Tenant-Bereitstellungen.