Minimierung von RADIUS Sicherheitslücken: Ein Leitfaden zur Härtung der Sicherheit
Dieser Leitfaden bietet eine umfassende, praxisnahe Referenz für IT-Leiter, Netzwerkarchitekten und CTOs, die für die Enterprise WiFi Infrastruktur in den Bereichen Hotellerie, Einzelhandel, Events 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 falsch konfigurierten EAP-Methoden - und liefert eine prioritäre Roadmap zur Härtung der Sicherheit, die auf die Anforderungen von IEEE 802.1X, PCI-DSS und GDPR abgestimmt ist. Unternehmen, die diese Empfehlungen umsetzen, reduzieren ihr Risiko für auf Anmeldedaten basierende Netzwerkangriffe erheblich, erfüllen Compliance-Verpflichtungen und bauen eine verteidigungsfähige Sicherheitsstruktur für ihre Gäste- und Unternehmens-WiFi-Infrastruktur auf.
Video overview
Diesen Leitfaden anhören
Podcast-Transkript ansehen
Teil unserer Kernserie: Enterprise WiFi Sicherheitsleitfaden →
Executive Summary
RADIUS (Remote Authentication Dial-In User Service) bleibt das wichtigste Protokoll für die Netzwerkzugriffskontrolle in Enterprise WiFi -Bereitstellungen und unterstützt die 802.1X -Authentifizierung in Hotels, Einzelhandelsgeschäften, Stadien, Konferenzzentren und Gebäuden des öffentlichen Sektors. Die Architektur von RADIUS stammt jedoch aus den 1990er Jahren, und mehrere grundlegende Designentscheidungen - die Abhängigkeit von MD5-Hashes, der UDP-Transport ohne native Verschlüsselung und statische Shared Secrets - stellen in der heutigen Bedrohungslandschaft erhebliche Risiken dar.
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 eine MD5-Integritätsschwachstelle in Access-Request-Paketen ausnutzt. Diese Schwachstelle betrifft alle wichtigen RADIUS-Implementierungen, einschließlich FreeRADIUS, Cisco ISE und Microsoft NPS. Nicht gepatchte Bereitstellungen sind weiterhin gefährdet.
Dieser Leitfaden bietet eine priorisierte Roadmap zur Härtung, die Patch-Management, Shared Secret-Hygiene, die Auswahl von EAP-Methoden, die RadSec-Bereitstellung, Multi-Faktor-Authentifizierung für den Administratorzugriff und die SIEM-Integration für die Anomalieerkennung abdeckt. Er richtet sich an IT-Experten, die in diesem Quartal - und nicht erst im nächsten Jahr - fundierte Entscheidungen treffen müssen.
Technische Tiefenanalyse
Funktionsweise von RADIUS und seine Schwachstellen
RADIUS arbeitet als Client-Server-Protokoll zwischen einem Network Access Server (NAS) - in der Regel ein WiFi -Access-Point, ein Switch oder ein VPN-Konzentrator - und einem RADIUS-Server, der die Anmeldedaten mit einem Backend-Identitätsspeicher wie Microsoft Entra ID oder LDAP abgleicht. Der Authentifizierungsaustausch folgt dem in RFC 2865 definierten Request-Challenge-Response-Modell, während das Accounting separat gemäß RFC 2866 behandelt wird.
Das Protokoll überträgt Authentifizierungspakete über UDP unter Verwendung von Port 1812 für die Authentifizierung und Port 1813 für das Accounting. Ein Shared Secret - ein auf dem NAS und dem RADIUS-Server konfiguriertes Pre-Shared Secret - wird verwendet, um das Feld Response Authenticator zu generieren und das Attribut User-Password über eine MD5-basierte XOR-Chiffre zu verschlüsseln. Dies ist keine Verschlüsselung im modernen Sinne, sondern eine reine Verschleierung, die vollständig von der Geheimhaltung und Stärke des Shared Secrets abhängt.
Es gibt fünf primäre Schwachstellenkategorien in einer typischen RADIUS-Bereitstellung.
MD5-Kollisionen und Integritätsschwachstellen. Der BlastRADIUS -Angriff (CVE-2024-3596) nutzt das Fehlen von Integritätsschutz in Access-Request-Paketen aus. Da viele Konfigurationen standardmäßig das Attribut Message-Authenticator vom NAS weglassen, kann ein Angreifer in einer Man-in-the-Middle-Position manipulierte Attribute in ein Paket einschleusen, bevor es den RADIUS-Server erreicht. Mithilfe einer MD5 Chosen-Prefix-Kollisionstechnik kann der Angreifer das Paket so manipulieren, dass der RADIUS-Server einen gültigen Response Authenticator für das geänderte 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 Attribut Message-Authenticator in allen Access-Request-Paketen zu erzwingen, was einen HMAC-MD5-Integritätsschutz über das gesamte Paket hinweg bietet. Dies erfordert Konfigurationsänderungen sowohl auf dem NAS als auch auf dem RADIUS-Server, nicht nur Server-Patches.
Schwache oder statische Shared Secrets. Das Shared Secret ist der kryptografische Anker des RADIUS-Austauschs. Wenn das Secret kurz, vorhersehbar oder nie rotiert ist, kann ein Angreifer, der RADIUS-Datenverkehr abfängt (was über ARP-Spoofing oder ein kompromittiertes Netzwerkgerät möglich ist), das Attribut User-Password offline per Brute-Force knacken. Die NIST SP 800-63B-Richtlinien für memorierte Secrets gelten auch hier: Keys sollten mindestens 20 Zeichen lang sein, zufällig generiert und in einem Key-Management-System gespeichert werden. Bei großen Netzwerken mit Dutzenden oder Millionen von NAS-Geräten ist eine manuelle Rotation operativ nicht machbar - eine Automatisierung über HashiCorp Vault oder einen ähnlichen Key-Manager ist hier der richtige Weg.
Unverschlüsselter UDP-Transport. Standard-RADIUS über UDP bietet keine Vertraulichkeit auf Transportebene. Das Attribut User-Password ist verschleiert, aber nicht verschlüsselt. Alle anderen Attribute - einschließlich Benutzernamen, NAS-IPs und Sitzungs-Metadaten - werden im Klartext übertragen. RadSec (RADIUS over TLS), definiert in RFC 6614 und aktualisiert in RFC 7360, löst dieses Problem, indem es das RADIUS-Protokoll in einen TLS-Tunnel über TCP-Port 2083 packt und eine TLS 1.2- oder TLS 1.3-Sitzung aufbaut. RadSec bietet gegenseitige Zertifikatsauthentifizierung, vollständige Payload-Verschlüsselung und Replay-Schutz zwischen dem NAS und dem RADIUS-Server. Es ist der einzig richtige Transportweg für RADIUS-Datenverkehr, der ungesicherte Netzwerkgrenzen überschreitet.
Auswahl der EAP-Methode. Das Extensible Authentication Protocol (EAP) definiert die internen Authentifizierungsmethoden, die innerhalb des 802.1X -Frameworks verwendet werden. EAP-MD5 ist veraltet und sollte sofort aus allen Bereitstellungen entfernt werden - es bietet keine gegenseitige Authentifizierung und keinen Schutz gegen Angriffe zum Abgreifen von Anmeldedaten. PEAP (Protected EAP) und EAP-TTLS verwenden ein Serverzertifikat, um vor der Übertragung von Anmeldedaten einen TLS-Tunnel aufzubauen, was eine gegenseitige Authentifizierung ermöglicht und die interne Methode vor Abhören schützt. EAP-TLS macht Passwörter überflüssig, indem es sowohl auf dem Server als auch auf dem Client X.509-Zertifikate voraussetzt. Es ist immun gegen Phishing- und Brute-Force-Angriffe und die empfohlene Methode für hochsichere Umgebungen.
Ungenügende Protokollierung und Überwachung. RADIUS-Accounting zeichnet jedes Authentifizierungsereignis auf - Erfolge, Fehlschläge, Sitzungsstarts und Sitzungsenden. Diese Daten sind operativ für die Kapazitätsplanung und kommerziell für WiFi Analytics von unschätzbarem Wert, aber sie sind auch eine kritische Quelle für Sicherheits-Telemetrie. Eine Flut von fehlgeschlagenen Authentifizierungen, Authentifizierungen von unbekannten MAC-Adressen und Zugriffsmuster außerhalb der Arbeitszeiten können alle über RADIUS-Accounting-Logs erkannt werden. Die meisten Unternehmen führen diese Daten nicht in einem SIEM zusammen, und diejenigen, die es tun, konfigurieren selten Warnschwellen.
BlastRADIUS Angriffsdetails
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 über ARP-Spoofing im gemeinsamen Netzwerksegment, einen kompromittierten Router oder einen böswilligen Insider mit Netzwerkzugriff.
Der Angriff läuft wie folgt ab: Ein Angreifer fängt ein Access-Request-Paket vom NAS ab. Da diesem Paket das Message-Authenticator-Attribut fehlt (eine Standardeinstellung in vielen Konfigurationen), kann der Angreifer die Attributliste des Pakets frei modifizieren. Mithilfe einer MD5 Chosen-Prefix Collision konstruiert der Angreifer ein modifiziertes Paket, für das der RADIUS-Server denselben Response Authenticator wie für das Originalpaket berechnet. Infolgedessen gibt der Server ein Access-Accept für die Anfrage zurück, die die vom Angreifer kontrollierten Attribute enthält - einschließlich des Administrative Service-Type, der vollen Netzwerkzugriff autorisiert.
Der Angriff ist wirksam gegen PEAP- und EAP-TTLS-Bereitstellungen, die MSCHAPv2 als interne Methode nutzen. Er betrifft keine EAP-TLS-Bereitstellungen, da die zertifikatsbasierte gegenseitige Authentifizierung einen Integritätsschutz bietet, den MD5 nicht aushebeln kann.
Für Organisationen, die sowohl Guest WiFi als auch Enterprise-Level 802.1X betreiben, muss die RADIUS-Instanz des Gästenetzwerks ebenfalls gepatcht werden, selbst wenn sie MAC Authentication Bypass anstelle von EAP verwendet. Die Sicherheitsregeln für Shared Secrets und die Anforderungen an den Message-Authenticator gelten gleichermaßen.
Implementierungsleitfaden
Phase 1: Sofortige Behebung (Woche 1 - 2)
Das Einspielen von Patches ist der erste Schritt. FreeRADIUS 3.2.5 und 3.0.27 enthalten die BlastRADIUS-Korrekturen 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 KB5040434 für Windows Server 2022 NPS im Juli 2024 veröffentlicht. Bitte überprüfen Sie Ihre aktuellen Versionen und wenden Sie diese Patches im nächsten geplanten Wartungsfenster an.
Überprüfen Sie gleichzeitig die Firmware Ihrer NAS-Geräte. Die Erzwingung des Message-Authenticators ist nur dann wirksam, wenn das NAS dieses Attribut auch sendet. Prüfen Sie die Sicherheitshinweise Ihrer Access Point- und Switch-Hersteller - Aruba, Ruckus, Cisco und Juniper haben alle Firmware-Updates für BlastRADIUS veröffentlicht. Wenn Sie Hardware von Ruckus verwenden, bietet der wireless access point Ruckus guide den entsprechenden Hintergrund für das Firmware-Management.
Falls Sie nach dem Patchen Probleme haben und ein troubleshooting Windows 11 802.1X authentication issues benötigen: Der häufigste Grund ist, dass der NPS-Server Client-Verbindungen ablehnt, die keinen Message-Authenticator enthalten - dies ist das korrekte Sicherheitsverhalten und erfordert möglicherweise eine Neukonfiguration des Supplicants auf älteren Windows-Clients.
Phase 2: Bereinigung der Shared Secrets (Woche 2 - 4)
Exportieren Sie die vollständige Liste der auf dem RADIUS-Server registrierten NAS-Clients. Dokumentieren Sie die Länge des Shared Secrets für jeden Eintrag sowie das Datum der letzten Änderung. Jedes Secret, 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 Keys einen kryptografischen Zufallsgenerator - openssl rand -base64 32 erzeugt einen 44-stelligen Base64-String, der sich hervorragend als Shared Secret für RADIUS eignet. Speichern Sie alle Keys in einem Key-Management-System. Richten Sie einen Rotationsplan ein: Jährlich für NAS-Geräte mit geringem Risiko, alle sechs Monate für NAS-Geräte, die in den Geltungsbereich von PCI-DSS fallen.
Phase 3: Optimierung der EAP-Methoden (Monat 1 - 2)
Überprüfen Sie die auf Ihrem RADIUS-Server zulässigen EAP-Methoden. Deaktivieren Sie EAP-MD5. Wenn Sie PEAP-MSCHAPv2 nutzen, stellen Sie sicher, dass alle Supplicants die Serverzertifikatsprüfung erzwingen - falsch konfigurierte Supplicants, die jedes Serverzertifikat akzeptieren, sind anfällig für Angriffe über Rogue RADIUS-Server. Für Umgebungen im PCI-DSS-Bereich wird EAP-TLS dringend empfohlen. Wenn Sie derzeit über keine entsprechende Zertifikatsinfrastruktur verfügen, beginnen Sie mit der PKI-Planung.
Hinweis zur Sicherheit von Gästenetzwerken: Da diese Netze meist ein Captive Portal zur Authentifizierung anstelle von 802.1X nutzen, betrifft die Härtung der EAP-Methoden primär die Enterprise- und Mitarbeiter-SSIDs.
Phase 4: RadSec-Bereitstellung (Monat 2 - 3)
Identifizieren Sie alle RADIUS-Datenpfade, die nicht vertrauenswürdige Netzwerkgrenzen überschreiten. Typische Szenarien sind zentrale RADIUS-Server, die entfernte Standorte über das Internet anbinden, lokale NAS-Geräte, die eine Verbindung zu einem Cloud-RADIUS-Dienst herstellen, sowie RADIUS-Proxy-Ketten, bei denen Datenverkehr über mehrere Netzwerkdomänen geleitet wird.
Konfigurieren Sie RadSec für jeden identifizierten Pfad. Bei FreeRADIUS bedeutet dies die Aktivierung des tls-Listeners auf Port 2083 und die Konfiguration von Mutual TLS mit Zertifikaten aus Ihrer PKI. Bei Cisco ISE wird RadSec unter Administration > Network Devices konfiguriert. Stellen Sie sicher, dass mindestens TLS 1.2 verwendet wird; TLS 1.0 und 1.1 müssen explizit deaktiviert werden.
Phase 5: Multi-Faktor-Authentifizierung für den administrativen Zugriff (Monat 2 - 3)
Die Verwaltungsoberflächen von RADIUS-Servern sind ein lohnendes Ziel. Wenn Angreifer einen RADIUS-Server kompromittieren, können sie Authentifizierungsrichtlinien ändern, Shared Secrets auslesen und Authentifizierungsdatenverkehr umleiten. Erzwingen Sie MFA für alle Administrator-Anmeldungen an RADIUS-Servern und deren zugrunde liegenden Betriebssystemen. Beschränken Sie den administrativen Zugriff auf ein dediziertes Out-of-Band-Management-VLAN. Implementieren Sie eine rollenbasierte Zugriffskontrolle: Netzwerktechniker sollten nicht dieselben Rechte wie Sicherheitsadministratoren haben.
Phase 6: SIEM-Integration und Alarmierung (Monat 3 - 4)
Konfigurieren Sie Ihren RADIUS-Server so, dass Accounting-Protokolle in Echtzeit an Ihr SIEM weitergeleitet werden. Definieren Sie die folgenden Schwellenwerte für Alarme:
| Alarm | Schwellenwert | Schweregrad |
|---|---|---|
| Mehrfache Authentifizierungsfehler für eine einzelne MAC-Adresse | >5 innerhalb von 60 Sekunden | Hoch |
| Anstieg der Ablehnungsrate (Access-Reject) | Mehr als 200 % des Durchschnitts der letzten 7 Tage | Mittel |
| Authentifizierung von einer neuen MAC-Adresse auf einem Enterprise SSID | Erstes Auftreten | Mittel |
| RADIUS-Serverzertifikat läuft bald ab | 90 / 30 / 7 Tage | Hoch / Dringend / Dringend |
| Fehler durch nicht übereinstimmenden Shared Secret | Jedes einzelne Auftreten | Hoch |
Haben Sie Fragen zu Ihrem spezifischen Setup?
Unser Team arbeitet mit Standortbetreibern, IT-Managern und Netzwerktechnikern an über 80.000 Standorten zusammen. Buchen Sie ein 20-minütiges Gespräch und wir zeigen Ihnen, wie andere diese Herausforderungen gelöst haben.
Best Practices
Die folgenden Empfehlungen fassen den Konsens aus IEEE 802.1X, NIST SP 800-63B, PCI-DSS v4.0 sowie den Sicherheitsrichtlinien der Hersteller zusammen.
Zertifikatsmanagement. Jede Bereitstellung mit EAP-TLS oder RadSec nutzt X.509-Zertifikate in ihrem Authentifizierungspfad. Bei Enterprise WiFi-Implementierungen ist der Ablauf von Zertifikaten die häufigste Ursache für plötzliche, vollständige Authentifizierungsausfälle. Implementieren Sie ein automatisiertes Zertifikats-Lebenszyklus-Management. Richten Sie Monitoring-Alarme 90, 30 und 7 Tage vor dem Ablaufdatum ein. Verwenden Sie für RADIUS-Serverzertifikate mindestens 2048-Bit RSA oder 256-Bit ECDSA-Schlüssel sowie SHA-256 oder stärkere Signaturalgorithmen. Verwenden Sie kein SHA-1.
Netzwerksegmentierung. RADIUS-Server sollten sich in einem dedizierten Management-VLAN befinden, das vom Gastnetzwerk und dem regulären Unternehmensnetzwerk isoliert ist. Der Zugriff auf RADIUS-Ports (UDP 1812, 1813 und TCP 2083 für RadSec) sollte über Firewall-ACLs auf spezifische IP-Adressen der registrierten NAS-Geräte beschränkt werden. Lassen Sie keinen direkten Zugriff auf RADIUS-Ports aus dem Internet zu.
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 Active-Passive- oder Active-Active-Konfiguration. Für Hospitality -Betriebe mit rund um die Uhr genutzten Gastverbindungen führt der Ausfall eines RADIUS-Servers direkt zum Ausfall des Gast-WiFi - ein erhebliches Reputations- und Geschäftsrisiko. WPA3 und 802.1X. WPA3-Enterprise im 192-Bit-Sicherheitsmodus ist eine zwingende Anforderung für Behörden und Hochsicherheitsumgebungen. Hierbei ist die Verwendung von AES-256-GCMP für die Datenverschlüsselung und HMAC-SHA-384 für die Authentifizierung vorgeschrieben. Für die meisten Enterprise-Implementierungen bietet WPA3-Enterprise in Kombination mit dem standardmäßigen 128-Bit-Schutz bereits eine erhebliche Verbesserung gegenüber WPA2-Enterprise, insbesondere in Verbindung mit EAP-TLS. Retail -Umgebungen, in denen Kartenzahlungen verarbeitet werden, sollten die Einführung von WPA3-Enterprise als Maßnahme zur Reduzierung des PCI-DSS-Risikos betrachten.
Patch-Zyklen der Hersteller. Abonnieren Sie Sicherheitswarnungen Ihrer RADIUS-Server- und NAS-Gerätehersteller. FreeRADIUS, Cisco, Microsoft, Aruba und Ruckus veröffentlichen regelmäßig CVE-Meldungen. Integrieren Sie diese Informationen in Ihr Schwachstellenmanagement und definieren Sie klare SLAs: Behebung kritischer Schwachstellen (CVSS ≥ 9.0) innerhalb von 72 Stunden; hochriskante Schwachstellen (CVSS 7.0 - 8.9) innerhalb von 14 Tagen.
Fehlerbehebung & Risikominderung
Häufige Fehlerszenarien
Authentifizierungsfehler nach dem Patchen. Wenn nach dem Einspielen des BlastRADIUS-Patches die Firmware einiger NAS-Geräte den Message-Authenticator nicht unterstützt, kann dies zu Authentifizierungsfehlern führen. Symptom: Ein plötzlicher Anstieg von Access-Reject-Antworten ohne Änderung der Benutzeranmeldedaten. Diagnose: Aktivieren Sie RADIUS-Debug-Logs und prüfen Sie auf den Fehler "Message-Authenticator required but not present" (Message-Authenticator erforderlich, aber nicht vorhanden). Lösung: Aktualisieren Sie die NAS-Firmware oder konfigurieren Sie den RADIUS-Server übergangsweise so, dass er während der geplanten Firmware-Aktualisierungsphase Anfragen von bestimmten NAS-IPs ohne Message-Authenticator akzeptiert.
Zertifikatsvalidierungsfehler bei EAP-TLS. Symptom: Clients erhalten die Meldung "authentication failed" (Authentifizierung fehlgeschlagen), im RADIUS-Protokoll ist jedoch kein entsprechender Access-Reject-Eintrag vorhanden. Diagnose: Überprüfen Sie die Zertifikatskette des RADIUS-Servers - vertraut die ausstellende CA dem Client-Supplicant? Ist das Serverzertifikat gültig? Lösung: Stellen Sie sicher, dass die vollständige Zertifikatskette (Endstufen-Zertifikat + Zwischenzertifikat + Root-Zertifikat) auf dem RADIUS-Server konfiguriert ist. Verteilen Sie das Root-CA-Zertifikat über MDM oder Gruppenrichtlinien an die Client-Geräte.
RadSec TLS-Handshake-Fehler. Symptom: Nach einer Konfigurationsänderung können NAS-Geräte keine RadSec-Verbindung aufbauen. Diagnose: Überprüfen Sie die TLS-Kompatibilität - ältere NAS-Firmware unterstützt TLS 1.2 möglicherweise nicht. Überprüfen Sie die gegenseitige Zertifikatsvalidierung - beide Seiten müssen der CA des jeweils anderen vertrauen. Lösung: Überprüfen Sie die unterstützte TLS-Version in den Release Notes der NAS-Firmware; stellen Sie sicher, dass das Zertifikat des NAS-Geräts von derselben CA ausgestellt wurde, der auch der RADIUS-Server vertraut.
Nicht übereinstimmendes Shared Secret. Symptom: Jede Authentifizierung von einem bestimmten NAS schlägt mit dem Fehler "invalid authenticator" (ungültiger Authentifikator) fehl. Diagnose: Der in der NAS-Konfiguration hinterlegte Shared Secret stimmt nicht mit dem Client-Eintrag auf dem RADIUS-Server überein. Lösung: Geben Sie den Shared Secret auf beiden Seiten neu ein und prüfen Sie auf nachfolgende Leerzeichen oder Zeichenkodierungsprobleme. Kopieren Sie den Schlüssel direkt aus Ihrem Passwort-Manager, um Tippfehler zu vermeiden.
Risikoregister
| Risiko | Wahrscheinlichkeit | Auswirkung | Sicherheitskontrollen |
|---|---|---|---|
| Ausnutzung der BlastRADIUS-Schwachstelle | Hoch (wenn ungepatcht) | Kritisch | Patch einspielen + Message-Authenticator erzwingen |
| Brute-Force-Angriff auf Shared Secret | Mittel | Hoch | Generierung eines zufälligen 32-Zeichen-Schlüssels, jährliche Rotation |
| Angriffe über Rogue-RADIUS-Server | Mittel | Hoch | Gegenseitige Authentifizierung über EAP-TLS, Zertifikat-Pinning |
| Ablauf des RADIUS-Serverzertifikats | Hoch | Kritisch | Automatisierte Überwachung, Alarmierung 90 Tage im Voraus |
| Credential-Stuffing-Angriffe über 802.1X | Mittel | Hoch | Kontosperrungsrichtlinien, SIEM-Alarmierung |
| Kompromittierung des RADIUS-Servers | Niedrig | Kritisch | MFA für Administrator-Zugriff, Netzwerksegmentierung |
Return on Investment (ROI) & geschäftliche Auswirkungen
Risikobewertung
Bei der Betrachtung der Kosten von Datenpannen wird die wirtschaftliche Notwendigkeit einer RADIUS-Härtung besonders deutlich. Im Jahr 2024 betrugen die durchschnittlichen Kosten einer Datenpanne in Großbritannien 3,58 Millionen Pfund - einschließlich behördlicher Bußgelder, Behebungsmaßnahmen, Rechtskosten und Reputationsverlust. Für Unternehmen, die unter den Geltungsbereich von PCI-DSS fallen - was praktisch jeden Retail - und Hospitality -Betreiber einschließt, der Kartenzahlungen über WiFi akzeptiert -, führt eine Kompromittierung der Netzwerkzugriffskontrolle, bei der Karteninhaberdaten offengelegt werden, zu obligatorischen forensischen Untersuchungen, potenziellen Bußgeldern der Kreditkartenorganisationen und der möglichen Sperrung von Kreditkartenabrechnungsdiensten.
Für Organisationen im Healthcare -Bereich führt eine Verletzung der GDPR durch den unbefugten Zugriff auf Patientendaten über einen kompromittierten RADIUS-Server gemäß Artikel 83 Absatz 5 zu Geldbußen von bis zu 4 % des gesamten weltweit erzielten Jahresumsatzes. Die Durchsetzungspraxis des ICO zeigt, dass Cybersicherheitsmängel als Fahrlässigkeit und nicht als bloßes technisches Unglück eingestuft werden.
Benchmarks für Implementierungskosten
Die folgenden Kostenschätzungen basieren auf einem Netzwerk mit 500 Geräten:
| Härtungsmaßnahme | Geschätzte Kosten | Zeitrahmen |
|---|---|---|
| Patching (FreeRADIUS / NPS / ISE) | Nur interne Arbeitszeit | 1 - 2 Wochen |
| Audit & Rotation gemeinsam genutzter Geheimnisse | Interne Arbeitszeit + Lizenzen für Secret Manager (ca. 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 (ca. 1.500 £) | 4 - 6 Wochen |
| SIEM-Integration & Alarmierung | Abhängig vom bestehenden SIEM; 0 - 10.000 £ | 4 - 8 Wochen |
Die Gesamtinvestition für die Härtung eines mittelgroßen Unternehmens liegt bei ca. 20.000 - 45.000 £. Verglichen mit den durchschnittlichen Kosten einer Datenpanne von 3,58 Millionen £ ist der risikobereinigte ROI selbst bei konservativen Annahmen zur Eintrittswahrscheinlichkeit äußerst überzeugend.
Operative Vorteile über die Sicherheit hinaus
Eine gehärtete RADIUS-Infrastruktur zahlt sich auch operativ aus. Eine zuverlässige, gut überwachte Authentifizierung reduziert Helpdesk-Tickets im Zusammenhang mit der WiFi-Konnektivität. Wenn RADIUS-Accounting-Daten mit WiFi Analytics integriert werden, bieten sie Transparenz auf Session-Ebene über Netzwerknutzungsmuster, Verweilzeiten und Gerätetypen - Daten, die für Betreiber in den Bereichen Hospitality und Transport einen direkten geschäftlichen Nutzen haben.
Für den öffentlichen Sektor und Organisationen im Gesundheitswesen liefert ein dokumentierter RADIUS-Härtungsplan den Nachweis technischer Kontrollen für Cyber Essentials Plus, ISO 27001 und NHS DSPT-Bewertungen - was den Audit-Aufwand verringert und den Regulierungsbehörden die gebotene Sorgfalt nachweist.
Schlüsseldefinitionen
RADIUS (Remote Authentication Dial-In User Service)
Ein in RFC 2865 definiertes Client-Server-Protokoll, das eine zentrale Authentifizierung, Autorisierung und Benutzerverwaltung (AAA) für den Netzwerkzugriff bereitstellt. RADIUS-Server validieren Anmeldedaten, die von Netzwerkgeräten (NAS) übermittelt werden, gegen einen Backend-Identitätsspeicher wie Active Directory oder LDAP.
IT-Teams begegnen RADIUS als Authentifizierungs-Backend für 802.1X WiFi, kabelgebundene Port-Authentifizierung, VPN-Zugang und die Verwaltung von Netzwerkgeräten. Es ist das Protokoll, das entscheidet, wer Zugriff auf das Netzwerk erhält.
IEEE 802.1X
Ein IEEE-Standard für die portbasierte Netzwerkzugriffskontrolle, der die Kapselung von EAP über LAN (EAPOL) definiert. Er bietet ein Authentifizierungs-Framework für kabelgebundene und kabellose Netzwerke und erfordert, dass sich Geräte authentifizieren, 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 aus dem Authentifizierungs-Austausch vollständig eliminiert werden.
EAP-TLS ist der Goldstandard für die Authentifizierung im enterprise WiFi. 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 in 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 nicht vertrauenswü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 so einem nicht authentifizierten Benutzer Netzwerkzugriff gewähren.
BlastRADIUS betrifft alle gängigen RADIUS-Implementierungen einschließlich FreeRADIUS, Cisco ISE und Microsoft NPS. Organisationen, die die im Juli 2024 veröffentlichten Patches nicht angewendet haben, sind diesem Angriff weiterhin ausgesetzt.
Message-Authenticator
Ein RADIUS-Attribut (Attribut 80), das HMAC-MD5-Integritätsschutz für das gesamte RADIUS-Paket bietet. Wenn es in einem Access-Request vorhanden ist, verhindert es den bei BlastRADIUS verwendeten Paketmanipulationsangriff.
Das Erzwingen des Message-Authenticator bei allen Access-Request-Paketen ist die primäre Maßnahme zur Behebung von BlastRADIUS. Er muss sowohl auf dem RADIUS-Server (um das Attribut zu verlangen) als auch auf dem NAS-Gerät (um das Attribut in Anfragen aufzunehmen) konfiguriert werden.
NAS (Network Access Server)
In der RADIUS-Terminologie ist der NAS das Netzwerkgerät - in der Regel ein WiFi-Access-Point, ein Switch oder ein VPN-Konzentrator -, das als RADIUS-Client fungiert. Er 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 einrichtet, bevor die interne Authentifizierungsmethode (in der Regel MSCHAPv2) übertragen wird. Sie bietet gegenseitige Authentifizierung und schützt Anmeldedaten vor dem Abhören.
PEAP-MSCHAPv2 ist die am weitesten verbreitete Authentifizierungsmethode für enterprise WiFi. 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 handelt sich dabei nicht um ein Passwort für Endbenutzer, sondern um eine Server-zu-Server-Authentifizierung.
Schwache oder statische Shared Secrets gehören zu den häufigsten RADIUS-Schwachstellen. Ein Angreifer, der den 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, der von den großen Kartenorganisationen (Visa, Mastercard, Amex) für Organisationen vorgeschrieben wird, die Karteninhaberdaten verarbeiten, speichern oder übertragen. Version 4.0, gültig ab März 2024, enthält spezifische Anforderungen für die Netzwerkzugriffskontrolle und starke Authentifizierung nach PCI-DSS.
Einzelhandels- und Gastronomieunternehmen mit über WiFi verbundenen POS-Terminals fallen in den Geltungsbereich von PCI-DSS. Schwachstellen im RADIUS-Server, die einen unbefugten Netzwerkzugriff auf Karteninhaber-Datenumgebungen ermöglichen könnten, stellen ein direktes Compliance-Risiko dar.
Ausgearbeitete Beispiele
Eine Hotelgruppe mit 350 Zimmern und 12 Standorten nutzt einen zentralisierten RADIUS Server, der im Rechenzentrum der Zentrale gehostet wird. Jedes Objekt ist über ein gemeinsam genutztes MPLS WAN angebunden. Ein Sicherheitsaudit hat ergeben, dass der RADIUS Traffic über das WAN unverschlüsselt ist, die Shared Secrets aus 8-stelligen Zeichenfolgen bestehen, die bei der Erstbereitstellung vor fünf Jahren festgelegt wurden, und auf dem RADIUS Server FreeRADIUS 3.0.21 läuft. Die Gruppe verarbeitet Kartenzahlungen über per WiFi verbundene Kassenterminals in ihren Restaurant- und Wellnessbereichen. Wie sehen die Priorisierung der Behebung und die Reihenfolge der Implementierung 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, die den Message-Authenticator nicht unterstützen. Schritt 2 (Woche 1-2): Rotieren Sie alle Shared Secrets. Generieren Sie mit openssl rand -base64 32 zufällige, 32-stellige Secrets 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 von den NAS-IP-Bereichen der Standorte zum RADIUS Server zuzulassen. Deaktivieren Sie UDP 1812/1813 auf den zum WAN zeigenden Schnittstellen, sobald der Betrieb von RadSec bestätigt wurde. Schritt 4 (Monat 2-3): Migrieren Sie für die im PCI-DSS-Scope liegende POS-WiFi-SSID von PEAP-MSCHAPv2 auf EAP-TLS. Richten Sie eine interne PKI ein (Microsoft ADCS oder HashiCorp Vault PKI Engine). Stellen Sie Client-Zertifikate über MDM an die Kassenterminals aus. Aktualisieren Sie die RADIUS Richtlinie, um EAP-TLS für die POS-SSID zu verlangen. Schritt 5 (Monat 3): Integrieren Sie RADIUS Accounting-Protokolle in das SIEM. Konfigurieren Sie Warnmeldungen für Spitzen bei fehlgeschlagenen Authentifizierungen und das Ablaufen von Zertifikaten.
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 eine 802.1X Authentifizierung migrieren und dabei Microsoft NPS als RADIUS-Server verwenden, der in Active Directory integriert ist. Die Filialen verfügen über eine Mischung aus Aruba und Cisco Access Points. Die Kette fällt in den PCI DSS Geltungsbereich. Welche Architektur sollte implementiert werden und welches sind die wichtigsten Konfigurationsentscheidungen?
Die empfohlene Architektur ist 802.1X mit PEAP-MSCHAPv2 als anfänglicher EAP-Methode, mit einer dokumentierten Roadmap für 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 für die Mitarbeiter-SSID mit PEAP-MSCHAPv2, die eine 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 die Gruppenrichtlinie (Windows) und MDM (iOS/Android) an alle Mitarbeitergeräte. (3) Supplicant-Konfiguration: Konfigurieren Sie Windows-Geräte über die Gruppenrichtlinie (Computerkonfiguration > Windows-Einstellungen > Sicherheitseinstellungen > Drahtlosnetzwerkrichtlinien). Für iOS- und Android-Geräte verwenden Sie 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 Zeichenfolge mit 32 Zeichen. Aktivieren Sie RadSec, sofern die Aruba-Firmware dies unterstützt (AOS 8.9+). Auf Cisco konfigurieren Sie unter Sicherheit > AAA > RADIUS. (5) NPS-Protokollierung: Aktivieren Sie die NPS-Accounting-Protokollierung in einer SQL Server-Datenbank. Konfigurieren Sie eine Aufbewahrungsfrist der Protokolle von mindestens 90 Tagen für die PCI DSS Konformität. (6) Nach der Migration: Deaktivieren Sie WPA2-Personal auf der Mitarbeiter-SSID. Behalten Sie es nur als Notfall-SSID mit einem komplexen PSK im Secrets Manager für den Fall, dass NPS nicht verfügbar ist.
Übungsfragen
Q1. Ihre Organisation betreibt einen FreeRADIUS 3.0.21 Server, der die 802.1X-Authentifizierung für 800 Mitarbeitergeräte auf einem Campus 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 den Message-Authenticator sofort erzwingen, aber das Netzwerkbetriebsteam befürchtet, dass die Authentifizierung für 800 Benutzer unterbrochen wird. Wie staffeln Sie die Behebung, um Dienstunterbrechungen zu minimieren?
Hinweis: Berücksichtigen Sie den Unterschied zwischen dem RADIUS-Server, der den Message-Authenticator erfordert, und den NAS-Geräten, die diesen senden. Dies sind zwei separate Konfigurationsänderungen mit unterschiedlichen Risikoprofilen.
Musterlösung anzeigen
Die korrekte Reihenfolge lautet: (1) Aktualisieren Sie FreeRADIUS zunächst auf Version 3.2.5. Diese Version erzwingt den Message-Authenticator standardmäßig, enthält jedoch einen Kompatibilitätsmodus, der eine Warnung protokolliert, anstatt Pakete abzulehnen, denen das Attribut fehlt. So erhalten Sie den Patch, ohne die Authentifizierung sofort zu unterbrechen. (2) Überprüfen Sie die Firmware-Versionen der Access Points. Ermitteln Sie, welche Modelle und Firmware-Versionen den Message-Authenticator in Access-Request-Paketen unterstützen. (3) Aktualisieren Sie die Firmware der Access Points in Chargen, beginnend mit einer Pilotgruppe von 50 Geräten. Überprüfen Sie nach jeder Charge, ob die Authentifizierung weiterhin funktioniert. (4) Sobald bestätigt wurde, dass alle Access Points den Message-Authenticator senden, aktivieren Sie die strikte Erzwingung auf dem FreeRADIUS-Server (require_message_authenticator = yes in clients.conf). (5) Überwachen Sie die RADIUS-Protokolle auf verbleibende Warnungen vom Typ 'Message-Authenticator missing', was auf NAS-Geräte hinweisen würde, bei denen das Firmware-Update übersehen wurde. Das Grundprinzip besteht darin, dass Sie den Server zuerst patchen können, ohne etwas zu beschädigen, da der Kompatibilitätsmodus eine Übergangsphase ermöglicht. Die strikte Ablehnung auf dem Server sollte der letzte Schritt sein, nachdem alle NAS-Geräte aktualisiert wurden.
Q2. Ein Konferenzzentrum-Betreiber nutzt einen einzigen RADIUS-Server, der sowohl die SSID für Unternehmensmitarbeiter (802.1X mit PEAP-MSCHAPv2) als auch das Event-Gast-WiFi (Captive Portal mit MAC-Authentifizierungsumgehung) unterstützt. Der IT-Leiter fragt, ob die RADIUS-Instanz für das 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: Berücksichtigen Sie die Angriffsvektoren, die für MAC-Authentifizierungsumgehungen im Vergleich zu EAP-basierten Authentifizierungen gelten, sowie das Risiko von Lateral Movement zwischen den Gast- und Unternehmens-RADIUS-Instanzen.
Musterlösung anzeigen
Die Gast-WiFi-RADIUS-Instanz erfordert eine Härtung, die spezifischen Kontrollen unterscheiden sich jedoch von der Unternehmensinstanz. Der BlastRADIUS-Patch gilt gleichermaßen - die Sicherheitslücke betrifft den RADIUS-Server unabhängig von der von den Clients verwendeten Authentifizierungsmethode. Die Hygiene bezüglich 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 wichtigste zusätzliche Risiko ist der gemeinsam genutzte RADIUS-Server: Wenn die Gast- und Unternehmens-SSID-Authentifizierungsanfragen von demselben RADIUS-Serverprozess verarbeitet werden, könnte eine Sicherheitslücke im Gast-RADIUS-Pfad genutzt werden, um auf die Unternehmens-Authentifizierungsrichtlinie überzugreifen. Die empfohlene Architektur besteht darin, separate RADIUS-Instanzen (oder zumindest separate virtuelle Server innerhalb von FreeRADIUS) für die Gast- und Unternehmensauthentifizierung auszuführen, mit separaten Shared Secrets und separaten Richtliniensätzen. Dies sorgt für eine Isolierung, so dass eine Kompromittierung des Gast-RADIUS-Pfads keine Unternehmens-Anmeldedaten offenlegt. Speziell für die Gast-Instanz: Patchen für BlastRADIUS, Shared Secrets rotieren und sicherstellen, dass die Gast-RADIUS-Instanz keinen Zugriff auf das Active Directory des Unternehmens hat. Die Anforderungen an EAP-TLS und RadSec 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 Netzwerkesegment als der RADIUS-Server befindet.
Q3. Ein Gesundheitsträger plant, sein klinisches WiFi von WPA2-Personal auf eine 802.1X-Authentifizierung zu migrieren. Der Träger 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-Leiter 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-Leiter, und was ist der empfohlene Implementierungspfad?
Hinweis: Berücksichtigen 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
Die Intuition des CISO ist richtig, aber die Sorge des IT-Leiters ist berechtigt. Der empfohlene Rat lautet: Implementieren Sie PEAP-MSCHAPv2 jetzt als Übergangslösung, mit einer verbindlichen 12-Monats-Roadmap zu EAP-TLS. Die Begründung dafür, PEAP-MSCHAPv2 im Gesundheitswesen nicht als dauerhafte Lösung zu akzeptieren, lautet: (1) PEAP-MSCHAPv2 ist anfällig für Angriffe durch gefälschte RADIUS-Server, wenn die clientseitige Zertifikatsvalidierung nicht erzwungen wird. In einer Gesundheitsumgebung, in der das klinische Personal möglicherweise private Geräte verbindet, ist die konsistente Durchsetzung der Supplicant-Konfiguration auf 1.200 Geräten betrieblich eine Herausforderung. (2) MSCHAPv2-Anmeldedaten können, wenn sie über einen gefälschten RADIUS-Angriff abgefangen werden, offline mit Tools wie hashcat geknackt werden. Im Kontext des Gesundheitswesens 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 die automatische Gruppenrichtlinienregistrierung. 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. Beibehaltung von PEAP als Fallback für alle Geräte, bei denen die Zertifikatsregistrierung fehlschlägt, mit erweitertem Monitoring. Weitere Informationen zur Sicherheitsarchitektur klinischer Netzwerke finden Sie im WiFi in Hospitals Leitfaden , der relevanten Bereitstellungskontext bietet.
Weiterlesen in dieser Reihe
So entziehen Sie den WiFi Zugriff, wenn ein Mitarbeiter das Unternehmen verlässt
Dieser Leitfaden zeigt IT- und Standort-Betriebsteams, wie sie den Staff WiFi Zugriff entfernen, wenn ein Mitarbeiter das Unternehmen verlässt, ohne die restliche Belegschaft zu stören. Er vergleicht zertifikatsbasiertes 802.1X, identitätsspezifisches iPSK und SCIM-gesteuertes Deprovisionieren und bietet anschließend ein Runbook für denselben Tag, ein Testverfahren und ein Audit-Nachweismodell.
Sicheres BYOD WiFi: Passpoint-Zertifikats-Onboarding vs. xPSK (iPSK)
Ein umfassender technischer Leitfaden für IT-Teams zur Absicherung unmanaged Mitarbeiter- und Studentengeräte (BYOD) mittels Zero-Touch Passpoint EAP-TLS-Zertifikaten im Vergleich zu herstellerspezifischen xPSK-Lösungen (iPSK/easyPSK, DPSK, PPSK, MPSK).
Konfigurieren von RADIUS-Authentifizierung für Gäste- und Mitarbeiter-WiFi-Netzwerke
Dieses technische Referenzhandbuch beschreibt die Architektur, Konfiguration und Bereitstellung der RADIUS-Authentifizierung für WiFi-Netzwerke von Unternehmen für Gäste und Mitarbeiter. Es bietet Netzwerkarchitekten und IT-Managern die genauen Protokolle, Sicherheitsstandards und Fehlerbehebungsmethoden, die für den Aufbau sicherer, skalierbarer drahtloser Zugriffskontrollsysteme erforderlich sind.
Haben Sie Fragen zu Ihrem spezifischen Setup?
Unser Team arbeitet mit Standortbetreibern, IT-Managern und Netzwerktechnikern an über 80.000 Standorten zusammen. Buchen Sie ein 20-minütiges Gespräch und wir zeigen Ihnen, wie andere diese Herausforderungen gelöst haben.