Mitigating RADIUS Vulnerabilities: A Security Hardening Guide
Dieser Leitfaden bietet eine umfassende, direkt anwendbare Referenz für IT-Manager, 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-Kollisionsschachstellen und schwachen Shared Secrets bis hin zu unverschlüsseltem UDP-Transport und falsch konfigurierten EAP-Methoden - und liefert eine priorisierte Hardening-Roadmap, die auf IEEE 802.1X, PCI-DSS und GDPR-Anforderungen abgestimmt ist. Organisationen, die diese Empfehlungen umsetzen, reduzieren ihre Gefährdung durch anmeldedatenbasierte Netzwerkangriffe erheblich, erfüllen Compliance-Verpflichtungen und bauen eine robuste Sicherheitsstruktur für ihre Gäste- und Unternehmens-WiFi-Infrastruktur auf.
Diesen Leitfaden anhören
Podcast-Transkript ansehen
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 |
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 Kontoführung (AAA) für den Netzwerkzugriff bietet. 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-Zugriff und Netzwerkgeräteverwaltung. 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 koordiniert, 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 Authentifizierungsaustausch vollständig eliminiert werden.
EAP-TLS ist der Goldstandard für die WiFi-Authentifizierung in Unternehmen. Es ist immun gegen Zugangsdaten-Phishing 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 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 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 angewendet 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 bei BlastRADIUS verwendeten Paketmanipulationsangriff.
Die Erzwingung des Message-Authenticator auf allen Access-Request-Paketen ist die primäre Behebung für 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, Switch oder 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 BlastRADIUS-Behebung erfordert Firmware-Updates auf 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 innere Authentifizierungsmethode (typischerweise MSCHAPv2) übertragen wird. Sie bietet gegenseitige Authentifizierung und schützt Zugangsdaten 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 keine Client-Zertifikate erforderlich sind. 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. Er ist kein Passwort für Endbenutzer, sondern ein Berechtigungsnachweis für die Server-zu-Server-Authentifizierung.
Schwache oder statische Shared Secrets gehören zu den häufigsten RADIUS-Schachstellen. 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 Zeichen, zufällig generiert.
PCI DSS (Payment Card Industry Data Security Standard)
Ein Satz von Sicherheitsstandards, der von den großen Kartenorganisationen (Visa, Mastercard, Amex) für Unternehmen vorgeschrieben wird, die Karteninhaberdaten verarbeiten, speichern oder übertragen. Version 4.0, die ab März 2024 gilt, enthält spezifische Anforderungen für die Netzwerkzugriffskontrolle und eine starke Authentifizierung.
Einzelhandels- und Gastronomiebetriebe mit über WiFi verbundenen POS-Terminals fallen in den Geltungsbereich von PCI DSS. RADIUS-Server-Schwachstellen, 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 zentralen RADIUS-Server, der im Rechenzentrum der Zentrale gehostet wird. Jedes Objekt ist über ein gemeinsames MPLS-WAN verbunden. Ein Sicherheitsaudit hat ergeben, dass der RADIUS-Verkehr ü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 ausgeführt wird. Die Gruppe wickelt Kartenzahlungen über WiFi-verbundene POS-Terminals in ihren Restaurant- und Wellnessbereichen ab. Wie sehen die Priorisierung der Behebung und die Implementierungsreihenfolge aus?
Die Behebungsreihenfolge sollte nach Risikoschweregrad und Implementierungsgeschwindigkeit priorisiert werden. Schritt 1 (sofort, innerhalb von 72 Stunden): FreeRADIUS auf 3.2.5 oder 3.0.27 patchen. 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): Alle Shared Secrets rotieren. 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): RadSec auf dem WAN-Pfad implementieren. 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 an den WAN-Schnittstellen, sobald die Funktion von RadSec bestätigt wurde. Schritt 4 (Monat 2-3): Für die im PCI-DSS-Bereich liegende POS WiFi SSID von PEAP-MSCHAPv2 auf EAP-TLS migrieren. Stellen Sie eine interne PKI bereit (Microsoft ADCS oder HashiCorp Vault PKI-Engine). Stellen Sie Client-Zertifikate über MDM an POS-Terminals aus. Aktualisieren Sie die RADIUS-Richtlinie, um EAP-TLS für die POS-SSID vorzuschreiben. Schritt 5 (Monat 3): Integrieren Sie RADIUS-Accounting-Logs in das SIEM. Konfigurieren Sie Alarme für Spitzen bei fehlgeschlagenen Authentifizierungen und Zertifikatsabläufe.
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 mit Microsoft NPS als RADIUS-Server migrieren, der in das Active Directory integriert ist. In den Filialen wird eine Mischung aus Aruba- und Cisco-Access-Points eingesetzt. Die Kette fällt in den Geltungsbereich von PCI DSS. 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 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 mit PEAP-MSCHAPv2 übereinstimmt und die Gruppenmitgliedschaft in einer AD-Sicherheitsgruppe (z. B. „WiFi-Staff-Access“) erfordert. Setzen Sie das Sitzungs-Timeout 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 > Drahtlosnetzwerk-Richtlinien). Verwenden Sie für iOS- und Android-Geräte ein MDM-Profil. Erzwingen Sie die Serverzertifikatsvalidierung - erlauben Sie Benutzern nicht, beliebige Zertifikate zu akzeptieren. (4) Access-Point-Konfiguration: Konfigurieren Sie auf Aruba den RADIUS-Server unter Authentifizierung > Server. Legen Sie das gemeinsame Geheimnis (Shared Secret) auf eine zufällige Zeichenfolge mit 32 Zeichen fest. 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 Break-Glass-SSID mit einem komplexen PSK im Secrets Manager für den Fall, dass NPS nicht verfügbar ist.
Übungsfragen
Q1. Ihr Unternehmen betreibt einen FreeRADIUS 3.0.21-Server, der die 802.1X-Authentifizierung für 800 Mitarbeitergeräte an einem einzigen Campus-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 Network Operations Team ist besorgt, dass die Authentifizierung für 800 Benutzer unterbrochen wird. Wie strukturieren Sie die Behebung, um Serviceunterbrechungen zu minimieren?
Hinweis: Berücksichtigen Sie den Unterschied zwischen dem RADIUS-Server, der Message-Authenticator verlangt, 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) Patchen Sie FreeRADIUS zuerst auf 3.2.5. Diese Version erzwingt 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. Identifizieren Sie, welche Modelle und Firmware-Versionen 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 ist, dass alle Access Points 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 "Message-Authenticator fehlt"-Warnungen, die auf NAS-Geräte hinweisen würden, die das Firmware-Update verpasst haben. Das Hauptprinzip besteht darin, dass Sie den Server zuerst patchen können, ohne etwas zu beschädigen, da der Kompatibilitätsmodus eine Übergangszeit ermöglicht. Das Erzwingen der strikten Ablehnung auf dem Server sollte der letzte Schritt sein, nachdem alle NAS-Geräte aktualisiert wurden.
Q2. Der Betreiber eines Konferenzzentrums betreibt einen einzigen RADIUS-Server, der sowohl die SSID für Unternehmensmitarbeiter (802.1X mit PEAP-MSCHAPv2) als auch das WiFi für Event-Gäste (Captive Portal mit MAC-Authentifizierungs-Bypass) unterstützt. Der IT-Manager fragt, ob die RADIUS-Instanz des Gäste-WiFi nach demselben Standard gehärtet werden muss wie die RADIUS-Instanz des Unternehmens, da sich Gäste nicht mit Unternehmensdaten authentifizieren. Was ist Ihre Empfehlung?
Hinweis: Berücksichtigen Sie die Angriffsvektoren, die für MAC-Authentifizierungs-Bypass im Vergleich zur EAP-basierten Authentifizierung gelten, und das Risiko von Lateral Movement zwischen den Guest- und Corporate-RADIUS-Instanzen.
Musterlösung anzeigen
Die RADIUS-Instanz für das Gäste-WiFi erfordert eine Härtung, aber die spezifischen Kontrollen unterscheiden sich 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 bezüglich Shared Secrets gilt gleichermaßen - ein schwaches Shared Secret zwischen dem Controller des Gäste-Captive-Portals 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 das Gäste- und das Unternehmens-SSID vom selben RADIUS-Serverprozess verarbeitet werden, könnte eine Schwachstelle im RADIUS-Pfad des Gastes genutzt werden, um auf die Authentifizierungsrichtlinie des Unternehmens zuzugreifen. Die empfohlene Architektur besteht darin, separate RADIUS-Instanzen (oder zumindest separate virtuelle Server innerhalb von FreeRADIUS) für die Gäste- und Unternehmensauthentifizierung auszuführen, mit separaten Shared Secrets und separaten Richtliniensätzen. Dies bietet eine Isolierung, so dass eine Kompromittierung des RADIUS-Pfads des Gastes keine Unternehmens-Anmeldedaten offenlegt. Speziell für die Gästeinstanz: Patchen Sie für BlastRADIUS, rotieren Sie Shared Secrets und stellen Sie sicher, dass die Gäste-RADIUS-Instanz keinen Zugriff auf das Active Directory des Unternehmens hat. Die EAP-TLS- und RadSec-Anforderungen sind für eine Bereitstellung über ein Captive Portal weniger relevant, aber RadSec sollte dennoch in Betracht gezogen werden, wenn sich der Captive Portal Controller in einem anderen Netzwerksegment als der RADIUS-Server befindet.
Q3. Eine Gesundheitseinrichtung plant, ihr klinisches WiFi von WPA2-Personal auf eine 802.1X-Authentifizierung umzustellen. Die Einrichtung 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 wie sieht der empfohlene Implementierungspfad aus?
Hinweis: Berücksichtigen Sie das spezifische Bedrohungsmodell für eine Umgebung im Gesundheitswesen - 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 CISOs ist richtig, aber die Sorge des IT-Leiters ist berechtigt. Die empfohlene Vorgehensweise lautet: Implementieren Sie PEAP-MSCHAPv2 jetzt als Zwischenlösung, mit einer verbindlichen 12-monatigen 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 über Rogue-RADIUS-Server, wenn die clientseitige Zertifikatsprüfung nicht erzwungen wird. In einer Umgebung im Gesundheitswesen, in der das klinische Personal auch private Geräte verbinden kann, ist die konsistente Durchsetzung der Supplicant-Konfiguration auf 1.200 Geräten im Betrieb eine Herausforderung. (2) Wenn MSCHAPv2-Anmeldedaten über einen Rogue-RADIUS-Angriff abgefangen werden, können sie 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 Serverzertifikatsprüfung ü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 Gruppenrichtlinien-Registrierung. Monat 6-9: Registrierung von iOS- und Android-Geräten über MDM-Zertifikatsprofile. Monat 9-12: Migration der klinischen SSID-Richtlinie von PEAP auf EAP-TLS. Beibehalten von PEAP als Fallback für alle Geräte, bei denen die Zertifikatsregistrierung fehlschlägt, mit erweiterter Überwachung. Weitere Informationen zur Sicherheitsarchitektur für klinische Netzwerke finden Sie im WiFi in Hospitals Guide , der den relevanten Bereitstellungskontext liefert.
Weiterlesen in dieser Reihe
Sophos Firewall und Gäste-WiFi: Captive Portal-Einrichtung mit Purple
Wie das Cloud-Gäste-WiFi von Purple mit Sophos Firewall und deren Access Points über ein standardmäßiges externes Captive Portal und RADIUS funktioniert, und wo Sie den Support prüfen und die Schritte finden.
Mikrotik RouterOS und Gäste-WiFi: Captive Portal-Einrichtung mit Purple
Wie das Cloud-Gäste-WiFi von Purple auf MikroTik-Geräten mit RouterOS unter Verwendung des integrierten Hotspots und RADIUS aufsetzt und wo Sie die genauen Einrichtungsschritte finden.
DrayTek Vigor und Gäste-WiFi: Captive Portal-Einrichtung mit Purple
Wie DrayTek Vigor-Router mit Purple Gäste-WiFi funktionieren: ein externes Captive Portal, RADIUS und ein Walled Garden, mit einem Link zur Schritt-für-Schritt-Anleitung von Purple für die genaue Konfiguration.