So I have already reported this directly to Mikrotik and they say it is normal and nothing to worry about. I disagree and would like to know what other people here think.

This "bug / hack" allows you to add device(s) to the neighbour list of any Mikrotik device anywhere in the world without knowing it's password as long as you know it's IP address. The prerequisites are that the target has neighbour discovery enabled on the interface the packet arrives on and no firewall blocking UDP port 5678 - which is the default state.

All you need to do is change the destination IP of an MNDP packet from 255.255.255.255 to the IP address of the target. It is also notable that this packet will add the same neighbour device to ALL Mikrotiks it passes through on it's way to the target.

While this is perhaps harmless fun - it could be the doorway to any kind of buffer overflow type attack as you can set the name of the neighbour to be any string you like. In my opinion only broadcast MNDP packets should be accepted.

Anyone have any thoughts on this?

It is not correct what you write. The default firewall on a small device blocks this traffic. And on a large device (CCR/CHR)
it is the full responsibility of the admin to setup a firewall to secure the router.

It is not correct what you write. The default firewall on a small device blocks this traffic. And on a large device (CCR/CHR)
it is the full responsibility of the admin to setup a firewall to secure the router.

Actually you are correct about the small device and it's defaults.

However it is more worrying this problem affects for example Cloud Core devices. And I disagree that the firewall is a replacement for bad coding - rather more a backup for it.

What would you have Mikrotik change about MNDP's behavior? Requiring authentication of some kind is counter to the purpose of MNDP.

Every practical administrator will apply a set of firewall rules to protect appropriate interfaces and set discovery to disabled because it's best practice. I have a standard set of firewall rules I apply to every router when I turn it on, then adjust as necessary. I'm sure most admins have a similar procedure.

What would you have Mikrotik change about MNDP's behavior? Requiring authentication of some kind is counter to the purpose of MNDP.

Well my answer to that question is that MNDP should only respond to broadcast packets and not routed.

I don't see a particular threat here. As was already pointed out, consumer-class gear is already firewalled, and commercial-class gear should have qualified people that understand networking configuring them.

Sure, Mikrotik could require MNDP to accept only broadcast. There are some benefits to allowing unicast. An administrator might want to poll his entire AS with MNDP for example.

Here's a firewall rule that does what you'd like (well, it should--I didn't test it). Feel free to add it to your standard ruleset if you wish.

Sure, Mikrotik could require MNDP to accept only broadcast. There are some benefits to allowing unicast. An administrator might want to poll his entire AS with MNDP for example.

I cannot see any place in Winbox where you can set MNDP to work in unicast or any good reason for it to be that way. I agree that the firewall rule is good practice but I still feel MNDP should only accept broadcast.

I still feel MNDP should only accept broadcast.

I think you should configure a default-deny firewall.
For input, accept what you need (amongst that is broadcast to port 5678 when you want to use MNDP) and at the end of the rule list drop everything else.

add action=accept chain=input dst-address-type=broadcast dst-port=5678 protocol=udp
.
add action=drop chain=input

While I am happy to accept those suggestions relating to firewall rules there does seem to be a hint of ignoring the root problem. After all neighbour discovery is exactly that - not for discovering devices halfway around the world!!

While I am happy to accept those suggestions relating to firewall rules there does seem to be a hint of ignoring the root problem. After all neighbour discovery is exactly that - not for discovering devices halfway around the world!!

I simply do not see this as a problem. A standard firewall config with a default drop resolves any potential issue.

Do you disable the DNS, WWW, API, and SSH services, or otherwise block public access to those services on routers you administer? If so, why do you do that? If not, you may want to check for signs of compromise or abuse.

I simply do not see this as a problem. A standard firewall config with a default drop resolves any potential issue.

Do you disable the DNS, WWW, API, and SSH services, or otherwise block public access to those services on routers you administer? If so, why do you do that? If not, you may want to check for signs of compromise or abuse.

So I was kinda busy and did not get a chance to look at this. However it seems I am right and all you guys are WRONG!!!

And here is why. The routers are reacting to passing packets and NOT input packets. So no end of firewall rules on the input will stop this from happening which is frankly ridiculous in the extreme. So I can basically add neighbours to any Mikrotik in the world as long as it has a public IP. The only way to stop this is to filter the incoming pipes from the Internet but that still won't stop mischief from inside my network.

I plan to contact Core Security as they seem good at getting Mikrotik off their asses and fixing bugs. For example:

https://www.securityweek.com/remotely-e ... s-routeros