Oh, this is long-awaited, if it works. For context: Mikrotik uses some (semi-)proprietary, but pretty nifty protocols to manage their gear.
One of these protocols, MAC-telnet, has been reverse-engineered pretty extensively previously. But, due to a (not unreasonable) security-related upgrade, the login phase was changed, and 3rd-party implementations stopped working. Mikrotik has refused repeated requests to document this protocol.
The linked repository looks like it may re-enable MAC-telnet logins, which would be great for 3rd-party scripts and management solutions.
(Why? Because it allows you to connect to, and properly provision, any Mikrotik gear using your own scripts, just based on Layer-2 presence. This is very cool for many use cases...)
So you can still connect to a device if it doesn’t have an IP? That’s pretty cool.
Then out of curiosity, do I understand correctly that these types of packets are bridged, not routed, and as such doesn’t work if you’re not in the same subnet?
Correct. You can't use these protocols outside of the same broadcast segment[0]. That segment can be stretched though with some frame encapsulation protocol like VXLAN or VPNs with bridged TAP devices.
[0] Broadcast segment would be the more accurate term here, given that subnet generally refers to layer 3 addressing mechanics. Technically a broadcast segment can contain more than one operational IP subnet, but this is uncommon on most user networks.
Yes, Mikrotik MAC-telnet works regardless of the IP configuration: it's technically broadcast UDPv4 to port 20561, but the address information in the protocol data is the only thing that's required for it to work.
So the IP addresses can be something invalid like 0.0.0.0, in which case you both need to be on the same L2 segment (bridged). But, it's also entirely possible to use valid IP source/destination addresses (which don't need to be exactly your addresses, just a combination that works in both directions across any routers involved, so Ethernet packets end up on the right segment -- this requires some NAT tricks, but in the end it does work...) for the same protocol to work in a L3 environment. Also, on an all-Mikrotik network, there's https://help.mikrotik.com/docs/display/ROS/RoMON, which, once you set it up, allows for even more interesting traffic flows.
My use case for MAC-telnet is "remote hands" provisioning of new/replacement routers and switches. The only thing the local IT resource needs to be able to do, is connect the equipment to a correct uplink port, after which things will usually work (if not, a factory defaults reset may be required).
At the moment, some minor manual configuration work using another Mikrotik box is still required to enable IPv6 and configure the correct VLAN, after which my scripts take over. If MAC-telnet authentication can now be automated as well (and testing that is next on my to-do list...), provisioning could be fully automated in most cases.
> The single best resource we used in reverse engineering was an unfinished IEEE submission draft courtesy of the WayBack Machine. In fact, MikroTik's implementation is nearly identical to the draft's proposed protocol. See if you can spot the minor nuances and marvel (as we did) that the shared secret remains the same.
That's a surprising twist. They duplicated the protocol from this unfinished draft almost exactly, but the draft doesn't appear to have gone anywhere (hence the archive link)
I wonder if the same person who wrote the paper consulted on this implementation, or if the MikroTik team just saw the paper at some point and decided to use it.
There are a surprising number of internet-drafts that died before reaching RFC status but nevertheless were implemented, even became widely implemented standards. The sftp protocol ("filexfer" over ssh) is one example.
Does anyone know why this is? I've never been closely involved in the RFC process; is there some hard-to-clear hurdle at the end of it?
The draft standard was an IEEE proposal, not an IETF one (RFCs are specific to the IETF standardization process), but it seems like the author was pretty familiar with the IEEE process and is involved with that organization.
Maybe it was just a solution looking for a problem at the time of its proposal? Honestly, I'm not sure exactly whether the exotic encryption choices (strange, little-used elliptic curves, etc.) actually add much security, or if they're window dressing.
Amazing work and another warning that Microtik remains subpar when it comes to security and doubly worrying because their strategy seems obfuscation rather than engaging the community.
It’s a shame because their hardware seems great for the price point (especially their point to point mmWave gear)
That's been my experience as well. Fantastic hardware value, but not great software.
And not just "insecure" libraries etc, just... strange design decisions. For example, SwitchOS doesn't allow configuration of a default gateway on the management interface, instead it just returns the request on whatever interface/vlan it gets it from. It leads to some very very strange behaviour when setting up firewall rules...
It's a shame, because the hardware is absolutely brilliant. I just wish they would open enough of their bootloader/hardware platform to allow 3rd party firmware to run easily.
Also, just the need to support two different OSes on the same hardware.
Network hardware should be rock solid appliances that live up to their specs on every front that I can just set and forget, and maybe occasionally need to do a security update. I shouldn't have to think of the pros and cons of one firmware choice over another, I don't have time for that crap.
Just make a fully-featured switch and fully-featured router and release them as such, instead of a crippled SwitchOS and crippled RouterOS, neither of which live up to the hardware's full potential.
What would a basic home Wi-Fi network with two access points, a router, and a switch look like? I attempted to figure this out since I wanted to set up a network with multiple VLANs to separate work machines, IOT devices, and trusted devices once I started working remote. I couldn't figure it out so just bought Ubiquity gear. They were the sweet spot for configurability with out spending weeks learning how to configure network equipment as far as I could tell.
I picked up a RB750 and a TP-Link AP several years back to enhance my networking knowledge. Took me several days of trial, error, and figuring out the right search terms to get a network like you described. I enjoyed the process but it's not for everyone.
But for about $130 the speed and stability blows away any equivalent-priced consumer technology with the added bonus of being much more configurable.
not allowing routing on the management interface is a big deal breaker for anyone trying to seperate their management networks from their revenue traffic.
This, including a couple of other issues, is keeping me from adapting mikrotik for anything more then a homelab.
I've been using it for about a year in a RBM11G for my home internet. it's been as stable as the Cradlepoint CBA750B it replaced. I reused the outdoor ABS box, still mounted on a 10ft steel pipe above my roof latitude 38 Eastern US, we get some pretty hot summers.
My answer here _used_ to be the Ubiquity Edgerouter-X series, but unfortunately Ubiquity has killed that line of products and they don't seem to be in the prosumer grade affordable router market anymore.
I still enjoy my little Edgerouter-X SFP, it's fast, compact, power efficient and I can plug my fiber internet connection straight into the SFP slot. Management can be done via SSH. What's not to like?
Edit: and yes, I know the edgerouters are still listed in the ubnt shop, but they have been 'sold out' for the past 3 years now. I don't think they'll ever return.
I would love to know as well, because I’ve been looking at MirkoTik as well. They are basically the only European manufacturer of network gear I’ve been able to find, for “consumers”.
I used to use MikroTik pretty extensively in the past (15y ago). My experience has always be that they are super solid. I even miss the time managing MT based networks.
I've bought three Protectli servers/routers and put OpenBSD on all of them with great success. (With coreboot!) I highly recommend taking a look at https://protectli.com/product-comparison/ though they do cost more than the microtik routers.
Another option if you don't need tremendous performance is https://pcengines.ch/ which also runs OpenBSD very well.
Is Draytek any good? I've just gotten their AX router as the first installment in a mesh home network - ultimate goal is to have separate VLANs for IOT vs core devices.
Immediate experience has been so so - the router kept rebooting every 12 hours - had to disable the AX interface and keep it wired only. WiFi is currently coming through a Netgear AC access point, which defeats the purpose of the system. I'm thinking if I should switch manufacturers before I get in too deep...
The article does not explain enough the implications for us mere mortals without high math/security knowledge. I think many people owning a Mikrotik device would want to know if:
1 - To what extent this makes Mikrotik hardware less secure? -> solutions?
2 - Does this make easier to flash open 3rd party Linux/BSD/whatever based firmware on said devices? -> suggestions?
I'm confused on why this is needed. I have a couple MikroTik devices and I just use SSH to login to them. I also have automation that runs via SSH to update things on the devices.
Can you explain "somewhat" reluctant? The forum seems to suggest you write an email to support. If that works (I haven't tried) it's not too bad. You have to register at many vendor sites to download something.
You also give a github link, but that's shared probably just same random github user, not by Microtik so there is even less evidence that it's complete.and correct.
Well this is downright scary. Homebrew crypto implementations, what could go wrong... I expect we'll see an exploit to log in with any password soon enough :).
It's "nearly identical" to an IEEE submission draft by a world renown cryptographer. While there could still be implementation issues, this isn't homebrew crypto.
One of these protocols, MAC-telnet, has been reverse-engineered pretty extensively previously. But, due to a (not unreasonable) security-related upgrade, the login phase was changed, and 3rd-party implementations stopped working. Mikrotik has refused repeated requests to document this protocol.
The linked repository looks like it may re-enable MAC-telnet logins, which would be great for 3rd-party scripts and management solutions.
(Why? Because it allows you to connect to, and properly provision, any Mikrotik gear using your own scripts, just based on Layer-2 presence. This is very cool for many use cases...)