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.1
2. 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).
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_CA
4. 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
5. 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
6. 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 Paket
7.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=string
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
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
Please 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
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
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.
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
👍
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.