My hot take here is that the article actually places Mikrotik in a high place.
The positive things:
Over 13k Mikrotik devices, most of them high end, used in the wild
The devices had updates available but were not installed by the owner
Devices were compromised most likely due to misconfiguration at set up
The extensive feature list of mikrotik makes them a top choice for hackers
The bad thing: Mikrotik’s name is used as clickbait in the title.
As someone that has set up a few online mikrotik routers and realizing that I had to find ways to be the first to log into the router or it would be compromised I would really love to have a way to deploy an image with a password already set, or secured. So far I have resorted to making the image offline and uploading it already harded which makes it hard for a company to offer vps with the image available, or disabling the network interface and using only remote access to the main terminal to harden in before making it appear online, or making a script to log in and set up passwords and filters before it can be accessed by someone else.
I am loving this software, and this company. This devices are incredible. I have already over 20 mikrotik devices and there are a lot of things left to learn from it.
Having said all that, I know how to leave a mikrotik secured by having a firewall and access restrictions, but you do not have that while you are setting it up in the wild on an x86 img, you can only do that on some routers if you can get the script into it first.
So my question is: How do you secure it while you are setting it up? (and before it is completely set up)
@anav, @gabacho4, you have to read very carefully to spot it in the text, but @kryztoval has in mind CHRs (virtual routers) deployed in the cloud. So yes, he does configure them over the internet.
@kryztoval, the strategy depends on the particular cloud provider. Many of them are aware that security is important and OS images come without tight firewall rules, so they provide their own firewalls free of charge, which you can use until you set up the firewall on the installed VM itself. Others are reportedly aware that security is so important that people are ready to pay for it so they offer the firewall as a paid service. Yet other ones do not care and it is up to you to modify the image prior to installing it in on their servers. Whereas most cloud providers allow to install your own disk image, the first start of the CHR image downloaded from the Mikrotik site includes some initialization, so installing the CHR on your virtualization platform at home, setting up some basic firewall rules or even a VPN, and then installing the disk image in the cloud will not work.
So for the moment, the only way I know is to avoid cloud providers that do not offer firewalls.
It might be helpful to ask Mikrotik to change the default firewall rules on the CHR images so that all input traffic was dropped by default, but maybe there are providers that provide neither console access nor firewall? Another way would be to ask them to implement some kind of “autoexec” feature - you would mount the downloaded disk image somewhere, copy an autoexec.rsc file to it, and upload the modified image to the cloud provider. During the first run of the CHR, this file would be imported before enabling the networking. But this approach would be even more complicated, hence only a few people would use it, so it would be quite a lot of development effort with little impact.
That is why I do not like such a clickbite “bleeping” news.
The article recalls a few years old problems that have a solution for a long time but makes bad impression using references to an old articles that could be not necessarily valid nowadays assuming that people do not check what is referenced.
One could write:
“ABC brand car manufacturer is responsible for most bank robberies as it’s cars are known for beeing delivered with no activated alarms and old drum breaks but HEMIs are very popular and loved by criminals to make money transfers from unprotected bank accounts that had unchanged default (for users convenience) 1234 pin even if that recommendation is described in the users’ manual and good practices suggest to change it to something unique. It’s strange that manufacturer ABC does not assure free lifetime >>upgrade sets<< for car users to avoid such problems”.
Yes. Many car manufacturers used drum breaks. Some even dared to use disels and so what? The problem are users who do not protect their accounts but the focus is set on car manufacturer that has nothing common with unprotected bank accounts. You cannot convince users to change their bank/router levels of protection if they do not care and they like that easy access. It’s not a manufacturer responsibility or fault.
(*) blue parts are not real links but in such articles they link to “facts” that could not be denied" but some/all have been already solved.
Most readres do not do factchecking and relies just on that misleading “link summaries” and web crawlers to index them as “current facts”.
I thought (never deployed a CHR online) that the “recommended” approach would have been:
download a “clean” CHR image from Mikrotik
mount/run it locally (VM)
change admin user and set a “strong” password
configure the CHR and test the main (if not all) settings, including firewall
upload this “final” version to the cloud provider and run it there
refine/tweak the configuration if needed
Are you telling me that this is not possible?
Or it is not possible in some particular cases only?
The idea of autoexec.rsc seems to me like a very good one, but of course there would be the need to test/troubleshoot the script locally, so it won’t make much difference, the only difference I can see could be that the actual CHR image could be dowloaded (uploaded) on the cloud provider directly from Mikrotik servers, so no way to “infect” it locally (but the hypothetical autoexec.rsc would as well be vulnerable locally).
As Bartosz says, most - if not all - these reports are at the end linked to people that put online (most often in good faith) routers with obsolete RouterOS and/or admin/blank, admin/admin or admin/123456 credentials.
The change with the teeny-tiny “random” passwords on the label of physical devices seems like a good step (for the physical devices) even if it can complicate management.
But doing something similar for CHR’s (each CHR download having its own unique first login password) would probably be complex not only for management, but also for Mikrotik distribution of the files.
Default CHR doesn’t have ip address, I believe.
You first need to go via hosting console to get in.
And that was ( for the provider I used) a really annoying complex password (but top points for security there !).
So first do your setup, then connect to Big Bad World.
A “default CHR” has a DHCP client attached to ether1, username admin, no password, and no firewall rules. If the cloud provider does not provide firewall or a possibility to disable the network interface, the machine is exposed to the internet with default credentials for at least a few seconds until you manage to log in via console and execute /ip firewall filter add chain=input action=drop.
No DHCP client on the version I used ?
I was wrong though. It defaults to 192.168.88.1 which however is useless facing outwards.
script: #| IP address 192.168.88.1/24 is on ether1
#| ether1 is enabled
:global action
# these commands are executed after installation or configuration reset
:if ($action = "apply") do={
:delay 5s
/ip address add address=192.168.88.1/24 interface=ether1 comment="default configuration"
}
# these commands are executed if user requests to remove default configuration
:if ($action = "revert") do={
/ip address {
:local o [find address="192.168.88.1/24" interface="ether1" comment="default configuration"]
:if ([:len $o] != 0) do={ remove $o }
}
There is even a caps-mode script on def-conf, for CHR ??
(probably same logic why wireless package is loaded on CRS devices after upgrade coming from below 7.13)
I guess each of us has something else in mind. What you seem to mean by “default CHR” is the contents of the /system default-configuration; what I had in mind was the configuration the CHR starts with once you download the image from Mikrotik pages and deploy it on your own hypervisor or in the cloud. These two are not the same.
I understand what you say but I am 200% sure the setup I had when applying that VPS instance in the cloud did not have a public IP address nor DHCP client.
It’s even in the instructions of the hosting provider I used (IS Hosting) that you first need to go via hosting console and you need to set the IP address to the address which has been provided or it will not work.
I first applied a default firewall before even touching that external IP address.
Definitely each hosting provider has their own approach, and I admit that I don’t remember whether there is some autoprovisioning embedded in the CHR image, as some hosting providers do not use DHCP to assign addresses to VMs and nevertheless the installed images do get the correct public IP via other communication channel to the orchestration platform. So it all boils down to the choice of the hosting provider.
I did know that the “s” in “cloud” is the same as the one in “iot” but didn’t expect the situation to be as bad as you are depicting it (at least on some providers).
Maybe it has changed at some point in history, but I can 100% confirm what sindy is saying.
“first boot of the vmdk/vhdx/img” config on a CHR is nearly blank, no firewall, no password, yet unfortunately dhcp on ether1.
A few months ago I was guiding someone here on the forums about deploying on OVH (whose VPS are horrible junk, but at price matching the quality), who doesn’t give you any safety options - can’t “unplug ethernet” from the VM, for example - so yes it picks up the dhcp ip on boot and yes botnets basically immediately try to log in as admin+no-password, you need to be faster.
CHR on first boot does some level of hardware detection / mapping / conversion.
Generates the license ID, resizes the partition to cover the size of whole available virt-hardware disk, and so on.
It can survive being moved to a very similar virtual environment, but most of bigger cloud providers are weird/quirky/specialsauce enough that a CHR booted e.g. on your local VMware or Hyper-V will not be (easily) moveable to something like OVH’s OpenStack or Linode’s homebrew, not to even mention the real big fish like AWS.
So, the only “defense” is what rextended suggested for the other case where default config (reset) might get online (LTE devices where you don’t want or cannot remove SIM)?
but in that case there are some 20-30 seconds of time before the SIM registers to the network: http://forum.mikrotik.com/t/device-got-hacked-1-min-after-connected-to-internet/178933/40
(be very quick).
Possibly having already the new (secure) password in the clipboard would help (doing it in two steps, quickly change the password for default user admin to a “strong” one and only later are new user, etc.).
As explained above, using a reference image is exactly what you can not do with a CHR, because the first run modifies the contents of the virtual disk significantly and the modified image will often not boot on the cloud host.
I don’t think there is any sufficient analogy from the automotive world for this.
As for using the configuration as a reference, that’s OK, but the issue here is what to do if your chosen cloud provider does not realize the need for doing this before connecting the newly deployed VM directly to internet. My personal choice is to avoid such providers, but other people may have no other choice.
I did quite some research before settling on the provider I’m using now.
Especially the fact they explicitly mentioned on their knowledge base you first had to do some config before being able to do anything, made me decide in their favor (ok, they “forgot” about the firewall in their instructions but that void I filled in myself ).
and so what? The problem are users who do not protect their accounts but the focus is set on car manufacturer that has nothing common with unprotected bank accounts. You cannot convince users to change their bank/router levels of protection if they do not care and they like that easy access. It’s not a manufacturer responsibility or fault.
).