User misconfiguration keeps port 53 open on the wan interface

So either you have found a huge security hole that noone else using openwrt has noticed or reported. Or your scan is reporting results from the LAN-side (where it's expected this ports would be open). Out of those 2 which do you think is the more reasonable explanation?

If you're sticking with your opinion would you mind posting the full contents of /etc/config/firewall from the router(s) in question? Just so we can understand where this security hole has come from..

1 Like

disable dnsmasq service? :slight_smile:
I need it, I don't want to turn it off :slight_smile:

you just live in some other world and tell that it is not possible to scan your wan address from the lan network, and you are not the only one, as I noticed. And I tell you that it is possible and very simple, the name of the utility. Where have you all been these 18 years, I do not understand.

I can tell you how to set up the utility and check it yourself, otherwise, most importantly, none of you checked it yourself and write that this cannot be. You first check your router yourself, and then tell.
And check with my method, not yours, which, as I understand it, does not work

Fine, what is this process? And why do you think it enables you to see what ports are open on the WAN side?

Maybe there's a reason for that. You are making an extraordinary claim so if you want people to believe you, especially when it is contrary to accepted networking normals, then you need to do better than simply insisting you must be right. For example, what have you done to close these ports? If you could explain that then we'd be better able to understand what's going on and why.

3 Likes

No, not another world. In a Zone-based firewall, when you are on LAN, the firewall uses LAN rules. This should be obvious, because LAN is in the LAN Zone.

That's what multiple posters have told you already. You seem unwilling to believe us.

:spiral_notepad: So you issue is that these ports are scanning from LAN, as posters have been telling you.

It's indeed possible, but the results are unreliable, since closed ports could be reported as open.

The scan doesn't bounce off any internet host, so you're scanning (from) the wrong side of the firewall.

Most daemons will bind to all network interfaces, including WAN, giving you the false positives, when scanning.

You can always force most daemons only to bind to the LAN IP, but it won't really change anything, security wise.

Want to do it properly?
Share internet from your phone, scan your public IP via your phones ISP.

1 Like

(The sad thing is, the OP doesn't understand Zone-based firewalls. So no matter how much we explain to the OP that they are testing from LAN, they will still believe it's OK to test WAN from the wrong zone. Now they think we're bashing their 18-year-old port scanner, instead of understanding that we're trying to explain - to run the scanner from WAN.)

EDIT: Furthermore the 40,000 port results are likely from LAN being set to ACCEPT and the Kernel itself rejecting or resetting the test connections due to no service listening.

1 Like

It would seem so, too bad he kept talking about WAN scanning, even though the scan was made from the LAN side, and never answered the question, when asked ...

1 Like

Send your IP to your friend and ask to scan it on the port 53 with nmap

namp -p 53 <yourIP>

(or do it yourself from a free VPS or when you are connected from outside your home) then report here.

1 Like

https://www.grc.com/x/ne.dll?bh0bkyd2

(Posters told the OP multiple times to scan from outside - nonetheless, they believe their LAN scan is valid and providing results for WAN.)

1 Like

Do you want to apologize for this libelous statement?

6 Likes

On a subnet router (dev box with WAN plugged into local LAN, configured with SSH and HTTP/S open on WAN):

β”Œβ”€ 08:57 root@rtr02
└─ ~$ opkg install luci-app-https-dns-proxy
Installing luci-app-https-dns-proxy (2021-11-22-7) to root...
...
Configuring ucode-mod-lua.
...
Configuring https-dns-proxy.
Starting https-dns-proxy 2022-10-15-10 βœ“βœ“
Configuring luci-app-https-dns-proxy.

Do a check on the router, yup, it's running...

β”Œβ”€ 08:58 root@rtr02
└─ /etc/config$ netstat -tunlp | grep 'http.*dns'
udp        0      0 127.0.0.1:5053          0.0.0.0:*                           28167/https-dns-pro
udp        0      0 127.0.0.1:5054          0.0.0.0:*                           28166/https-dns-pro

Then scan the router's WAN from an EXTERNAL workstation:

β”Œβ”€ 8:58 efahl@brainjar
└─ ~$ nmap 10.1.1.3
Starting Nmap 7.92 ( https://nmap.org ) at 2023-01-25 08:58 Pacific Standard Time
Nmap scan report for rtr02.brain.lan (10.1.1.3)
Host is up (0.00068s latency).
Not shown: 997 closed tcp ports (reset)
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https
MAC Address: 7C:2B:E1:15:23:A7 (Shenzhen Ferex Electrical)

Nmap done: 1 IP address (1 host up) scanned in 42.86 seconds

What do you know? No DNS ports open on WAN, but SSH and HTTP/S open as expected.

And on an INSIDE workstation connected to the router's LAN, we scan the router's WAN address and see dnsmasq at 53, but not the proxy (because, well, it's on 5053 and 5054, and only listening to the loopback anyhow):

efahl@dendrite:~> nmap 10.1.1.3
Starting Nmap 7.80 ( https://nmap.org ) at 2023-01-25 09:03 PST
Nmap scan report for 10.1.1.3
Host is up (0.00074s latency).
Not shown: 996 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
53/tcp  open  domain
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 38.18 seconds

Port 53 appears to be exposed, but this is as expected since I'm scanning the network from the WRONG SIDE of the firewall.

6 Likes

Thnx, was going to post the same (but forgot), but I'm pretty sure @fkl7834456 already left this thread through the back door...

3 Likes

Ahah this thread is material for: r/masterhacker :grin:

2 Likes

pun intended.

1 Like

If you are unsure of your firewall configuration skills you can easily restrict DNSMASQ from binding to some interfaces.

By default, dnsmasq servivce is configured with '-bind-dynamic / option nonwildcard' parameter set.
This means that if new interfaces or addresses appear in the system, it automatically listens on those.

To exclude some interfaces from binding by DNSMASQ:

  1. Edit '/etc/config/dhcp' config file

nano /etc/config/dhcp

  1. Find the 'config dnsmasq' section.
  2. Add the following options:
config dnsmasq
	...
	list	notinterface		'eth0'
	list	notinterface		'eth0.2'
	list	notinterface		'wan'
	list	notinterface		'tun*'
	list	notinterface		'wg*'
	list	notinterface		'vpn*'
	...

Note that 'eth0' and 'eth0.2' in the example above are representing physical and virtual (tagged) WAN interfaces. On different router models the name of the WAN interface would be different, you should replace 'eth0' and 'eth0.2' with the corresponding WAN interfaces names.
Also note, not to use wildcards * with the names of virtual WAN interfaces. That's because virtual (tagged) WAN interface name contains dot in it (eth0.2 in the example above) but wildcards are not working in this case e.g eth0* will not match the eth0.2 interface name.

  1. Restart DNSMASQ to apply changes:

/etc/init.d/dnsmasq restart

  1. Verify results:
netstat -lenpW | egrep "(:53)"
find /tmp/ -name '*dns*' -type f -exec ls -l {} \;
1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.