Testing LAN - Unwanted exposed ports on the WAN

wrtfan · February 8, 2019, 8:44pm

I am new to OpenWRT.

I installed it, got a WAN ip using DHCP from my ISP.

Then I did an nmap scan to check open/vulnerable ports.

I was a bit shocked to see that three ports were open 22,53 and 80.

My understanding was that the WAN side should have no ports open at all.

There is a difference on the ports when connected through the WAN or LAN, but i dont want the ports to show up as open at all !

I managed to close the port 22 by turning SSH off and on again ( no idea what happpened ).
Then I disabled the web interface(/etc/init.d/uhttpd stop)

Now the last open port is port 53, I cant figure out how to close this one for incomming traffic on the WAN, or is this nessesary for the DNS in some strange way?

darksky · February 8, 2019, 9:05pm

Are you sure that you're not scanning to the LAN ip and not the WAN ip? (Internal vs. external)? Try a tool like this one for port scanning to the external IP: https://www.grc.com/shieldsup

psherman · February 8, 2019, 9:49pm

@wrtfan - Exactly as @darksky said, you are probably probing the LAN, as those ports are ssh, dns, and http (ssh and http are for you to be able to log in and configure your router, dns is a more-or-less universal thing to need).

Going one step further than @darksky, try probing your network from a device that is not connected to your network (go to work/school/library/friend, etc. or you can use your mobile phone with wifi disabled so that it uses cellular data). The reason this is important is that some of the port scanning websites will use an app embedded in the page that runs locally on your machine to do the probing, and therefore if it is running on a device from within the network, it may report LAN side open ports).

trendy · February 8, 2019, 10:38pm

Probably was not needed there
The default firewall configuration does not expose those ports on the WAN zone.

wrtfan · February 9, 2019, 8:41am

Thanks for the responses.

I used an online scan tool, and the port shows up as filtered. Thus it is quite certain true that it is closed on the WAN side.

The scan that i peformed before was done like this:

curl ifconfig.me
w.a.n.x < this is the WAN ip 
nmap -p 53 --open w.a.n.x

PORT   STATE SERVICE
53/tcp open  domain

So it seems that when I test the port from within the LAN network somehow it turns up to be open on the WAN side ? What is going on here?

Look netstat info below
root@noone:~# netstat -an | grep 53 
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      
tcp        0      0 192.168.1.1:53          0.0.0.0:*               LISTEN      
tcp        0      0 w.a.n.x:53          0.0.0.0:*               LISTEN          
udp        0      0 127.0.0.1:53            0.0.0.0:*                           
udp        0      0 192.168.1.1:53          0.0.0.0:*                           
udp        0      0 w.a.n.x:53          0.0.0.0:*                           
                               
root@noone:~# netstat -pln | grep 53 
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      10586/dnsmasq
tcp        0      0 192.168.1.1:53          0.0.0.0:*               LISTEN      10586/dnsmasq
tcp        0      0 w.a.n.x:53          0.0.0.0:*               LISTEN      10586/dnsmasq
udp        0      0 127.0.0.1:53            0.0.0.0:*                           10586/dnsmasq
udp        0      0 192.168.1.1:53          0.0.0.0:*                           10586/dnsmasq
udp        0      0 w.a.n.x:53          0.0.0.0:*                           10586/dnsmasq

Is this normal?

lleachii · February 9, 2019, 12:49pm

Not sure if this a joke...you are aware that you accept traffic that orginates from LAN!

LOL yes!

You been told 3 times above that you were testing from LAN, so why do you insist something's wrong instead of believing them?

vgaetera · February 9, 2019, 1:12pm

OpenWrt firewall is based on a zone model.
Zone assignment relies on the network interface, which receives/sends traffic.
So when you test open ports from LAN, it uses LAN-zone policy, and IP-address doesn't matter.

lleachii · February 9, 2019, 1:19pm

@wrtfan, if you can install the LuCI web GUI, this becomes apparent:

Screenshot%20from%202019-02-09%2008-19-35

jeff · February 9, 2019, 3:46pm

netstat -anl or the like doesn't show what the firewall allows, only what sockets are listening. It is not surprising that an application open a listener on all interfaces' IP addresses, or on the wildcard address. For many services, listening on all interfaces is the default configuration. In cases where the service should not be provided to a given topological domain, access to the listener can be blocked by the firewall.

Many applications allow the listeners to be specified in config. How this is done will vary by application and may not be available through LuCI, or even through the OpenWrt UCI configuration files.

trendy · February 9, 2019, 7:19pm

If you @wrtfan want to limit the interfaces that SSH, HTTP, and NS listen to, you can fine tune it in the configuration of each service.
For SSH in /etc/config/dropbear you add the line

        option Interface 'lan'

under config dropbear

For HTTP in /etc/config/uhttpd add the lines

        list listen_http '192.168.1.1:80'
        list listen_https '[fe80:...::1]:443'

under config uhttpd main

And for DNS in /etc/config/dhcp you add the lines

        option nonwildcard '1'
        list notinterface 'pppoe-wan'

or you can allow interfaces, under config dnsmasq
Interface names and IP addresses are examples, you should adjust them to yours.

eduperez · February 9, 2019, 10:17pm

Even if you use the WAN address, when you test from the LAN you test the LAN interface, not the WAN interface; you need to test from an external computer.

togepy · February 17, 2019, 6:32pm

default：wan Input (reject／拒絕) Forward (reject／拒絕)
sample test： https://www.grc.com/su/UPnP-Rejected.htm

My advice：wan Input (drop／丟棄) Forward (drop／丟棄)
sample test：https://www.grc.com/su/UPnP-NoResponse.htm

English LuCI

zh-tw 繁體中文 LuCI