I installed V7.1.1 on my personal RB4011 today. I was very disappointed to see that routeros is now one large, single package. I would have liked to retain the V6 ability to disable unused packages. For example, the wireless and hotspot packages on devices with no radios, ipv6, mpls and routing.
I hope that this becomes possible again in the future and if not, an explanation as to why this was changed would be appreciated.
With many things, if you don’t enable them, all they do is eating some disk space. I’d understand the poor souls with 16MB storage devices, but why do you worry about it, when yours has half a gigabyte? 
More seriously, I like separate packages too, but they may create dependencies that need to be dealt with, system may behave differently depending on what’s installed, etc. For example, “security” depends on “dhcp” for a while already, because some IPSec configs use DHCP. Or I can imagine that e.g. IPv6 is so deeply integrated in the system that having it as separate package and supporting both cases, when it is and isn’t present, is simply too much work and it’s not worth it.
On the other hand, I’m sure that there are independent things that could be easily taken out and made into separate packages, because nothing else depends on them. Question is how much it’s worth it. If it would save a megabyte or more, it could help 16MB devices. But if it’s just few tens of kilobytes, it’s not that great.
+1
Many devices require netinstall
IPv6 can be disabled from /ipv6 settings menu. MPLS, DHCP, hotspot, and dynamic routing protocols must be explicitly configured to make them work. None of these features work by default.
But…
Even though hotspot is not active on my maplite, there is a default server config which I can not delete.
Lots of files under flash hotspot but that could be a left over from an earlier trial.
They do have the date of the recent upgrade though.
Why change those files if that module is not active ?
Is considered “best practice” to uninstall/disable unused features.
This is even stated by the German BSI, Bundesamt für Sicherheit in der Informationstechnik (Federal Office for Information Security).
With your step (everything always enabled), we cannot comply anymore with the BSI-recommendation with ROSv7. Which makes it hard to keep/using Mikrotik products.
In my opinion this was a BIG design flaw! One of the ugliest things are enabled but unused features (which one-one cares about). This is a REAL security risk!!
Installed yet disabled is the same as not used.
No ?
That’s not " always enabled", not by a long shot.
But, mentioned features are not enabled by default, you have to explicitly configure to make one or another feature to work. So it still complies with BSI statement “to uninstall/disable unused features”.
That seems not to be entirely true. It can be seen that e.g. even when no dynamic routing protocol is configured, some of their processes run in the background.
This can be seen from the log:
09:15:52 route,rpki,debug stats roas 0 roa 0 nodes4 0 nodes6 0
09:15:54 route,debug,calc 1.3.3 Loading new prefix values
09:15:54 route,debug,calc 3 Main publish
09:15:55 route,rpki,debug wipe stats roas 0 roa 0 nodes4 0 nodes6 0
09:15:59 route,debug,calc 1.3.1 Tag updated routes for merging
09:15:59 route,debug,calc 1.3.3 Loading new prefix values
09:15:59 route,debug,calc 1.3.4 Merge route updates
09:15:59 route,debug,calc 2.2 Merge forwarding path updates
09:15:59 route,debug,calc 3 Main publish
09:15:59 route,debug,calc 6.1 Cleanup merge
09:15:59 route,debug,calc 1.3.1 Tag updated routes for merging
09:15:59 route,debug,calc 1.3.3 Loading new prefix values
09:15:59 route,debug,calc 1.3.4 Merge route updates
09:15:59 route,debug,calc 2.2 Merge forwarding path updates
09:15:59 route,debug,calc Prepare queued LINK/%*7/10-5/0/SRC192.168.188.1%*7
09:15:59 route,debug,calc Set initial reachability for interface LINK/%*7/10-5/0/SRC192.168.188.1%*7
09:15:59 route,debug,calc Apply reachability to LINK/%*7/10-5/0/SRC192.168.188.1%*7
09:15:59 route,debug,calc Resolving LINK/%*7/10-5/0/SRC192.168.188.1%*7
09:15:59 route,debug,calc 3 Main publish
09:15:59 route,debug,calc 6.1 Cleanup merge
09:16:01 route,debug,calc 1.3.1 Tag updated routes for merging
09:16:01 route,debug,calc 1.3.3 Loading new prefix values
09:16:01 route,debug,calc 1.3.4 Merge route updates
09:16:01 route,debug,calc 2.2 Merge forwarding path updates
09:16:01 route,debug,calc 3 Main publish
09:16:01 route,debug,calc 6.1 Cleanup merge
09:16:03 route,debug,calc 1.3.1 Tag updated routes for merging
09:16:03 route,debug,calc 1.3.4 Merge route updates
09:16:03 route,debug,calc 2.2 Merge forwarding path updates
09:16:03 route,debug,calc 3 Main publish
09:16:03 route,debug,calc 6.1 Cleanup merge
09:16:07 route,debug,calc 1.3.1 Tag updated routes for merging
09:16:07 route,debug,calc 1.3.4 Merge route updates
09:16:07 route,debug,calc 2.2 Merge forwarding path updates
09:16:07 route,debug,calc 3 Main publish
09:16:07 route,debug,calc 6.1 Cleanup merge
09:16:07 route,debug,calc 1.3.1 Tag updated routes for merging
09:16:07 route,debug,calc 1.3.4 Merge route updates
09:16:07 route,debug,calc 2.2 Merge forwarding path updates
09:16:07 route,debug,calc 3 Main publish
09:16:07 route,debug,calc 6.1 Cleanup merge
09:16:07 route,debug,calc 1.3.1 Tag updated routes for merging
09:16:07 route,debug,calc 1.3.4 Merge route updates
09:16:07 route,debug,calc 2.2 Merge forwarding path updates
09:16:07 route,debug,calc Prepare queued IP/192.168.128.1/30-10/0
09:16:07 route,debug,calc Resolving IP/192.168.128.1/30-10/0
09:16:07 route,debug,calc 3 Main publish
09:16:07 route,debug,calc 6.1 Cleanup merge
09:16:07 route,debug,calc 1.3.1 Tag updated routes for merging
09:16:07 route,debug,calc 1.3.3 Loading new prefix values
09:16:07 route,debug,calc 1.3.4 Merge route updates
09:16:07 route,debug,calc Need to update fwp link IP/192.168.128.1/30-10/0 via 192.168.128.0/24->LINK/%*1/10-5/0/SRC192.168.128.2%*1 FLD{0}
09:16:07 route,debug,calc 2.2 Merge forwarding path updates
09:16:07 route,debug,calc Prepare queued LINK/%*1/10-5/0/SRC192.168.128.2%*1
09:16:07 route,debug,calc Queue recursively updated IP/192.168.128.1/30-10/0
09:16:07 route,debug,calc Prepare queued IP/192.168.128.1/30-10/0
09:16:07 route,debug,calc Set initial reachability for interface LINK/%*1/10-5/0/SRC192.168.128.2%*1
09:16:07 route,debug,calc Apply reachability to LINK/%*1/10-5/0/SRC192.168.128.2%*1
09:16:07 route,debug,calc Propagate reachability for IP/192.168.128.1/30-10/0
09:16:07 route,debug,calc Apply reachability to IP/192.168.128.1/30-10/0
09:16:07 route,debug,calc Resolving LINK/%*1/10-5/0/SRC192.168.128.2%*1
09:16:07 route,debug,calc Resolving IP/192.168.128.1/30-10/0
09:16:07 route,debug,calc Resolved link IP/192.168.128.1/30-10/0 via 192.168.128.0/24->LINK/%*1/10-5/0/SRC192.168.128.2%*1 FLD{1} tr has metric BEST/24
09:16:07 route,debug,calc 3 Main publish
09:16:07 route,debug,calc 6.1 Cleanup merge
calc
topis shoud log routing calculation. Is any calculation done for static routing configuration?
So they are considered as disabled if you do not configure them ?
The features that are potentially a security risk (or at least most of them) can be disabled by using the new device-mode setting and changing the mode from “enterprise” to “home”. This disables hotspot, socks proxy, and other functionality that is being exploited by the Maris botnet.
It probably wouldn’t save anything - it probably would take up even more space. The RouterOS v6 bundle package is larger than the RouterOS v7 monolithic package, due in part to the extra headers needed to create the “sub-packages” and allow enabling and disabling of those, and probably also there were some checks that they could remove in v7 (ex. they could get rid of “if IPv6 is also installed, do this, else do this” because IPv6 is always guaranteed to be there).
I suspect if they tried to go back to a bundle package in v7 emulating the v6 design, the added space from the headers and those extra checks would be large enough that it would no longer work on 16MB flash devices at all.
As someone who uses IPv6 all the time, it has also been frustrating to find it does not work with certain features in RouterOS v6, presumably to save them from having to code in extra checks to see whether that package is installed or not. So I personally like this move to a monolithic package as it increases the likelihood of other add on features supporting things like IPv6 because they are guaranteed to be there instead of optional.
Because with all things, there’s a little thing called bugs. What do you think happens when 7.10 “long term” is released, 5 years in the future from now, with a fatal flaw in SMB, socks, web-proxy, take-your-pick, and all tiks on the internet, all of a sudden is vulnerable? But yes - a critical core router, needs a samba server… Or a socks proxy, Or a HTTP proxy…
MT needs to draw a CLEAR line, between a SOHO package, and a ENTERPRISE package.
I won’t fight too hard for SMB. And for the record, I do like packages and ability to choose what I install. But let’s be fair, if it’s done as anyone would expect it to be, i.e. it’s separate executable that can be started or not, and if not (when not enabled), then it just lies there and does nothing except taking up some disk space, it can hardly do any harm.
In fairness, they do have /system/device-mode, that in fact does make this “home”/“enterprise” distinction.
Totally agree that, yes more packages be better. But that may just not be easy with dependency (see @Sob’s comments), and does seem new V7 feature are packages (zeroteir, wifiwave2, containers) so I’ve come to accept V6 features are now just one package.
But being able to definitively remove a feature certainly has been somewhat lost. The Mêris attack vectors are covered by /system/device-mode that so prevent them from being enabled (without hardware access). But even that doesn’t let you disable other features that could be used in a similar attack (e.g. compromised admin password) using a different set of protocols/“features”. Again doesn’t solve unused code causing potential bugs/vulnerabilitiese, but also having multiple packages with complex dependencies may also be a source potential future bugs too…
Still generally prefer to remove as much unneeded code, NOT just config, as possible. Given I don’t think Mikrotik is going to reintroduce the separate packages anytime soon… So I’d take an expansion of /system/device-mode that be able to control a wider set of protocol/features, as at least another layer of security.