Was ist ein 802.1X Supplicant? Client-Typen und Gerätekonfiguration

Sprechen Sie in britischem Englisch mit einem selbstbewussten, autoritären und lockeren Tonfall - wie ein leitender Netzwerksicherheitsberater, der einen Kunden brieft. Gemäßigtes Tempo, klare Aussprache, professionell, aber nicht steif. Gelegentliche natürliche Pausen zur Betonung: Willkommen zur technischen Briefing-Reihe von Purple. Heute befassen wir uns mit einem Thema, das das Herzstück der WLAN-Sicherheit in Unternehmen bildet - dem 802.1X Supplicant. Wenn Sie sich jemals gefragt haben, warum sich einige Geräte ohne Kennwortabfrage mit Ihrem Unternehmensnetzwerk verbinden, während andere Zertifikatsfehler und Helpdesk-Tickets verursachen, dann ist dies die richtige Folge für Sie. [mittlere Pause] Beginnen wir mit den Grundlagen. Der 802.1X Supplicant ist die Softwarekomponente auf einem Client-Gerät - einem Laptop, einem Smartphone, einem Tablet - die den Authentifizierungs-Handshake abwickelt, wenn dieses Gerät versucht, einem durch IEEE 802.1X geschützten Netzwerk beizutreten. Stellen Sie sich das wie den Ausweisvorzeiger des Geräts vor. Das Netzwerk lässt nicht einfach jeden hinein. Es fragt nach Zugangsdaten. Der Supplicant tritt vor und sagt: Das bin ich, hier ist mein Zertifikat, lass mich rein. Der Standard selbst - IEEE 802.1X - definiert die portbasierte Netzwerkzugriffskontrolle. Bevor die Authentifizierung erfolgreich war, lässt der Access Point oder Switch nur eine sehr begrenzte Art von Datenverkehr durch: EAPOL-Frames, was für Extensible Authentication Protocol over LAN steht. Alles andere wird blockiert. Sobald der Supplicant seine Identität über den Authenticator gegenüber dem RADIUS-Server nachgewiesen hat, öffnet sich der Port und der normale Datenverkehr fließt. [mittlere Pause] In diesem Spiel gibt es drei Akteure. Erstens der Supplicant - das Client-Gerät. Zweitens der Authenticator - Ihr Access Point oder Switch, also Hardware von Cisco Meraki, HPE Aruba, Ruckus oder Juniper Mist. Drittens der Authentifizierungsserver - fast immer ein RADIUS-Server, der die Zugangsdaten mit einem Verzeichnis wie Microsoft Entra ID oder Okta abgleicht. Der Supplicant initiiert den Prozess durch das Senden einer EAPOL-Start-Nachricht. Der Authenticator antwortet mit einem EAP-Request für die Identität. Der Supplicant antwortet mit seiner Identität. Diese Identität wird an den RADIUS-Server weitergeleitet, der den Supplicant dann mit der vereinbarten EAP-Methode auffordert. Wenn alles in Ordnung ist, sendet der RADIUS-Server ein Access-Accept, der Port öffnet sich und das Gerät wird im richtigen VLAN platziert. [mittlere Pause] Lassen Sie uns über EAP-Methoden sprechen, denn hier werden die meisten Bereitstellungsentscheidungen getroffen. EAP-TLS - das steht für Extensible Authentication Protocol mit Transport Layer Security - ist der Goldstandard. Es erfordert, dass sowohl der Client als auch der Server Zertifikate vorlegen. Gegenseitige Authentifizierung. Keine Passwörter. Das Client-Zertifikat beweist die Identität des Geräts; das Server-Zertifikat beweist, dass das Netzwerk legitim ist, was vor Evil-Twin-Angriffen schützt, bei denen ein betrügerischer Access Point versucht, Anmeldedaten abzufangen. EAP-TLS wird in zwölf Schritten durchgeführt und nutzt durchgehend Kryptografie mit öffentlichen und privaten Schlüsseln. Es ist die Methode, die für WPA3-Enterprise im höchsten Sicherheitsmodus erforderlich ist, und sie entspricht den Anforderungen von NIST SP 800-171 für die Verifizierung der Geräteidentität. PEAP - Protected EAP - ist der gängigere Ausgangspunkt für Organisationen, die noch über keine vollständige PKI verfügen. PEAP verpackt eine passwortbasierte interne Methode, in der Regel MSCHAPv2, in einen TLS-Tunnel. Der Server legt ein Zertifikat vor; der Client nicht. Das bedeutet, dass die Bereitstellung einfacher ist - Sie müssen keine Client-Zertifikate verteilen - aber sie ist weniger sicher. MSCHAPv2 verwendet MD4-Hashing, das seit 1995 als kompromittiert gilt. Wenn sich ein Benutzer mit einem betrügerischen Access Point verbindet, der ein vertrauenswürdig aussehendes Zertifikat vorlegt, können seine Anmeldedaten abgefangen werden. Die Validierung des Server-Zertifikats auf der Client-Seite ist daher bei der Ausführung von PEAP nicht verhandelbar. [medium pause] Kommen wir nun zum Supplicant selbst - insbesondere zur Wahl zwischen nativen Betriebssystem-Supplicants und Client-Software von Drittanbietern. Jedes gängige Betriebssystem wird mit einem integrierten 802.1X-Supplicant ausgeliefert. Windows unterstützt dies seit XP nativ über die Dienste für die automatische WLAN-Konfiguration und die automatische Konfiguration für verkabelte Netzwerke. macOS und iOS verarbeiten 802.1X über ihre Netzwerkkonfigurationsprofile. Android unterstützt dies über das WiFi-Einstellungsmenü. Diese nativen Supplicants decken EAP-TLS und PEAP-MSCHAPv2 auf allen aktuellen Plattformen ab. Der Vorteil nativer Supplicants liegt auf der Hand: keine zusätzliche Software, die bereitgestellt werden muss, keine Lizenzkosten, automatische Sicherheitsupdates des Betriebssystems und eine enge Integration in den Zertifikatsspeicher des Betriebssystems. Für verwaltete Geräteflotten - Windows-Geräte, die in Microsoft Intune registriert sind, oder Macs, die über Jamf verwaltet werden - können Sie 802.1X-Konfigurationsprofile geräuschlos über MDM verteilen, ohne dass die Benutzer jemals eine Aufforderung sehen. Das Gerät authentifiziert sich jedes Mal automatisch, wenn es in Reichweite kommt. Supplicants von Drittanbietern kommen in bestimmten Szenarien ins Spiel. Wenn Sie eine Cisco Infrastruktur betreiben und EAP-FAST - das proprietäre EAP-Verfahren von Cisco - nutzen möchten, benötigen Sie die Client-Software von Cisco, in der Vergangenheit der Secure Services Client oder AnyConnect Network Access Manager. Wenn Sie eine konsistente Konfigurationsverwaltung über einen gemischten Betriebssystembestand hinweg benötigen und die Supplicant-Einstellungen sperren möchten, damit Benutzer sie nicht versehentlich falsch konfigurieren, bietet Ihnen ein Client eines Drittanbieters diese Kontrolle. Tools wie die JoinNow-Suite von SecureW2 fungieren auch als Onboarding-Agenten - sie konfigurieren den nativen Supplicant, anstatt ihn zu ersetzen, und führen die Benutzer durch die Zertifikatsregistrierung und Profilinstallation. [medium pause] Lassen Sie mich Sie durch zwei Praxisszenarien führen, um dies zu verdeutlichen. Erstens, ein Hotel mit 400 Zimmern. Das Hotel betreibt heute ein Personalnetzwerk auf Basis von WPA2-Enterprise mit PEAP-MSCHAPv2. Das IT-Team möchte auf EAP-TLS migrieren, um die passwortbasierte Authentifizierung zu eliminieren und das Risiko des Diebstahls von Anmeldedaten zu verringern. Die Herausforderung: Bei den Geräten der Mitarbeiter handelt es sich um eine Mischung aus Windows Laptops, die über Intune verwaltet werden, privaten Android Telefonen, die für die Hotelmanagement-Software genutzt werden, und einer Handvoll veralteter Windows 7 Rechner im Back-of-House-Bereich. Der Ansatz hier ist phasenweise. Beginnen Sie mit der verwalteten Windows Flotte. Pushen Sie ein Intune Konfigurationsprofil, das das Root-CA-Zertifikat des RADIUS-Servers installiert, das WiFi Profil für EAP-TLS konfiguriert und die SCEP-basierte Zertifikatsregistrierung aus der internen PKI auslöst. Diese Geräte authentifizieren sich vom ersten Tag an automatisch. Für Android BYOD-Geräte stellen Sie ein Self-Service-Onboarding-Portal bereit - Benutzer rufen eine URL auf, laden ein Konfigurationsprofil herunter und der Supplicant wird für sie konfiguriert. Die alten Windows 7 Rechner verbleiben bei PEAP mit erzwungener strenger Serverzertifikatsvalidierung, isoliert in einem separaten VLAN mit eingeschränktem Zugriff, bis sie ausgemustert werden. [medium pause] Zweites Szenario: eine große Einzelhandelskette mit 200 Filialen. Jede Filiale verfügt über eine Mischung aus Point-of-Sale-Terminals, Mitarbeiter-Tablets und einem Gäste WiFi Netzwerk. PCI-DSS erfordert, dass Karteninhaber-Datenumgebungen von anderen Netzsegmenten isoliert sind. Der Einzelhändler nutzt 802.1X im Mitarbeiter- und POS-Netzwerk, wobei die VLAN Zuweisung durch Zertifikatsattribute gesteuert wird. Ein POS-Terminal präsentiert ein Geräteertifikat mit einer Organisationseinheit "POS" - die RADIUS Richtlinie weist es dem PCI-VLAN zu. Ein Mitarbeiter-Tablet präsentiert ein Zertifikat mit "Staff" - es landet im Mitarbeiter-VLAN. Gäste-Geräte verbinden sich mit einer völlig separaten SSID, die über eine Captive Portal Lösung abgewickelt wird. Die Supplicant-Konfiguration auf den POS-Terminals ist über MDM gesperrt. Keine Benutzerinteraktion erforderlich. Die Terminals authentifizieren sich beim Booten im Hintergrund. Die Zertifikatsverlängerung ist über SCEP automatisiert, sodass kein manueller Eingriff erforderlich ist, wenn Zertifikate ablaufen. [medium pause] Nun zu den Fallstricken bei der Implementierung. Lassen Sie mich Ihnen die vier häufigsten nennen. Nummer eins: Fehlende Server-Zertifikatsvalidierung bei PEAP-Bereitstellungen. Wenn Sie den Supplicant nicht so konfigurieren, dass er das Zertifikat des RADIUS-Servers validiert und den Servernamen überprüft, sind Benutzer anfällig für Verbindungen mit einem Rogue Access Point. Geben Sie im Supplicant-Profil immer die vertrauenswürdige Root-CA und den Servernamen an. Nummer zwei: Ablauf von Zertifikaten, der zu massenhaften Authentifizierungsfehlern führt. Client-Zertifikate haben eine Gültigkeitsdauer. Wenn Sie keine automatisierte Verlängerung über SCEP oder NDES eingerichtet haben, stehen Sie vor einem abrupten Ausfall, bei dem sich hunderte von Geräten gleichzeitig nicht mehr authentifizieren können. Richten Sie eine Verlängerungsautomatisierung ein, bevor Sie live gehen. Nummer drei: BYOD-Geräte mit uneinheitlichem Supplicant-Verhalten. Insbesondere Android weist herstellerübergreifend eine fragmentierte 802.1X-Unterstützung auf. Einige Versionen erfordern, dass der Benutzer das CA-Zertifikat manuell installiert, bevor das WiFi-Profil es akzeptiert. Ein Onboarding-Portal, das diesen Schritt übernimmt, reduziert das Helpdesk-Aufkommen erheblich. Nummer vier: Windows 11-Funktionsupdates, die die Supplicant-Konfiguration beschädigen. Microsoft hat das 802.1X-Verhalten in mehreren Windows 11-Updates geändert. Insbesondere das 24H2-Update führte Änderungen an der Art und Weise ein, wie der native Supplicant mit dem EAP-TLS-Fallback umgeht. Testen Sie Ihre Supplicant-Profile mit neuen OS-Versionen, bevor Sie diese in der Produktion bereitstellen. [medium pause] Nun zu schnellen Fragen. Können IoT-Geräte 802.1X unterstützen? Die meisten können es nicht. IoT-Geräten fehlt in der Regel ein Supplicant vollständig. Die Ausweichlösung ist MAC Authentication Bypass - MAB - bei dem der RADIUS-Server das Gerät anhand seiner MAC-Adresse authentifiziert. MAC-Adressen können manipuliert werden, daher sollten MAB-Geräte immer in einem isolierten IoT-VLAN mit strengen Firewall-Regeln landen. Benötige ich eine PKI, um 802.1X zu nutzen? Für PEAP nein - Sie benötigen lediglich ein Server-Zertifikat auf dem RADIUS-Server. Für EAP-TLS ja - Sie benötigen eine PKI, um Client-Zertifikate auszustellen. Cloud-basierte PKI-Dienste reduzieren den Infrastrukturaufwand erheblich. Wie interagiert 802.1X mit der Netzwerkzugangsplattform von Purple? Purple fungiert als Cloud-Overlay auf Ihrer vorhandenen Hardware - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist und andere. In WiFi-Netzwerken für Mitarbeiter lässt sich das SecurePass-Add-on von Purple in Ihren Identity Provider - Microsoft Entra ID, Okta oder Google Workspace - integrieren, um eine 802.1X-Authentifizierung zu erzwingen und VLAN-Richtlinien pro Benutzer anzuwenden, ohne dass eine RADIUS-Infrastruktur vor Ort erforderlich ist. [medium pause] Zusammenfassend: Der 802.1X-Supplicant ist der geräteseitige Client, der die portbasierte Netzwerkzugriffskontrolle ermöglicht. Ihre Wahl der EAP-Methode - EAP-TLS für maximale Sicherheit, PEAP als Übergangsoption - bestimmt Ihre PKI-Anforderungen und Ihren Ansatz zur Supplicant-Konfiguration. Native OS-Supplicants decken die Mehrheit der Szenarien mit verwalteten Geräten ab, wenn sie über ein MDM bereitgestellt werden. Drittanbieter-Clients bieten in bestimmten Fällen einen Mehrwert: proprietäre EAP-Methoden, gemischte Betriebssystemumgebungen, die eine einheitliche Konfiguration erfordern, oder ein Self-Service-BYOD-Onboarding. Die drei wichtigsten Erkenntnisse: Validieren Sie Ihr RADIUS-Serverzertifikat auf jedem Supplicant-Profil, automatisieren Sie die Zertifikatserneuerung, bevor Sie EAP-TLS im großen Stil bereitstellen, und isolieren Sie Geräte, die 802.1X nicht unterstützen können - IoT-Geräte, ältere Hardware - auf dedizierten VLANs mit MAC-Authentifizierungs-Bypass als Ausweichlösung. Weitere Informationen darüber, wie sich Purple in Ihre Netzwerkzugriffsarchitektur integriert, finden Sie unter purple dot ai. Vielen Dank fürs Zuhören.