Open Source im professionellen Einsatz

Newsletter abonnieren
Seite durchsuchen

HEFTARCHIV | NEWS | E-BIBLIOTHEK | VIDEO | BLOGS | WHITEPAPER | EVENTS | ACADEMY | ABO | SHOP

user friendly

  Home  »  Heft & Abo  »  Heftarchiv  »  2009  »  09  »  Hartes Türregime  

RSS-Feed der aktuellen News von Linux-Magazin Online Folgen Sie Linux-Magazin Online auf Twitter
Diesen Artikel druckenDiesen Artikel weiterempfehlen Diesen Artikel kommentieren Newsletter abonnieren
Share/Bookmark

© Gordon Bussiek, Fotolia.com

Mit IEEE 802.1X und Zertifikaten Network Access Control implementieren

Hartes Türregime

von Sven Übelacker, Nils Magnus
Erschienen im Linux-Magazin 2009/09

Öffentlich zugängliche Netzwerkdosen eröffnen trotz Firewall & Co. Angriffsvektoren. IEEE 802.1X bietet auch im kabelgebundenen Netz eine Lösung und macht aufwändiges Umpatchen überflüssig. Free Radius und Supplikant-Clients sichern mittels EAP-TLS und Benutzerzertifikaten den Zugang zum Switch.

Es ist ein Kreuz mit den Ethernet-Ports: Hängt an dem Kabel aus der Bürodecke nun das Produktivnetz oder das Test-Segment? Der Kollege vom anderen Ressort will am Notebook eine Anwendung vorführen, braucht aber Zugriff auf das Netz seiner Abteilung. Bisher blieb geplagten Anwendern dann nur ein Anruf im Serverraum mit der Bitte, doch schnell den einen oder anderen Switchport in ein neues Netz umzupatchen.

Sicherheitsbeauftragte und Admins haben zusätzliche Sorgen: Wer kann schon ausschließen, dass in einem Büro mit regem Besuchsverkehr ein Gast sich nicht - sei es unabsichtlich oder mit Vorsatz - in das Allerheiligste des Firmennetzes einklinkt? MAC-based Port Authentication ist da ein wenig wirksamer Schutz - zu einfach sind MAC-Adressen abgehört und gefälscht, vom Alptraum der Verwaltung durch den Admin mal ganz abgesehen.

So überrascht es, dass die Client-Authentifizierung nach IEEE 802.1X nach wie vor ein Schattendasein fristet [1]. Viele schreiben den Standard der Wireless-Welt zu und wissen gar nicht, dass sich damit schon seit einiger Zeit eine einfache Form von Network Access Control (NAC) bewerkstelligen lässt: Zugangskontrolle für Geräte am Netzwerk - noch lange bevor Login-Bildschirm oder Webbrowser gestartet sind [2].

Port freischalten

Dabei spielt ein IEEE 802.1X-fähiger Switch eine wichtige Rolle. Er ist der Network Access Server (NAS). Bevor er überhaupt irgendwelchen Datenverkehr über einen seiner Ports - der Standard nennt sie Port Access Entity (PAE) - zulässt, muss das anfragende Gerät - also in der Regel ein Desktop oder Notebook - seine Berechtigung nachweisen. Das passiert über das Extensible Authentication Protocol (EAP) auf dem Verbindungslayer. Das anschlusssuchende Gerät betreibt dazu einen kleinen Client, den Supplikanten, der einen Ausweis in Form eines speziellen Ethernet-Frame vorlegt, das sich EAPoL nennt.

EAP erlaubt eine Vielzahl an Berechtigungsnachweisen, als praktisch haben sich in diesem Umfeld X.509v3-Client-Zertifikate erwiesen: Sie haben einen hohen kryptographischen Standard, vermeiden zu einfache Passwörter und lassen sich sowohl einzeln als auch in größerer Zahl bei Bedarf in einer PKI verwalten. Dazu kommt noch, dass sie sich mit einem Token gut schützen lassen und auch anderen Anwendungen noch von Nutzen sind, etwa einem VPN.

Die Proktokollerweiterung dazu heißt EAP-TLS [3]. Neben der Authentisierungsmethode, die wie bei einem SSL-Webserver funktioniert, gibt es theoretisch eine Reihe weitere, etwa One Time Password (OTP), Protected EAP (PEAP) oder getunneltes TLS (TTLS).


Abbildung 1: Die Zugangsberechtigung bei IEEE 802.1X erhält ein beantragender Client (Supplikant), indem er über Bande spielt: Er sendet per EAP-TLS einen Antrag an den Switch, der legt ihn per Radius-Anfrage einem RAS-Server vor. Nickt der die Anfrage ab, schaltet der Switch die zugehörige Port Access Entity (PAE) frei.

Kommt eine EAP-Anfrage vom Typ »EAP-Response/Identity« beim Switch an, leitet dieser sie zu einem Remote-Access-Server (RAS) weiter. Der kennt alle Berechtigten und teilt dem Switch das Ergebnis der Prüfung mit. War sie erfolgreich, öffnet der Switch die PAE und der Client holt sich beispielsweise eine IP-Adresse per DHCP oder konfiguriert sein Interface statisch (siehe Abbildung 1). Das Tandem aus Switch und RAS-Server kann aber noch mehr: Beherrscht der erste IEEE 802.1q, darf der andere zum Beispiel ein VLAN mitteilen, in das der Switch den Antragsteller steckt.

Authentifizierung an Bord

Ein Großteil der administrierbaren Switches ab einer bestimmten Größe kennt IEEE 802.1X, darunter etwa der Netgear FSM726 Managed Switch für 200 Euro mit zwei Gigabit-Ports [4], der 3Com 2924-SFP Plus für 270 Euro [5] oder der Level One GSW-2494 für rund 340 Euro [6]. Alle Geräte haben 24 Ports und unterscheiden sich in einzelnen Ausstattungsmerkmalen, etwa einer stackbaren Backplane.


Abbildung 2: Viele Switches bringen ein Webfrontend zum Konfigurieren mit. Der Netgear FSM726 Managed Switch hat 24 Ports, die sich einzeln für den IEEE-802.1X-Betrieb »Auto« konfigurieren lassen.

Fast alle kommen mit einem Webinterface (Abbildung 2), einige lassen sich über ein Command Line Interface wie Ciscos IOS konfigurieren. Artikel 5.1 des 802.1X-Standards legt fest, welchen Anforderungen die Switches genügen müssen. Einige, wie die IOS-basierten, stellen zusätzliche Features zur Verfügung, etwa ein Gast-VLAN, in das der NAS den Supplikanten steckt, wenn er sich nicht ausweisen konnte - praktisch für Besucher oder in Konferenzräumen.

Um Network Access Control zu aktivieren, verbindet sich der Systemverwalter mit dem Switch. Er stellt die betroffenen PAEs von »Authorized« auf den Modus »Auto« und teilt dem Netzgerät das Passwort und die IP-Adresse für den Remote-Access-Server mit. Den schließt er optimalerweise in einem separaten VLAN mit getrenntem Admin-Subnetz an. Um ein Henne-Ei-Problem zu vermeiden, stellt er den zugehörigen Port auf »Authorized«.

Sie können diesen Artikel als PDF für 99 Cent kaufen. Klicken Sie dazu einfach auf eine der beiden Bezahloptionen Paypal oder ClickandBuy.


Diesen Artikel druckenDiesen Artikel weiterempfehlen Diesen Artikel kommentieren Newsletter abonnieren
Share/Bookmark
Ähnliche Artikel
Abgebrannt Das Leben nach der Firewall – oder warum das Netz neue Sicherheitsmodelle braucht
Schutzwall Packetfence gewährt nur sicherheitsüberprüften Rechnern Zugang zum LAN
Meldestelle Zertifikate mit Open CA verwalten
Offenes Grün Praxistest: Endian Firewall Macro X2
Abschirmdienst MSM-VPN-Appliance: Virtuelle private Netze mit IPsec, PKI und Smartcards
Schnurlos schnurren No Cat Auth authentifiziert WLAN-Benutzer am NAT-Router
Whitepaper
Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele (Folge 2)

Der zweite Teil des Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele White Papers beleuchtet anhand weiterer ausgewählter Case Studies die Implementierung von Open Source Datenintegration in der Praxis und benennt die daraus resultierenden Vorteile.

Download PDF (Registrierung erforderlich)
Usage Landscape Enterprise Open Source Data Integration

Die Nachfrage nach Datenintegrationslösungen für Unternehmen ist zunehmend gestiegen und vor allem das Interesse an Open Source Technologien wird immer größer. Doch wie und von wem werden Open Source Datenintegrationslösungen genutzt und welches Nutzungsverhalten lässt sich daraus ableiten? Das vorliegende White Paper präsentiert die Erfahrungswerte von über 1000 Open Source Nutzern und liefert fundierte Antworten auf diese Fragen.

Download PDF (Registrierung erforderlich)
Kommentare (2)
von
Sven,
28.02.2010 22:59
RE: Beschreibung Freeradius
Hi,

Da scheints an vielen liegen zu können:

* falsch selbst kompiliert
* oder einfach tls Sektion nicht auskommentiert
* Zertifikate verhunzt
* Empfehlungen bis hin zur Neuinstallation vom FreeRadius:
http://ubuntuforums.org/showthread.php?t=478804


Hoffe, das hilft Dir weiter.
Sven.
von
Eric,
27.08.2009 22:15
Beschreibung Freeradius
Es wird sehr detailliert die Vorgehensweise der Konfiguration des Freeradius beschreiben. Allerdings erhalte ich unter verschiedenen Distributionen (Debian, Ubuntu) nach der im Heft angeführten Änderung immer folgende Fehlermeldung:

rlm_eap: Failed to link EAP-Type/tls: rlm_eap_tls.so: cannot open shared object file: No such file or directory
radiusd.conf[10]: eap: Module instantiation failed.
radiusd.conf[1939] Unknown module "eap".
radiusd.conf[1886] Failed to parse authenticate section.

Wurde eine Konfigurationsdirektive vergessen anzugeben?