It looks like the built in DNS server listens on all interfaces when enabled. Is there a way to specify the interfaces it listens on (not firewalling traffic, but limiting listen interfaces)?
I want to have different DNS servers listen on Internet-facing interface vs internal-facing interfaces. Is dstnat on external interface the right approach here? Is there a way to limit the interfaces the built in DNS server listens on to a subset of interfaces?

ROS DNS service is pretty decent DNS relay but lousy DNS server. And answer to all of your questions is "no". You need a proper DNS server and configure it according to your needs. You can configure RB firewall to pass/NAT DNS traffic towards your DNS server according to your wishes and that's about it.

Thanks.
Is there a netstat-like command that lists the ports the router is listening on? I have accidentally discovered it's listening on internet side of the house when I wanted to run some other DNS server there. I am wondering if there are other ports in listen state on the router that I am not expecting.

Not that I know of.
That's why you should use a firewall

That's why you should use a firewall

Indeed. Preferably following the concept "allow only what needs to be allowed, drop all the rest". It's easy to find that something is blocked that should be allowed while it's nearly impossible to explicitly block everything that needs to be blocked. Not until it's too late.

It is still not very comforting not knowing the list of open ports on the router. You never know if you are a part of a botnet. Firewall blocks connections, but does not tell you much about processes on the router itself that may be unwanted.

You can't be a part of a botnet if you allow access to only what you know you need open. The default firewall on a lot of devices does just that (well it treats LAN as "trusted" but that's your job).
You can always run a port scanner against your router.

I do not agree with your assessment. Router can be protected by firewall, while being infected by botnet and listening on some UDP port. Port scanner would not help either - botnet could ignore and blackhole traffic that does not match specific pattern from control node - port scanner will see no response - as in case of blackholed traffic. Not seeing ICMP connection refused is not an indication that the port is open. It is not an indication that it is closed either.
If what you are saying is that one should do a netinstall followed by a firewall config in an isolated environment, that is still not a guarantee against infections - there may be protocol buffer overflow exploits that are capable to execute code on the router. Not being able to check on listening ports is a serious security miss.

remember you can firewall following traffic:

input: towards the router
forward: across the router
output: from the router

if you don't trust this platform please use another or build your own like you want

MikroTik is not open source is a commercial product

I dare you to run some code on RouterOS that can listen on some port.
But I didn't get the firewall part you wrote above, if your firewall blocks everything, how can anything else you've said be valid (having some service listening, bypassing the firewall), example, please. Because I can't sleep tonight knowing that my firewall does nothing.

I dare you to run some code on RouterOS that can listen on some port.
But I didn't get the firewall part you wrote above, if your firewall blocks everything, how can anything else you've said be valid (having some service listening, bypassing the firewall), example, please. Because I can't sleep tonight knowing that my firewall does nothing.

Exploits running on routers - either Cisco IOS or ROS are nothing new. You could allow access to legitimate ports, which could have 0-day exploits allowing RCE.
viewtopic.php?t=132368
https://www.exploit-db.com/exploits/43450

if you don't trust this platform please use another or build your own like you want

MikroTik is not open source is a commercial product

Burying one's head in sand is not a good security posture. Firewall rules do not guarantee lack of possible exploits through legitimate traffic. I do not see a valid reason for not having a command showing ports that are listening for traffic, given this proprietary software runs on top of open source kernel that has facilities to provide such information. It's not like Mikrotik built the whole thing from scratch. No one does it these days. Even Cisco's monolithic legacy IOS has open source bits and pieces compiled into it.
Recent log4j vulnerability proved that 10-year mature proprietary software can have silly security vulnerabilities that even a kid can exploit.

All of those exploits are .. unexploitable against a device running a properly configured firewall.
Even the thread you linked with the exploit that was fixed in 2017, they all had the management web interface open to the world, the winbox vulns that were found after, they all had winbox port open to the world.
You don't leave your car with the keys in contact, window open, and go on vacation expecting to find the car in the same place, or at all, when you come back.
You're talking scenarios, but nothing real.
"hiding behind legitamate traffic"
Ok, so I use port 53 because I run a DNS server, what could possibly be running instead of that DNS server without me noticing that it's down?
Or instead any other service that I'm allowing the world to talk to it?
It's not "Burying one's head in sand" it's more like sending packets I don't want in the pit. You should try it.

Unexploitable is a bold claim with no data to support it.

Internet-facing router with NAT is usually running some ALGs at minimum, which process externally-controlled data to patch up the packets in tracked eligible connections. A vulnerability in ALG, which runs in kernel btw, can compromise the router and cause RCE.
In log4j it was the logs that were causing RCE, so if the attacker was in control of the logs (as in your device logging attacker's actions including strings controlled by attacker like logins or URLs), attacker can take over the vulnerable machine.
Spectre and Meltdown demonstrated side channel attack vectors that were present in pretty much every single device for decades!
You don't seem to have a good understanding of possible attack vectors if you think that just by limiting the traffic you could make the device safe. There could be vulnerabilities in anything, including connection tracking code that your firewall is using to inspect the packets!

There is absolutely no excuse for not exposing listening ports. It does not cost anything - it is already part of underlying OS. "Nothing to see here" is a silly dismissal of a lack of basic functionality.
Cisco IOS has it - `show control-plane host open-ports`. Linux has it out of the box with netstat exposing results from Kernel. It is beyond me why people defend the lack of a basic command to show listening ports on a device which has kernel capabilities to expose it out of the box.

Post the IP address of your router. I'll then tell you which ports are open.

Bwahahah.

Post the IP address of your router. I'll then tell you which ports are open.

But..... Really???


Scan this pool......
76.222.0.0/16

It is beyond me why people defend the lack of a basic command to show listening ports on a device which has kernel capabilities to expose it out of the box.

BECAUSE SAID DEVICE HAS CAPABILITIES TO BLOCK LISTENING PORTS OUT OF THE BOX.
As previous stated.
As per your topic, submit a proper feature request, which is not done in the forum, but by making a proper feature request submitting a ticket. https://mikrotik.com/support

It is beyond me why people defend the lack of a basic command to show listening ports on a device which has kernel capabilities to expose it out of the box.

BECAUSE SAID DEVICE HAS CAPABILITIES TO BLOCK LISTENING PORTS OUT OF THE BOX.

Ok, this is the best answer of the month, which I prefer...

Or, the OP can scan the router's WAN address from outside of the network to expose open ports.

Exactly... Without install anything, are present dozen of sites that can do that freely... But disable firewall first...

Or you can disable the firewall and wait.

...right... others do scans freely and without the need to ask...

DeviceLocksmith, I would also like the port listing available in ROS for the reasons you described as well as a convenience feature. When debugging network problems it's second nature for me to run netstat on a server. Hopefully MT employees will see it. Also consider making the request here: viewtopic.php?t=45934

I still think that this is the proper way to submit a feature request: But whatever, keep spamming the forum.

Scan the ports? Really? Let's say I am listening on UDP port for a 'knock' pattern from botnet control node. I am not responding to anything that does not contain the pattern. I am not sending ICMP Connection Refused on any port. (Or I send it to every packet that does not contain the pattern if ICMP responses are enabled.) How are you going to tell by scanning the ports if the port is listening or not? You may want to google how UDP and ICMP protocols work. Even a TCP port may only accept connection from a specific range of IPs, so a port scan will find nothing.

This philosophical discussion of "ifs" and "buts" leads nowhere.
You probably have more backdoors in smartphones, printers and computers combined, than in a single MikroTik router with the default firewall configuration.

Did you "suggest new feature"?
Arguing with other forum users will not push MikroTik to do anything.

I did, SUP-85276. In security it is usually not ifs, but whens. I've had enough pages in the middle of the night for day-0 events to not discard security vulnerability risks as distant or unlikely. It is always a risk until proven otherwise. My CCR2116 came with no firewalls configured out of the box. Who knows, maybe my machine is infected by something that was waiting to see arm64 Tik on the network, and infected it immediately once I connected Winbox. It may already be infected and listening for control traffic - until proven otherwise by `netstat` or similar. Port scan is a useful tool for validating that ports you have left open for the world to see are in fact open. It cannot be relied on to check if there is malicious code listening on the port. I've even seen POCs of ICMP Echo packets used as covert communication channels bypassing firewalls with DPI. DNS being used as encapsulation for VPN traffic. Not displaying listening ports of software, open source or not, does not help with security posture.

Your argument is, at this point, perfectly stupid and sloppy.
Who guarantees me that the distributor (not the manufacturer) has not already purposely "infected" the router
before distributing it to whoever sold it to you,
hacking your beloved "netstat" so that don't show you what he doesn't want you to see?

You could trust vendor or not trust vendor. Software coming from manufacturer may have SHA2 hashes or even secure bootloader chains to ensure it is not modified by distributor - it can be netinstalled with validation of a secure bootloader chain. No security is perfect, so there are always new ways to attack software, but such a basic thing as `netstat` costs nothing and does add additional layer of complexity for attacker to emulate to sneak under the radar.
Are you familiar with "FIPS 140-2"? Have you seen tamper evident seals on DOD Cisco routers? They have them for a reason - you could always find ways to bypass security. The goal of security process is to make it more difficult. But it is never impossible. There is also a reason Huawei and ZTE devices are banned in the US. If you can't trust the manufacturer or the distribution chain, you cannot trust the device.

Ok Bob, getting serious now.
Did you find some open port not mentioned by MikroTik here https://help.mikrotik.com/docs/display/ROS/Services
Or what is this trolling about?
Not to mention that all this "open ports bla bla" talk is completely offtopic.
AND the correct reply marked as solved should've been the 2nd post in this topic, by @mkx. viewtopic.php?t=186997&sid=42d17601791a ... 59#p941209
The rest of the netstat garbage is offtopic.

This is a related topic. The list of ports tells me nothing without seeing which ports are actually open. You seem to be going in circles failing to understand the simple requirement to expose the list of open ports. Not the list of ports that may or may not be open. Not the list of ports that are responding to port scan. The list of open ports.

"Built-in DNS server interfaces" and your initial post have nothing in common with your ranting that followed.
As suggested, submit a proper feature request.
Until then, use a proper firewall.
End of offtopic.

I for one think that being able to see more about internals would be good thing. Originally there wasn't even info about what's eating up CPU. Now there's Tools->Profile and it's definitely useful (except when something shows up as "unclassified"). But there's still room for improvements. Info about memory would be good next step, e.g. if you suspect a leak, to give you some idea where to look. And open ports fall in same category. Of course I wouldn't overestimate it, because anything breaking in system will likely get root anyway (I somehow doubt that everything in RouterOS is separated as much as possible) and make sure it's not seen. But it can still have some use.

I think the more info we have about different sections, the easier it will be to debug the network when needed.