Default Configuration Privacy

RouterOS General
1

If I flash a custom default configuration to a Mikrotik device using NetInstall, is that custom configuration reasonably private? Is it acceptable practice to put the admin password on it this way or to add certificate private keys or other sensitive information/credentials?

By “reasonably private” I mean let’s ignore the possibility of someone soldering some kind of mod chip on the motherboard or an incredibly advanced attack that requires access to the hardware.

I apologize if this has already been answered, but I have been searching for a couple days now and cannot find it.

2

This is basically applying a config as part of the install, so no different than manual configuration. As long as there is a strong admin password then only physical access or an exploit will be able to discover the config.

3

So someone with admin or console access to the device can dump out the configuration? I was hoping the answer was no, that it was treated like passwords where, once it’s on there, you can’t see the custom default script.

4

When you have admin access (i.e. when you have the router password) you can see both the actual and the default configuration.
I would not know of any router where that is not the case.
Anyone with router access can print the default configuration script using:
/system default-configuration print
and of course they can see the current configuration using:
/export

5

At least /export doesn’t dump out any private keys or passwords though. I was hoping once you flashed a custom default configuration on there, it was impossible to dump it back out to the command line in its entirety because that might have some pretty sensitive stuff in there. I have my answer, but I do find this pretty disappointing. Thanks for your help though!

6

Export skipping keys and stuff is not exactly advantage, it’s major shortcoming, even though for your use case it could be seen as good. But it won’t save you, because backup should contain everything, and it can be restored elsewhere.

7

Export skipping keys and stuff is not exactly advantage, it’s major shortcoming

I really can’t think of a scenario where this is a shortcoming other than you lost your private key or password and need to recover it. Is it so you can /export and copy the config to other devices? Seems like you could add it to the script yourself. You should have the key elsewhere, right? You could append it to the end of an export if you really needed it to transfer it somewhere else.

Sure you could take a backup, but it’s kind of an all or nothing proposition as far as I know. I mean, maybe someone has reverse-engineered the backup format, but it’s not like you can open it in notepad and see the keys or passwords in it (I hope).

Maybe I’m being naïve, but it seems like the ability to export a custom default config, possibly containing sensitive information is a major shortcoming.

Oh well, it is what it is.

8

We clearly have different goals. I don’t like current backup, because the result is just binary file, which you can restore to same device and that’s it. Only same model devices are officially supported, and I’m not sure about compatibility between different RouterOS versions. You can’t even see what’s inside, compare differences between two backups, nothing. This is what I really hate about it. Readable export is so much better, except for the missing parts. In most cases I currently don’t use RouterOS to manage certificates and keys, so I do have them elsewhere. But sometimes it would be handy to use RouterOS to create them and still have convenient backups.

As I see it, if it’s there, it should be exportable (subject to user’s permissions of course). Current export is strangely selective. You can say that for example IP address is a little different from private key. But they are both important. And what about IPSec secret (pre-shared key) and IPSec key (RSA)? They are on same level and yet one is exported and the other isn’t. That’s very convenient example for me. :slight_smile:

And security-wise, backup does contain keys. They don’t seem to be directly readable (even in unencrypted backup), but the format must be reversible, in order to be able to import it back. Which is exactly what you can do, import it to any other device and get everything. It won’t work if you somehow get random encrypted backup, but if you’re admin user who can create one, no problem. Although in that case (being admin), you don’t even need to bother, you can just export whatever is in running system.

But our goals don’t necessarily conflict. If export could contain everything, only admin users would get sensive parts like keys. In any case, you can’t let untrusted admin users in, because when default config is also current config, they can export anything. So your problem is when someone resets the router, becomes admin and can see default config. I don’t hard-reset routers very often, so right now I’m not sure how it works with default configuration, i.e. if I can get equivalent of “/system reset-configuration no-defaults=yes” with reset button. If I remember correctly, factory-default config is applied on reset, but gives user the option to revert it. If this can be prevented with custom default config and if you can also set users and passwords (so nobody could get in without knowing it), you’re good. Even if my wish came true and export could contain everything, nothing would change for you, because only admin users would be able to see sensitive parts of current config, and it would make sense to use same kind of filtering for default config too.

9

Well, while the user can revert the default config, this function is actually provided by the default config script itself.
So when you write your own default config, you can modify the script to make this revert a no-op and keep all your config.
(this is because the default config is always applied at button reset, to allow access to the router and basic functionality, and only when the user logs in using commandmode this prompt is shown and the script basically removes all config that has the “defconf” comments)

For the original poster: maybe you have overlooked that it is possible to prevent button-reset-to-defaults or make them very hard to do for those not knowing your config.
As long as you give your users admin access you will have problems, but frankly I would not know for what devices that would not be the case.
But when you want to lease boxes and do not want to clients to look at how you configed them, and they do not have admin access to them, that can be done.