IEEE 802.1X

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von 802.1x)
Zur Navigation springen Zur Suche springen
Ein WLAN-Client (Wireless Node WN) muss authentifiziert werden, bevor er auf weitere LAN-Ressourcen zugreifen darf. Dazu befragt der Access-Point (AP) den Authentifizierungsserver (AS).
Einordnung des Standards im IEEE-Modell

IEEE 802.1X ist ein Standard zur Authentifizierung in Rechnernetzen.

Der Standard IEEE 802.1X stellt eine generelle Methode für die Authentifizierung und Autorisierung in IEEE-802-Netzen zur Verfügung. Am Netzwerkzugang, einem physischen Port im LAN, einem logischen IEEE 802.1Q VLAN oder einem WLAN, erfolgt die Authentifizierung eines Teilnehmers durch den Authenticator, der mittels eines Authentifizierungsservers (RADIUS-Server) die durch den Teilnehmer (Supplicant) übermittelten Authentifizierungsinformationen prüft und gegebenenfalls den Zugriff auf die durch den Authenticator angebotenen Dienste (LAN, VLAN oder WLAN) zulässt oder abweist.

Durch diese Möglichkeit der Nutzung eines Authentifizierungsservers kann auch lokal unbekannten Teilnehmern der Netzzugang ermöglicht werden. Zum Beispiel können Angehörige vieler Hochschulen mittels eduroam an anderen Hochschulen WLAN nutzen, ohne dass dort ein für alle offener Gastzugang oder ähnliches eingerichtet werden muss.

Der Standard empfiehlt das Extensible Authentication Protocol (EAP) oder das PPP-EAP-TLS Authentication Protocol zur Authentifizierung, da keine eigenen Authentisierungsprotokolle definiert werden.

Bei der Schreibweise ist laut IEEE ein Großbuchstabe zu verwenden, da IEEE 802.1X ein alleinstehender Standard ist und keine Ergänzung eines bestehenden Standards.

Supplicant

[Bearbeiten | Quelltext bearbeiten]

Supplicants (deutsch „Bittsteller“) sind alle IEEE 802.1X-authentisierungsfähigen Geräte (siehe IEEE 802.1X Artikel 5.1 „Requirements“), die sich gemäß Netzwerkregel am Netzwerk authentisieren müssen, bevor dem Netzwerkgerät der Zugriff auf die Ressourcen des Netzwerks erlaubt wird.

In der Praxis wird der Supplicant in Form einer Softwareimplementierung umgesetzt. Weiterhin kann man sich auch der freien Supplicant-Implementierungen aus den Projekten von Open1x oder SecureW2 bedienen, um eine IEEE-802.1X-Infrastruktur aufzubauen. Nicht alle Netzwerkkomponenten (wie z. B. Netzwerkdrucker) sind jedoch in der Lage, sich über IEEE 802.1X am Netzwerk zu authentisieren. Oft fehlt alter und sogar neuerer Hardware die IEEE 802.1X Supplicant-Implementierung. Diese Tatsache stellt bei der Einführung von IEEE 802.1X in Produktivsystemen den größten Kritikpunkt an IEEE 802.1X dar. Einige Switches stellen für dieses Problem z. B. die „MAC-Bypass“-Funktion bereit. Damit ist es möglich, das Netzwerkgerät anhand der MAC-Adresse zu authentifizieren. Somit können auch Geräte authentifiziert werden, die keine IEEE-802.1X-Supplicant-Implementierung besitzen.

Authenticator

[Bearbeiten | Quelltext bearbeiten]

Zwischen dem Supplicant und dem zu schützenden Netzwerk existiert der Authenticator. Die Rolle des Authenticators ist es, die Authentizität des Supplicants zu überprüfen, ähnlich der Rolle eines Türstehers im Rahmen einer Ausweiskontrolle. Kann sich der Supplicant gegenüber dem Authenticator erfolgreich mit gültigen Credentials (zu dt. „Berechtigungsnachweis“ oder „Legitimation“) ausweisen, wird dem Supplicant der Zugriff auf das Netzwerk durch den Authenticator gewährt. Schlägt die Authentifizierung fehl, wird der Zugriff verweigert. Der Authenticator kann in der Praxis ein IEEE 802.1X-fähiger Switch, Router oder IEEE 802.11-WLAN-Access-Point sein. Die Credentials werden i. d. R. von dem Authenticator bei einem „Authentication Server“ (AS) angefragt. Der Authentication-Server findet sich im IEEE-802.1X-Modell in einem vertrauenswürdigen Netzwerk wieder.

Port Access Entity: PAE

[Bearbeiten | Quelltext bearbeiten]

Die PAE, welche man sich in der Praxis als Port am Switch vorstellen kann, implementiert hierbei einen Zustandsautomaten, indem immer der jeweilige Authentifizierungszustand zwischen Supplicant und Authenticator am kontrollierten Port abgebildet ist. Der IEEE 802.1X sieht für die Zugriffseinstellung im PAE drei mögliche Zugriffsmodi für Supplicants vor:[1]

ForceUnauthorized
Der kontrollierte Port ist im Modus „nicht bevollmächtigt“. Dabei wird jeder Zugriff eines Supplicants blockiert. Es ist egal, ob sich der Supplicant erfolgreich authentisieren kann oder nicht, in jedem Fall wird der Zugriff gesperrt.
ForceAuthorized
Das Gegenteil von ForceUnauthorized. Der kontrollierte Port ist im Modus „autorisiert“. Dabei wird dem Supplicant der Zugriff immer gewährt. Es ist nicht wichtig, ob sich der Supplicant gegenüber dem Authenticator authentisieren kann, in jedem Fall wird der Zugriff gestattet. Dieser Modus ist für die praktische Einrichtung von IEEE 802.1X-Switches interessant. Mit der Aktivierung der IEEE 802.1X-Authentifizierung in Verbindung mit dem ForceAuthorized-Modus ist z. B. eine sukzessive Aktivierung von IEEE 802.1X möglich. Im ForceAuthorized-Modus können z. B. am Switch interne Tests zur IEEE-802.1X-Funktionstauglichkeit vorgenommen werden, bevor anschließend der produktive „Auto“-Modus aktiviert wird, der alle Supplicants zum Authentisieren zwingt.
Auto
Verlangt eine erfolgreiche Authentisierung von dem Supplicant. Wenn sich der Supplicant erfolgreich authentisiert hat, wird der Zugriff gewährt, andernfalls bleibt er weiterhin gesperrt.

Die PAE kann eine Supplicant- oder Authenticatorfunktionalität annehmen.

Authentication Server (AS)

[Bearbeiten | Quelltext bearbeiten]

Der AS stellt dem Authenticator einen Authentifizierungsdienst bereit. Dabei ist der AS in der Regel im geschützten Netz installiert und braucht sich nicht zu authentifizieren. Der AS kann in der Praxis ein RADIUS-Serverdienst sein, wie ihn z. B. das FreeRadius-Projekt frei bereitstellt. Werden die Betriebssysteme Windows 2000 oder Windows 2003 genutzt, so kann mit dem „Internet Authentication Service“ (IAS) ein RADIUS-Server betrieben werden. Jeder größere Hersteller von Switches und Routern stellt auch eine eigene RADIUS-Implementierung bereit, hier sei auf das Produktangebot der jeweiligen Hersteller verwiesen.

Die zu überprüfenden Credentials können direkt auf dem AS liegen, in Form einer einfachen Textdatei, der AS kann aber auch durch Datenbanktreiber auf einen Datenbankdienst zugreifen. Die Back-End-Möglichkeiten sind in der Theorie für einen AS unbegrenzt. In der Praxis wird einer LDAP-Anbindung oft der Vorzug gegeben. Der Vorteil liegt auf der Hand: Bestehende Domänenbenutzerkennungen sind im Active Directory Service (ADS) von Microsoft-Betriebssystemen bereits vorhanden. Im Fall von freien LDAP-Implementierungen kann es auch der OpenLDAP3-Dienst sein, der sich für einen LDAP-Betrieb eignet. Die vielfältigen Backend-Möglichkeiten des RADIUS-Servers sind somit auch Vorteile für den Einsatz von IEEE 802.1X. An diesem Beispiel ist gut zu erkennen, dass der IEEE-802.1X-Standard auf vorhandene Schnittstellen aufsetzt und somit bemüht ist, praxistauglich zu sein.

Im Kontext der RADIUS-Terminologie wird statt des Begriffs „Authenticator“ der Begriff Network Access Server (NAS) verwendet. Einwählende Computer betrachten den NAS als Server. Aus der Sicht des RADIUS-Servers ist der NAS hingegen ein Client.

Das Dienstspektrum und die Benutzerkennung (Zuordnung des VLANs)

[Bearbeiten | Quelltext bearbeiten]

Einen großen Vorteil bei der Nutzung von IEEE 802.1X bilden die RADIUS-Access-Accept-Nachrichten vom Authentication Server zum Authenticator. Das RFC 2869 „RADIUS Extensions“[2] beschreibt eine große Menge an Attributen, die vom AS an den Authenticator gesendet werden. Drei interessante Attribute heißen hierbei „Tunnel-Type“, „Tunnel-Medium-Type“ und „Tunnel-Private-Group-Id“. Am Ende der RADIUS-Authentifizierung sendet der RADIUS-Server an den Network-Access-Server eine Access-Accept-Nachricht. Werden diese drei Attribute an die Access-Accept-Nachricht angehängt, wird damit vom NAS gefordert, den Supplicant in das betreffende VLAN zu zuweisen. Die VLAN-ID steht hierbei genau im Attribut „Tunnel-Private-Group-Id“ des Antwortpakets. Der NAS schaltet hierbei den Port vom Gast-VLAN in das für den Supplicant bestimmte VLAN um. Für die Praxis bedeutet es, dass anhand der Benutzerinformationen, die der Authenticator an den AS sendet, im Gegenzug ein angepasstes Dienstspektrum für den Supplicant stattfinden kann. Auf Linux-, BSD- oder Windowsservern ist es heute relativ leicht, mehrere VLANs umzusetzen und damit je VLAN eine Auswahl an Diensten bereitzustellen.

Betriebssysteme mit IEEE 802.1X-Unterstützung

[Bearbeiten | Quelltext bearbeiten]

Bei anderen Betriebssystemen kann Software eines anderen Herstellers nachgerüstet werden, um die Funktion zu nutzen. Das Open1X-Projekt[5] hat sich zum Ziel gesetzt, mit einer eigenen 802.1X-Implementierung viele Systeme zu unterstützen. Weiterhin ist es möglich, Netzwerkkomponenten zu verwenden, die eine webbasierte Authentifizierung gestatten.

Sicherheitslücken in 802.1X-2001 und 802.1X-2004

[Bearbeiten | Quelltext bearbeiten]

Mehrere Endgeräte pro Anschluss

[Bearbeiten | Quelltext bearbeiten]

Im Sommer 2005 hat Steve Riley von Microsoft einen Artikel veröffentlicht, in dem er eine ernsthafte Sicherheitslücke im 802.1X-Protokoll aufzeigte, die auf einem Man-in-the-Middle-Angriff beruht. Zusammengefasst basiert die Lücke auf der Tatsache, dass per 802.1X nur der Anfang der Verbindung gesichert wird, dass es aber nach der Authentifizierung potenziellen Angreifer möglich ist, die geöffnete Verbindung zu eigenen Zwecken zu missbrauchen, sofern es dem Angreifer gelingt, sich physisch in die Verbindung einzuschleusen. Dazu kann ein Arbeitsgruppen-Hub mit authentifiziertem Rechner oder ein zwischen authentifiziertem Rechner und abgesichertem Port geschalteter Laptop genutzt werden. Riley schlägt für kabelbasierende Netzwerke die Verwendung von IPsec oder eine Kombination aus IPsec und 802.1X vor.[6]

EAPOL-Logoff-Frames werden von dem 802.1X-Supplicant im Klartext übertragen und beinhalten keine nur dem Sender bekannten Informationen.[7] Daher können sie leicht von einem verbundenen Gerät gefälscht werden, um einen DoS-Angriff durchzuführen; dies funktioniert auch per WLAN. Während eines EAPOL-Logoff-Angriffs sendet eine bösartige dritte Partei mit Zugriff zum Medium des Authenticators wiederholt gefälschte EAPOL-Logoff-Frames mit der MAC-Adresse des Ziels. Der Authenticator geht aufgrund der MAC-Adresse davon aus, dass das Zielgerät die Verbindung beenden möchte. Er schließt die authentifizierte Sitzung des Zielgerätes und blockiert damit den Datenstrom des Zielgerätes. Das Zielgerät ist logisch vom Netz genommen.

Die 2010 verabschiedete 802.1X-2010-Spezifikation begegnet diesen Sicherheitslücken, indem per MACsec IEEE 802.1AE die Daten zwischen logischen Ports, die oberhalb der physischen Ports anzusiedeln sind, und den per IEEE 802.1AR (Secure Device Identity / DevID) authentifizierten Geräten verschlüsselt werden.[8][9]

Als Zwischenlösung bis zur Verbreitung dieser Verbesserungen haben einige Hersteller das Protokoll 802.1X-2001 und 802.1X-2004 erweitert, um mehrere gleichzeitige Authentifizierungssitzungen auf einem einzelnen Port zuzulassen. Dies verhindert zwar das versehentliche Eindringen von nicht authentifizierten MAC-Adressen auf 802.1X-authentifizierten Ports, aber es hindert ein bösartiges Gerät nicht daran, Daten abzugreifen, die authentifizierte MAC-Adresse anzunehmen oder einen EAPOL-Logoff-Angriff durchzuführen.

[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. ↑ Definition aus dem IEEE-Standard 802.1X-2004. (PDF; 1007 kB) Kapitel 8.2.2.2, Global variables, S. 46, Definition p) 1 bis 3 (englisch; Datei wird per E-Mail kostenfrei zugesendet)
  2. ↑ RFC 2869 – RADIUS Extensions. Juni 2000 (englisch).
  3. ↑ KB 313664 Using 802.1x authentication on client computers that are running Windows 2000, Microsoft Knowledge Base
  4. ↑ Bei Abruf der Gruppenrichtlinien-Objekte, servergespeicherte Profile und Anmeldeskripts von einem Windows 2003-Domänencontroller treten Probleme auf. In: Support.microsoft.com. 14. September 2007, abgerufen am 4. August 2011 (deutsch).
  5. ↑ Open1X-Homepage. Sourceforge.
  6. ↑ Steve Riley: Artikel über die 802.1X Sicherheitslücken. In: Microsoft.com. 9. August 2005, abgerufen am 10. Februar 2010 (englisch).
  7. ↑ IEEE 802.1X-2001, § 7.1.
  8. ↑ 2 February 2010 Early Consideration Approvals. In: Standards.ieee.org. Abgerufen am 10. Februar 2010 (englisch).
  9. ↑ IEEE 802.1: 802.1X-2010 – Revision of 802.1X-2004. In: Ieee802.org. 21. Januar 2010, abgerufen am 10. Februar 2010 (englisch).
Abgerufen von „https://de.wikipedia.org/w/index.php?title=IEEE_802.1X&oldid=239602998“