16
Mikrotik: 802.1X Port basierte Authentifizierung mit Zertifikaten unter RouterOS 7 mit User-Manager als Radius-Server
Inhaltsverzeichnis
Einleitung
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.
Hinweise
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.
1. 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.12. Interface für 802.1X Authentifizierung vorbereiten
/interface dot1x server add interface=ether2 enabled=noHinter 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).
3. 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.
3.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
3.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
3.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_CA4. 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=pkcs125. 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_CLIENT16. 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
7. 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 Paket7.1 wpa_supplicant Package installieren und Konfiguration anlegen
Als erstes installieren wir wpa_supplicantsudo pacman -S wpa_supplicant
(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
}7.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
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:
Die Zähler am Radius-Client des Mikrotiks sollten das ebenfalls bestätigen
Und der User-Manager eine aktive Session anzeigen
8. 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=stringhttps://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 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:
Ebenfalls wird nun das zugewiesene VLAN für den Port aufgeführt:
9. 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.
Bis dahin, bleibt von mir nur noch ein Gruß an alle Networker da draußen.
@colinardo
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 577655
Url: https://administrator.de/contentid/577655
Printed on: October 1, 2023 at 14:10 o'clock
16 Comments
Latest comment
Das sind ja mal gute News von Mikrotik. 
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.
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.
Selbstredend 
.Danke dir!
.Danke dir!
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
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
Servus @commodity,
Zitat:
https://help.mikrotik.com/docs/display/ROS/Dot1X
In neueren Beta ist MACSec schon eingezogen wohl aber noch nicht ganz komplett bzw. lückenhaft, konnte es aber bisher noch nicht testen.
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
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
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.
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.
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 ...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.
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.
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
Viele Grüße, commodity
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
Viele Grüße, commodity
Hast du die MacSec Funktion mal mit der nun Stable 7.1.1 verifiziert ? Gibts da irgendwelche Änderungen im Status ?
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.Hast du die MacSec Funktion mal mit der nun Stable 7.1.1 verifiziert ? Gibts da irgendwelche Änderungen im Status ?
Zitat von @colinardo:
Steht noch aus, glaube aber im Mikrotik Forum schon gelesen zu haben das es noch immer nicht fertig ist.
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.
Beide pusten EAPOL Frames in den Äther, aber das interessiert die Gegenseite jeweils nicht.
1
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. 😉
Bleibt ja dann nur noch das (Beta) mit dem nun offiziellen Launch der 7er Firmware aus der Überschrift zu nehmen. 😉
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. 😉
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. 😉
#edit# Mein Fehler, meine Migrations-Config war verbuggt.
1
Uhhh, das ist böse. OK, dann heisst es auch hier wohl warten auf die nächsten Patch Releases...
Müsst ich gleich mal checken ob das auch mit einem externen Radius Server in der 7.1.1 passiert.
Müsst ich gleich mal checken ob das auch mit einem externen Radius Server in der 7.1.1 passiert.
Zitat von @aqui:
Uhhh, das ist böse. OK, dann heisst es auch hier wohl warten auf die nächsten Patch Releases...
Müsst ich gleich mal checken ob das auch mit einem externen Radius Server in der 7.1.1 passiert.
Uhhh, das ist böse. OK, dann heisst es auch hier wohl warten auf die nächsten Patch Releases...
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
.
👍
Mit externem Radius auch fehlerfrei. Obwohl ja jetzt im Mikrotik Umfeld mit dem onboard Radius in 7.3 obsolet.
Mit externem Radius auch fehlerfrei. Obwohl ja jetzt im Mikrotik Umfeld mit dem onboard Radius in 7.3 obsolet.
1
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:
Der Test von einem ArchLinux und wpa_supplicant zu einem Mikrotik verlief ebenso positiv:
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.
Grüße Uwe
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:
Der Test von einem ArchLinux und wpa_supplicant zu einem Mikrotik verlief ebenso positiv:
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 ...Version not recommended on TILE and RB5009 devices if MACsec is used;
Grüße Uwe
1