Was ist PEAP-Authentifizierung? Wie PEAP Ihr WiFi sichert

Was ist PEAP-Authentifizierung? Wie PEAP Ihr WiFi schützt. Ein Purple Enterprise WiFi Intelligence Briefing. Willkommen. Wenn Sie für die Netzwerksicherheit in einer Hotelgruppe, einem Einzelhandelsunternehmen, einem Stadion oder einer Organisation des öffentlichen Sektors verantwortlich sind, ist dieses Briefing genau das Richtige für Sie. In den nächsten zehn Minuten werden wir uns mit der PEAP-Authentifizierung befassen - was sie eigentlich ist, wie sie unter der Haube funktioniert, wo sie in Ihre Sicherheitsarchitektur passt und vor allem, wann sie die richtige Wahl ist und wann Sie nach etwas Stärkerem suchen sollten. Gehen wir ins Detail. Abschnitt eins: Kontext und warum das genau jetzt wichtig ist. Die meisten Enterprise WiFi-Bereitstellungen basieren heute immer noch auf einem von zwei Authentifizierungsmodellen. Sie haben entweder einen Pre-Shared Key - ein einziges Passwort, das im gesamten Unternehmen geteilt wird - oder Sie nutzen 802.1X, den IEEE-Standard für portbasierte Netzwerkzugriffskontrolle. PEAP gehört eindeutig in das 802.1X-Lager und ist weltweit die mit Abstand am häufigsten eingesetzte EAP-Methode in Unternehmens- und institutionellen Umgebungen. Der Grund, warum PEAP so dominant wurde, ist einfach: Es löste ein reales Betriebsproblem. Vor PEAP bedeutete die Bereitstellung einer zertifikatsbasierten WiFi-Authentifizierung, dass Client-Zertifikate für jedes Gerät ausgestellt werden mussten - für jeden Laptop, jedes Telefon, jedes Tablet. Für ein Unternehmen mit fünfhundert Mitarbeitern und einer BYOD-Richtlinie ist das ein administrativer Aufwand für die PKI-Bereitstellung, für den die meisten IT-Teams schlichtweg weder das Budget noch die Zeit hatten. PEAP bot einen Mittelweg: starke serverseitige Authentifizierung über TLS mit Benutzername und Passwort auf der Client-Seite. Keine Client-Zertifikate erforderlich. Dieser Kompromiss machte PEAP in den 2000er und 2010er Jahren zum De-facto-Standard für die WiFi-Authentifizierung in Unternehmen und ist auch heute noch extrem weit verbreitet. Das Verständnis der Architektur - und ihrer Grenzen - ist für jeden, der im Jahr 2024 und darüber hinaus Entscheidungen über die Infrastruktur trifft, von entscheidender Bedeutung. Abschnitt zwei: Technische Vertiefung. Lassen Sie uns genau durchgehen, was passiert, wenn sich ein Gerät über PEAP authentifiziert. Der Prozess besteht aus zwei verschiedenen Phasen, und das Verständnis beider Phasen ist entscheidend. Die drei Akteure bei diesem Austausch sind: der Supplicant - das ist das Client-Gerät, sei es ein Laptop, ein Smartphone oder ein IoT-Terminal; der Authenticator - in der Regel der Wireless Access Point oder der Wireless LAN Controller; und der Authentifizierungsserver - fast immer ein RADIUS-Server, wie Microsoft NPS, FreeRADIUS oder ein Cloud-gehosteter RADIUS-Service. Phase eins ist der Aufbau des TLS-Tunnels. Wenn der Supplicant versucht, eine Verbindung herzustellen, gewährt der Authenticator nicht sofort Zugriff. Stattdessen initiiert er einen EAP-Austausch über das lokale Netzwerk - das ist EAPOL, EAP over LAN. Der Authenticator leitet dies an den RADIUS-Server weiter, der dem Client sein serverseitiges TLS-Zertifikat präsentiert. Der Client validiert dieses Zertifikat mit seinem vertrauenswürdigen Zertifikatsspeicher. Wenn die Validierung erfolgreich ist, wird ein TLS-Tunnel zwischen dem Client und dem RADIUS-Server aufgebaut. Dieser Tunnel ist verschlüsselt - in modernen Bereitstellungen typischerweise mit TLS 1.2 oder 1.3. Phase zwei ist die innere Authentifizierung. Innerhalb dieses verschlüsselten Tunnels werden die eigentlichen Anmeldedaten ausgetauscht. Bei der am häufigsten verwendeten Implementierung - PEAP-MSCHAPv2 - sendet der Client einen Benutzernamen und ein Passwort unter Verwendung des Microsoft Challenge Handshake Authentication Protocol Version 2. Der RADIUS-Server validiert diese Anmeldedaten mit seinem Identitätsspeicher, bei dem es sich um Active Directory, LDAP oder einen Cloud-Identitätsanbieter handeln kann. Wenn die Anmeldedaten korrekt sind, sendet der RADIUS-Server eine Access-Accept-Nachricht über den Authentifikator zurück, und dem Client wird der Netzwerkzugriff gewährt. Der entscheidende Sicherheitsvorteil hierbei ist, dass der MSCHAPv2-Austausch innerhalb des TLS-Tunnels stattfindet. Ein Angreifer, der den drahtlosen Kanal passiv überwacht, kann die übertragenen Anmeldedaten nicht sehen. Das ist der wesentliche Vorteil von PEAP. Wo liegen nun die Schwachstellen von PEAP-MSCHAPv2? Es gibt zwei wesentliche Probleme, die jeder sicherheitsbewusste Architekt verstehen muss. Erstens: Die Validierung des Serverzertifikats. PEAP erfordert nur, dass der Server ein Zertifikat vorlegt - es erfordert nicht, dass der Client eines vorlegt. Dies schafft einen gut dokumentierten Angriffsvektor. Wenn ein Client-Gerät so falsch konfiguriert ist, dass es jedes Zertifikat akzeptiert - oder Zertifikate von jeder CA akzeptiert - kann ein Angreifer einen betrügerischen Access Point einrichten, ein gefälschtes Zertifikat vorlegen und den MSCHAPv2-Handshake abfangen. Tools wie hostapd-wpe haben diesen Angriff kinderleicht gemacht. Die Gegenmaßnahme ist eine rigorose Konfiguration des Supplicants: Erzwingen Sie die Validierung des Serverzertifikats, pinnen Sie die erwartete CA und geben Sie den Common Name des Servers an. Dies ist in jeder professionellen Bereitstellung nicht verhandelbar. Zweitens: MSCHAPv2 ist ein älteres Protokoll mit bekannten Schwachstellen. Die Untersuchungen von Moxie Marlinspike aus dem Jahr 2012 haben gezeigt, dass MSCHAPv2-Challenge-Response-Paare mit ausreichender Rechenleistung offline geknackt werden können. Wenn ein Angreifer den inneren Authentifizierungsaustausch abfängt - beispielsweise durch den oben beschriebenen Angriff über einen gefälschten Access Point - kann er versuchen, das Passwort im Klartext offline wiederherzustellen. Die Stärke Ihrer Passwortrichtlinie wirkt sich daher direkt auf Ihr Risiko aus. Lange, komplexe, zufällig generierte Passwörter reduzieren dieses Risiko erheblich. Vergleichen Sie dies mit EAP-TLS, bei dem sowohl der Server als auch der Client Zertifikate vorlegen. Es gibt keine Passwörter, die gestohlen werden können. Die Angriffsfläche wird drastisch reduziert. Der Nachteil ist die betriebliche Komplexität: Sie benötigen eine PKI, Sie müssen Client-Zertifikate ausstellen und verwalten, und Sie benötigen einen Mechanismus, um diese an jedes Gerät zu verteilen. Für Organisationen mit einer ausgereiften MDM-Bereitstellung und einer gut verwalteten PKI ist EAP-TLS der Goldstandard. Für alle anderen bleibt PEAP-MSCHAPv2 mit einer rigorosen Konfiguration eine vertretbare und praktische Wahl. Abschnitt drei: Implementierungsempfehlungen und Fallstricke. Hier sind einige praktische Richtlinien für die Bereitstellung. Dies sind die Punkte, die eine sichere PEAP-Bereitstellung von einer anfälligen unterscheiden. Erstens: Erzwingen Sie die Serverzertifikatsvalidierung auf jedem Supplicant. Dies ist der wichtigste Konfigurationspunkt überhaupt. Unter Windows ist dies das Kontrollkästchen "Serverzertifikat überprüfen" im WLAN-Profil. Unter iOS und Android ist es das CA-Zertifikatsfeld in der EAP-Konfiguration. Wenn dies nicht konfiguriert ist, ist Ihre PEAP-Bereitstellung anfällig für Rogue AP-Angriffe, unabhängig davon, wie gut alles andere eingerichtet ist. Zweitens: Die Bereitstellung sollte über MDM oder GPO erfolgen, nicht über eine manuelle Konfiguration. Die manuelle Konfiguration durch Endbenutzer ist unzuverlässig. Benutzer klicken sich durch Zertifikatswarnungen. Sie konfigurieren das CA-Feld falsch. Verteilung Sie Ihre WLAN-Profile über Microsoft Intune, Jamf oder Gruppenrichtlinien (GPO). Dies stellt eine konsistente, richtlinienkonforme Supplicant-Konfiguration auf all Ihren Geräten sicher. Drittens: Verwenden Sie mindestens TLS 1.2 auf Ihrem RADIUS-Server. Deaktivieren Sie TLS 1.0 und 1.1. Die meisten modernen RADIUS-Implementierungen unterstützen dies, aber es lohnt sich, dies zu überprüfen - insbesondere bei älteren On-Premises-Bereitstellungen. Viertens: Integrieren Sie Ihren Identitätsanbieter. PEAP-MSCHAPv2 authentifiziert sich gegen einen Anmeldedatenspeicher. Dieser Speicher sollte Ihr autoritativer Identitätsanbieter sein - Active Directory, Azure AD über NPS-Erweiterung oder ein Cloud-RADIUS-Service mit LDAP-Integration. Das bedeutet: Wenn ein Mitarbeiter das Unternehmen verlässt, entzieht das Deaktivieren seines Kontos sofort seinen WiFi-Zugang. Keine gemeinsam genutzten Passwörter, die geändert werden müssen, keine manuelle Deaktivierung. Fünftens: Betrachten Sie Ihr Gastnetzwerk separat. PEAP ist eine Authentifizierungsmethode für Unternehmen. Für das Gäste-WiFi - wo Sie Besucher, Kunden oder Event-Teilnehmer anmelden - benötigen Sie einen anderen Ansatz. Plattformen wie Purple bieten eine speziell entwickelte Gäste-WiFi-Ebene, die die Authentifizierung über ein Captive Portal, die Datenerfassung und Analysen übernimmt, ohne dass eine RADIUS-Infrastruktur auf der Gäste-SSID erforderlich ist. Belassen Sie Ihre Unternehmens-SSID auf 802.1X mit PEAP und Ihre Gäste-SSID auf einem separaten, isolierten Netzwerk mit entsprechendem Onboarding. Sechstens: Planen Sie die Zertifikatsrotation. Das Zertifikat Ihres RADIUS-Servers läuft irgendwann ab. Wenn dies geschieht, schlägt die Authentifizierung bei jedem Client, der dieses Zertifikat fest hinterlegt hat, fehl, bis das neue Zertifikat verteilt ist. Planen Sie die Zertifikatserneuerung fest in Ihren Betriebskalender ein - mindestens 90 Tage vor Ablauf - und testen Sie den Rotationsprozess in einer Staging-Umgebung, bevor Sie ihn in der Produktion einführen. Die häufigsten Fehlerursachen, die ich in der Praxis sehe, sind: Die Zertifikatsvalidierung wird nicht erzwungen, was zu einer Sicherheitslücke durch Rogue APs führt; RADIUS-Serverzertifikate laufen ohne Vorwarnung ab, was zu weitreichenden Authentifizierungsfehlern führt; und die interne MSCHAPv2-Authentifizierung liegt offen, weil der RADIUS-Server aus dem falschen Netzwerksegment erreichbar ist. Alle drei Probleme lassen sich mit der richtigen Planung vermeiden. Bereich vier: Schnelle Fragen und Antworten. Kann PEAP mit Cloud-Identitätsanbietern wie Azure AD verwendet werden? Ja. Die NPS-Erweiterung von Microsoft für Azure AD MFA ermöglicht es Ihnen, die PEAP-Authentifizierung über Azure AD zu proxyen, was eine Multi-Faktor-Authentifizierung für Ihr WiFi ermöglicht. Alternativ können Cloud-RADIUS-Dienste wie Cisco ISE, Aruba ClearPass oder JumpCloud RADIUS direkt in Azure AD oder Okta integriert werden. Ist PEAP konform mit PCI-DSS? PEAP-MSCHAPv2 kann in PCI-DSS-Umgebungen eingesetzt werden, aber Sie müssen sicherstellen, dass die Serverzertifikatsvalidierung erzwungen wird, TLS 1.2 oder höher verwendet wird und der RADIUS-Server ordnungsgemäß segmentiert ist. PCI-DSS 4.0 verschärft die Anforderungen an Netzwerkzugriffskontrollen - überprüfen Sie die relevanten Anforderungen mit Ihrem QSA. Sollte ich von PEAP auf EAP-TLS migrieren? Wenn Sie über eine ausgereifte MDM-Bereitstellung und die operative Kapazität zur Verwaltung einer PKI verfügen, ja - EAP-TLS ist die stärkere Wahl. Wenn Sie eine gemischte Umgebung mit persönlichen Geräten, älterer Hardware oder eingeschränkter MDM-Abdeckung verwalten, bleibt PEAP-MSCHAPv2 mit strenger Konfiguration weiterhin angemessen. Dies ist eine risikobasierte Entscheidung, keine binäre. Was ist mit WPA3-Enterprise? WPA3-Enterprise schreibt den 192-Bit-Sicherheitsmodus für Hochsicherheitsumgebungen vor, unterstützt aber weiterhin EAP-Methoden einschließlich PEAP. WPA3 verbessert die Verschlüsselung über die Luft, ändert jedoch nicht den EAP-Authentifizierungsaustausch selbst. Abschnitt fünf: Zusammenfassung und nächste Schritte. Zusammenfassend lässt sich sagen: PEAP ist ein zweiphasiges Authentifizierungsprotokoll, das interne Anmeldeinformationen - in der Regel MSCHAPv2 - in einen TLS-Tunnel verpackt. Es ist die am weitesten verbreitete 802.1X EAP-Methode, da sie Client-Zertifikate überflüssig macht und dennoch eine starke Serverauthentifizierung bietet. Seine Hauptschwachstelle sind Rogue-AP-Angriffe, die durch falsch konfigurierte Supplicants ermöglicht werden, die das Serverzertifikat nicht validieren. Verringern Sie dieses Risiko durch über MDM erzwungene WLAN-Profile, CA-Pinning und Servernamensvalidierung. Für die meisten Enterprise WiFi-Bereitstellungen - Unternehmensbüros, Back-of-House-Netzwerke in Hotels, Netzwerke für Einzelhandelsmitarbeiter - ist PEAP-MSCHAPv2 mit der richtigen Konfiguration eine solide, vertretbare Wahl. Für Hochsicherheitsumgebungen, regulierte Branchen oder Organisationen mit einer ausgereiften PKI-Infrastruktur bietet EAP-TLS eine deutlich stärkere Sicherheit und sollte die Zielarchitektur sein. Wenn Sie neben Ihrem Unternehmensnetzwerk auch ein Gast-WiFi betreiben - was auf die meisten von Ihnen zutrifft - denken Sie daran, dass PEAP nicht das richtige Tool für das Onboarding von Gästen ist. Nutzen Sie Plattformen wie Purple, die eine speziell entwickelte Gast-WiFi-Authentifizierung mit Analysen, Datenerfassung und Marketingintegration bieten, sodass Ihr Gast- und Unternehmensdatenverkehr ordnungsgemäß getrennt und Ihre Compliance gewahrt bleibt. Weitere Informationen finden Sie in den Leitfäden von Purple zur RADIUS-Serverarchitektur und zur Enterprise WiFi-Authentifizierung. Die Links finden Sie in den Shownotes. Vielen Dank fürs Zuhören. Dies war ein Purple Enterprise WiFi Intelligence Briefing.