Hi all.
I’ve setup a new Mikrotik box.
My policy is to only allow traffic that’s meant to be allowed and dropping anything else.
Soon after the upgrade to v6.43.1 I am finding a number of events in the logs like this one:
DROP-OUTPUT output: in:(unknown 0) out:ether24, proto UDP, 192.168.255.252:38962->159.148.147.201:15252, len 66
DROP-OUTPUT output: in:(unknown 0) out:ether24, proto UDP, 192.168.255.252:49614->159.148.172.251:15252, len 66
every two minutes. 192.168.255.252 is the management IP address of the box and there’s also a default route though it.
Both public IPs are Latvian IPs.
And very likely they are run by the Mikrotik company itself as www.mikrotik.com=159.148.147.196 and download.mikrotik.com=159.148.147.204,159.148.172.226.
A similar box running v6.42.7 isn’t showing such traffic.
That wouldn’t be a problem, as long as I knew this is a _normal_™ behaviour.
I really don’t expect a default “blank” router configuration to enable outbound connections over unknown protocols.
So I’ve also disabled that “Time Zone Autodetect” setting.
I still see those outbound UDP:15252 connections.
Anyway, if that’s legitimate, I think there should be some documentation about it.
Also the firmware update procedure should be documented as its traffic is legitimate.
But in that case, the default behavior is that the updates are run manually by the net admin and not automatically nor by default configuration.
Those settings all get actualized ONLY after a reboot.
Only after the reboot all that UDP traffic stopped.
Which is really weird: a router shouldn’t never be rebooted, unless a firmware update has been done or a huge bug is freezing it.
I would treat this a bug and file a ticket for it if there was a ticketing system.
Thanks for the insight and the wiki reference: while I do usually read the changelogs, I don’t re-read the whole wiki at every update.
Why there’s no reverse DNS for Mikrotik IPs?
support@Feynman ~] nslookup 159.148.147.201
** server can't find 201.147.148.159.in-addr.arpa: NXDOMAIN
[support@Feynman ~] nslookup 159.148.172.251
** server can't find 251.172.148.159.in-addr.arpa: NXDOMAIN
If you know the host names, you can check the IP address, just like you did.
But if If you don’t know and there’s no reverse DNS (like 201.147.148.159.in-addr.arpa.) you won’t ever know the host name.
The main point, in the end, is not who my router is talking to, but rather, why is it doing it without my consent/configuration.
And, secondly, why on earth do I need a reboot to disable those few settings.
Then it’s interesting to read on the wiki about the protocol to be used for the cloud features:
When /ip cloud set ddns-enabled=yes is set, then the device will send encrypted packets to MikroTik’s Cloud server using port UDP/15252. For devices using RouterOS v6.43 and newer the encrypted IP/Cloud packets are going to be sent to cloud2.mikrotik.com. For devices using older RouterOS versions (prior to v6.43), encrypted IP/Cloud are going to be sent to cloud.mikrotik.com.
But in the very beginning I had to really struggle to link the weird traffic to the cloud features.
UDP#15252 is everything related to cloud - Time-zone detection, time (if not set in SNTP/NTP), DDNS, backup management frames.
TCP#15252 is IP Cloud backup
Also, the problem about disabling IP Cloud DDNS sending packets after disabled - it sent “remove my IP from DDNS” packets to IP Cloud servers. Also, if you print in that menu, it could trigger check - if DDNS is disabled check and if disabled - “delete my IP address” packet was sent once again - will be resolved in future releases.
If you are checking your DDNS entry - if that is deleted, give some time (up to 5 minutes) to check against our IP Cloud NS servers, also, make sure that someone in between is not caching entries.
Edit: in this transition period from old IP Cloud to the new IP Cloud - if you remove your address from new IP Cloud and you did not remove it from the old, your assigned domain will still reply with your old entry from the old Cloud if not removed. After some time this will go away when the old IP Cloud servers are shut down.
there are defaults that are enabled, like time-zone detection. and other stuff that is not setting/saving any information about you anywhere
and there is a service like DDNS that is saving your IP address. if you disable the service then UDP packet is sent to remove you. UDP packet can fail to reach the target, as a result, your IP is still listed in our service. I as a security conscious person would rather ensure that MY IP is removed for sure if want that service disabled. That was that traffic you were seeing - repeated packets of “please delete my IP, thank you”. You disabling a service does not mean - do not send traffic. It means " remove me from your service"
Now, disabling the service will send 1 packet to unsubscribe, if it fails to reach us, your IP will still be assigned to the generated FQDN and you will have to enable/disable the service until we do receive said UDP packet.
force-update also will not work if you disable DDNS. Prior to this, it was possible to disable service and if UDP did not reach and your IP is not removed, one could force-update that you have disabled the service.
Best way to ensure that no traffic leaves your router - is ip/ipv6 firewall filter chain=output. Nothing gets past that.
…except DHCP server responses and VRRP master advertisements… what else? I know both these cases are specific, but is there a full list of protocols which are handled between the interface and the firewall so the firewall cannot be used to block them?
Maybe I am wrong, but a router that’s been reset should simply not be sending anything out. Period.
If I enable a “cloud” feature, I can expect some traffic getting out.
If I enable NTP, I also expect some traffic getting out.
An “empty” router should not be sending any traffic anywhere.
reset to default config. Default config on my models has “time zone detect” enabled and according to janisk cloud functionality is used for this. It is debatable whether this should be enabled or not, my vote is NO (my network gear and servers are all set to UTC even though that’s not my local time zone).
reset to blank config. In this case I agree with Uqbar that router should not send out anything for “its own entertainment”.
the default configuration is available on wiki.mikrotik.com and on all the routers it is possible to reset this configuration to the one you desire using Netinstall (when Netinstall is used to re-install software on the router it is possible to provide a new default configuration that will replace one provided by MikroTik)
So, if your use case requires different defaults feel free to customise your router. Current default configuration represents what MikroTik thinks is best for its customers.
