There are my first two firewall rules:
0 ;;; Drop incoming DNS requests
chain=input action=drop protocol=tcp dst-address=149.20.228.2 in-interface=ether1 - CMC Office dst-port=53 log=no log-prefix=""
1 ;;; Drop incoming DNS
chain=input action=drop protocol=udp dst-address=149.20.228.2 in-interface=ether1 - CMC Office dst-port=53 log=no log-prefix=""
But if I probe the WAN side of the router, nmap reports that the port is open. Why? How do I fix this?
Why?
For example in this default set of rules, the last rule is drop all and nothing else is required.
Link at Para B. - https://forum.mikrotik.com/viewtopic.php?t=182373
/ip firewall filter
{Input Chain}
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input in-interface-list=LAN
add action=drop chain=input comment="drop all else" *****
No unwanted traffic is permitted from the WAN to the Router. Done!!
In other words you dont need to add EXTRA rules.
Without seeing the rest of the config, there is no way to tell what you have done. 
/export hide-sensitive file=anynameyouwish
Since you say it’s your “first two” rules, which is confirmed by the numbers, I would assume you are using PPPoE as WAN, with ether1 as the bearer for the PPPoE client interface, or you have a WAN bridge with ether1 as one of the member ports of that bridge. If so, the rules do not match because ether1 is not an IP interface, so from the perspective of the IP stack (and thus the firewall), the packets came in via the PPPoE client interface or via the bridge interface.
If neither is the case, follow @anav’s suggestion to post the complete configuration. His other suggestion, to use the “let in what you want, drop the rest” approach instead of “drop what you don’t want, let in the rest”, is also valid (your legal users will let you know quickly if you forget to let something in, your illegal users will never let you know if you forget to prohibit something), but the “mystery” in the OP has to be resolved no matter which approach you choose, as otherwise you could lock yourself out of the router in better case, and keep it open for the “filth from the net” in the worst one.
Hes right, by default mikrotik FW rules when you check via port scanner DNS shows open(If you enable it in IP>DNS),i also manually close it to be sure…
What means “if you enable it in IP/DNS”. There is nothing to enable? The default firewall rule do not allow port 53.
IP>DNS>Allow remote requests, do open port check and it will show 53 as open, DEFAULT mikrotik firewall config latest OS version.
I assume he means enabling remote access ..
/ip dns
set allow-remote-requests=yes
However when I do that, my system does not show an open port when probed from the Internet, confirming what has already been stated that the firewall does not permit DNS by default. My rules on that router are default, except for the addition of some lines to permit remote access VPN.
For me nmap scan shows it as open, not every port scanner shows it as that for some reason.
Also you cant actualy make DNS requests over internet, its blocked, but shows open on nmap..
It may be time to do a full reset of the firewall rules and build them again based on current defaults and requirements.
Unfortunately there is no button in RouterOS to easily do that (you can reset the entire configuration to defaults but not just the firewall rules).
So it will require some manual work and someone who really understands how it all works.
concur, POST config…
/export hide-sensitive file=anynameyouwish
OP has not replayed to that.
If some blocks 53, its to block DNS. Then use DoH (or DoT ) and bypass this block.
So why block it?
We’re talking about inbound DNS requests from the Internet.
Why to block 53 for requests coming from the internet? Because if an attacker wants to get someone else in trouble, they find a DNS server responding requests coming from the internet, and send small queries, spoofing a source address and port of the victim, which they know to produce large responses. So the DNS server resolves these queries and sends the responses “back”, which actually means to the victim. So the actual attacker remains unknown even to the DNS server acting as “smurf amplifier”.
Still it is strange to have those rules, because you would normally block everything incoming from internet!
53 should not be open to internt by default.
@pyeager Please post full config and what you are trying to do and why.
Thank you all very much for taking the time to look at my issue and share your advice.
For those who asked “what is he trying to do?”, I am testing my network for PCI compliance to make sure it meets industry standards for credit card processing.
The scanner complains that I my router is interfering with the scan. As evidence of this it claims that too many ports are open. Probing my router’s IP address from another server with nmap shows around a thousand ports open. Port 53 is just one of them, and the one I was trying to close as a first step to solving this problem. There is no reason I can see for my router to accept connections on port 53 (or most of the others that appear open).
ether1 is connected to a cable modem.
Some suggested that default rules be restored, which makes sense. I am not sure how those rules were removed. I added those rules and moved them to the top of the list, but port 53 and others still show open when probed with nmap.
How are you probing with nmap (aka where are you plugging in)?
Try gibsons port checker too.
https://www.grc.com/x/ne.dll?bh0bkyd2
Forward chain.
You can remove this rule… port 53 is not a concern on forward chain and you have it effectively blocked on input chain.
You are creating either a security nightmare for yourself by allowing WANIPs access to devices, or its a rule with no effect as the forward chain is not to allow unrestricted access to ones LAN.
add action=accept chain=input comment=“Accept PCI vulnerability scan”
in-interface=“ether1 - CMC Office” src-address=64.37.231.0/24
The only mechanism to allow WAN clients to access your LAN should be through destination NAT.
That is port forwarding.
There is only one firewall rule required to allow destination NAT>
add action=accept chain=forward comment=“allow port forwarding” connection-nat-state=dstnat
All these look WRONG to me as well. INPUT CHAIN DOES NOT INCLUDE DST addresses on the LAN ???
add action=accept chain=input comment=
“Allow SNMP access to router from intranet server (nagios)” dst-address=
192.168.10.1 dst-port=161 protocol=udp src-address=192.168.10.30
add action=accept chain=input comment=
“Allow SNMP access to router from intranet server (nagios)” dst-address=
192.168.10.1 dst-port=162 protocol=udp src-address=192.168.10.30
add action=drop chain=input comment=“Block external SNMP access” dst-port=161
in-interface=“ether1 - CMC Office” protocol=udp src-address=0.0.0.0
add action=drop chain=input comment=“Block external SMNP access” dst-port=162
in-interface=“ether1 - CMC Office” protocol=udp src-address=0.0.0.0
This looks plain WRONG as well… Again INPUT CHAIN is to the router not to a device on the LAN.
add action=accept chain=input comment=“External Access to PTZ Lodge Cam”
dst-address=149.20.228.2 dst-port=1080 protocol=tcp