I know this is an over discussed topic, I’ve followed http://forum.mikrotik.com/t/deny-outside-dns-on-port-53-permit-inside-dns/84285/1
Both TCP & UDP for dst-port 53 in iput chain on WAN interface are blocked, but nmap still shows UDP/53 is still open Nessus also detects that router replies to dns queries on UDP/53.
Firewall rules are triggered and logged as expected.
What can be wrong?
Here are the 2 rules:
The important difference is if the port just looks like open when tested by nmap (case 1), or if it actually is open and answers dns queries (case 2).
With tcp, unless the port is filtered (you drop incoming packets), it always sends something back and it’s different for closed and open port. But with udp, you can’t really tell the difference between filtered and open port, because there’s nothing sent back by default in both cases (I mean udp in general, not specifically dns). That’s why nmap shows perhaps a little confusing “open|filtered” state.
You need to test what’s actually happening. If it’s case 1, you can either ignore it, or reject packets intead of dropping them, to make the port look as closed (action=reject reject-with=icmp-port-unreachable). If it’s case 2, then you must have some other rule somewhere that allows the packets to slip through, before they get to your drop rule.
You were right, I rearranged the fw rules placing all the input chain filtering on top and it ended up a case 1 type (no real response to dns queries). Nessus scan turned all green now.
nmap still insists on detecting UDP/53 filtered/open.
I followed your advice and changed drop to reject-with-host-unreachable, although I see no more fw rule mattching on dst 53 UDP, even during the nmap scan!
Thank you very much for your response, it is greatly appreciated!