davzftl
Goto Top

PacketFence MAC-Authentifizierung

Hallo,

bin neu in einem Unternehmen und möchte sehr gerne ein NAC-System implementieren, erstmalig nur für MAC-Authentifizierung und dynamische VLAN-Zuweisung.
Gesagt - getan.

Geworden ist es bei mir PacketFence auf Basis einer Debian 12 Maschine. Netzwerk besteht aus einigen Aruba 2930F und Aruba 2540.

Die VLAN's haben ich gemäß Anleitung als Roles im PacketFence definiert, Switches wurden auch angelegt.

Am ersten Switch habe ich Testweise folgende Config eingespielt:

radius-server host X.X.X.X key "key"  
radius-server host X.X.X.X dyn-authorization
radius-server host X.X.X.X time-window 0
aaa server-group radius "PacketFence" host X.X.X.X  
aaa accounting network start-stop radius server-group "PacketFence"  
aaa authentication mac-based chap-radius server-group "PacketFence"  
aaa port-access mac-based 37-38
aaa port-access mac-based 37 addr-moves
aaa port-access mac-based 38 addr-moves

Der Test ergab folgende Erkenntnis:
  • Stecke ein Gerät an --> Status unregistriert --> Kriege eine APIPA zugewiesen

  • Ändere Status im PacketFence auf registriert und vergebe eine Role --> tut sich nichts
Stecke ich dann ab und wieder an, erhalte ich vom richtigen VLAN eine IP

Genau das selbe Spiel wenn ich die Role eines Devices ändere, es wird erst bei ab- und anstecken ein neuer Discover geschickt.

Habe herausgefunden, dass es auch die Option am Switch aaa port-access mac-based 38 reauth-period gibt.
Diese Option gibt an, nach welcher Zeit das Device sich wieder beim Radius-Server melden muss.

Nun meine Frage, gibt es eine Möglichkeit es so einzustellen, das Role-Changes direkt durchgeführt werden und nicht erst nach ab- und anstecken oder ablaufen einer Zeitspanne?

Klar ich könnte einfach die Reauth-period auf einen sehr kleinen Wert stellen, könnte mir jedoch vorstellen das Packetfence oder die Switches selber dies nichtmehr handlen könnten (Stichwort "Paketbombardierung").

Wäre toll wenn sich hier im Forum der ein oder andere befinden würde der mir weiterhelfen kann!

Gruß

Content-ID: 669798

Url: https://administrator.de/contentid/669798

Printed on: December 7, 2024 at 19:12 o'clock

aqui
aqui Nov 27, 2024 updated at 13:04:24 (UTC)
Goto Top
das Role-Changes direkt durchgeführt werden und nicht erst nach ab- und anstecken oder ablaufen einer Zeitspanne?
Das klappt so bei MAB leider nicht. Zumindestens nicht mit den üblichen Bordmitteln. Das Retriggern der Authentisierung passiert nur dann wenn...
  • A Reauthentication überhaupt aktiviert ist und nach Ablauf des Reauth Timers und wenn die Port Mac noch in der Mac Forwarding Tabelle des Switches ist.
  • B wenn die Mac Adresse aus der L2 Forwarding Tabelle ausgetimed sein sollte und der Switch sie am Port durch Traffic neu lernt. (Mac Timeout Parameter)
  • C ein Link Loss am Port auftritt durch Trennung oder Standby. Löscht auch sofort den Mac Eintrag.
Wie sollte der Switch auch das Ändern von Attributen im Radius Server an ein Endgerät übermitteln um dort eine Reaktion auszulösen wenn ihm die Änderung prinzipbedingt nicht bekannt gemacht wird? MAB ist ja eher ein passives Verfahren aus Endgeräte Sicht.
Das Radius Attribut 28 (Idle Timeout) greift m.E. nicht bei Ethernet NAS. Die Mac Timeout Zeit runterzudrehen hat auch wenig Sinn, denn ein Reauth greift nur dann wenn in der Zeitspanne das Endgerät "stumm" ist, also kein Traffic das Mac Learning retriggert. Bei so geschwätzigen Endgeräten wie Winblows wohl eher Utopie.
Du musst also einen guten Kompromiss deines Reauth Intervalles finden. face-wink
Weitere Details zu der Thematik auch HIER und in den weiterführenden Links.
tech-flare
tech-flare Nov 27, 2024 at 12:11:28 (UTC)
Goto Top
Zitat von @aqui:

das Role-Changes direkt durchgeführt werden und nicht erst nach ab- und anstecken oder ablaufen einer Zeitspanne?
Nein das klappt so bei MAB leider nicht. Das Retriggern der Authentisierung passiert nur dann wenn...
  • A Reauthentication überhaupt aktiviert ist und nach Ablauf des Reauth Timers und wenn die Port Mac noch in der Mac Forwarding Tabelle des Switches ist.
  • B wenn die Mac Adresse aus der L2 Forwarding Tabelle ausgetimed sein sollte und der Switch sie am Port durch Traffic neu lernt. (Mac Timeout Parameter)
  • C ein Link Loss am Port auftritt durch Trennung oder Standby. Löscht auch sofort den Mac Eintrag.
Wie sollte der Switch auch das Ändern von Attributen im Radius Server an ein Endgerät übermitteln um dort eine Reaktion auszulösen wenn ihm die Änderung prinzipbedingt nicht bekannt gemacht wird? MAB ist ja eher ein passives Verfahren aus Endgeräte Sicht.
Das Radius Attribut 28 (Idle Timeout) greift m.E. nicht bei Ethernet NAS. Die Mac Timeout Zeit runterzudrehen hat auch wenig Sinn, denn ein Reauth greift nur dann wenn in der Zeitspanne das Endgerät "stumm" ist, also kein Traffic das Mac Learning retriggert. Bei so geschwätzigen Endgeräten wie Winblows wohl eher Utopie.
Du musst also einen guten Kompromiss deines Reauth Intervalles finden. face-wink
Weitere Details zu der Thematik auch HIER und in den weiterführenden Links.

Dem muss ich leider widersprechen. Dies funktioniert in Verbindung mit PacketFence und CoA

Dies nutzen wir bei Cisco Meraki Switches in Verbindung mit Packetfence

www.packetfence.org/doc/PacketFence_Installation_Guide.html
documentation.meraki.com/MS/Access_Control/Change_of_Authorization_with_RADIUS_(CoA)_on_MS_Switches
tech-flare
tech-flare Nov 27, 2024 updated at 12:13:20 (UTC)
Goto Top
Der Test ergab folgende Erkenntnis:
  • Stecke ein Gerät an --> Status unregistriert --> Kriege eine APIPA zugewiesen
Dann hast du in PF kein NEtzwerk für unregistriere Geräte mit einer "Splash Page" definiert

Habe herausgefunden, dass es auch die Option am Switch aaa port-access mac-based 38 reauth-period gibt.
Diese Option gibt an, nach welcher Zeit das Device sich wieder beim Radius-Server melden muss.

Nun meine Frage, gibt es eine Möglichkeit es so einzustellen, das Role-Changes direkt durchgeführt werden und nicht erst nach ab- und anstecken oder ablaufen einer Zeitspanne?
ja, CoA
aqui
aqui Nov 29, 2024, updated at Dec 02, 2024 at 08:31:54 (UTC)
Goto Top
Du hast natürlich Recht! CoA ist die Alternative der Wahl bei der o.a. Anforderung, erfordert aber entsprechenden Support auf den Endgeräten (Switches) des TOs was aus seinem Posting leider nicht hervorgeht.
Gerade eben mal mit dem Freeradius getestet und zumindestens bei Mikrotik, Ruckus ICX und Cisco Catalysten klappt es problemlos wie bei deinen Merakis auch.
Beim Cisco Catalysten sehen die entsprechenden CoA Konfig Zeilen so aus:
aaa server radius dynamic-author
 client 10.1.10.222 server-key testing123!
 port 3799 
(10.2.100.222=Radius Server IP)
Beim Mikrotik Radius Server (User-Manager) dann entsprechend:
mtcoa
Mit debug aaa coa kann man sich das Verhalten dann auch sehr schön auf dem Cisco Switch ansehen. Beim Mikrotik im Log.
Bei Packet Fence werkelt ja ganz sicher auch ein Freeradius im Hintergrund?! face-wink

Hier ein Live Beispiel für einen Cisco Catalyst Swich:
Der Cisco führt eine CoA Reauthentication ohne Link Loss für den Client mit dem CoA Vendor spezifischen Attribut 26 Cisco:Avpair=“subscriber:command=reauthenticate” durch.
Das radclient Kommando kann leider keine Werte senden die ein "=" Gleichheitszeichen enthalten wie das o.a. Attribut so das man dieses VSA Attribut als Hex Wert senden muss was aber kein Problem ist. Bei Attributen ohne "=" ist das nicht erforderlich.
Entweder konvertiert man es über einen ASCCI/Hex Konverter oder zieht es direkt aus einem Wireshark Trace.
coa-av
Daraus erhält man dann den erforderlichen Hex String: (1a29)000000090123737562736372696265723a636f6d6d616e643d726561757468656e746963617465 dessen erste 2 Bytes entfernt werden müssen, da radclient dies übernimmt.
Das resultiert dann für den MAB Client mit der Mac Adresse B827EBF5C6A4 in dem folgenden radclient Kommando:
root@radius:~# echo Calling-Station-Id=B8-27-EB-F5-C6-A4,Attr-26=0x000000090123737562736372696265723a636f6d6d616e643d726561757468656e746963617465|radclient -x 10.1.10.7 coa testing123!

Sent CoA-Request Id 247 from 0.0.0.0:50961 to 10.1.10.7:3799 length 80
        Calling-Station-Id = "B8-27-EB-F5-C6-A4"  
        Cisco-AVPair = "subscriber:command=reauthenticate"  
Received CoA-ACK Id 247 from 10.1.10.7:3799 to 10.1.10.222:50961 length 20
Ein Wireshark zeigt oben die 2 an den Switch gesendeten CoA Pakete.
Der Switch (IP: 10.1.10.7) quittiert das erwartungsgemäß mit einem ACK und der betreffende Switchport führt dann sofort eine Reauthentication aus ohne den angeschlossenen Client zu disconnecten.
CiscoSwitch#debug aaa coa
AAA CoA packet processing debugging is on

Dec  1 11:59:07: COA: 10.1.10.222 request queued
Dec  1 11:59:07: RADIUS:  Calling-Station-Id  [31]  19  "B8-27-EB-F5-C6-A4"  
Dec  1 11:59:07: RADIUS:  Vendor, Cisco       [26]  41
Dec  1 11:59:07: RADIUS:   Cisco AVpair       [1]   35  "subscriber:command=reauthenticate"  
Dec  1 11:59:07:  ++++++ CoA Attribute List ++++++
Dec  1 11:59:07: 0387B8E0 0 00000081 formatted-clid(37) 17 B8-27-EB-F5-C6-A4
Dec  1 2024 11:59:07 CET: %MAB-5-SUCCESS: Authentication successful for client (b827.ebf5.c6a4) on Interface Fa0/1 
Works as designed! 😉
Dank an @tech-flare für den Wink in die richtige Richtung. face-wink
aqui
aqui Dec 01, 2024 at 11:09:40 (UTC)
Goto Top
Keinerlei Feedback vom TO ist natürlich auch ein Feedback! face-sad
Wenn es das denn nun war als Lösung bitte deinen Thread dann auch als gelöst markieren!
How can I mark a post as solved?
davzftl
davzftl Dec 02, 2024 at 08:09:01 (UTC)
Goto Top
Hallo zusammen,

vielen Dank für die zahlreichen Antworten!

Habe mich mithilfe der Antworten noch bissl reingefuchst, aktueller Stand sieht folgend aus:
  • Authorisierungsstufe (registered/unregistered) kann geändert werden ohne das die Verbindung vom Device zum
Switch getrennt werden muss, desweiteren werden die Roles auch gleich berücksichtigt.

CoA ist aktiviert.
Soweit bin ich zufrieden.

Einziges kleines Schönheitsproblem:
Bei registrierten Devices muss immer noch das Kabel ab- und angesteckt werden, wenn die Rollen geändert werden
Kleiner ärgerlicher Umstand, aber zu verkraften. Evtl. wird dies bei Gelegenheit auch noch geändert!
aqui
aqui Dec 02, 2024 at 08:25:35 (UTC)
Goto Top
Bei registrierten Devices muss immer noch das Kabel...
Das widerspricht ja dann komplett dem CoA Gedanken und wäre netztechnisch völlig unsinnig. Außerdem lassen sich so oder so ja immer nur registrierte Endgeräte per CoA reauthentisieren. Zu mindestens wenn mit "registriert" die Mac Adresse bei MAB oder der Dot1x User am Switch gemeint ist.
Ansonsten würde der Switch ja auch gar nicht wissen welches Device er reauthentisieren soll. Das klingt eher nach einem Firmware Bug in den Switches. face-sad
Bei dem o.a. Catalyst Test und auch Ruckus ICX ist sowas (CoA) erwartungsgemäß nicht erforderlich. Auch die Billigschiene mit Mikrotik verhält sich hier Standard konform und unauffällig.
tech-flare
tech-flare Dec 02, 2024 at 18:05:43 (UTC)
Goto Top
Works as designed! 😉
Dank an @tech-flare für den Wink in die richtige Richtung. face-wink

Freut mich, dass ich dir auch mal auf die Sprünge helfen konnte. Wobei Mit den Hex-Werten ist mir neu, da dies im Meraki mit Packetfence OOTB KlickBunti funktioniert.

Gruß
tech-flare
tech-flare Dec 02, 2024 at 18:07:35 (UTC)
Goto Top
Zitat von @davzftl:

Hallo zusammen,

vielen Dank für die zahlreichen Antworten!

Habe mich mithilfe der Antworten noch bissl reingefuchst, aktueller Stand sieht folgend aus:
  • Authorisierungsstufe (registered/unregistered) kann geändert werden ohne das die Verbindung vom Device zum
Switch getrennt werden muss, desweiteren werden die Roles auch gleich berücksichtigt.

CoA ist aktiviert.
Soweit bin ich zufrieden.

Einziges kleines Schönheitsproblem:
Bei registrierten Devices muss immer noch das Kabel ab- und angesteckt werden, wenn die Rollen geändert werden
Kleiner ärgerlicher Umstand, aber zu verkraften. Evtl. wird dies bei Gelegenheit auch noch geändert!
Dafür gibt es aber meines Wissens nach im Packetfence die Funktion Reevaluate Access