colinardo
Goto Top

Mikrotik: 802.1X Port basierte Authentifizierung mit Zertifikaten unter RouterOS 7 mit User-Manager als Radius-Server

back-to-topEinleitung

Die folgende Anleitung soll als eine zusätzliche Ergänzung zu der schon bestehenden hervorragenden Übersicht von @aqui in der Anleitung Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik dienen, und die Möglichkeiten des User-Managers vorstellen der als bislang in RouterOS 6 als "abgespeckter" Radius-Server sein Dasein pflichtete. Mit den neuen Möglichkeiten wird der User-Manager endlich auch zu einem echten Radius-Server den man auch zur Authentifizierung zusätzlich zu PAP, CHAP, MS-CHAP, MS-CHAPv2 über die gängigen EAP-Methoden EAP-TLS, EAP-TTLS and EAP-PEAP nutzen kann, damit wächst der User-Manager zu einem, zwar nicht einem freeradius ebenbürtigen Kandidaten heran, aber in Zukunft kann man auch für einige Setups auf einen separaten Radius-Server verzichten.

Ich greife hier schon etwas der aktuellen Entwicklung von RouterOS im produktiven 6er Zweig voraus und möchte den neuen User-Manger im aktuellen Release von Router OS 7 im Zusammenspiel mit 802.1X Port basierter Authentifizierung vorstellen. Da in @aqui 's Anleitung schon die dynamische VLAN Zuweisung für WLAN-Clients behandelt wurden, greife ich hier als Beispiel die auch seit neuerem in RouterOS enthaltene 802.1x Port basierte Authentifizierung auf.

Die Anleitung funktioniert ausdrücklich nicht auf dem 6er Zweig von RouterOS.

back-to-topHinweise

Für den User-Manager wird es in Zukunft auch kein extra Web-Administrationsportal mehr geben und die Verwaltung wird in Winbox und in das reguläre Konfigurationswebinterface eingepflegt. Da es zum Zeitpunkt des Verfassens dieser Anleitung noch keine User-Manager GUI gab beschränke ich mich hier vornehmlich auf die Konfiguration über die Konsole.
Das User-Manager Paket ist ein separates Package zu finden unter "Extra packages" unter https://mikrotik.com/download. Das *.npk extrahiert man und zieht es entweder per Drag n' Drop in Winbox auf den Router, oder überträgt es per (S)-FTP in das Root Verzeichnis des Mikrotik. Nach einem obligatorischen Reboot steht der User-Manager zur Verfügung.


back-to-top1. Radius Server Eintrag erstellen

Damit der Mikrotik Radius-Anfragen an den User-Manager schicken und empfangen kann legen wir einen entsprechenden Eintrag wie folgt an:
/radius add address=127.0.0.1 secret=Passw0rd service=dot1x src-address=127.0.0.1
Da der User-Manager hier auf dem gleichen Mikrotik läuft reicht hier die Loopback Adresse. Das Passwort kann natürlich frei gewählt werden, muss aber dann mit dem im User-Manager angelegten Passwort (unter Punkt 5) identisch sein.

back-to-top2. Interface für 802.1X Authentifizierung vorbereiten

/interface dot1x server add interface=ether2 enabled=no

Hinter interface= geben wir den Port an welchen wir mit 802.1x schützen möchten. Vorerst deaktivieren wir den Eintrag noch (enabled=no) da sonst die Verbindung zum Client gekappt wird. Zum späteren Zeitpunkt aktivieren wir den Eintrag dann (Punkt 6).

back-to-top3. Zertifikate erstellen

Die Anleitung soll jetzt nicht erneut die Grundlagen über die Erstellung von Zertifikaten behandeln, dafür existieren genügend ausführliche Anleitungen im Netz. Für das Beispiel generieren wir hier der Einfachheit halber eine Zertifizierungsstelle,Server- und Client-Zertifikat direkt auf dem Mikrotik.
Unsere CA nennen wir im Beispiel DOT1X_CA, den Common-Name des Server-Zertifikats DOT1X_SERVER und den des Clients DOT1X_CLIENT1.

back-to-top3.1 CA Zertifikat erstellen und signieren

/certificate add name=DOT1X_CA common-name=DOT1X_CA days-valid=7300 trusted=yes country=DE
/certificate sign DOT1X_CA

back-to-top3.2 Server Zertifikat erstellen und signieren

/certificate add common-name=DOT1X_SERVER days-valid=730 country=DE key-usage=tls-server,tls-client,digital-signature,key-encipherment
/certificate sign DOT1X_SERVER ca=DOT1X_CA

back-to-top3.3 Client Zertifikat erstellen und signieren

/certificate add common-name=DOT1X_CLIENT1 days-valid=730 country=DE key-usage=tls-client,digital-signature,key-encipherment
/certificate sign DOT1X_CLIENT1 ca=DOT1X_CA

back-to-top4. Zertifikate für die Verwendung am Client exportieren

Das Zertifikat der Zertifizierungsstelle (CA) exportieren wir als *.crt
/certificate export-certificate DOT1X_CA

Und das Client Zertifikat mit dessen privatem Schlüssel als *.p12 pkcs12 Container
/certificate export-certificate DOT1X_CLIENT1 export-passphrase=Passw0rd type=pkcs12
Die Zertifikate werden im lokalen Speicher des Mikrotik abgelegt. Von dort aus kopiert man sie auf den Client. Unter Windows via Winbox entweder per Drag n' Drop auf den Desktop/Ordner ziehen oder per S-FTP oder FTP am Mikrotik einloggen und übertragen.

back-to-top5. User-Manager einrichten

Dieser Schritt besteht hauptsächlich aus folgenden Schritten:

  • Router-Objekt anlegen (Authenticator festlegen)
  • Zu nutzendes Server Zertifikat festlegen
  • Profil anlegen(definieren von Limits usw.)
  • Authentifizierungs-Variante für EAP-TLS erstellen
  • User anlegen
  • User dem Profil zuweisen.

Die Schritte fasse ich hier als Konsolenbefehle zusammen, Passwort und Namen der Zertifikate müssen angepasst werden wenn oben dafür andere Werte verwendet wurden:
/user-manager router add address=127.0.0.1 name=localrouter shared-secret=Passw0rd
/user-manager set certificate=DOT1X_SERVER enabled=yes
/user-manager profile add name=dot1x name-for-users=dot1x
/user-manager user group add name=dot1x-tls-auth outer-auths=eap-tls
/user-manager user add name=DOT1X_CLIENT1 group=dot1x-tls-auth
/user-manager user-profile add profile=dot1x user=DOT1X_CLIENT1

back-to-top6. 802.1X am Mikrotik für das Interface aktivieren

Achtung: Nach Aktivierung der 802.1X auf dem Port verliert der dort angeschlossene Client seine LAN-Verbindung zum Mikrotik so lange er sich noch nicht authentifiziert hat! Das bitte berücksichtigen.
/interface dot1x server set 0 enabled=yes

back-to-top7. Client-Computer einrichten (Linux) und erster Test

Für einen Test von 802.1x am Client nehme ich hier als Beispiel eine Arch-Linux Distribution und das wpa_supplicant Paket

back-to-top7.1 wpa_supplicant Package installieren und Konfiguration anlegen

Als erstes installieren wir wpa_supplicant
sudo pacman -S wpa_supplicant
Dann legen wir unter /etc/wpa_supplicant/wpa_supplicant.conf eine Konfigurationsdatei an und fügen folgenden Inhalt ein:
(eigene Werte und Pfade anpassen):
eapol_version=2
ap_scan=0
network={
	key_mgmt=IEEE8021X
	eap=TLS
	identity="DOT1X_CLIENT1"  
	private_key="/path/to/DOT1X_CLIENT1.p12"  
	private_key_passwd="Passw0rd"  
	eapol_flags=0
}
Die identity sollte dem Common-Name im Client-Zertifikat und den Namen des Users im User-Manager entsprechen.

back-to-top7.2 Verbindung mit wpa_supplicant herstellen (Test)

Für den ersten Test starten wir wpa_supplicant unter Angabe des Pfades zur oben erstellten Konfigurationsdatei, dem Parameter -D der den Driver auf "wired" (kabelgebunden) festlegt und dem Interface (-i) welches wir freischalten möchten:
wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -D wired -i eth0
Die Ausgabe sollte dann ähnlich wie diese aussehen

screenshot

Nach Authentifizierung kann der Befehl mit CTRL+C abgebrochen werden.

Auf dem Mikrotik sollte dann die entsprechende Freigabe für das Interface zu sehen sein und das Interface auf "authorized" stehen:

screenshot

screenshot

Die Zähler am Radius-Client des Mikrotiks sollten das ebenfalls bestätigen

screenshot

Und der User-Manager eine aktive Session anzeigen

screenshot

back-to-top8. Dynamische VLAN-Zuweisung für den Port

Alternativ lässt sich statt einer statischen VLAN-Zuweisung des Ports über die Bridge auch eine dynamische VLAN-Zuweisung für den Port über den neuen User-Manager vornehmen.
Wie bei den gängigen Radius-Servern wird dies auch hier über Attribute geregelt die der Radius-Server an den Authenticator im "Access-Accept" Paket mitschickt.
Die Attribute die wir für die port basierte Authentifizierung benötigen sind bei Mikrotik und 802.1x folgende:
* Tunnel-Type = 13 (13 steht für "VLAN" siehe https://tools.ietf.org/html/rfc2868#section-3.1)* Tunnel-Medium-Type = 6 (steht für "IEEE-802" siehe https://tools.ietf.org/html/rfc2868#section-3.2)* Tunnel-Private-Group-ID = 10 (unsere VLAN ID)

Damit der Usermanager diese Attribute bei einer "Access-Accept" Antwort mitsendet, müssen wir die Attribute dem User-Manager erst einmal bekannt machen und anlegen (falls sie noch nicht existieren, in aktuellen /er Versionen sind diese schon angelegt und müssen nicht erneut hinzugefügt werden):
/user-manager attribute
	add name=Tunnel-Type type-id=64 value-type=uint32
	add name=Tunnel-Medium-Type type-id=65 value-type=uint32
	add name=Tunnel-Private-Group-ID type-id=81 value-type=string
Eine Liste der im Usermanager möglichen Attribute findet sich hier:
https://help.mikrotik.com/docs/display/ROS/User+Manager#UserManager-Attr ...

Jetzt kann man die Attribute beim Anlegen oder ändern eines Users oder einer Benutzergruppe mit individuellen Werten zuweisen.
Hier für einen User den man dynamisch dem VLAN 10 zuordnet:
/user-manager user add name=DOT1X_CLIENT1 attributes=Tunnel-Private-Group-ID:10,Tunnel-Type:13,Tunnel-Medium-Type:6 
Wenn sich der User nun wie oben gezeigt am Port authentifiziert, wird der auf 802.1x geschützte Port in der Bridge des Mikrotik für dieses VLAN automatisch als untagged in dem VLAN hinzugefügt und wird damit Mitglied des angegebenen VLANs. Geht der Port wieder in den Status "un-authorized" wird der Port auch automatisch wieder als untagged Port aus dem VLAN entfernt.
Damit die dynamische Zuweisung auch funktioniert muss der Port natürlich vorher der Bridge schon einmal als Port zugewiesen werden da ansonsten die dynamische Port-Zuweisung fehl schlägt.

Hier sieht man im LOG des Mikrotik wie der User-Manager unsere hinzugefügten Attribute an den Mikrotik verschickt:

screenshot

Ebenfalls wird nun das zugewiesene VLAN für den Port aufgeführt:

screenshot

back-to-top9. Troubleshooting am Mikrotik

Sollte es wieder erwarten zu Problemen kommen, sollte man als erstes das LOG um die radius und manager Topcs ergänzen, dann erhält man im LOG detaillierte Informationen über die versendeten Radius-Pakete und die User-Manager Meldungen.

screenshot

Bis dahin, bleibt von mir nur noch ein Gruß an alle Networker da draußen.
@colinardo

Content-Key: 577655

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

Ausgedruckt am: 28.03.2024 um 23:03 Uhr

Mitglied: aqui
aqui 08.06.2020, aktualisiert am 21.10.2023 um 12:08:12 Uhr
Goto Top
Das sind ja mal gute News von Mikrotik. face-big-smile Interessant und auch löblich das MT sich nun auch an die Standard Radius Attribute für VLANs hält und die Vendor spezifischen Attribute wohl nicht mehr zwingend sind.
Dein Einverständnis vorausgesetzt hab ich es mit dem o.a. Tutorial verlinkt.
Offizielle MT Doku hier.
Mitglied: colinardo
colinardo 08.06.2020 um 11:00:26 Uhr
Goto Top
Zitat von @aqui:
Dein Einverständnis vorausgesetzt hab ich es mit dem o.a. Tutorial verlinkt.
Selbstredend face-smile.Danke dir!
Mitglied: commodity
commodity 04.11.2021 aktualisiert um 17:45:12 Uhr
Goto Top
Hallo @colinardo,

Danke für das vorzügliche Tutorial! Ich finde die Geräte und Router OS klasse.
Zu 802.1x bei MT aber zwei Fragen:

1. Sehe ich das richtig, dass es sich bei der Mikrotik-Umsetzung faktisch um den alten 802.1x (2004) Standard handelt, der mittels zwischen einen authorisierten Client und MT-Port geschalteten Simpel-Switch umgangen werden kann?
Wenn ich das richtig verstanden habe, hat erst die Anpassung von 802.1x (2010) dies (u.a.) berücksichtigt, indem MACSec (802.1AE) eingeführt wurde. Darüber hinaus gibt es (kenne da nur Cisco) herstellerspezifische Umsetzungen. Cisco unterstützt z.B. MACSec nur oberhalb der SG/CBS-Serie, hat für die KMU-Switche aber immerhin eine Lösung namens "Multi-Sessions" geschaffen, mit der sich, wenn ich das richtig verstehe, jeder am Port angeschlossene Client individuell authentifizieren muss.

2. Wenn das bei Router OS fehlt, ist dort dann die (aufwändige) Radius-Implementierung von 802.1x im LAN mit Blick auf die Sicherheit des Netzes überhaupt noch sinnvoll?
Ich hätte dann zwar immerhin dynamische VLAN-Zuweisung aber keine echte Sicherheit und könnte einen MT-Switch dann doch wohl nur in bereits sicheren Umgebungen einsetzen.

Danke und viele Grüße, commodity

Edit: Da ist offenbar was in der Pipeline: https://forum.mikrotik.com/viewtopic.php?t=164427
Mitglied: colinardo
colinardo 04.11.2021 aktualisiert um 22:02:43 Uhr
Goto Top
Servus @commodity,
1. Sehe ich das richtig, dass es sich bei der Mikrotik-Umsetzung faktisch um den alten 802.1x (2004) Standard handelt, der mittels zwischen einen authorisierten Client und MT-Port geschalteten Simpel-Switch umgangen werden kann?
Ja, zumindest in der alten Beta ist das so, sobald der Port freigeschaltet wurde geht da so ziemlich alles, natürlich nur wenn sich auch der Client authentifiziert nachdem man das Kabel gezogen hat.

Zitat:
https://help.mikrotik.com/docs/display/ROS/Dot1X
A RouterOS dot1x server acts as an authenticator. An interface where dot1x server is enabled will block all traffic except for EAPOL packets which is used for the authentication. After client is successfully authenticated, the interface will accept all received traffic on the port. If the interface is connected to a shared medium with multiple hosts, the traffic will be accepted from all hosts when at least one client is successfully authenticated. In case of failed authentication, it is possible to accept the traffic with a dedicated port VLAN ID.

In neueren Beta ist MACSec schon eingezogen wohl aber noch nicht ganz komplett bzw. lückenhaft, konnte es aber bisher noch nicht testen.

2. Wenn das bei Router OS fehlt, ist dort dann die (aufwändige) Radius-Implementierung von 802.1x im LAN mit Blick auf die Sicherheit des Netzes überhaupt noch sinnvoll?
Es hindert halt Otto-Normalo daran sich halt mal schnell an Ports ins Netz zu schalten die bspw. an IP-Cams oder dergleichen hängen.
Auch wenn aktuell kein aktiver Client am Port hängt verhindert es das der Port missbraucht wird, halt nur so lange bis ein Client sich wieder dort einloggt.
Aber man hat ja alternativ noch die Möglichkeit eine weitere Sicherheitsebene einzuziehen (IPSec & Firewall & Co.)
Ist halt nur eine weitere Ebene die hier eben nicht der Weisheits letzter Schluss in Sachen Sicherheit ist.

Grüße Uwe
Mitglied: aqui
aqui 05.11.2021, aktualisiert am 11.06.2022 um 18:23:53 Uhr
Goto Top
Zumindestens bei anderen aktuellen Switches ist das schon lange nicht mehr so das man es per Switch davor aushebeln kann, denn das Forwarding ist immer Mac abhängig und wird nur auf Basis der Mac gemacht. Auch wenn einer den Port öffnet können andere Macs am gleichen Port NICHT durch.
Stichwort Multi- oder single Host Port Authentication. Beherrschen mittlerweile alle besseren Switches.
Wurde früher auch mal als Mac based VLANs bezeichnet und ist heute, wie bereits gesagt, eigentlich mittlerweile überall Standard... Wenn MT noch nicht so weit ist, ist das natürlich schade.
Mitglied: colinardo
colinardo 05.11.2021 aktualisiert um 12:02:49 Uhr
Goto Top
Zitat von @aqui:

Zumindestens bei anderen aktuellen Switches ist das schon lange nicht mehr so das man es per Switch davor aushebeln kann, denn das Forwarding ist immer Mac abhängig und wird nur auf Basis der Mac gemacht. Auch wenn einer den Port öffnet können andere Macs am gleichen Port NICHT durch. Wurde früher auch mal als Mac based VLANs bezeichnet und ist heute eigentlich mittlerweile überall Standard... Wenn MT noch nicht so weit ist, ist das natürlich schade.
Naja, ein MAC-Filter ist in der Firewall des Mikrotik schnell hinzugefügt aber wie wir ja alle wissen , MAC Adressen lassen sich ja bekanntlich faken ...

p.s. Habe das MACSec Interface der aktuellen Beta mal getestet, scheint wohl noch nicht komplett zu sein, die Interfaces schicken zwar gegenseitig EAPOL Frames raus, nehmen sie aber offensichtlich noch nicht an und die Interfaces bleiben im Status "negotiating" trotz korrekt konfiguriertem CAK und CKN.
Mitglied: commodity
commodity 10.11.2021 um 19:08:41 Uhr
Goto Top
Danke Euch für die Anmerkungen. Ja, ich war auch etwas irritiert, als ich die Doku gelesen habe. Bei Mikrotik (oder generell) darf man 802.1x eben nicht als Sicherheitsfeature sehen.
Das schöne an den MTs ist aber, dass sie sich entwickeln, wo bei anderen gar nichts passiert. Und es gibt ja andere Lösungswege - oder halt Cisco face-wink

Viele Grüße, commodity
Mitglied: aqui
aqui 30.12.2021 um 11:15:09 Uhr
Goto Top
Hast du die MacSec Funktion mal mit der nun Stable 7.1.1 verifiziert ? Gibts da irgendwelche Änderungen im Status ?
Mitglied: colinardo
colinardo 30.12.2021 um 11:26:02 Uhr
Goto Top
Zitat von @aqui:

Hast du die MacSec Funktion mal mit der nun Stable 7.1.1 verifiziert ? Gibts da irgendwelche Änderungen im Status ?
Steht noch aus, glaube aber im Mikrotik Forum schon gelesen zu haben das es noch immer nicht fertig ist.
Mitglied: colinardo
colinardo 30.12.2021 aktualisiert um 12:06:34 Uhr
Goto Top
Zitat von @colinardo:
Steht noch aus, glaube aber im Mikrotik Forum schon gelesen zu haben das es noch immer nicht fertig ist.

Gerade gecheckt. Status quo hat sich mit Version 7.1.1 bei MACsec nicht geändert bei der 7.2rc1 ebenso wenig (status steht weiterhin nur bei negotiating, weiter kommt es nicht), die aktuelle Prio liegt da wohl momentan erst mal die Version 7 in den Basis-Features wirklich stable zu bekommen.

screenshot

Beide pusten EAPOL Frames in den Äther, aber das interessiert die Gegenseite jeweils nicht.
Mitglied: aqui
aqui 30.12.2021 um 12:02:30 Uhr
Goto Top
Danke für das Feedback. Bleibt also weiter spannend an der Baustelle...
Bleibt ja dann nur noch das (Beta) mit dem nun offiziellen Launch der 7er Firmware aus der Überschrift zu nehmen. 😉
Mitglied: colinardo
colinardo 30.12.2021 aktualisiert um 13:41:31 Uhr
Goto Top
Zitat von @aqui:

Danke für das Feedback. Bleibt also weiter spannend an der Baustelle...
Bleibt ja dann nur noch das (Beta) mit dem nun offiziellen Launch der 7er Firmware aus der Überschrift zu nehmen. 😉

Ja wenn da nur nicht ein Bug in der aktuellen "Stable" 7.1.1 wäre der das dynamische Hinzufügen des Ports zu einem VLAN verhindert. Ohne dynamische VLAN Zuweisung klappt es, aber mit nich, da kommt es zu einem nicht weiter definierten Fehler im Log
#edit# Mein Fehler, meine Migrations-Config war verbuggt.
Mitglied: aqui
aqui 30.12.2021 um 12:59:25 Uhr
Goto Top
Uhhh, das ist böse. OK, dann heisst es auch hier wohl warten auf die nächsten Patch Releases... face-wink
Müsst ich gleich mal checken ob das auch mit einem externen Radius Server in der 7.1.1 passiert.
Mitglied: colinardo
colinardo 30.12.2021 aktualisiert um 13:41:55 Uhr
Goto Top
Zitat von @aqui:

Uhhh, das ist böse. OK, dann heisst es auch hier wohl warten auf die nächsten Patch Releases... face-wink
Müsst ich gleich mal checken ob das auch mit einem externen Radius Server in der 7.1.1 passiert.

Ohhhh my fault, da muss ich doch zurückrudern, war ein Migrationsfehler der Test-VM! Sorry, klappt wieder face-confused.
Mitglied: aqui
aqui 30.12.2021, aktualisiert am 10.06.2022 um 16:55:27 Uhr
Goto Top
👍
Mit externem Radius auch fehlerfrei. Obwohl ja jetzt im Mikrotik Umfeld mit dem onboard Radius in 7.3 obsolet. face-wink
Mitglied: colinardo
colinardo 25.09.2022 aktualisiert um 17:19:10 Uhr
Goto Top
Zur Info an alle die hier an MACsec interesse gezeigt haben:

In der aktuellen RouterOS Version 7.6Beta8 (Testing channel), funktioniert nun endlich auch MACsec grundlegend!

Hier der Test zwischen zwei Mikrotiks mit der aktuellen Testing-FW:

screenshot

Der Test von einem ArchLinux und wpa_supplicant zu einem Mikrotik verlief ebenso positiv:

screenshot

Bitte beachten das diese spezielle Firmware für Geräte die auf der TILE Architektur basieren und auch die RB5009 Serie laut Mikrotik nicht zu empfehlen ist wenn MACsec zum Einsatz kommt.
Important note!!!
Version not recommended on TILE and RB5009 devices if MACsec is used;

https://mikrotik.com/download/changelogs/testing-release-tree#show-tab-t ...

Grüße Uwe