Interesting case,
I performed netinstall (without default config) on my device (Chateau LTE12) to latest ROS version (7.16) because I had some trouble doing it with regular upgrade procedure due to my fault (power failure while upgrade process was in progress).
After netinstall is done and rebooting I connected to ROS using Winbox and changed password but I was not unable to open Terminal (Terminal - not permitted (9)) because I wanted to apply my configuration from export. This raised suspicion and I looked into logs: Device got hacked approx 1 minute after connected to internet, created backdoor System user and changed api port.


Since Chateau LTE12 is lte device it connects to internet immediately and in short period until password is set without default configuration device is vulnerable since I have public IP over lte, but I wonder how some scanner is such fast to detect unprotected device while password is not set...
I performed 2 netinstalls so far hoping I will be faster than scanner, but no luck, now I will go with some small configuration script which disables lte interface for avoiding internet connection until configuration is fully imported.
I done same thing in the past but never had such issues because device is unprotected in short period.
My IP is public but not static and I downloaded official ROS npks from MT site, it should not be compromised.

Curious because how fast it got hacked and hoping that ROS is not calling somwhere which triggers scanner and hacking over unprotected API.

Isn't there a (removable) SIM card?

Nah there are lots of hosts that are focused on scanning such things. I got caught by the same thing and ALSO with api but on a fresh CHR on VPS.
It's actually your fault that you netinstall with WAN/modem link up, eject it until your config is reapplied and device is secure.

P.S.: still propose MT to disable api/rest stuff in defconf to prevent such things. Those API hacks seem to be common.

defconf has firewall rules in place that dont allow api access from WAN. But basically I agree; API should be disabled by default in defconf.

Isn't there a (removable) SIM card?

Yes sure Removed once and destroyed nanosim-to-microsim-to-sim adapter because it was very difficult to pull it out.

defconf has firewall rules in place that dont allow api access from WAN. But basically I agree; API should be disabled by default in defconf.

Netinstall was performed without config, no defconf or any config to avoid conflicts with exported config. Complex configs are not applicable for import automatically with netinstall, but I solved later with simple config script: /interface lte disable lte1.

optio, I know. I've read your report. I know you performed a Netinstall without default config. My response was to kleshki's post:

P.S.: still propose MT to disable api/rest stuff in defconf to prevent such things. Those API hacks seem to be common.

Removed once and destroyed nanosim-to-microsim-to-sim adapter because it was very difficult to pull it out.

Sure, life stinks.

Anyway, there are three common adapters in a kit:
1. nano to micro
2. micro to standard
3. nano to standard

Sometimes 1+2 doesn't make 3.

The nano to micro is so thin on one side that it is rather easy to break, but having two adapters one inside the other increases this risk, as when you pull the external one the internal one may easily go out of the plane and actually be the cause of the jamming or at least contribute to it .

Yes sure Removed once and destroyed nanosim-to-microsim-to-sim adapter because it was very difficult to pull it out.

Chateau has a push-to-eject mechanism. Did not destroy my nano-SIM adapter in years.

Sometimes 1+2 doesn't make 3.

Ikr, but I had that combination, got it from MNO, so I used it.

Chateau has a push-to-eject mechanism. Did not destroy my nano-SIM adapter in years.

Maybe new models, on my SIM slot doesn't have.

Connecting to the internet prior to having at least the requisite firewall rules in place is a fools game, unless one is into gambling.

Maybe new models, on my SIM slot doesn't have.

Then you maybe crushed it somehow. My first Chateau in mid 2020 already had that.

Only for the record, and as a side-side note, besides using the "right" adapter and not attempt to combine two into one, metal adapters (as opposed to plastic) do exist, they don't cost (IMHO) excessively more and they are much more sturdy and the SIM fits in them more tightly.

Connecting to the internet prior to having at least the requisite firewall rules in place is a fools game, unless one is into gambling.

Well after thinking why I was doing it like that in the past and not bothering much, it was because my MNO always assigned me WAN IP behind CGNAT over network provided APN which protects you from direct access from internet and in that short period until new password is set and firewall rules applied I wasn't concerned, but it seems they changed that and I'm now getting assigned public IP for which I was needed to setup custom APN in the past. Now I definitely needs to be more careful when performing clean netinstall to apply config script for disabling lte interface after first boot.

Regarding damaged adapter I was wrong, it is only nano-to-micro adapter used since micro SIM slot is on device, adapter was damaged when I was last time pulling SIM out with tweezers since it is very thin plastic, no way to do it with fingers and push-to-eject never worked I'm sure, maybe was delivered damaged if LTE12 has such slot type.

The good Mikrotik guys did warn you, though :
https://help.mikrotik.com/docs/pages/vi ... d=73826313

SIM slot usage

SIM card slot is designed to use with Micro SIM cards.
Nano SIM cards have different thickness, usage with adapter are not recommended.

Unfortunately my MNO provides only nano SIM cards with adapters like this so I need to use adapter to insert into router.

Yep, but if the good Mikrotik guys (who have an established record for omitting even vital documentation and even when documenting it, doing it in the most minimal and succinct possible form) felt compelled to put this info in the manual, adding even a picture, it must mean that the issues with that type of slot/SIM holder was a known (and serious) one.
BTW I never understood why on relatively large devices nano or micro SIM are used, the mini/standard size is so much better.
There is another possibility (only for the record), there are extension cables that can be also converters for SIM sizes (though they are not cheap).
Example only, B3014A-N:
https://www.amazon.com/ADT-Link-Convert ... B0BXP2TLQB

I used different nano-SIMs from different providers with their adapters and never had an issue. I even once had a microSIM trimmed down with a cutter to the size of a nanoSIM (so I could put it into a smartphone), years later used it in an microSIM adapter again. No problem at all.

Unfortunately my MNO provides only nano SIM cards with adapters like this so I need to use adapter to insert into router.

Isn't it that cuttings for different SIM sizes are not through? So if one needs e.g. micro SIM, only outer piece of plastic has to be removed. The rest is still decently sturdy so that nano SIM doesn't separate from micro SIM sized frame ...

Yes, these "frames" are connected initially. You need to break out if you need it smaller.

And it breaks when you use some amount of force to pull it out of tight slot.

I think @optio is getting a bad wrap here. He was trying re-enforce the point that an attack can happen quickly. And LTE can surprise you since it can, sometimes, take no configuration to come up and work with a public IP. (Now... having public IP on LTE is not that common, and more typical CGNAT from carrier would likely have block the attack even with an empty firewall).

But I'll note that Netinstall will upgrade the "default configuration" that gets applied & normal upgrade do NOT upgrade the default configuration used on /system/reset-configuration. So while using "empty config" might have been good advice years ago... it's generally a bad idea, unless you have some specific needs. And the default configuration has improved a lot over the course of V7.

Unfortunately my MNO provides only nano SIM cards with adapters like this so I need to use adapter to insert into router.

Now on the SIM cards... the advice to not use an adapterif you can avoid it is a good one. But I have some MVNO come in packaging with the nano SIM, that come with holders to "upsize" - but certain the 3-in-1 that let you downsize are way more common.

With some fixed Chateau, most adapter should be fine & you'll see some SIM not available kinda message if loose. But if the LTE devices move around in vehicles/etc., speaking with your carrier's support/dealer/rep to see about getting the SIM in exact size is worth the trouble (or even cutting a 2FF into 3FF is better than "snap-ins") IMO - why risk one more thing that can wrong with LTE/networks in general.

BTW I never understood why on relatively large devices nano or micro SIM are used, the mini/standard size is so much better.

Me neither - agree! It's actually annoying that the Mikrotik LTE products do not all use the same size - since you cannot necessity just swap SIMs between device. Even on the hAPaxLite-LTE6, that has room for classic/"mini"/larger 2FF slot. But ship has sail on 3FF "micro" - so my hope is Mikrotik NEVER uses 4FF/"nano" ones.

Thank you for getting the point of this topic.

Now regarding applying default config on netinstall, my config is build around it, some defaults are slightly changed, some left as is, but if you export whole config and you need to import it again, it needs to be on clean install because if default config is already applied some rules will be duplicate or fail to import. It would be possible to compare which rules are already applied and skip those, but there is also order in place, etc... To reduce time especially when you have 300kb+ rsc export (most of this size are scripts), on clean install it much easier to apply but it requires precautions regarding security to avoid possible surprises (CGNAT vs public IP).

Back to the off topic SIM card size issues .
I think that it greatly depends on how the actual socket receptacle is made, in theory the nano is thinner than the micro (by a teeny tiny amount, 0.67 instead of 0.76 mm) to allow the adapter to have a "back sheet" (that can often be replaced by some sticky tape) but the actual fit in the device may be too tight or sometimes you need to add the tape even to a normal micro because it is too loose.

Lenovo take on the matter, they must have had issues too:
https://support.lenovo.com/ch/en/soluti ... d-thinkpad

When resetting the router configuration, WI-FI interfaces are disabled by default. Developers also need to disable the LTE interface by default. This will be logical and will solve this problem.

The logic is NOT to connect to the internet until firewall rules are in place and admin information/access to router has been changed from default and secured.
Relying on default anything in the router is the wrong approach. Just dont attach the cable or sim card etc, until the router is ready to be connected to external sources.

Generally speaking that is correct, but LTE device is specific when performing netinstall without config, it can provide internet connection without any config if connects using network provided APN and default route is dynamically assigned to LTE WAN IP, in other cases you need at least assign default route manually when device is up after netinstall where before you can setup firewall and user access. In some cases removing SIM from slot is not convenient, for eg. due to slot issues as in my case, then providing simple script to netinstall with command which disables lte1 interface is the way.
IMO some basic security mitigation from MT regarding this case can be that lte1 interface is disabled if configuration is not provided, default config can have command to enable it since it contains basic firewall rules for securing device.

You can always install without SIM being present.
Result: no LTE.

Mission accomplished.

Genius, brilliant! Solution of the century. So basically remove the invisible cable wire.... who would of thunk it.........

Maybe reading a bit carefully won't hurt

...In some cases removing SIM from slot is not convenient ... then providing simple script to netinstall with command which disables lte1 interface is the way...

A question of priorities: getting hacked or remove SIM.

or just apply script...
It seem logic is here - more stupid people are ones which cannot for any reason remove SIM than ones that don't know that lte1 needs to be enabled to have internet access (if is mitigated like that)

Sure, disable lte1 interface in script. But keep in mind, you have to wait until lte interface is available. Here is how default-configuration does it - in a very cumbersome while loop but this is how (limited) ROS scripting:
Have fun.

Or you remove SIM card.

Maybe reading a bit carefully won't hurt

...In some cases removing SIM from slot is not convenient ... then providing simple script to netinstall with command which disables lte1 interface is the way...

Convenience is a factor which has a huge impact towards lowering security.
Human factor BTW is by far number 1 (with humans usually wanting a convenient way ...).

Choose: convenience or security ?

I do agree the best way would be any LTE interface is by default inactive.
But that's a question to be raised to MT developers ...

Choose: convenience or security ?

Maybe convenience is not right term in case when such HW issues are present and requires a lot of effort to eject SIM including risk to damage it, convenience can be for eg. laziness when simple push-to-eject SIM is available.

I get your point and I do agree default inactive interface is the best way, security-wise.
But it may be inconvenient for some to enable it again

Inconvenience to get convenience

Maybe first line in provisioning script could disable all IP services:
Later on when IP firewall rules are added or at end of script you can selectively re-enable needed services with proper "address" restriction.

I think the FUD is a bit overblown. There is nothing to worry about a SIM being in a new unit with factory defaults. The default firewall will protect you and all LTE devices come with a firewall. And on newer AX things, there not a lot of reasons for netinstall, less so in starting from empty configs since the defaults in V7 have gotten very good.

Let's also remember @optio's SIM has a public IP — most of SIM uses a CGNAT which block hack attempts before getting to an empty config. i.e. Just like how CGNAT prevent running a VPN servers on RouterOS: no ports are not opened from internet side in CGNAT.

Not saying the case cannot happen... routers come with older version and/or 16MB AC LTE devices might want wifi-qc-qcom... so know there are cases for netinstall may be warranted. And also, if you had some previous config you wanted apply... someone might choose "no-default" in netinstall or use /system/reset-configuration no-defaults=yes to config "manually" at CLI after netinstall — i.e. to avoid problems with netinstall (or run-after-reset=) applying some script from :export – which is not always 100% to "just work" when importing at boot.

So I think lesson @optio was pointing out is when dealing with netinstall (or /system/reset-configuration no-defaults=yes) or really any empty configs. And iyou have to remember to remove the SIM cards on LTE devices — since just not as obvious as ether1 being plugged-in.

But I'm not sure I'd make a config that run via netinstall any more complex than needed (or reset-configuration run-after-reset= or branding defconf, to be complete) . If one of these scripts fails - that's exactly how you'd leave stuff unconfigured since the config script failed. If someone really wanted to leave the SIM, and using at boot from netinstall/etc (which hopefully a small subset), it be easier to just change the default APN config to "use-default-gateway=no" as first step in config, or turn off USB using /system/routerboard/usb/power-reset with long duration=5m (i.e. give it 5 minutes before LTE will re-power) so if config fails, you have that time to try again (or remove the SIM).

or just apply script...
It seem logic is here - more stupid people are ones which cannot for any reason remove SIM than ones that don't know that lte1 needs to be enabled to have internet access (if is mitigated like that)

Go ahead and rely on scripts the rest of the "real" IT human race will rely on either physically removing cable or sim card etc................

Since in my test lte1 started immediately, but it took a while for the SIM to register to the network,
it is more than enough to immediately set the password to the admin user, logging in immediately as soon as RouterOS has started...


Easy step for not remove the SIM:
Enable PIN,
netinstall,
do config stuff
Disable PIN,
Done.

@Ammo As you wrote, not a common case, several cases matched:

• issue with SIM slot

• failed ROS upgrade - unable to boot, this is preventing for eg. configuring SIM pin before not expected netinstall (as @rextended suggested) without inserting it into another device

• public IP over LTE due to changes on ISP side - expected CGNAT without custom APN

• low storage device (LTE12) - restoring with custom complex config (rules for VPNs, containers...) .rsc instead backup over defconf to free some space; defconf brings secure enough config but then rules needs to be removed to apply exported .rsc

@anav but it can be simply mitigated as I wrote in above posts to be by default disabled on system, disabled interface can be considered enough safe as is physically disconnected.

New devices come with a default password. This is the only way I think can solve this issue.

There is an even simpler solution: On newer versions of RouterOS leave LTE turned off, it will be turned on in case of defconf that also set firewall in place.


Reset or netinstall without default config = no interface active except etherX and sfpX, like wifi is disabled if no default config.

Exactly, which I suggested above...
ROS without config should not have internet access because of exposed services.

Exactly, which I suggested above...
ROS without config should not have internet access because of exposed services.

On that we can agree LOL.

How do you suggest the router will determine which port has internet access, and then disable it? You can't disable all interfaces.

Sure, "interesting case" here, as @optio put... But solution is for @normis/team to update the netinstall and reset-configuration docs to clarify to REMOVE any potential internet source, including SIM cards. So, yes, "what if my SIM is stuck" - you hopefully find this thread.

But there is no need for changes in the boot process — that just introduces more problems. See 7.17beta & "device-mode". And I have to believe a majority of users never get to an "empty config" state since they just use default and adjust.

And on newer AX things,

... which include using they come with default password as @normis notes. Since similar problems could happen if you have a "failed" script applied. But it is the admin/<blank-password> that's at the root of the troubles, and since that was the default for long time... problems can happen (and why they changed it).

My problem is there not a lot of newer LTE devices, and ZERO for US/CA, that could even come with default password.

Just some clarification, all devices with LTE and WiFI come with default password for at least a year, I think. I have to check for up to date info. I think the last remaining devices with no password are CCR series.

Just some clarification, all devices with LTE and WiFI come with default password for at least a year, I think. I have to check for up to date info. I think the last remaining devices with no password are CCR series.

and if y'all add eSIM support... you'd have to provision something in config for LTE to come up. And no stuck SIMs, either.

Maybe stupid question, but couldn't the (safe/complex/random/whatever) password be asked during the netinstall process for those (older) devices that still have the blank one?

How do you suggest the router will determine which port has internet access, and then disable it? You can't disable all interfaces.

Is it possible to have internet access without default route is set? If not, which other than LTE can dynamically set default route without config?

Edit:
But this is inbound access (long day), so default route is not required for it if ROS services are listening on all interfaces... At least wireless interfaces can be included which LTE is one of them as @rextended mentioned.

Maybe stupid question, but couldn't the (safe/complex/random/whatever) password be asked during the netinstall process for those (older) devices that still have the blank one?

Good suggestion! It will cover user access security if internet access is on any interface.