With 7.17 specifically, “:convert from=num to=raw” adds converting from an ASCII code, into a letter (among other uses). Combined with “inkey” to collect a single character but returns a numeric (“num”) ASCII code, so if you want to match on a letter, it’s much shorter now.
:put "Press 'y' to continue, or any other key to abort"
:if ( [:convert from=num to=raw [/terminal/inkey]] != "y" ) do={ :error "script stopped by user" }
# more code after 'y' key ...
In regards to have a “more advanced” DNS service in a separate package is not a bad idea at all, I like it!!
Actually there are a lot of features missing in the DNS service that could be addressed. Users who don’t need additional features could stick to the integrated basic DNS service.
additionally, splitting up services / make services more modular would be a great feature anyways. put smb, dlna, mpls, proxy and so on into separate packages like wireless, wifi-qcom(-ac) or rose.
this even helps saving storage footprint and modules which need to get loaded at bootup!
That might have some truth in it - some devices are so stupid that they “resolve” loss of their IP address configuration by disconnecting from wifi network.
An option in /system routerboard that will be available for 24 hours since upgrade/since first boot/since running a command confirmed with button press/since running a command confirmed with power cycle, that will return a random 16 character string, that will also be permanently written to the device. This random 16 character string may then be used to authorize restricted operations remotely. What’s wrong with this? Why can’t we have good things?
i operate hundreds of devices in multiple locations and several countries as an external consultant, some features that will be blocked in 7.17 i use it frecuently so i will have to stay on 7.16 because of this extreme measures
i use traffic gen on a daily basis for performance testing and bandwidth validation i will have to stay on 7.16 because of this being disabled on 7.17, is very expensive to move personel to every site at off peak hours, paying hotel, etc, to do this upgrades and do the procedure to activate this features on production equipment
Another option would be to have a token that can be user settable for say 30 minutes after initial upgrade to v7.17 or first power on if already 7.17+. After that period of time you would need to set a flag and power cycle or reset the device to allow the token to be set again. Once the token is set to nvram the only way to change it would be set a flag and power cycle or reset. This covers someone downgrading and upgrading again to get the 30 minute window (if the user had allowed that already).
Having a user settable token is much easier for enterprises/businesses to handle as they can standardise it.
If you are concerned this could lead to poor token complexity you could have a command to generate a token, have a checksum in the token to ensure its a generated random token. Then only allow ‘generated’ tokens to be set. The admin would generate a token on one device and use that securely generated token across all devices. Simple as hashSha256(‘someRandomStringThatOnlyMTknows’ | <32 byte random array>) and taking the last 8 bytes of the hash as the ‘checksum’, then take the combined (in any way you wish) 40 byte result mime encode and present to the user. A secure string that is highly probable to be MT generated and is random and secure with 256 bit strength.
This would allow enterprises to manage their upgrade to 7.17, set a highly secure key that when used would allow the admin to change options without power cycle or reset.
It allows for flexibility as to how the enterprise wants to manage the key(s). They could generate a key, set it and record it (encrypted) against the devices base MAC in a database somewhere on a per device basis.
They could generate a key to be used on a group of devices and record that in a password manager.
I appreciate the need for MT to secure these devices and it is great they are working on options to do it. I also fully agree that this needs to be manageable by IT teams, and especially the transition.
I hope MT takes onboard this approach, and turn this in to a win for everyone.
Mikrotik won’t adopt this approach. The introduced the “downgrade” flag so an attacker can not downgrade to an insecure ROS version.
In the proposed case of token within 30minutes of initial upgrade to 7.17, the pitfalls are clear:
attacker gains access to device running < 7.17 somehow. Hits upgrade button; the token is presented to the attacker. Now the attacker can enable “downgrade” flag, enable e.g. “scheduler” or whatever device mode property that was previously disabled. Finally downgrade to previous ROS version. An admin without remote logging or remote uptime checks would notice that. It would only take some minutes for upgrade and downgrade again.
Or an attacker that does not want to “sneak into” but wants to make your life hard: Hits upgrade button, knows the token now and sets device-mode to “home”. Now you have a “dumb” device instead of your previously full fledged router.
Would be a pretty effort to reset such a device to “advanced” mode again. It would not just involve netinstall, additionally some power cycle or button presses.
But I must admit: it is the best alternative approach suggestion so far. But it has this major pitfall.
I must add that this device-mode change was not thought enough in advance, but pushed on us users in some sort of “let’s see if anybody would complain” way. Luckily, it’s only in beta, so it should be easy to go back and think things over.
You (Mikrotik) are asking us (users) about “Device Controller” that is not even on horizon (and that most don’t care about because they have already got things under control), but did not bother to ask about “security” feature that WILL affect (in most negative way - by hitting their wallets) everyone already using MT devices unless they decide to never update past 7.16 (so bye-bye to “lifetime updates”).
PLEASE make this completely optional, let us know that it exists and that we CAN lock-down the devices we WANT to, even remind us every time like with default passwords if you must, but don’t force this on us!
Mikrotik will now either try (again) to make case that “nothing will change for devices that are already set up” - which is highly questionable (except when you do not use features to be locked out) or will be just ignoring this specific issue here.
I see no other solution than to activate the new device mode defaults only for factory-new devices. Unless someone has a really secure alternative to that power-off/button-press thing that can confirm changes without physical access.
And one reminder: only a few are reading/following beta topics. This discussion will go through the roof - if really introduced in stable version.
@infabo, I like how you think, but we need to find a suitable path forward. The pitfall, I guess falls into the “you can’t trust a compromised device/pc/mac/toaster” category. You should netinstall such a device or ‘recycle it’ (rubbish bin).
(A possible workaround would be to only allow the ‘devicekey’ to be set in that 30 minute window via api/ssh/console/web but not a scheduled script. This would make it much harder for the attacker to maintain their foothold via a scheduled script - yes I can see ways around this too, but again its a compromised device to begin with trust = zero, but we can make them work harder for it, and since the ‘door’ is already open you probably have much bigger issues inside your network now than power cycling a device! Ransomware/wiper/multiple footholds bell ringing…).
If after upgrading you find you can’t set the device key because it has already been set, that should set alarm bells ringing too. Again easy for an enterprise/ISP, they upgrade a device via api/ssh, wait for it to come back online, using api/ssh set the device key, failure to set results in a flagged device. Quarantine/bin.
The point of what I am proposing is to enable enterprises/ISPs to maintain their devices securely and remotely. Again, I am aiming for the win-win if possible. There are probably variations of what I am suggesting, but this fits into what most enterprises/ISPs could easily manage and keeps a very high degree of security by enforcing a strong random ‘deviceKey’.
We already do. We manage over 7 thousand routers, have daily backups of configuration of each. Adding one more string to the database should take one man-hour with testing by my estimates +/- 30 min.