NIC mit Port Security

Es wird wohl noch andere Ideen dazu geben und auch Lösungswege nur,
sollte man eben nicht davon ausgehen dass das alles via Treiber der NIC läuft.


Gruß
Dobby

Nein, das ist Unsinn und nur die halbe Miete.
Bei Verwendung von 802.1x ist das auch mit Usernamen /Passwort oder Zertifikaten möglich
Netzwerk Zugangskontrolle mit 802.1x und FreeRadius am LAN Switch

Verwende also 802.1x am Switch dann hast du die Mac Adress Problematik nicht mehr !
Eine NIC wie du sie beschreibst gibt es de facto nicht !

Nein...auch wieder falsch ! Der Switch hat nicht die Zertifikate, der reicht nur durch. Die liegen auf dem Radius und wenn die OK sind sagt der Radius dem Switch dann "Port aufmachen !"

Sollte auch keine Klugsch...sein
Dann viel Erfolg...bei Fragen weisst du ja wo du sie stellen musst...?!

Da hilft aber nur 802.1x-2010 mit MACsec, und wo kann man das schon konsequent umsetzen?
Das 2004er heute noch von Grund auf neu zu implementieren (wenn die Infrastruktur nicht dafür vorbereitet ist), ist m.E. rausgeworfenes Geld.

-Richard

MacSec ist per se erstmal was ganz anderes, nämlich in erster Linie Verschlüsselung und hat mit dem Thema hier bedingt etwas zu tun:
http://www.juniper.net/techpubs/en_US/junos13.2/topics/concept/macsec.h ...

802.1x ist generell eine Benutzer oder Port Authentisierung und etablierter Standard den alle Hersteller supporten:
http://de.wikipedia.org/wiki/IEEE_802.1X
Da es EAP oder PPP-EAP-TLS Authentication verwendet kann die Authentisierung sowohl über den Client Usernamen und Passwort (Betriebssystem) oder eben Zertifikate erfolgen sofern man eine CA aufsetzt. Viele VoIP Telefone, Drucker, Switches haben heute deshalb oft auch .1x Clients an Bord um Zugang zu solch gesicherten Netzen zu bekommen.
Unverständlich was da "2004" oder "2010" bedeuten soll ?!

Einige Switchhersteller erlauben zusätzlich zur Client Usernamen und Passwort oder Zertifikats Authorisierung noch die über Mac Adressen der Clients. Mit dynamischer VLAN Zuweisung erreicht man so sog. Client based VLANs.
Aber genau das ist ja hier nicht gefordert, da man die Mac Adressen eben leicht faken kann, was mit den o.a. Verfahren so nicht möglich ist.
802.1x ist heute mittlerweile Commodity geworden da es im kommerziellen Umfeld sehr häufig in WLANs großflächig zum Einsatz kommt.

Nein, das ist eben ein weit verbreiteter Irrglaube, weshalb ich es zu 802.1x kurz ansprechen wollte, auch wenn es jetzt über eine Frage, die von simpler Port-Security ausgeht, hinaus reicht. Das ist auch bei Wikipedia bei Sicherheitslücken knapp bemerkt (dort auch zur Unterscheidung 2004er- bzw. 2010er-Standard).

Das Problem ohne MACsec ist, dass es gerade so einfach ist, wie Du oben schreibst: Der Client authentisiert sich, der Switch macht den Port auf, und zwar für die MAC des authentifizierten Clients. An dem Port des authentifizierten Clients besteht insofern weiterhin eine MAC-Problematik, unabhängig von der Art der Authentifizierung.

Sicher eine Abwägungsfrage, aber da Zertifikat-Authentifizierung und Pipapo für kleine Unternehmen manchmal nur schwer umsetzbar ist, halte ich 802.1x deshalb in vielen Fällen für vergebene Liebesmühe.

Man sollte sich zumindest im Klaren sein, dass die praktische Einschränkung für den Angreifer sich darin erschöpft, dass er als Man-in-the-Middle an einen authentifizierten Client gebunden ist. Der Angriff sieht so aus, dass man auf einem MITM-Gerät eine EAPOL-durchlässige Bridge aufsetzt, die dann "als Client" Pakete injizieren kann.

Ahhh...OK so war das gemeint, das hatte ich missverstanden. Ja da hast du natürlich Recht, denn wenn der Client wie auch immer authentisiert ist trägt der Switch einfach dessen Mac Adresse ein in seine Port Forwarding Tabelle (Mac Table) und damit wird dann generell dessen Traffic geforwardet. Stimmt da hast du Recht !
Da besteht dann ein gewisses Risiko mit der Mac.
Nur auch wenn das der Fall ist und man den Port so aufbekommt müsste man mit GENAU der Mac von einem 2ten Gerät senden und hätte dann doppelte Macs im Netz.
Denn abziehen darf man den Client nicht, ein Link Loss triggert die Authentisierung neu. Wenn man aber ohne Link Loss die Ursprungs Mac ändert und mit dem Angreifer dann weitersendet ist man natürlich drin, richtig.
Man müsste dann den Reauth Timer entsprechend niedrig setzen was so den Zugang dann erheblich erschweren würde aber ganz könnte man ihn nicht verhindern...das stimmt.
Sorry nochmal für das Missverständniss !