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..
disable dnsmasq service?
I need it, I don't want to turn it off
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.
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.
So you issue is that these ports are scanning from LAN, as posters have been telling you.
(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.
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 ...
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.
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:
Edit '/etc/config/dhcp' config file
nano /etc/config/dhcp
Find the 'config dnsmasq' section.
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.
Restart DNSMASQ to apply changes:
/etc/init.d/dnsmasq restart
Verify results:
netstat -lenpW | egrep "(:53)"
find /tmp/ -name '*dns*' -type f -exec ls -l {} \;