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 primäre Protokoll für die Netzwerkzugriffskontrolle in Enterprise-WiFi-Umgebungen und bildet die Grundlage für die IEEE 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 einige seiner grundlegenden Designentscheidungen - die Abhängigkeit von MD5-Hashing, UDP-Transport ohne native Verschlüsselung und statische Shared Secrets - sind in der aktuellen Bedrohungslage zu erheblichen Risiken geworden.
Im Juli 2024 zeigte die BlastRADIUS-Schachstelle (CVE-2024-3596), dass ein Man-in-the-Middle-Angreifer RADIUS-Access-Accept-Antworten fälschen kann, indem er MD5-Integritätsschwachstellen in Access-Request-Paketen ausnutzt. Die Schwachstelle betrifft jede wichtige RADIUS-Implementierung, einschließlich FreeRADIUS, Cisco ISE und Microsoft NPS. Ungepatchte Implementierungen 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 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 in diesem Quartal und nicht erst im nächsten Jahr fundierte Entscheidungen treffen müssen.
Technischer Deep Dive
Wie RADIUS funktioniert und wo seine Schwachstellen liegen
RADIUS arbeitet als Client-Server-Protokoll zwischen einem Network Access Server (NAS) - in der Regel ein WiFi-Access-Point, Switch oder VPN-Konzentrator - und einem RADIUS-Server, der die Anmeldedaten mit einem Backend-Identitätsspeicher wie Active Directory oder LDAP abgleicht. Der Authentifizierungsaustausch folgt dem in RFC 2865 definierten Request-Challenge-Response-Modell, wobei das Accounting separat unter RFC 2866 abgewickelt wird.
Das Protokoll überträgt Authentifizierungspakete über UDP unter Verwendung von Port 1812 für die Authentifizierung und Port 1813 für das Accounting. Das Shared Secret - der auf dem NAS und dem RADIUS-Server konfigurierte Pre-Shared Key - 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; es ist eine Verschleierung, die vollständig von der Geheimhaltung und Stärke des Shared Secrets abhängt.
Die fünf Hauptkategorien von Schwachstellen in einer typischen RADIUS-Bereitstellung sind wie folgt.
MD5-Kollisions- und Integritätsschwachstellen. Der BlastRADIUS-Angriff (CVE-2024-3596) nutzt den Mangel an Integritätsschutz bei Access-Request-Paketen aus. Da viele Konfigurationen standardmäßig das Message-Authenticator-Attribut des NAS nicht enthalten, kann ein Angreifer in einer Man-in-the-Middle-Position manipulierte Attribute einschleusen, bevor das Paket 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 Message-Authenticator-Attribut für alle Access-Request-Pakete zu erzwingen, was einen HMAC-MD5-Integritätsschutz für das gesamte Paket bietet. Dies erfordert Konfigurationsänderungen sowohl auf dem NAS als auch auf dem RADIUS-Server, nicht nur einen Server-Patch.
Schwache oder statische Shared Secrets. Das Shared Secret ist der kryptografische Anker des RADIUS-Austauschs. Wenn das Secret kurz, leicht zu erraten ist oder nie rotiert wird, kann ein Angreifer, der den RADIUS-Verkehr abfängt (erreichbar durch ARP-Spoofing oder ein kompromittiertes Netzwerkgerät), das User-Password-Attribut offline per Brute-Force angreifen. Die Richtlinien von NIST SP 800-63B für gespeicherte Secrets gelten auch hier: Secrets sollten mindestens 20 Zeichen lang sein, zufällig generiert und in einem Secrets-Management-System gespeichert werden. Für große Netzwerke mit Dutzenden oder Hunderten von NAS-Geräten ist eine manuelle Rotation betrieblich nicht machbar; eine Automatisierung über HashiCorp Vault oder einen ähnlichen Secrets Manager ist der richtige Ansatz.
Unverschlüsselter UDP-Transport. Standard-RADIUS über UDP bietet keine Vertraulichkeit auf der Transportschicht. Das User-Password-Attribut wird verschleiert, aber nicht verschlüsselt. Jedes andere Attribut - einschließlich Benutzernamen, NAS-IPs und Sitzungs-Metadaten - wird 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 einen TLS-Tunnel über TCP-Port 2083 einpackt und eine TLS 1.2- oder TLS 1.3-Sitzung aufbaut. 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 unvertrauenswürdige Netzwerkgrenze ü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 Implementierungen entfernt werden - es bietet keine gegenseitige Authentifizierung und keinen Schutz vor Angriffen zum Abgreifen von Zugangsdaten. PEAP (Protected EAP) und EAP-TTLS bauen vor der Übertragung von Zugangsdaten einen TLS-Tunnel mithilfe eines Serverzertifikats auf, was eine gegenseitige Authentifizierung ermöglicht und die interne Methode vor Abhören schützt. EAP-TLS macht Passwörter völlig überflüssig, da sowohl auf dem Server als auch auf dem Client X.509-Zertifikate erforderlich sind. Es ist immun gegen Phishing und Brute-Force-Angriffe und ist die empfohlene Methode für hochsichere Umgebungen. Unzureichende Protokollierung und Überwachung. Die RADIUS-Abrechnung erfasst jedes Authentifizierungsereignis - Erfolg, Misserfolg, Sitzungsstart, Sitzungsende. Diese Daten sind betrieblich wertvoll für die Kapazitätsplanung und kommerziell wertvoll für WiFi Analytics , aber sie sind auch eine entscheidende Quelle für Sicherheits-Telemetry. Stürme von fehlgeschlagenen Authentifizierungen, Authentifizierungen von unbekannten MAC-Adressen und Zugriffsmuster außerhalb der Geschäftszeiten sind alle aus den RADIUS-Abrechnungsprotokollen erkennbar. Die meisten Organisationen leiten diese Daten nicht in ein SIEM weiter, und diejenigen, die dies tun, konfigurieren selten Alarmschwellenwerte.
Der BlastRADIUS-Angriff im Detail
BlastRADIUS wurde im Juli 2024 von Forschern der Boston University und der UC San Diego offengelegt. Der Angriff erfordert eine Man-in-the-Middle-Position zwischen dem NAS und dem RADIUS-Server - realisierbar über ARP-Poisoning auf 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 (die Standardeinstellung in vielen Konfigurationen), kann der Angreifer die Attributliste des Pakets frei modifizieren. Mithilfe einer MD5-Chosen-Prefix-Kollision konstruiert der Angreifer ein modifiziertes Paket, für das der RADIUS-Server denselben Response Authenticator wie für das Original berechnet. 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 von Administrative, der den vollen Netzwerkzugriff autorisiert.
Der Angriff ist effektiv gegen PEAP- und EAP-TTLS-Bereitstellungen, die MSCHAPv2 als innere Methode verwenden. Er betrifft keine EAP-TLS-Bereitstellungen, bei denen die zertifikatsbasierte gegenseitige Authentifizierung einen Integritätsschutz bietet, den MD5 nicht untergraben kann.
Für Organisationen, die sowohl Guest WiFi als auch geschäftliches 802.1X betreiben, muss auch die RADIUS-Instanz des Gastnetzwerks gepatcht werden, selbst wenn sie MAC-Authentifizierungs-Bypass anstelle von EAP verwendet. Die Hygiene der Shared Secrets und die Anforderung an den Message-Authenticator gelten gleichermaßen.
Implementierungsleitfaden
Phase 1: Sofortige Behebung (Woche 1-2)
Das Patchen steht an erster Stelle. FreeRADIUS 3.2.5 und 3.0.27 enthalten die BlastRADIUS-Fixes und erzwingen den Message-Authenticator standardmäßig. 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 die Patches in Ihrem nächsten geplanten Änderungsfenster an.
Prüfen Sie gleichzeitig die Firmware Ihrer NAS-Geräte. Die Erzwingung des Message-Authenticator ist nur wirksam, wenn der NAS das 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 relevanten Kontext für das Firmware-Management.
Für das troubleshooting Windows 11 802.1X authentication issues , die nach dem Patchen auftreten können, ist die häufigste Ursache, dass der NPS-Server Verbindungen von Clients ablehnt, die den Message-Authenticator nicht enthalten - ein korrektes Sicherheitsverhalten, das bei älteren Windows-Clients eine Rekonfiguration des Supplicants erfordern kann.
Phase 2: Pflege der Shared Secrets (Woche 2 - 4)
Exportieren Sie die vollständige Liste der auf Ihren RADIUS-Servern registrierten NAS-Clients. Erfassen Sie für jeden Eintrag die Länge des Shared Secrets und das Datum der letzten Änderung. Jedes Secret mit weniger als 20 Zeichen oder ein Secret, das seit mehr als 24 Monaten nicht geändert wurde, sollte sofort rotiert werden.
Verwenden Sie für neue Secrets einen kryptografischen Zufallsgenerator - openssl rand -base64 32 erzeugt eine 44-stellige Base64-Zeichenfolge, die sich hervorragend als RADIUS Shared Secret eignet. Speichern Sie alle Secrets in einem Secret-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-Bereich.
Phase 3: EAP-Methoden rationalisieren (Monat 1 - 2)
Überprüfen Sie die EAP-Methoden, die Ihre RADIUS-Server zulassen. Deaktivieren Sie EAP-MD5. Wenn Sie PEAP-MSCHAPv2 ausführen, stellen Sie sicher, dass alle Supplicants die Validierung von Serverzertifikaten erzwingen - ein falsch konfigurierter Supplicant, der jedes Serverzertifikat akzeptiert, ist anfällig für Angriffe durch gefälschte RADIUS-Server. Für Umgebungen im PCI-DSS-Bereich wird EAP-TLS empfohlen. Wenn Sie keine vorhandene Zertifikatsinfrastruktur haben, beginnen Sie mit der PKI-Planung.
Beachten Sie für die securing guest WiFi networks , dass Gastnetzwerke in der Regel eine Captive Portal-Authentifizierung anstelle von 802.1X verwenden. Die Härtung der EAP-Methode gilt daher in erster Linie für Unternehmens- und Mitarbeiter-SSIDs.
Phase 4: RadSec-Bereitstellung (Monat 2 - 3)
Identifizieren Sie alle RADIUS-Verkehrswege, die eine nicht vertrauenswürdige Netzwerkgrenze überschreiten. Typische Szenarien sind ein zentraler RADIUS-Server, der entfernte Hotels über das Internet bedient, On-Premises-NAS-Geräte, die eine Cloud-RADIUS-Verbindung herstellen, und RADIUS-Proxy-Ketten, bei denen der Datenverkehr über mehrere Netzwerkdomänen verläuft.
Konfigurieren Sie für jeden identifizierten Pfad RadSec. Unter FreeRADIUS bedeutet dies, den tls-Listener auf Port 2083 zu aktivieren und Mutual TLS mit Zertifikaten aus Ihrer PKI zu konfigurieren. Auf Cisco ISE wird RadSec unter Administration > Network Devices konfiguriert. Stellen Sie mindestens TLS 1.2 sicher und deaktivieren Sie explizit TLS 1.0 und 1.1.
Phase 5: Multi-Faktor-Authentifizierung für den administrativen Zugriff (Monat 2 - 3)
Die Verwaltungsoberfläche eines RADIUS-Servers ist ein lohnendes Ziel. Ein Angreifer, der den RADIUS-Server kompromittiert, kann die Authentifizierungsrichtlinien ändern, Shared Secrets extrahieren und Authentifizierungsströme umleiten. Erzwingen Sie MFA für administrative Logins auf allen RADIUS-Servern und den 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 Privilegien besitzen wie Sicherheitsadministratoren.
Phase 6: SIEM-Integration und Alarmierung (Monate 3 - 4)
Konfigurieren Sie Ihre RADIUS-Server so, dass sie Accounting-Protokolle in Echtzeit an Ihr SIEM weiterleiten. Definieren Sie die folgenden Schwellenwerte für Basisalarme:
| Alarm | Schwellenwert | Dringlichkeit |
|---|---|---|
| Mehrfache Authentifizierungsfehler von einer einzelnen MAC-Adresse | >5 in 60 Sekunden | Hoch |
| Anstieg der Access-Reject-Rate | 200 % über dem 7-Tage-Basiswert | Mittel |
| Authentifizierung von einer neuen MAC-Adresse auf einer Enterprise-SSID | Erstmaliges Auftreten | Mittel |
| Zertifikat des RADIUS-Servers läuft bald ab | 90 / 30 / 7 Tage | Hoch / Kritisch / Kritisch |
| Fehler durch abweichende Shared Secrets | Jedes 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 und Sicherheitswarnungen von Anbietern zusammen.
Zertifikatsmanagement. Bei jeder Bereitstellung mit EAP-TLS oder RadSec befinden sich X.509-Zertifikate im Authentifizierungspfad. Das Ablaufen von Zertifikaten ist die häufigste Ursache für plötzliche, vollständige Authentifizierungsfehler in Enterprise-WiFi-Umgebungen. Implementieren Sie ein automatisiertes Zertifikats-Lifecycle-Management. Richten Sie Überwachungswarnungen 90, 30 und 7 Tage vor dem Ablaufdatum ein. Verwenden Sie für RADIUS-Server-Zertifikate Schlüssel mit mindestens 2048-Bit-RSA oder 256-Bit-ECDSA sowie SHA-256 oder stärkere Signaturalgorithmen. Verwenden Sie kein SHA-1.
Netzwerksegmentierung. RADIUS-Server sollten sich in einem dedizierten Managementsegment befinden, das von Gäste- und allgemeinen Unternehmensnetzwerken isoliert ist. Der Zugriff auf die RADIUS-Ports (UDP 1812, 1813 und TCP 2083 für RadSec) sollte per Firewall-ACL auf die spezifischen IP-Adressen der registrierten NAS-Geräte beschränkt werden. Erlauben Sie keinen direkten Internetzugriff auf RADIUS-Ports.
Redundanz und Hochverfügbarkeit. Ein einzelner RADIUS-Server stellt einen Single Point of Failure für Ihre gesamte Netzwerkkontrollinfrastruktur dar. Stellen Sie mindestens zwei RADIUS-Server in einer Active-Passive- oder Active-Active-Konfiguration bereit. Bei Implementierungen im Bereich Hospitality mit Anforderungen an eine 24/7-Gästekonnektivität führt der Ausfall eines RADIUS-Servers direkt zum Ausfall des Gäste-WiFi - ein Reputations- und Geschäftsrisiko. WPA3 and 802.1X. WPA3-Enterprise im 192-Bit-Sicherheitsmodus, der für staatliche und hochsichere Implementierungen erforderlich ist, schreibt AES-256-GCMP für die Datenverschlüsselung und HMAC-SHA-384 für die Authentifizierung vor. Für die meisten Enterprise-Implementierungen ist WPA3-Enterprise mit standardmäßiger 128-Bit-Sicherheit bereits eine deutliche Verbesserung gegenüber WPA2-Enterprise, insbesondere in Kombination mit EAP-TLS. Einzelhandelsumgebungen , die Kartenzahlungen verarbeiten, sollten die Einführung von WPA3-Enterprise als Maßnahme zur Risikominderung im Rahmen von PCI-DSS betrachten.
Patch-Frequenz der Anbieter. Abonnieren Sie Sicherheitswarnungen Ihres RADIUS-Server-Anbieters und Ihrer NAS-Gerätehersteller. FreeRADIUS, Cisco, Microsoft, Aruba und Ruckus veröffentlichen alle CVE-Benachrichtigungen. Integrieren Sie diese in Ihr Schwachstellenmanagementprogramm mit definierten SLAs: Kritische Schwachstellen (CVSS ≥ 9,0) müssen innerhalb von 72 Stunden behoben werden; Schwachstellen mit hoher Priorität (CVSS 7,0-8,9) innerhalb von 14 Tagen.
Fehlerbehebung und Risikominderung
Häufige Fehlermuster
Authentifizierungsfehler nach dem Patchen. Nach dem Einspielen von BlastRADIUS-Patches schlägt bei einigen NAS-Geräten die Authentifizierung möglicherweise fehl, wenn deren Firmware Message-Authenticator nicht unterstützt. Symptom: Ein plötzlicher Anstieg von Access-Reject-Antworten ohne Änderung der Benutzeranmeldedaten. Diagnose: Aktivieren Sie das RADIUS-Debug-Logging und prüfen Sie auf Fehler wie "Message-Authenticator required but not present". Lösung: Aktualisieren Sie die NAS-Firmware oder konfigurieren Sie den RADIUS-Server vorübergehend so, dass er Anfragen ohne Message-Authenticator von bestimmten NAS-IPs akzeptiert, während Firmware-Updates geplant werden.
Zertifikatsvalidierungsfehler bei EAP-TLS. Symptom: Clients erhalten die Meldung "Authentifizierung fehlgeschlagen", ohne dass ein entsprechendes Access-Reject im RADIUS-Protokoll angezeigt wird. Diagnose: Überprüfen Sie die Zertifikatskette des RADIUS-Servers - vertraut der Client-Supplicant der ausstellenden CA? Liegt das Serverzertifikat innerhalb seiner Gültigkeitsdauer? Lösung: Stellen Sie sicher, dass die vollständige Zertifikatskette (Leaf + Intermediate + Root) auf dem RADIUS-Server konfiguriert ist. Verteilen Sie Root-CA-Zertifikate per MDM oder Gruppenrichtlinie an die Client-Geräte.
RadSec TLS-Handshake-Fehler. Symptom: NAS-Geräte können nach einer Konfigurationsänderung keine RadSec-Verbindungen herstellen. Diagnose: Überprüfen Sie die TLS-Versionskompatibilität - ältere NAS-Firmware unterstützt möglicherweise kein TLS 1.2. Überprüfen Sie die gegenseitige Zertifikatsauthentifizierung - beide Seiten müssen der CA des jeweils anderen vertrauen. Lösung: Überprüfen Sie die TLS-Versionsunterstützung in den Versionshinweisen der NAS-Firmware; stellen Sie sicher, dass die NAS-Gerätezertifikate von derselben CA ausgestellt wurden, der auch der RADIUS-Server vertraut.
Fehlerhafter Shared Secret. Symptom: Jede Authentifizierung von einem bestimmten NAS schlägt mit Fehlern wie "invalid authenticator" fehl. Diagnose: Das Shared Secret stimmt zwischen der NAS-Konfiguration und dem Client-Eintrag des RADIUS-Servers nicht überein. Lösung: Geben Sie das Shared Secret auf beiden Seiten neu ein und achten Sie dabei auf nachfolgende Leerzeichen oder Probleme mit der Zeichenkodierung. Kopieren Sie den Wert aus Ihrem Secrets-Manager, um Übertragungsfehler zu vermeiden.
Risikoregister
| Risiko | Wahrscheinlichkeit | Auswirkung | Risikomindernde Maßnahmen |
|---|---|---|---|
| BlastRADIUS-Exploit | Hoch (wenn ungepatcht) | Kritisch | Patching + Erzwingen des Message-Authenticator |
| Brute-Force auf Shared Secret | Mittel | Hoch | Zufällige Secrets mit 32 Zeichen, jährliche Rotation |
| Rogue RADIUS Server | Mittel | Hoch | EAP-TLS gegenseitige Authentifizierung, Zertifikat-Pinning |
| RADIUS Serverzertifikat-Ablauf | Hoch | Kritisch | Automatisiertes Monitoring, Benachrichtigung 90 Tage im Voraus |
| Credential Stuffing via 802.1X | Mittel | Hoch | Kontosperrungs-Richtlinie, SIEM-Alarmierung |
| RADIUS Server-Kompromittierung | Niedrig | Kritisch | MFA für Admin-Zugriff, Netzwerksegmentierung |
ROI und geschäftliche Auswirkungen
Quantifizierung des Risikos
Die finanzielle Argumentation für die Härtung von RADIUS ist am deutlichsten, wenn man sie den Kosten einer Datenpanne gegenüberstellt. Die durchschnittlichen Kosten einer Datenpanne in Großbritannien lagen im Jahr 2024 bei 3,58 Millionen Pfund - dies umfasst behördliche Bußgelder, Behebungsarbeiten, Rechtskosten und Reputationsschäden. Für Organisationen im Anwendungsbereich von PCI-DSS - praktisch alle Betreiber in Retail und Hospitality , die Kartenzahlungen über WiFi akzeptieren - führt eine Sicherheitsverletzung bei der Netzwerkzugangskontrolle, die Karteninhaberdaten offenlegt, zu einer obligatorischen forensischen Untersuchung, potenziellen Bußgeldern der Kartensysteme und einer möglichen Aussetzung der Berechtigung zur Kartenverarbeitung.
Für Organisationen im Bereich Healthcare führt eine DSGVO-Verletzung (GDPR), die Patientendaten betrifft und über einen kompromittierten RADIUS Server erfolgt, gemäß Artikel 83 Absatz 5 zu Bußgeldern von bis zu 4 % des weltweiten Jahresumsatzes. Die Durchsetzungspraxis des ICO zeigt, dass Mängel in der Netzwerksicherheit als Fahrlässigkeit und nicht als technisches Unglück eingestuft werden.
Benchmarks für Implementierungskosten
Die folgenden Kostenschätzungen basieren auf einem Unternehmensnetzwerk mit 500 Geräten:
| Härtungsmaßnahme | Geschätzte Kosten | Zeitrahmen |
|---|---|---|
| Patching (FreeRADIUS / NPS / ISE) | Nur interne Arbeitszeit | 1-2 Wochen |
| Audit und Rotation des Shared Secret | Interne Arbeitszeit + Secrets Manager-Lizenz (~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 bestehenden SIEM; 0-10.000 £ | 4-8 Wochen |
Die Gesamtinvestition für die Härtung in einem mittelständischen Unternehmen liegt bei ca. 20.000-45.000 £. Verglichen mit dem Ausgangswert für die Kosten einer Datenpanne von 3,58 Millionen Pfund 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 Verbindung. RADIUS Accounting-Daten bieten bei der Integration mit WiFi Analytics Transparenz auf Sitzungsebene über Netzwerknutzungsmuster, Verweilzeiten und Gerätetypen - Daten mit direktem kommerziellem Wert für Standortbetreiber in den Bereichen Hospitality und Transport . Für Organisationen des öffentlichen Sektors und des Gesundheitswesens bietet ein dokumentiertes RADIUS-Härtungsprogramm 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 Regulierungsbehörden.
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.