Any port open to public networks is unsecure! The point is if port is closed by firewall or by disabling service then it is considered secure.
That is only the situation after it went wrong. In fact I always configured my equipment like that and carried it forward into MikroTik
equipment configuration, but there could be many users who believe that a service listening on an open port and fitted with authentication
is “secure” too. Unless the attacker knows the password they can’t get in, right?
Of course others have become victim of that when there turned out to be bugs in the service handling the request
(remember logging in to systems by entering the username -froot instead of root because -f meant “no need to authenticate this login”?)
and now the general stance is that a service cannot be trusted no matter if it does authentication or not, you need to lock the attackers
out of the service before they attempt authentication.
But as you know, there is a very big group of users of your equipment in countries where there apparently is a market for wireless last mile
internet access, technical development in general is a bit back compared to other countries, but there are bright guys with no money who
don’t mind to hack the system to get the access they want. The operators usually have little networking and security knowledge and they
deploy more or less default configurations and/or follow guidelines for setup they find on youtube (before consulting your own documentation).
These networks are hacked all the time because the security mechanisms are not well configured, or simply are not up to the task of
really providing security as opposed to holding back some nosey people who have no real interest in cracking the system.
This is partly because of the availability of vulnerabilities like the last two big ones, partly because of naive approach to security,
and some of that is of course part of the standards that are being used. A system like hotspot really cannot withstand any serious attack,
but it is likely not so easy do do much better.
So services like OpenVPN and IPsec in Mikrotik are “unsecure” as well? A router that drops all traffic on all interfaces is probably secure, but it also isn’t much use to anyone.
“Open to public networks”, yes. There is an immediate high risk, unless you implement a good firewall, if you really need to access that OpenVPN server from ANY IP address.
For road warrior VPN, it usually is not practical to have a valid peer address list. So those types of services require even more attention from you (and other developers) to keep the secure.
Of course for VPN between two fixed addresses I always have firewall rules that permit only that traffic.
But e.g. for L2TP/IPsec from mobile users it cannot be done.
(especially as there are no script possibilities in the IPsec peer config where you could run a script when an IPsec peering comes up to allow the traffic from that peer’s current address)
+1 for security announcement mailinglist
Posted in an other thread also and I had the idea after discussion with an other member. My ISP will close down my connection when I have a device that misbehave so why not extent this to the router itself.
RouterOS calls home each day or week to check if there is something wrong. If so every http session gets a page displayed that an update is needed because the router is below the minimal required version.
If ignored then after two weeks the router only functions when you are initiating an update. After the update all the functions are restored.
What a terrible idea 
Maybe it’s just me (and @R1CH, I guess), but aren’t we slowly crossing the ridiculous boundary? Wouldn’t it be better to just admit that this WinBox bug was as bad as it can get, instead of trying to redefine security? You have my word, I’ll forgive you.
I mean, whitelist for OpenVPN (assuming that it’s used mainly for road warriors, so by design nobody knows from where will clients need to connect)? So maybe a 24/7 operator and clients phoning in IP adresses they need to whitelist? Maybe port knocking, but unless it’s something more complex (and not easily doable with RouterOS), it’s just security through obscurity. What will be next? One company I’m involved with has some client portal on https and of course open to whole world, 10k clients or so. Security depends only on username and password, kind of similar to WinBox. By the same logic, should I suggest a whitelist to them too? Or perhaps an unconditional drop on tcp/443? No doubt it would be secure then. 
It is a terrible idea but we have to start somewhere. It is a responsibility to each of us and hacked routers can do a lot of damage.
Yes we have to start somewhere. How about users start to read how networks work and don’t make stupid mistakes like disabling a firewall?
Where to start…
You talk about doing MITM essentially to modify forwarded traffic. That’s preposterous! And what about TLS? Everything moves to TLS. Doing it on http is not even viable.
You also talk about call home. I don’t know what exactly are you referring to, but AFAIK the only ‘call home’ that ROS does (not CHR) is when using the IP > Cloud feature (which I generally don’t use).
How does invading our privacy by calling home (so MikroTik knows our IPs and our exact router model/serial for starters) will make things better?
And the worst of all: Forcing me to update to a potentially unwanted version (because of bugs, because of removed functionality, or because there is no need frankly) is monumentally stupid. It’s as stupid as Microsoft’s forced win10 updates.
Remove functionality until you upgrade? Are you out of your mind?
I know the Netherlands have good weed, but man, you must be high as a kite to suggest such things! 
To go to a HTTPS page you most of the time need a initiate that on http.
Even the handshake on 80/443 is giving away that someone is looking at a screen that can be warned.
Call home is the term for a device/application getting in touch with where it comes from. The IP address is to me not a significant problem. We share it and much more when we request a firmware/routerOS. Or do you have a separate IP to have your firmware/RouterOS updates.
Which type device or settings of any kind is not shared with Mikrotik and the page just contains the information that the router needs to know. There can be more information on that page that not applies to that router. You could use exiting download page and add in plain text the minimal requered routerOS version.
If you are not waning to update you router you forbid the router to visit the mikrotik page like I do Windows 10. It is then not Mikrotiks fault that your router is turned evil.
My Windows 10 does not use it’s own mechanism to update and I use WSUS for that.
Yes weed is the stuff that attracks many people to the Neterlands and of course the canals in Giethoorn. I use neither.
“Mikrotik call home” … crazy idea.
And what about routers which has “unsafe” ROS version but are hidden behind other firewall with good security? Should they magically be banned? What about connections with low bandwith? Should it be “eaten” by regular ROS verion checks?
Tha main idea of routers like Mikrotik where you HAVE TO configure it yourself is FREEDOM. You are not pushed to do things “the right way”
Then that good firewall takes the burden on them by not allowing to have that unsafe router to call home. The must not be a button to switch itall of and only a firewall rule can block it.
It is like you are jumping out of a plain on a parachute and start cutting lines. Nobody can help you by knotting the correct lines together. There is no reserve chute when your router is hacked.
When I advise a RouterOS device I always tell that it has a very steep learning ramp and the best is to use the default config first and grow from there.
You have all the freedom but Mikrotik has the fallout from this freedom.
What is the conclusion?
I made a filter that act as a honeypot for port 8291 and I caught some fish and added that to my drop line in RAW and log when there is a revisit in that CIDR.
I have the 146.185.222.0/24 (Barbarich Viacheslav Yuryevich) CDIR trying every 30 seconds to approach a port. It is still going it tried port: 34441,6436,8168,3961,37818,4566,3126,3497,3911,2989,7993,4600,9608,22676,42264,52463… with addresses ending on 222.29 222.32 222.37 222.7 222.11 222.28 222.35 and address 146.185.222.32 is used the most.
More addresses and ports are coming in but time to post it.
Update:
After a night sleep it is still going on so I am going it to add this CIDR to the list that is blocks but not log it and I have 809 log entries of that address range coming along. It was probably not looking specific for port 8291 like some others did. Reset the counter to see if there are more returning port 8291 sniffers.
Those days are almost gone. HSTS
Plus, all major browsers have their own predefined list of major websites that support https and will connect only to https even if you only type the domain in the address bar.
https://hstspreload.org/
What you suggest will break TLS faster than you can spell out its initials.
It’s been a full business day and the blog is still not updated with the news about what these four security bugs from the latest RouterOS release actually are. This seems to be a step backwards, before the blog the changelog said things like “www) fixed vulnerability” so admins at least knew the www service was affected and could take necessary steps to limit access if a RouterOS upgrade wasn’t immediately possible.
Now we have private CVE numbers and no information to go on, meanwhile hackers are likely reverse engineering the patches to find the vulnerabilities. I appreciate the effort to be more public about security issues but the disclosure about these four issues so far is really not giving me a good feeling.