port 53 open despite firewall rules

torgr2019 · Fri Apr 02, 2021 3:25 pm

These are my first 4 firewall rules in ip>firewall>filter

add action=accept chain=input comment="defconf: accept established,related" connection-state=established,related
add action=drop chain=input connection-state=invalid
add action=drop chain=input dst-port=53 in-interface-list=WAN protocol=tcp
add action=drop chain=input dst-port=53 in-interface-list=WAN protocol=udp

No other rules above them.

Despite that, port 53 (both tcp and udp) in port scanning with nmap is open. Any ideas, how to filter that port?

anav · Fri Apr 02, 2021 3:45 pm

Yes, quite correct, the router is alive and has a mind of its own.
You are just a pawn in the evil plans of the router.

Post the complete config
/export hide-sensitive file=anynameyouwish

tdw · Fri Apr 02, 2021 3:50 pm

Most likely the interface you are scanning through is not a member of the WAN interface list, just conjecture without seeing the configuration.

torgr2019 · Fri Apr 02, 2021 5:10 pm

Here is my setup.
Internet is coming in through ethernet 1
I added also 2 drop rules in the forward chain, but same results.

/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN

/interface list member
add comment="WAN interface" interface=ether_01 list=WAN
add interface=bridge_lan list=LAN

/ip dhcp-client
add disabled=no interface=ether_01 use-peer-dns=no

/ip dns
set servers=1.1.1.1

/ip firewall filter
add action=accept chain=input connection-state=established,related
add action=drop chain=input connection-state=invalid
add action=drop chain=input dst-port=53 in-interface-list=WAN protocol=tcp
add action=drop chain=forward dst-port=53 in-interface-list=WAN protocol=tcp
add action=drop chain=input dst-port=53 in-interface-list=WAN protocol=udp
add action=drop chain=forward dst-port=53 in-interface-list=WAN protocol=udp
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN log=yes
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN

/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set sip disabled=yes
set pptp disabled=yes
set udplite disabled=yes
set dccp disabled=yes
set sctp disabled=yes

jvanhambelgium · Fri Apr 02, 2021 6:24 pm

/ip dns
set servers=1.1.1.1

And what else if configured ?? "Allow remote requests" ???

2frogs · Fri Apr 02, 2021 6:40 pm

Is this your full export? I also do not see any of your LAN settings. No bridge_lan or ports connected to it. No DHCP Server.

From what you have posted, you don't have DNS running on your device.

/ip dns
set allow-remote-requests=yes

Or you would see this present.

Jotne · Fri Apr 02, 2021 6:46 pm

Post the complete configuration.

/export hide-sensitive

torgr2019 · Fri Apr 02, 2021 7:27 pm

ip dns set allow-requests=no

I have declare DNS 1.1.1.1
dig google.com shows as dns server the 1.1.1.1 and i am just fine with that.

Why do you need my LAN config for a firewall problem?
The ether 1 is the WAN and all the others lan ports in bridge are LAN. Not so complicated.

All the relevant info is there.

The most interesting thing is that with exactly the same config in another mikrotik machine (RB941) the 53 port is filtered in nmap scanning. The machine with the open port is RB4011. I have also take a backup and RESET configuration. With the default config is the exact SAME problem.
Also if the scanning is : nmap - Pn -p 53 <IP address> the port is closed. If the scanning is nmap -sS (or -sU) -Pn -p 53 <IP> the port is open.

Jotne · Fri Apr 02, 2021 7:39 pm

Why do you need my LAN config for a firewall problem?

It gets a better overall picture on what is going on.
What other ports open/service running.
How the bridge/ports are configured.

If you post /export hide-sensitive and remove all sensitive IP, I do not see any reason for not posting your config.
At the same time post what version of RouterOS you are running on and what hardware.

torgr2019 · Fri Apr 02, 2021 8:34 pm

Here is the complete export
RB 4011
apr/02/2021 20:05:20 by RouterOS 6.47.9

/interface bridge

add admin-mac=******** auto-mac=no frame-types=admit-only-vlan-tagged ingress-filtering=yes name=bridge_lan vlan-filtering=yes

/interface ethernet

set [ find default-name=ether1 ] name=ether_01

set [ find default-name=ether2 ] name=ether_02

set [ find default-name=ether3 ] name=ether_03

set [ find default-name=ether4 ] name=ether_04

set [ find default-name=ether5 ] name=ether_05

set [ find default-name=ether6 ] name=ether_06

set [ find default-name=ether7 ] name=ether_07

set [ find default-name=ether8 ] name=ether_08

set [ find default-name=ether9 ] name=ether_09

set [ find default-name=ether10 ] name=ether_10

/interface vlan

add interface=bridge_lan name=vlan_50_management vlan-id=50

add interface=bridge_lan name=vlan_10 vlan-id=10

add interface=bridge_lan name=vlan_11 vlan-id=11

add interface=bridge_lan name=vlan_12 vlan-id=12

/interface ethernet switch port

set 0 default-vlan-id=0

set 1 default-vlan-id=0

set 2 default-vlan-id=0

set 3 default-vlan-id=0

set 4 default-vlan-id=0

set 5 default-vlan-id=0

set 6 default-vlan-id=0

set 7 default-vlan-id=0

set 8 default-vlan-id=0

set 9 default-vlan-id=0

set 10 default-vlan-id=0

set 11 default-vlan-id=0

/interface list

add comment=defconf name=WAN

add comment=defconf name=LAN

/ip pool

add name=dhcp_pool_vlan_50_management ranges=192.168.50.2-192.168.50.254

add name=dhcp_pool_vlan_10 ranges=192.168.10.2-192.168.10.254

add name=dhcp_pool_vlan_11 ranges=192.168.11.2-192.168.11.254

add name=dhcp_pool_vlan_12 ranges=192.168.12.2-192.168.12.254

/ip dhcp-server

add address-pool=dhcp_pool_vlan_50_management disabled=no interface=vlan_50_management name=dhcp_vlan_50_management

add address-pool=dhcp_pool_vlan_10 disabled=no interface=vlan_10 name=dhcp_vlan_10

add address-pool=dhcp_pool_vlan_11 disabled=no interface=vlan_11 name=dhcp_vlan_11

add address-pool=dhcp_pool_vlan_12 disabled=no interface=vlan_12 name=dhcp_vlan_12

/interface bridge port

add bridge=bridge_lan frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=ether_02 pvid=50

add bridge=bridge_lan frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=ether_03 pvid=10

add bridge=bridge_lan frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=ether_04 pvid=11

add bridge=bridge_lan frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=ether_05 pvid=12

add bridge=bridge_lan comment=defconf disabled=yes interface=ether_06

add bridge=bridge_lan comment=defconf disabled=yes interface=ether_07

add bridge=bridge_lan comment=defconf disabled=yes interface=ether_08

add bridge=bridge_lan comment=defconf disabled=yes interface=ether_09

add bridge=bridge_lan disabled=yes interface=ether_10

/ip neighbor discovery-settings

set discover-interface-list=none

/interface bridge vlan

add bridge=bridge_lan tagged=bridge_lan untagged=ether_02 vlan-ids=50

add bridge=bridge_lan tagged=bridge_lan untagged=ether_03 vlan-ids=10

add bridge=bridge_lan tagged=bridge_lan untagged=ether_04 vlan-ids=11

add bridge=bridge_lan tagged=bridge_lan untagged=ether_05 vlan-ids=12


/interface list member

add comment="WAN interface" interface=ether_01 list=WAN

add interface=vlan_50_management list=LAN

add interface=vlan_10 list=LAN

add interface=vlan_11 list=LAN

add interface=vlan_12 list=LAN

add interface=bridge_lan list=LAN

/ip address

add address=192.168.50.1/24 interface=vlan_50_management network=192.168.50.0

add address=192.168.10.1/24 interface=vlan_10 network=192.168.10.0

add address=192.168.11.1/24 interface=vlan_11 network=192.168.11.0

add address=192.168.12.1/24 interface=vlan_12 network=192.168.12.0

/ip cloud

set update-time=no

/ip dhcp-client

add disabled=no interface=ether_01 use-peer-dns=no

/ip dhcp-server network

add address=192.168.50.0/24 gateway=192.168.50.1 netmask=24

add address=192.168.10.0/24 gateway=192.168.10.1 netmask=24

add address=192.168.11.0/24 gateway=192.168.11.1 netmask=24

add address=192.168.12.0/24 gateway=192.168.12.1 netmask=24

/ip dns

set servers=1.1.1.1

/ip firewall filter

add action=drop chain=input dst-port=53 in-interface-list=WAN log=yes protocol=tcp

add action=drop chain=forward dst-port=53 in-interface-list=WAN protocol=tcp

add action=drop chain=input dst-port=53 in-interface-list=WAN protocol=udp

add action=drop chain=forward dst-port=53 in-interface-list=WAN protocol=udp

add action=accept chain=input connection-state=established,related

add action=drop chain=input connection-state=invalid

add action=accept chain=input protocol=icmp

add action=accept chain=input dst-address=127.0.0.1

add action=drop chain=input in-interface-list=!LAN log=yes

add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec

add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec

add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related

add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked

add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid

add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

/ip firewall nat

add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN

/ip firewall service-port

set ftp disabled=yes

set tftp disabled=yes

set irc disabled=yes

set h323 disabled=yes

set sip disabled=yes

set pptp disabled=yes

set udplite disabled=yes

set dccp disabled=yes

set sctp disabled=yes

/ip service

set telnet disabled=yes

set ftp disabled=yes

set www disabled=yes

set ssh disabled=yes

set www-ssl address=************************ certificate=******************* disabled=no tls-version=only-1.2

set api disabled=yes

set winbox address=****************************************************************

set api-ssl disabled=yes

/ip ssh

set strong-crypto=yes

/system clock

set time-zone-name=*****************************

/system console

add disabled=no port=serial1

/system identity

set name=*****************************

/system ntp client

set enabled=yes server-dns-names=pool.ntp.org

/system package update

set channel=long-term

/tool bandwidth-server

set enabled=no

/tool mac-server

set allowed-interface-list=none

/tool mac-server mac-winbox

set allowed-interface-list=LAN

/tool mac-server ping

set enabled=no

Jotne · Fri Apr 02, 2021 8:37 pm

Edit your post.
Select the code part and click the code button. </>

Do you scan the router on the WAN or LAN side?

jvanhambelgium · Fri Apr 02, 2021 8:44 pm

Can you post some logging ? And also enable the logging for the other 3 rules below.
Then basically perform this nmap scan from exterior and post some logging ? Just to make sure these rules are effectively hit ?

add action=drop chain=input dst-port=53 in-interface-list=WAN log=yes protocol=tcp
add action=drop chain=forward dst-port=53 in-interface-list=WAN protocol=tcp
add action=drop chain=input dst-port=53 in-interface-list=WAN protocol=udp
add action=drop chain=forward dst-port=53 in-interface-list=WAN protocol=udp

Since there is for these rules no "state" flags selected (eg. new,invalid,...) I would assume ANY state would be dropped in the incoming packets, so that should not be a problem.

torgr2019 · Fri Apr 02, 2021 8:46 pm

Here is the command in nmap and the result:

sudo nmap -sS -sU -sV -Pn -p 53 <external IP address> (from a machine outside the LAN)
Starting Nmap 7.70 ( https://nmap.org ) at 2021-04-02 19:55 EEST
Nmap scan report for ******************************
Host is up (0.0025s latency).

PORT STATE SERVICE VERSION
53/tcp open domain dnsmasq 2.79
53/udp open domain dnsmasq 2.79
MAC Address: ******************* (Unknown)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.34 seconds

torgr2019 · Fri Apr 02, 2021 8:52 pm

How can i filter the logs only for port 53 in firewall?

Jotne · Fri Apr 02, 2021 9:16 pm

Configuration looks OK. Normally you should not need to block port 53 on outside, nor should it be open by it self.
I have no linux server outside, so can not test my port.

Do you see any count increase on your firewall rule when you test port 53?

torgr2019 · Fri Apr 02, 2021 9:23 pm

Configuration looks OK. Normally you should not need to block port 53 on outside, nor should it be open by it self.
I have no linux server outside, so can not test my port.

Do you see any count increase on your firewall rule when you test port 53?

No, the counters are freeze.
I think that the whole process of nmap is not reaching the firewall rules. Have no idea why.
It is something more fundamental wrong, beneath the user configuration, maybe a security flaw.

jvanhambelgium · Fri Apr 02, 2021 9:42 pm

Configuration looks OK. Normally you should not need to block port 53 on outside, nor should it be open by it self.
I have no linux server outside, so can not test my port.

https://pentest-tools.com/network-vulne ... nline-nmap

Just try a free scan ? It will test 53 also in the "free" edition
In my case I have 0 ports open so that's good.

torgr2019 · Fri Apr 02, 2021 9:50 pm

Configuration looks OK. Normally you should not need to block port 53 on outside, nor should it be open by it self.
I have no linux server outside, so can not test my port.
https://pentest-tools.com/network-vulne ... nline-nmap

Just try a free scan ? It will test 53 also in the "free" edition
In my case I have 0 ports open so that's good.

It is not helpful. If you scan with classic nmap query "sudo nmap -sV -p 53 <IP>"
without the -Pn then the answer is that the host seems down.
Just try a nmap scan even from a raspberry pi...Ideally in a RB4011 because another RB that i have behave normally

Jotne · Fri Apr 02, 2021 9:52 pm

Did test my server with the same command as above.

nmap -sS -sU -sV -Pn -p 53 92.220.xx.yy
Starting Nmap 7.80 ( https://nmap.org ) at 2021-04-02 20:43 CEST
Nmap scan report for x.y.z(92.220.xx.yy)
Host is up.

PORT STATE SERVICE VERSION
53/tcp filtered domain
53/udp open|filtered domain

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 104.45 seconds

So from this test it looks up, but DNS does not resolve anything.

nslookup
> server 92.220.xx.yy
Default server: 92.220.xx.yy
Address: 92.220.xx.yy#53
> google.com
;; connection timed out; no servers could be reached
>

Another thing I did see, is that IP entered my block list.
I have a rule that if someone tries any port on my router that is not open, it will be blocked for 24 hour on all port, even open ports.
So this may just be some ghost errors. Do not think anything are in dangerous.

PS no need to quote the post above, use Post Reply under the post to reply to it.

torgr2019 · Fri Apr 02, 2021 9:57 pm

Your results are different.
TCP filtered means blocked by firewall.
UDP open/filtered means no response from the server ==> blocked by firewall.

Your machine seems to work as expected.

In my 4011 when i perform the test:
1. The ports are open, that means that the router responds with an ACK to the SYN of the nmap. Its not false positive.
2. The firewall counters are not catching anything. And the rules are at the TOP. That means that something is wrong inside the routerOS that we cannot see.

Any ideas how can i check it or solve it?

Jotne · Fri Apr 02, 2021 10:07 pm

I do use 6.48.1, so you can try to upgrade.
Test using default config is a mayor operation, so that may not be possible.

Try to add these two rule at the bottom of you filter list to pick up anything that has not been logged before.

/ip firewall filter
add action=log chain=input protocol=tcp
add action=log chain=input protocol=udp

I do also see a difference from me, that I do miss from your config.
Last rule in firewall should be drop, since default is allowed if no rule are found.

Here is a visio drawing of my rules.

fw-rules.jpg

torgr2019 · Fri Apr 02, 2021 10:22 pm

My last input rule is a DROP

add action=drop chain=input in-interface-list=!LAN log=yes

I have tried something different:

Scan without -p53 (specific port argument in nmap) shows all ports filtered and the counters of the rules at the top of my firewall is increasing.
When i run the exact same command with -p53 then the firewall counters not catching anything and the nmap shows the port open.

Where can i see the log of the firewall? At the general log?

Upgraded just now to your version. Let see if anything change.

mkx · Fri Apr 02, 2021 10:41 pm

My guess is that your ISP is redirecting/blocking connections to port 53 (DNS server) ... possibly in attempt to block DDoS attacks which abuse mis-configured routers of your ISP's clients.

torgr2019 · Fri Apr 02, 2021 10:54 pm

I tried also
nc -w5 -z -v <MyIP> 53
and
Connection to <MyIP> 53 port [tcp/domain] succeeded!

I dont know what to say....

How my ISP can make a port in my router to respond to requests?

mkx · Fri Apr 02, 2021 11:02 pm

I tried also
nc -w5 -z -v <MyIP> 53
and
Connection to <MyIP> 53 port [tcp/domain] succeeded!

I dont know what to say....

How my ISP can make a port in my router to respond to requests?

You ran the command from where? If you ran it from a device connected directly to WAN interface of your router, then indeed your router is replying. If you ran it from some internet host, then there's a plethora of devices between nmap host and your router, including ISP who might be running a (simple) firewall on it's upstream edge. If you ran it from your LAN, then again it's your router but possibly different set of firewall rules apply (and dst IP address used doesn't matter much).

torgr2019 · Fri Apr 02, 2021 11:21 pm

The commands are from my router WAN.
The exact same commands (nmap and nc -w5 -z -v <MyIP> 53) when tested at the exact same config with RB941 that i had spare, working as expected. POrt 53 is closed.
WTF?
Should i netinstall clean firmware?
And how can i do it?

mkx · Fri Apr 02, 2021 11:36 pm

Should i netinstall clean firmware?
And how can i do it?

Netinstalling your device would certainly be a good action. Prior to doing it do export of configuration (/export file=yourexport) so task of configuring the unit afterwards will be easier. The process of netinstalling is quite well documented.

torgr2019 · Sat Apr 03, 2021 1:31 am

Tried netinstall and failed.
Followed the instructions carefully but the router didnt came visible to the application.
i dont know...

anav · Sat Apr 03, 2021 4:41 am

I think your DNS rules are the problem.

This works just fine...........
THe key here is to only allow the admin to the router itself
and only allow USERS on the LAN to access the DNS servers.
To accomplish this make sure you construct an allow rule first for the admin to access the router in the input chain.
/ip firewall filter
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 comment="Allow ADMIN to Router" log-prefix=\
AdminAccess src-address-list=adminaccess in-interface-list=LAN
add action=accept chain=input comment="Allow LAN DNS queries - TCP" \
connection-state=new dst-port=53 in-interface-list=LAN protocol=tcp
add action=accept chain=input comment="Allow LAN DNS queries-UDP" \
connection-state=new dst-port=53 in-interface-list=LAN protocol=udp
add action=drop chain=input comment="Drop All Else"

Where you need to make a firewall address list (assuming fixed LANIps of admin devices)
/ip firewall address-list
add address=LANIP of admin desktop list=adminaccess
add address=LANIP of admin latptop list=adminaccess
add address=LANIP of admin smart phone list=adminaccess

AS for the forward chain there is NO NEED for any dns port 53 rules.
last rule in forward chain should also be drop all else.

torgr2019 · Sat Apr 03, 2021 8:10 am

@anav
My firewall rules are not the problem.
Why?
Because my first no1 rule in the filter is
chain=input action=drop protocol=tcp in-interface=ether_01 dst_port=53 log=yes

What is the result of this rule?
When i run
sudo nmap -sS -sU -Pn <WAN IP>
all ports are fitered
AND the firewall is working because in the log file i catch the entries of dropping the packets.

When i run
sudo nmap -sS -sU -Pn -p53 <WANIP>
the port is open
AND the firewall is not working and the log file is empty.

Obviously the problem is that nmap uses a different approach when scanning is at specific port OR SMALL port ranges (same result with -p 30-60) and that approach evades my firewall.

The next step is to try someone else the same approach, nmap with -p53 at a RB4011 because i think it is something specific to this RB. I have also a spare RB941 that works just fine.

So the question is: is it my RB 4011 or is it a generic issue of RB4011? tried to downgrade the firmware... nothing. tried to reset to default config, same behaviour.

So forget my local firewall config. It is something different.

jvanhambelgium · Sat Apr 03, 2021 11:46 am

This is really a weird story.
Can you take a packet CAPTURE in the ingress interface in the case you log remains empty ? (sudo nmap -sS -sU -Pn -p53 <WANIP>) just to confirm the nmap probing actually arrives ?!

torgr2019 · Sat Apr 03, 2021 12:19 pm

i have used Packet sniffer inside routerOS.
Filters: ether 01, tcp 53, direction any, filter operation AND.
When sudo nmap -sS -Pn <IP> packets are visible, firewall is working and packets blocked. Nmap says all ports are filtered.
When sudo nmap -sS -Pn -p 53 <IP> packets not coming, and obviously firewall do nothing. But Nmap says port is open.

So the real question is:
Is it a bug of nmap OR is it a method of evading the packet discovery and eventually the firewall?

Any ideas to differentiate between the 2?

PS: Exactly the same results with Torch. With -p 53 packets are not coming OR are not visible.
Exactly the same query (sudo nmap -sS -Pn -p22 <IP> at port 22 is working fine. Packets are coming, packets are been blocked as expected). That makes me think that it is not a bug of nmap. It is something else.
Also the fact that the same query at another mikrotik RB produces different results makes me crazy. The same -p53 at RB 941 is normally visible and rejected by the firewall.

jvanhambelgium · Sat Apr 03, 2021 12:27 pm

i have used Packet sniffer inside routerOS.
Filters: ether 01, tcp 53, direction any, filter operation AND.
When sudo nmap -sS -Pn <IP> packets are visible, firewall is working and packets blocked. Nmap says all ports are filtered.
When sudo nmap -sS -Pn -p 53 <IP> packets not coming, and obviously firewall do nothing. But Nmap says port is open.

So the real question is:
Is it a bug of nmap OR is it a method of evading the packet discovery and eventually the firewall?

Any ideas to differentiate between the 2?

Very hard to believe the packet-capture (very low level) would "miss out" on your nmap packets which are supposed to come in.
Did you try with -sS -Pn -p U:53 or something too and see if you would actually capture an UDP:53 packet in ingress ?

torgr2019 · Sat Apr 03, 2021 12:50 pm

yes i have tried -p with all possible combinations.
-p 53
-p T:53
-p U:53

same results.
As long as there is -p argument the packets either not coming or coming invisible.
same command in same environment with RB941, packets are coming and blocked.

Tried to change WAN port to ether10, same results. So seems not a hardware problem with ether1.

jvanhambelgium · Sat Apr 03, 2021 1:14 pm

What is a bit disturbing is the fact that you've tried with a RB941 and that box seems to behave as it should...
Not being able to even capture these nmap packets on the RB4011 is ... weird to say the least...
I'm running 6.47.7 on my RB3011
Feel free to probe my system on services.vanham-franck.be and I wonder if I would find them back in the logs.

torgr2019 · Sat Apr 03, 2021 1:18 pm

i am now creating a virtual environment that actually i will set the router behind another router (double NAT) and i will try to test again.
To set ISP DNS interference out.

I will post my findings.

anav · Sat Apr 03, 2021 2:10 pm

Still, would like to see the results of the config I recommended.
That would be more convincing.

torgr2019 · Sat Apr 03, 2021 2:39 pm

I am almost pretty sure its ISP related...
Putting 4011 behind 941 made 4011 work as expected.
Still its a mystery why 941 is not affected by ISP.
Still to find out why the fast scan without -p 53 works fine and what the specific scan with -p 53 triggers maybe in ISPs WAN to redirect the packets...
Still do not know for sure how to prove that its ISPs DNS "hijacking" but i found also this

https://security.stackexchange.com/ques ... gets-ports

mkx · Sat Apr 03, 2021 3:50 pm

You could try to run TCP traceroute ... targeting same destination IP address, but different standard TCP ports (e.g. 443 along with 53) and compare the path.

And choose some normal destination known not to be hosted by some large cloud hosting company as those tend to geographically distribute service and they may play different tricks for different services. You can try to target mikrotik's servers: authoritative DNS server for domain mikrotik.com has (for me at least) IP address 159.148.147.194 while www.mikrotik.com has IP address 159.148.147.196 which quite likely means they're both in same subnet and thus traced route should not differ (apart from final hop).
BTW, routers of Telia Latvia seem not to respond with ICMP time exceeded ...

torgr2019 · Sat Apr 03, 2021 4:29 pm

I think that the whole story is DNS "hijacking" aka redirection from ISP.
This is the only reasonable explanation why the packets never reached 4011 and of course never triggered firewall etc.
This is the only reasonable explanation why the problem was only at port 53.
This is the only reasonable explanation why when i hide the router behind 941, port was filtered (obviously the scan was done at the space between 941 and 4011).
I will try on Monday to move the router to another ISP in a friends home to test it to be absolutely sure.
Still not know why RB941 was immune against DNS hijacking or redirection more polite.

Thank you all for the help.
All the best.

R1CH · Sat Apr 03, 2021 8:01 pm

Yes, this is exactly what happens. A Mikrotik router does not run "dnsmasq", it is instead home-grown MT DNS server. So an ISP in between the place you are scanning from and your router is intercepting your DNS queries. This is why users should use DoH / DNSCrypt / etc to prevent this kind of abuse from ISPs.

Jotne · Sat Apr 03, 2021 8:57 pm

This is why users should use DoH / DNSCrypt / etc to prevent this kind of abuse from ISPs.

¨
Sadly its broken in all current version of RouterOS with a memory leakage. When that is fixed I will for sure turn DoH back on.
There are noe reason for my ISP (government or other) to be able to look at my DNS requests.

memborsky · Sat May 01, 2021 3:38 am

I want to add more data to this post for if someone else happens to run across this issue themselves as well. I was experiencing the exact same issue as the OP was describing, nmap was showing port 53 as being open. In my case, the router was also responding to DNS requests. I have all the same firewall rules placed in the same location and order as well as the allow-remote-requests set to no under "/ip dns".

However, what I'm doing that is not the same as the OP is dst-nat'ing all dns queries to my own internal DNS server to combat devices that do not adhere to the DHCP settings that are given out and attempt to use their own settings instead.

The resolution for my problem was to add "in-interface-list=!WAN" to both of these nat rules, which prevents it from accepting any DNS queries on the WAN interface, as well as showing as open with nmap.

/ip firewall nat
add action=dst-nat chain=dstnat dst-address=!X.X.X.X dst-port=53 in-interface-list=!WAN log=yes log-prefix=NAT-DNS-TO-X.X.X.X protocol=tcp to-addresses=X.X.X.X to-ports=53
add action=dst-nat chain=dstnat dst-address=!X.X.X.X dst-port=53 in-interface-list=!WAN log=yes log-prefix=NAT-DNS-TO-X.X.X.X protocol=udp to-addresses=X.X.X.X to-ports=53

chknpikr · Mon Feb 13, 2023 12:04 am

I want to add more data to this post for if someone else happens to run across this issue themselves as well. I was experiencing the exact same issue as the OP was describing, nmap was showing port 53 as being open. In my case, the router was also responding to DNS requests. I have all the same firewall rules placed in the same location and order as well as the allow-remote-requests set to no under "/ip dns".

However, what I'm doing that is not the same as the OP is dst-nat'ing all dns queries to my own internal DNS server to combat devices that do not adhere to the DHCP settings that are given out and attempt to use their own settings instead.

The resolution for my problem was to add "in-interface-list=!WAN" to both of these nat rules, which prevents it from accepting any DNS queries on the WAN interface, as well as showing as open with nmap.
Code: Select all
/ip firewall nat
add action=dst-nat chain=dstnat dst-address=!X.X.X.X dst-port=53 in-interface-list=!WAN log=yes log-prefix=NAT-DNS-TO-X.X.X.X protocol=tcp to-addresses=X.X.X.X to-ports=53
add action=dst-nat chain=dstnat dst-address=!X.X.X.X dst-port=53 in-interface-list=!WAN log=yes log-prefix=NAT-DNS-TO-X.X.X.X protocol=udp to-addresses=X.X.X.X to-ports=53

Thanks so much for this. This was driving me crazy.

Who is online