Yes, because if you want set wifi or other interface that appear later because driver must be loaded, the script fail.
If is a simple thing, like set system identity, that not involve wait to load something, delay is not needed.
Shell script that SSHes into the device and applies the configuration.
Your SSH script will simply have to be modified to use netinstall-cli command line interface that reinstalls the device and applies your custom config. It is a change, but not that drastic
@everyone
Please stop being hypocrites.
Better security helps everyone.
Those who complain probably don’t know how to organize or do their job.
As long as the RouterBOARDs arrive from the distributors without the protected-routerboot active,
THOSE WHO WORK WITH IT can use NetInstall without problems to first do the software update to a consistent version,
and then set a default password that allows provisioning as before…
But if you’re doing NetInstall it can already be fed Branding and/or Configuration Script in one pass.
SPOILER: And then it will soon be possible to use RouterOS 7.10 to use NetInstall directly on RouterOS (and with Container it can already be done)
“Convenience is the worst factor for securing systems”
I understand it may create some “friction” with the new way of doing but it is not such a big issue when you adapt the process (as indicated, netinstall or branding package).
And let’s face it, most of the devices which are being complained about in this thread, ARE by far home-use devices.
Don’t count on a home user to set a decent default password. Just don’t.
Better prepare in advance, than suffer when it’s too late.
Imagine even if there is no legislation. How about just for sake of basic security?
A scenario where you purchase a device that has nice default config. You plug in your ISP and your internet works (because DHCP client and default NAT, you don’t even need to log in once). So you plug it in and leave it. Then a malware in your Windows PC scans the LAN and supplies some malicious config on your router, as there is no password. And then imagine this on a million devices.
So … better safe than sorry.
Please, Please, Please, NEVER activate protected-routerboot on default batch!!!
Btw you can boot into cap mode and work as usual.
Is not easy as “press the button until netinstall start”… (And not all devices are CAP clients…)
any router can be booted into cap mode, especially the ones that have defconf with a password.
I know, but is better for the installer the concept “press until not appear” than count exactly 10 seconds (or check if LED turns solid on brighter environment)…
And in any case when connected to the capsman, the server do not change (or create) username and the “label” password and other needed parameters…
I am wrong?
Try to put one RB5009 as CAPsMAN client…
I am quite happy that MikroTik finally does something about the “blank password”, but I am a bit worried by the text in the newsletter:
Contact your MikroTik distributor if you lost access to the stickers and need help finding the default
password. We’ve provided tools for distributors to assist you in such a case.
Hopefully the default password is really a unique password stored in the device, and not something derived from e.g. the MAC address via some “super secret function”.
Experience with many other manufacturers that implemented this before, the “super secret function” will invariably leak, and tools like what you supplied to the distributor will become available for everyone.
(of course it could be that the tool for distributors does a query at some service at MikroTik, and we can hope that access to that service will be well-secured)
3 considerations:
-
If you do protected-routerboot, no matter if you have or not “sticker” or ask distributor for password.
-
For sure end user can consider “sticker” password sure, and do not change it, and if (can happen) the database (or algorythm) of passwords are steal…
-
Probably the password is based on NAND / Flash serial number (is not the device serial number). Impossible to obtain directly wih standard way.
For retrieve password from the distributor probably you must provide device serial number, and the password is with the serial number…
The password is unique and random, but we do have it in a database in readable form (I mean, this is still better than blank). You can’t guess it, but you will need to change it anyway.
That’s okay, it’s the right way to do it.
Surely it’s more secure than a blank password…
And then, if the protected-routerboot is not active by default, it is easy for those who have to develop a network to configure the devices…
There is no way it will be default. We might even remove this funcion, since some people manage to lock their device irreversibly
Why not restore that function as in the initial version?:
When you press the button for the exact right number of seconds, wipe the config (except licence) and you can do netinstall for restore damaged OS,
or keeping it pressed for 10 minutes format all NAND/Flash (wipe the config except licence) and require netinstall…
The differencies between the X seconds and the 10 minute timeout is just for prevent the accidetal (…???..) reset of the router config by end user…
On this old way it was perfect…
protected-routerboot feature are used for WISP not for protect from physical stealing the device but:
- Hide the config (keys, cert, etc.) from the other competitors or to the end user…
- Prevent the user from resetting the router like the crap competitors.
There will be videos coming up on this “feature”. As a note, thanks to a post here I would never have gotten into my AX3. I normally thrown away any silly paperwork in the box and just access the router and start working on it. Hence I had no clue about a pull-out tab LOL.
The problem is that this protection feature has too many goals:
- to protect against viewing of the configuration that includes secrets
- to protect against reset of the configuration by a customer, losing the connection and requiring technician visit to fix it
- to protect against stealing of the device and re-use for another purpose
The first two are “easy” to achieve using the timed button press tricks, but when the last one is also included it will lead to inadvertent permanent locks…
Maybe that function could be optional and be part of a branding package. Normal users would not be able to lock their device but those WISPs that are in an environment where this is an issue could still enable it via their branding package.
Of course that assumes that normal users are not going to play with branding packages…
As a matter of fact, it is also mentioned in Quick guide on the website.
Even with a picture where the tab is with the sticker.
https://help.mikrotik.com/docs/pages/viewpage.action?pageId=110362626
I guess you don’t read those guides either ?