Just intercept routerboard traffic and provide fake webserver, dns, ip. Test already done successfully.
Try integrate website certs and check https before download from update. Tested on previous 7.12 versions.
I do not know if 7.13+ / 7.17 check website certs before download/connect.
I can’t find the right words to express myself, I’m not a native speaker, the idea is that other users would say to you
You and the others staff members possibly can’t understand that the devices are not all mounted in the same room,
but are installed hundreds of kilometers away, and are often on pylons or in places that are difficult to reach normally???
What do you think that all the devices are mounted inside an office???
That’s not true, RouterOS itself checks package integrity, checksum and allowed version. It does not matter where package came from, it will not be installed.
rextended, is it a language barrier also, that makes you not understand that already installed devices are not changed by this? and new devices you are configuring before mounting on the tower.
about downgrades, there is ZERO logical reason to knowingly downgrade to a version with a known CVE, possibly allowing easy access to the device by a hacker. Zero. Do not try to find it.
already installed devices are not changed by this?
So if I understand wrongly, how come to me and other people on the forum it seems CLEARLY that it says that after upgrade traffic-gen, partition (command “repartition”), routerboard and install-any-version features will be disabled
It says clearly: after upgrade features will be disabled. So where did I misunderstand?
I wrote what I had to write.
Now I will wait at the pass for the results of the MikroTik choices such as protected-routerboot and all the various consequences.
The real question is: how many people - in teh real world - rely on traffic-gen, re-partition and downgrade to insecure ROS versions with known security vulnerabilities? Ok, the routerboot settings thing may be an issue for someone. But tbh: if you have the regular need to mess around with routerboard settings then I think your environment is flawed.
@infabo
Is not a point on traffic-gen or repartition.
I, for first, have never spoken of install insecure versions of RouterOS.
It means installing a previous version of RouterOS, which perhaps does not have the bugs of the next version, as often happens.
No matter how many tests you do in the lab, things can be different in production…
Can happen that I remote netinstall devices with some problems caused for various reasons, and I use routerboard menu for that, obviously.
On routerboard, there is an important thing to be taken into account… upgrade or autoupgrade FW to latest version.
There have been quite a bit of fixes lately where this upgrade was needed for some corrections to work afterwards.
E.g.
*) ethernet - improved linking after reboot for hAP ax lite devices (“/system routerboard upgrade” required);
*) routerboot - fixed boot MAC for devices with Alpine CPU (“/system routerboard upgrade” required);
*) routerboot - fixed boot MAC for MIPSBE CRS3xx and CRS5xx switches (“/system routerboard upgrade” required);
*) routerboot - improved stability for IPQ8072 and IPQ6010 when flash-boot is used (“/system routerboard upgrade” required);
*) sfp - improved initialization for certain SFP modules on CRS309 and CRS317 devices (“/system routerboard upgrade” required);
Default device mode = advanced, routerboard is set to disabled.
Manual upgrade is still possible as of now BUT I’ve seen a response to a bug ticket this will be prevented later on.
Setting auto-upgrade is not possible without first changing device mode settings.
How would this be done then for all devices already in the wild ??
That presents a real problem, isn’t it ?
“routerboard” restricts “system routerboard settings”. “system routerboard upgrade” is still possible even with this flag enabled. so no need to worry at all.
The problem was that with 7.17b4, after changing device mode to advanced, routerboard settings could be changed without first changing that setting (it was “yes” without doing anything).
It seems that part has been “corrected” (7.17rc1, maybe already with b6 ? Didn’t check).
You first need to change that part now before you can proceed (but that requires again a press of a button or power toggle).
So manual upgrade remains to be possible indeed.
Still a problem but less invasive.
I don’t want to get into the whole war, but sometimes I have found it useful to set cpu frequency to non-auto values. I don’t think that it would have security implications to allow this without any special mode settings.
(My reason for setting non-auto rates is that I have seen TCP “oscillations” on rb5009 devices, where a starting TCP stream gets lost packets on 350MHz before the cpu can ramp up the frequency, lowers transmission rate, the cpu dials back the frequency again and so on.)
install-any-version it’s misleading, it should be install-unsecure-version
For what I understand till now, 7.17rc has internal databases of compromised versions that do not accept to downgrade.
So far, all good and correct.
But how does it work with versions that are NOT in the database of compromised versions? Read this text on doc:
This list can be updated to versions which includes some major changes in RouterOS below which downgrade should not be allowed.
Simply someone do not want you to downgrade to a SECURE working version once you install some version that have major changes but later is unexpected unstable…
This means that those who produce RouterOS feel like God and are immune to errors.
Isn’t it enough for them to have the example that twice, for two versions of WinBox,
it had to be downloaded manually because the update was not recognized???
Sooner or later it happens that they make some similar error and RouterOS can no longer be updated to any version due to some internal error.
So someone will have to travel a few kilometers to press the button…
And maybe urgently because the unupgradeable version contains some security bugs…
Again, in light of what I learned today, after the misinterpretation, and the apology for it,
I have nothing more to add on that.
We dont know. I assume this info about insecure version is hardcoded into ROS main package. But this would make no sense TBH (as some devices may not be updated regularly). A check against an external database would make more sense somehow. But what if intruder of network blocks or redirects these remote database requests to own fake-service? ok, responses could be signed so ROS only accepts trusted data. But intruder could still block outgoing requests to the database, so ROS wont be able to update its “insecure version” list.
The device-mode itself carrying a lot of possibilities of deadlocks. Like install-any-version, flagged, etc. What if I enabling all of the needed features, then something happens and flagged activating and disables the escape possibilities, or if I upgrade some production routers to a stable but buggy version and need to downgrade to a previous stable version which is marked as insecure by MTik, but that is the version where the bug is not “implemented” in and we could operating stable on…and opening a ticket which is never answered
Simply there is no way to physically access all (thousands) of our CPE routers. I was bravely says that to my company to change to MTik devices until 7.17. Now? I tell him DON’T, as MTik implemented a “how to make a brick” function. It is not funny if we need to send our engineers to all sites where MTik routers bricked itselves. It is also a shame if we need to call these site to unpower the whole cabinet to surefully reactivating the internet service.
I understand and accept that security is important, but it is not too elegant to pass the poop to the customers, and stubbornly cling to it.
