IEEE 802.1X: Unterschied zwischen den Versionen

Aus Foxwiki
K Textersetzung - „Netzwerkkomponente“ durch „Netzwerk/Hardware“
K Textersetzung - „Man-Pages“ durch „Man-Page“
 
(3 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 31: Zeile 31:
; In der Praxis wird der Supplicant in Form einer Softwareimplementierung umgesetzt.  
; 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.  
* 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 Netzwerk/Hardwaren (wie z. B. Netzwerkdrucker) sind jedoch in der Lage, sich über IEEE 802.1X am Netzwerk zu authentisieren.  
* Nicht alle Netzwerk/Hardwaren (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.  
* 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.  
* 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.  
* 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.  
* 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.
* Somit können auch Geräte authentifiziert werden, die keine IEEE-802.1X-Supplicant-Implementierung besitzen.
Zeile 59: Zeile 59:
* Es ist nicht wichtig, ob sich der Supplicant gegenüber dem Authenticator authentisieren kann, in jedem Fall wird der Zugriff gestattet.  
* 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.  
* 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.  
* 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.  
* 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.
* 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.  
* 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.
* Wenn sich der Supplicant erfolgreich authentisiert hat, wird der Zugriff gewährt, andernfalls bleibt er weiterhin gesperrt.
Zeile 70: Zeile 70:
; Der AS stellt dem Authenticator einen Authentifizierungsdienst bereit.  
; 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.  
* 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 [[Remote Authentication Dial-In User Service|RADIUS-Serverdienst]] sein, wie ihn z. B. das FreeRadius-Projekt frei bereitstellt.  
* Der AS kann in der Praxis ein [[Remote Authentication Dial-In User Service|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.  
* 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 [[Router]]n stellt auch eine eigene RADIUS-Implementierung bereit, hier sei auf das Produktangebot der jeweiligen Hersteller verwiesen.
* Jeder größere Hersteller von Switches und [[Router]]n stellt auch eine eigene RADIUS-Implementierung bereit, hier sei auf das Produktangebot der jeweiligen Hersteller verwiesen.
Zeile 140: Zeile 140:
=== Dokumentation ===
=== Dokumentation ===
==== RFC ====
==== RFC ====
==== Man-Pages ====
==== Man-Page ====
==== Info-Pages ====
==== Info-Pages ====
=== Links ===
=== Links ===
==== Einzelnachweise ====
<references />
==== Projekt ====
==== Projekt ====
==== Weblinks ====
==== Weblinks ====
Zeile 157: Zeile 155:
# WLAN und LAN sichern mit IEEE 802.1X und Radius https://www.heise.de/netze/artikel/WLAN-und-LAN-sichern-mit-IEEE-802-1X-und-Radius-979513.html
# WLAN und LAN sichern mit IEEE 802.1X und Radius https://www.heise.de/netze/artikel/WLAN-und-LAN-sichern-mit-IEEE-802-1X-und-Radius-979513.html
* [http://www.security-insider.de/themenbereiche/netzwerksicherheit/protokolle-und-standards/articles/275103/ Netzwerk-Grundlagen Authentisierung] Das Authentication Framework des Standards IEEE 802.1X
* [http://www.security-insider.de/themenbereiche/netzwerksicherheit/protokolle-und-standards/articles/275103/ Netzwerk-Grundlagen Authentisierung] Das Authentication Framework des Standards IEEE 802.1X
== Testfragen ==
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 1''
<div class="mw-collapsible-content">'''Antwort1'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 2''
<div class="mw-collapsible-content">'''Antwort2'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 3''
<div class="mw-collapsible-content">'''Antwort3'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 4''
<div class="mw-collapsible-content">'''Antwort4'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 5''
<div class="mw-collapsible-content">'''Antwort5'''</div>
</div>


[[Kategorie:WLAN]]
[[Kategorie:WLAN]]
[[Kategorie:IEEE 802]]
[[Kategorie:IEEE 802]]

Aktuelle Version vom 6. November 2024, 12:24 Uhr

IEEE 802.1X ist ein Standard zur Authentifizierung in Rechnernetzen

Beschreibung

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 stellt eine generelle Methode für die Authentifizierung und Autorisierung in IEEE-802-Netzen zur Verfügung
Netzwerkzugang erfordert Authentifizierung
  • Authentifizierung eines Teilnehmers durch den Authenticator
  • Physischer Port im LAN
  • Logischen IEEE 802.1Q VLAN
  • WLAN
RADIUS-Server
  • Authentifizierungsserver (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

Supplicants (deutsch Bittsteller) sind alle IEEE 802.1X-authentisierungsfähigen Geräte (s. 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 Netzwerk/Hardwaren (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

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)

Die PAE, welche in der Praxis als Port am Switch vorgestellt werden 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)

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.

Dienstspektrum und Benutzerkennung

Zuordnung des VLANs
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“ 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.

Betriebssystem-Unterstützung

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

Sicherheit

Sicherheitslücken

In 802.1X-2001 und 802.1X-2004
  • Mehrere Endgeräte pro Anschluss
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.[5]
EAPOL-Logoff-Frames werden von dem 802.1X-Supplicant im Klartext übertragen und beinhalten keine nur dem Sender bekannten Informationen.[6] 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.[7][8]
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.

Siehe auch

  1. Port Based Network Access Control

Dokumentation

RFC

Man-Page

Info-Pages

Links

Projekt

Weblinks

  1. https://de.wikipedia.org/wiki/IEEE_802.1X
  2. IEEE 802.1X Arbeitsgruppe Offizielle Seite der 1X-Arbeitsgruppe
  3. FreeRADIUS Freie und populäre Implementierung eines RADIUS-Servers
  4. daloRADIUS Freie und webbasierte Software auf der Basis des FreeRADIUS-Servers und einer SQL-Datenbankanbindung, die das Ziel verfolgt, Benutzerkennungen zu verwalten
  5. Einrichtung von IEEE 802.1X mit drahtgebundenen Netzen unter Verwendung von Microsoft Windows Deployment of IEEE 802.1X for Wired Networks Using Microsoft Windows
  6. Einrichtung der VLAN-Zuordnung mit der Windows RADIUS Serverimplementierung Internet Authentication Service (IAS) Deploying Windows Server 2003 Internet Authentication Service (IAS) with Virtual Local Area Networks (VLANs)
  7. 802.1X Port-Based Authentication HOWTO bei The Linux Documentation Project
  8. Open1X Freie Supplicant-Implementierung für Linux, BSD und Windows
  9. WLAN und LAN sichern mit IEEE 802.1X und Radius https://www.heise.de/netze/artikel/WLAN-und-LAN-sichern-mit-IEEE-802-1X-und-Radius-979513.html
  1. Definition aus dem IEEE-Standard 802.1X-2004, Kapitel 8.2.2.2, Global variables, Seite 46, Definition p) 1 bis 3 (PDF, 1007 KB, Englisch; Datei wird per E-Mail kostenfrei zugesendet)
  2. KB 313664 Using 802.1x authentication on client computers that are running Windows 2000, Microsoft Knowledge Base
  3. Vorlage:Cite web
  4. Open1X-Homepage, Sourceforge
  5. Vorlage:Cite web
  6. IEEE 802.1X-2001, § 7.1.
  7. Vorlage:Cite web
  8. Vorlage:Cite web