Not sure if you are just trolling but here you are : Securing your router - RouterOS - MikroTik Documentation
“ Keep your device up to date, to be sure it is secure.”
3 Likes
That does not say always update your device to latest version because those latest versions can introduce new bugs, as @strods said in his reply, and link also suggests that you follow security announcement blog if you are worried about security as you should be...
And blindly updating RouterOS expecting that just for this reason you would be secure may just give you false sense of safety while you forget to protect your network by firewall for example, or you could become exposed to some new and unknown security issue in the latest version...
If you are too lazy to check all the changelogs and blogs reasonable update policy would probably be to wait for minor version 7.x.2 or later because by that time most of outstanding issues would be fixed...
1 Like
Nobody is able to know beforehand how many minor versions each release will have until next (non-minor) version is released. Therefore safest bet would be to update to latest minor version of previous version. That's why "previous-stable" would be good addition to release channels if we do not have long-term channel on v7 (yet).
Without this only way to do "not-latest/previous-stable" updates is do it manually by uploading npk's. Mikrotik does not want to make it easier to us but wants to have more users as latest version testers - one of the ways to keep development efficient is "partial outsourcing" (at least what comes to testing).
3 Likes
I think from reading of suggestions here. I now understand that in Mikrotik or maybe at least some Mikrotik users deals with versioning Major.Minor.BugFix (eg. 7.19.4) in way (not strictly):
For Stable channel:
Major = Stable - main OS release
Minor = Stable - should update
BugFix = Release Candidate - update carefully, can bring some problems
And than we have Beta channel, and Testing channel which are even less stable than BugFix version in Stable channel.
I personally would prefer if Mikrotik did more releases on Beta / Testing channels and then did releases to Stable channel when they are confident that it is suitable for everybody. Or when there are critical CVE fixed. And to do staged releases if they are not confident to release it to everyone at same time even when in Stable channel. In similar manner that many of IT companies do IT. But I guess it is their way and we can only silently agree to it.
But I see we will get into circles in this topic, obviously everybody has some point of view to this topic, I see lot of them to make sense in the way they are presented. Obviously I expect something different under Stable release and suggestion in help page "Keep your device up to date" than others do. I will refrain from further comments to prevent spamming this thread about issues with current release 7.19.4.
1 Like
But MT is already doing it, there are 4 stages:
- nightly build
- (beta) testing
- stable
- long-term
The only problem is that with ROS v7, stage #4 is missing. And stage #1 is not option to be chosen when configuring a particular device.
And every user has freedom to choose in which stage (s)he wants to receive updates/upgrades (if I'm not much mistaken, default is stable now days).
So yes, you're right, everybody has some point of view to this topic 
1 Like
There is no standard "automatic" upgrade procedure, only some examples of how you could write a script to do them. And there is no suitable channel for automatic upgrades either. So in practice the only time upgrades are done is when the admin selects it while logged in. For mass-deployed devices (e.g. supplied by an ISP) that is usually "never" (unless the ISP has pre-configured a script or uses TR-069)
As an ISP, after OBVIOUSLY running several MONTHLY tests on a group of devices,
when it's time to "almost" mass update the devices,
the file is downloaded from my server, not the MikroTik server,
to ensure that the file is the same, hasn't been removed or replaced, and that the server is online.
Except if you're using MikroTik in any enterprise type environment or have SOC requirements...... update to fix any patched CVE's.
This is nonsensical reply from MikroTik.. suggesting users to "NOT upgrade" their routers. Okay fine, so you want your customers to stay on v6? Good grief..
Yeah, v6 is working - head in the sand, everything is fine mindset. How many customers of MIkroTik are still running v6 with un-patched exploits? Does MikroTik even have stats on this?
Sigh.. This goes back to the notion of MikroTik catering to all spectrums of networking vertical; trying to be consumer/PROSUMER and enterprise. Consumer type [home users] do not give a crap about patching exploits, as long as their internet and wireless is working [and appropriate speeds].
For us prosumers, MSP,ISP,WISP and those have MikroTik hardware deployed in business or enterprise environments; yes - time will be taken to review change logs and revision history for bug fixes and CVE patches......................regular system/network administration duties.
MikroTik should leave the consumer home market with this notion; lets not update your router if aint broke mentality....
v6 is still maintained with security and quality updates, just not with feature upgrades.
2 Likes
yes, Correct. But the notion or suggestion from MikroTik staff saying "dont upgrade if aint broken" its a terrible point of view. Sure, its a general saying - but not in networking world with the constant eb and flow of exploits.
How many unpatched MikroTik's running v6 with the open exploits are in the wild.... This is terrible security practice and mindset by MikroTik. Exactly why we've been seeking greener pastures, and why we feel their development and state of technology is where it is today.....
Yes, I am flustered and triggered by the post @strods mentioned for maintaining MikroTik equipment, or perhaps the reply is/was being taken out of context.
My passion for MikroTik runs deep, but we have to remove our rose colored glasses.
Unsure if they feel it now, or how their sales are [consumer hAP]. But the consumer hardware market has zero margin and is more problem and headache for them in our opinion. Overly complex configuration for regular user, not unless using mobile app or web based config. Also other consumer based hardware will self-update after initial setup....... to get on a current firmware to fix any potential exploits, bugs since initial HW release.....
2 Likes
Had a first example today of an ancient hAP lite not having enough free storage. Deleted everything out of files and it managed to update... guess time to consider replacement. Upgraded some other kit today and was pleasantly surprised that it only need two reboots - first upgrade to latest v6.x and then just one update to latest v7.x, not two.
Rule #10:
'nuff said.
and third one for the firmware
Is the firmware dependant on the RoS version? Isn't it more like a mainboard BIOS, in the sense that it affects hardware, but makes (usually) no difference to the OS?
Yes, Mikrotik insists on versioning it like the OS (big mistake), but it's cosmetic.
1 Like
Indeed I always use the parent.vlan## naming scheme for VLAN subinterfaces and would appreciate it when that would be the default name when adding one.
I also do not change interface names but rather add such info to "comment". It seems that many users do not know about comments, maybe caused by the confusing user interface they have.
2 Likes
I don't think this renaming feature is a bad thing. In fact, I think it's powerful and excellent!
I just think it could be better semi-curated.
Something like leaving the bike with training wheels installed... and with the ability to remove them if the operator so desires.
Yes, I have that enabled along with "use-bfd=yes" for both OSPF and BGP.
Comments are manageable trough winbox, but make life hell when using the CLI
I have SUP-196740 referencing Print proplist=!comment
basically, asking for consistent behaviour regarding comments:
Either it be a parameter in the last column of table-view (respecting "proplist" syntax)
or at least permit the supression of comments (as they break table-view in CLI)
Yeah, I don't like the move of comment from last to first column either. In winbox3 it was either separate line (I think for legacy reasons) or last column, and I always have that set to last column ("inline comments").
Now with winbox4 I need to first make the comments visible and then move the column to the end...
Worst is that this layout storage has been made inaccessible (a binary blob instead of a JSON format) so I cannot write a script to fix a set of workspace files either...
In the past I sometimes renamed interfaces but I always have chosen a "originalname-purpose" format, i.e. only appended a - and some text to the original name. I quickly learned that having spaces in interface names is inconvenient when entering commands or processing them in external scripts (just like spaces in filenames).
With a couple of changes, everything could be a lot more convenient.
