Port Bounce, NAC, NPS und CoA

Sie sichern ihr Netzwerk mit 802.1x/Radius/NPS ab und je nach Authentifizierung bekommt der Client über eine VLAN-Zuordnung oder Port-Policies andere Rechte. Hier geht es darum, wie ihr Netzwerk auf eine Veränderung des Compliance Status des Endgeräts reagieren kann.

Grundsätzliches

Es gibt zwar immer noch viele Firmen, die ihre Netzwerk-Ports überhaupt nicht schützen und wer einen Computer an die Dose verbindet, ist im im LAN schon mal drin, meist sogar mit per DHCP vergebener Adresse. Das ist nicht sicher.

Die erste Stufe wäre also die Authentifizierung von Clients per 802.1x. Das können heute eigentlich alle Switches, alle Windows Clients und ein Radius-Server (NAC/NPS) als auch eine PKI für das Rollout von Computerzertifikaten ist in wenigen Stunden aufgebaut. Mit etwas Konfiguration von VLANs und Firewall-Regeln können Sie Domaincomputer, Drucker und Gäste individuell in eigene Subnetze einsortieren.

Der Computer fährt hoch, der Netzwerklink wird etabliert und noch vor dem IP-Handshake wird über 802.1x und dem Zertifikat der Computer in das passende VLAN eingeordnet. Dann kann er per DHCP eine IP-Adresse beziehen und loslegen.

Reauth als Benutzer

Die erste Herausforderung kommt, wenn Sie die VLAN-Zuordnung auch noch beim Benutzer abhängig machen wollen. Das ist tatsächlich möglich, dass mit der Anmeldung des Benutzers der Client in ein andere VLAN kommt. Wenn der Client dies anstößt, dann kann er auch selbst eine neue IP-Adresse anfordern. Das klingt einfach aber ist es nicht, denn der PC ändert dann mitten während der Anmeldung seine IP-Adresse.

Das kann durchaus schiefgehen, wenn im Hintergrund eine Softwareverteilung gerade etwas vom Netzwerk installiert, Anmeldeskripte laufen o.ä. Der Client verliert ja kurz seine Verbindung und nicht alle Programme versuchen es wieder oder setzen entsprechend auf .

Richtlinien auf Ports

Bessere Switche können daher einen Port mit einem Client nicht nur in ein VLAN zuordnen, sondern sogar individuelle Richtlinien für Verbindungen erzwingen. Der große Vorteil dabei wäre, dass die IP-Adresse des Clients sich quasi nie ändert, sondern jeder Switch Port eigene Firewall-Regeln bekommt. Solange der Client nicht authentifiziert ist, kann er nur per DHCP eine IP-Adresse beziehen und die DNS-Auflösung nutzen. So kann er dann z.B. nur ins Internet oder zu einem Proxy-Server. Der Zugriff auf Domain Controller, Exchange Server oder andere lokalen Dienste bleibt aber verwehrt.

Erst nach der Authentifizierung als Computer kann er die Domaincontroller, den WSUS-Server und alle anderen Dienste erreichen, die der Computer für seine Funktion benötigt. Sobald sich dann ein Anwender auf dem Gerät anmeldet, kann der Client eine erneute Authentifizierung als Benutzer anstoßen und der Switch schaltet den Port dann auf eine andere Richtlinie um, so dass der Anwender nun die für seine Arbeit erforderlichen Server zusätzlich erreichen kann. Dabei bleibt die IP-Adresse und die Verbindung bestehen.

Reevaluation

Bislang ging es nur um die erste Aushandlung der Verbindung und Zuordnung. Mit Intune und anderen Client Management Lösungen gibt es aber neue Anforderungen. So kann ich den "Compliance-Status" eines Endgeräts in die Evaluierung mit aufnehmen. Es reicht dann nicht mehr aus, wenn ich mit als Client mit einem Zertifikat ausweise, sondern ich muss nach nachweisen, dass ich Updates installiert und Bitlocker aktiviert habe, aktuelle Virenscanner aktiv sind und auch sonst den Vorgaben meines Unternehmens entspreche. Entra ID pflegt dazu ja einen Compliance-Status, der durch Intune und andere Lösungen gepflegt wird.

Ein NPS/Radius-System kann daher diesen Status sowohl beim Start des Computers aber auch immer wieder während der Aktivität überprüfen. Wenn ein Client beim Start noch die alten Richtlinien hatte und damit als "Compliant" gewertet wurde, so kann er einige Zeit später mit neuen Vorgaben schon wieder als "nicht Compliant" klassifiziert sein. Aus Sicht des NPS ist er aber schon authentifiziert und damit im Netzwerk. Es gibt tatsächlich Systeme, die alle par Minuten z.B. den Compliance Status aus Intune abrufen und abhängig davon die Netzwerk-Authentifizierung anpassen.

Wenn ihre Schutzlösung einfach entsprechende Firewall-Richtlinien auf den Switch-Ports anpasst, dann wird der Anwender vieleicht von einigen Diensten abgetrennt aber er muss nichts tun. Anders sieht es aus, wenn Sie abhängig vom Compliance-Status den Client in ein anderes VLAN verschieben wollen. Sie können das Tagging auf dem Switch gerne umstellen, aber dann wird der Client mit der falschen IP-Adresse in einem VLAN unterwegs sein und gar nicht mehr kommunizieren können. Es gibt auch andere Änderungen, die eine Reevaluierung durch den Client erforderlich machen würden. Stellen Sie sich vor, sie bauen gerade ihr Netzwerk um und möchten, dass die Client nicht erst am nächsten Morgen die neue Konfiguration erhalten.

EAPPoL Reauthentication

Damit stellt sich die Frage, wie ein Client im Netzwerk (Windows, Linux, Drucker, BDE-Terminal etc.) von so einer Änderung etwas mitbekommen. Für Windows könnten Sie nun sagen, dass ich aus der Ferne z.B. die Netzwerkkarte deaktivieren und neu aktivieren kann. Ich könnte auch einfach ein "IPCONFIG /Release && IPCONFIG /renew"" ausführen, damit der Client eine neue IP-Adresse aus dem Subnetz bekommt. Das ist aber alles nicht "sicher" und erfordert die Kooperation des Clients, z.B.: durch die Verteilung eines Pakets über die Softwareverteilung. Das kann aber auch etwas dauern.

Wenn die Anmeldung per 802.1x erfolgt, dann startet der Client mit einem EAPol-Start und der Switch sendet EAPoL-Request:Identify-Messages, die vom Client mit einem EAPoL-Response:Identify beantwortet wird. Der Switch kommuniziert im Backend weiter mit dem Radius und nach weiteren Request/Response Paketen kommt am ende ein EAPol:Success  oder eben auch Fail, der Client ist authentifiziert und der Switch hat die Zuordnung vorgenommen. Wenn nun eine Änderung erfolgen soll, dann kann der Switch jederzeit wieder ein EAPol-Request senden, worauf der Client entsprechend antworten muss, um weiter authentifiziert zu bleiben oder eben neu zugeordnet wird.

Unabhängig von einer angetriggerten Reauthentication können sie natürlich auch eine regelmäßige Reauthentication eintragen. Damit wird der Client immer wieder genötigt, sich erneut auszuweisen. Hier gibt es zwei Stellschrauben:

  • Access Point
    Der Switch oder WLAN-AccessPoint kann so konfiguriert werden, dass er nach festen Intervallen eine Reauthentifizierung an den Radius/NPS-Server sendet und diese dann die Konfiguration liefert. Hat ich die Konfiguration geändert, wir der Client kurz getrennt und die neuen Richtlinie angewendet.
  • Radius/NPS Parameter
    Schon bei der Antwort zur ersten Anmeldung kann der Authentication-Service einen Timeout mitsenden. Die Anmeldung ist damit befristet und nach Ablauf der Zeit erfolgt eine erneute Authentifizierung

Diese zyklischen Reauthentifizierungen sorgen ebenfalls dafür, dass zumindest nach einiger Zeit eine geändert Konfiguration beim Client ankommt und sind eine Alternative, wenn CoA nicht möglich ist. Allerdings erhöht dies die Last auf ihren Authentication Server, was mit zu berücksichtigen ist.

Port Bounce

Ein anderer Weg wäre am Clientkurz das Netzwerkkabel zu ziehen. Das müssen Sie aber nur bei "unmanaged Switches" tun, die es in Firmen hoffentlich nicht mehr gibt. Prüfen Sie doch einfach mal, ob sie per Software auf einem Switch einen Netzwerkport aus- und wieder einschalten können. Das geht per SNMP bei eigentlich jedem Switch per SNMP.

#REM Port abschalten
snmpset -v 2c -c snmprwcommunity 192.168.1.2 1.3.6.1.2.1.2.2.1.7.portnummer i 2

#REM Port einschalten
snmpset -v 2c -c snmprwcommunity 192.168.1.2 1.3.6.1.2.1.2.2.1.7.portnummer i 1

Das Management System müsste also nur wissen, an welchem Port der Client hängt. Das geht einfach, da er ja die IP-Adresse hat und über die Router die MAC-Adresse und darüber den Port ermitteln kann. Zudem sollte ihr System auch eine Übersicht haben, an welchem Port welches System mit 802.1x authentifiziert ist

Je nach Herstelle des Switches gibt es natürlich auch andere Wege, z.B. eine Konsole per SSH o.ä.

Juniper hat dies auch treffend beschrieben:


Quelle: https://www.juniper.net/documentation/us/en/software/junos/user-access/topics/topic-map/802-1x-authentication-switching-devices.html#id-understanding-radius-initiated-changes-to-an-authorized-user-session

Juniper nutzte dazu ein "Vendor-specific"-Feld im CoA-Paket vom Radius-Server (uniper-AV-Pair = "Port-Bounce")

Port Bounce und DHCP

Mit Wireshark kann ich problemlos eine Netzwerkkarte mitschneiden, auch wenn Sie keine Verbindung hat. Mit einem Filter auf DHCP sehen wir folgendes Verhalten, wenn ich einen PC mit aktiver Netzwerkverbindung per Bounce "trenne" und wieder online nehme. Eine neue DHCP-Aushandlung besteht immer aus vier Paketen:

  1. Discover:  Der Client sucht per Broadcast nach einem DHCP-Server-Angebot
  2. Offer: Der oder die DHCP-Server bieten dem Client eine IP-Adresse an. Das Paket kann mehrfach vorkommen
  3. Request: Der Client nimmt dann eines der Angebot an
  4. ACK: Der Server bestätigt dies

Dann kann der Client die ihm so zugewiesene IP-Adresse nutzen. Wenn eine "Collision Detection" aktiv ist, dann prüft der Server vor dem Angebot bzw. Client nach Erhalt mit einem ARP-Request oder ICMP-Ping, ob die IP-Adresse wirklich frei ist. Wenn Sie sich die "Source" anschauen", dann sehen Sie den Hersteller "Microsoft  00-15-5d" in der MAC-Adresse. Das ist dem Hyper-V Unterbau meines Windows 11 geschuldet.

Nach der Wiederherstellung der Verbindung sehen wir erst zwei "DHCP Request"-Pakete (417/448) . Mein Client möchte nämlich seine alte Adresse (192.168.103.88) weiter nutzen, die ja noch nicht abgelaufen war.

Das macht ja Sinn, wenn sich das Netzwerk nicht ändert. Allerdings gibt es keinen DHCP-Server, der darauf ein ACK sendet.

Was hier fehlt: Wenn ich nach einem Netzwerkwechsel in einem Netzwerk einen "DHCP Request" als "Renew" versende, dann wäre es gut, wenn ein DHCP-Server ein DHCP NACK antwortet, so dass mein Client sofort zum DHCP Discover übergeht und nicht weiter Zeit durch erneute "DHCP Request" und Timeouts verliert.

Bei mir schaltet der Client dann nach ca. 5 Sekunden um und verhält sich wie ein neuer Client. Er startet einen "DHCP Discover", der dann mit einem Offer, Request und ACK abgeschlossen wird. Damit ist der Umzug in das andere VLAN abgeschlossen.

DNS und Bounce

Wenn ein Client in ein anderes Netzwerk kommt, sind alle vorher erhaltene DNS-Einträge ungültig. Namen könnten in einem anderen Subnetz auf andere IP-Adressen oder Server auflösen oder einfach nicht mehr gültig sein. Denken Sie allein an Exchange mit seinen "InternalURL" und "ExternalURL".  Sie sind vieleicht vorher in einem Gäste-LAN und kommen von extern auf die Server während Sie danach im internen LAN ohne Proxy den Server erreichen.

Meine Tests haben ergeben, dass ein Port Bounce beim Client den DNS-Cache komplett löscht. Ich habe dazu extra vorher ein paar DNS-Namen in den Cache geladen und danach abgefragt

Mit der ersten Abfrage wurde der Wert mit einem TTL=515 Sekunden addiert und nach dem Bounce war der Wert direkt aus dem Cache bereinigt. Mein Windows Client startet damit immer mit aktuellen Namen, die er neu auflöst.

PoE und Bounce

Ein Sonderfall sind Geräte, die vom Switch nicht nur mit Netzwerk sondern auch mit Strom versorgt werden. Das sind zwar in der Regel keine Großverbraucher, also keine Notebooks oder PCs aber sehr wohl VoIP-Tischtelefone, BDE-Geräte etc. Hier sollten Sie für ihren Switch prüfen, ob ein Abschalten der Datenverbindung auch zugleich die Energiezufuhr über PoE unterbricht.

Es gibt z.B. bei Aruba einen eigenen Befehl, um die PoE-Versorgung zu deaktivieren ohne den Port selbst abzuschalten. So eine Konfiguration ist natürlich sinnvoll, wenn an einem Port kein PoE-Gerät betrieben wird. Das dürfte nicht nur etwas Energie und Abwärme einsparen, sondern es kann auch niemand ein PoE-Gerät ohne weitere Vorbereitungen betreiben.

Allerdings gibt es wohl keinen Weg, diese Funktion per Radius anzustoßen. Andere Quellen wünschen sich aber genau das, da es wohl VoIP-Telefone gibt, ein Bounce der Datenverbindung nicht als Trigger für eine Neuaushandlung nutzen, wenn die PoE-Versorgung bestehen bleibt.

In dem Fall müssten Sie dann wieder über SNMP oder proprietäre Schnittstellen die Switche ansteuern.

Radius CoA oder eigene Lösungen

Der reguläre Weg für die Umsetzung von CoA mit Port Bounce ist eine passende Konfiguration ihres NPS/RADIUS-System. Es muss ja nicht der "einfache Windows NPS-Server" sein, der zwar mit einem Connector an EntraID für MFA angebunden werden kann, aber nah meinem Wissen weder den Compliance Status in Entra ID bei der Anmeldung noch zyklisch prüft.

Das ist aber keine Lösung für CoA. Hier müssen Sie einen Radius-Services mit ihren Switches verbinden, der zudem aus den gewünschten Quellen den Status der Geräte erhält und bei einer Änderungen einen CoA antriggert. 

Wenn Sie nun aber keinen "kompatiblen" Radius-Server haben, ihre Switches kein CoA über Radius unterstützen oder der Compliance Status mal grade nicht aus Intune/Entra ID kommen, dann könnten Sie immer noch einen eigenen Prozess entwickeln. Ein regelmäßig laufendes Skript müsste dazu aus ihrer autoritativen Quellen einen "Compliance Status" ermitteln und dann die Änderungen erkennen. Gibt es Geräte, die eine Veränderung benötigen, könnten sie den dazu passenden Port ermitteln und per SNMP oder SSH auf die Konsole über die bekannten APIs des Switches ein Port Bounce umsetzen.

Ein geplanter Task, der Änderungen im Intune Compliance Status von Geräten erkennt und dann per SNMP den Port des Clients in ihrem Netzwerk ermittelt und dann den Port kurz Aus/Ein-Schaltet. ist durchaus denkbar.

Der Aufwand ist aber nur gerechtfertigt, wenn Änderungen den den Richtlinien relativ zügig umgesetzt werden. Ich würde dann eher schauen, ob ihre Umgebung eine CoA-Meldung vom Authenticator an den Switch erlaubt oder eine regelmäßige Reauthentication des Clients nicht ebenso ausreichend ist.

Weitere Links