DNS (and other services) available via WAN port

[grueneedv]

We run a FreiFunk Router directly attached to the internet with an own IPv4 address. We recently got informed from our provider that we run an open dns resolver at this box from the public IP (we use VPN tunnel). I wasn't aware of that since I pretty much used all defaults I could find and thought all traffic goes through the VPN tunnel.

I helped myself now with adding manually at the startup script (/etc/init.d/dnsmasq) behind -k "--except-interface=eth0.2" and it worked accordingly to http://www.openresolver.com/ Online Check.

I strongly recommend to set this default, that no dns querys can be made at the WAN interface. I don't mean it in the quirky manner I did this now but generally. Maybe this little heaty discussion: https://dev.openwrt.org/ticket/14951 helps sorting things out.

[sarumpaet]

As per https://dev.openwrt.org/ticket/14951#comment:18 this should be fixed in current master anyways (need to check). We should perhaps add an option to the assistent that disallows any external access on the WAN port for people who connect the FF router to a modem directly - it's not only DNS but also SSH/HTTP(S)/OLSRd port 689+2006+9090. Then again this is quite a bit of hassle to implement (and test); perhaps covering this in some documentation would be better for the few people who need it.

[lynxis]

enable the firewall on that interface?

[lynxis]

IMHO: this is not an upstream problem.

[SvenRoederer]

I recently setup a fresh OpenWRT 15.05.1 and there was no open external port (for PPPoE dialup). So I agree to @lynxis .

Manual checking of the iptables-rules looks like all ports are blocked for the WAN-zone Chain INPUT (policy ACCEPT 3632 packets, 415K bytes) pkts bytes target prot opt in out source destination 2532K 3250M delegate_input all -- * * 0.0.0.0/0 0.0.0.0/0 ` Chain delegate_input (1 references) pkts bytes target prot opt in out source destination 41397 247M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 2491K 3003M inputrule all -- * * 0.0.0.0/0 0.0.0.0/0 /* user chain for input / 1245K 1468M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 15 952 syn_flood tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 541 17312 zone_wan_input all -- eth1.9 * 0.0.0.0/0 0.0.0.0/0 Chain zone_wan_input (1 references) pkts bytes target prot opt in out source destination 541 17312 input_wanrule all -- * * 0.0.0.0/0 0.0.0.0/0 / user chain for input / 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:68 / Allow-DHCP-Renew / 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 / Allow-Ping / 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate DNAT / Accept port redire ctions / 541 17312 zone_wan_src_ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain forwarding_wan_rule (1 references) pkts bytes target prot opt in out source destination Chain zone_wan_src_ACCEPT (1 references) pkts bytes target prot opt in out source destination 541 17312 ACCEPT all -- eth1.9 \ 0.0.0.0/0 0.0.0.0/0`

the last involved rule "zone_wan_src_ACCEPT" seems to be the one letting the packages pass. Any idea where this comes from?

[SvenRoederer]

this seems to be caused by "freifunk-berlin-firewall-defaults" as on backbone images all ports are closed by default. I assume related to https://github.com/freifunk-berlin/firmware-packages/blob/master/utils/freifunk-berlin-firewall-defaults/uci-defaults/freifunk-berlin-firewall-defaults#L24

[booo]

Very plausible. What default behaviour do we expect?

There is also an option to rate limit specific services. Maybe an interesting option if we want to enable some services on the wan port but limit abusive behaviour.

[sarumpaet]

This is difficult to resolve properly. We could disallow WAN access, but this would make SSH and web UI unavailable from WAN (which isn't desirable in the normal use case).

Unless we want to support the "use FF router as main (DSL/cable) router" as a first class use case, we should only document this. DNS amplification isn't an issue anyways since the upgrade to Chaos Calmer.

I'd say close this after writing a proper "How to set up FF router as main router" FAQ/Howto entry.

[SvenRoederer]

on a fresh installed Hedy-1.0.0 (uplink via WAN) a nmap scan of br-wan gives:

Starting Nmap 7.01 ( https://nmap.org ) at 2018-03-16 20:17 CET Nmap scan report for SAm0815-test-glmt300n.bln.roederer.dhs.org (192.168.8.241) Host is up (0.0027s latency). All 1000 scanned ports on SAm0815-test-glmt300n.bln.roederer.dhs.org (192.168.8.241) are closed Nmap done: 1 IP address (1 host up) scanned in 38.19 seconds

scanning the ipaddress of the ffuplink_wan gives

PING 192.168.8.203 (192.168.8.203) 56(84) bytes of data. From 192.168.8.203 icmp_seq=1 Destination Port Unreachable

sven@hypnosis:/tmp$ nmap -P 0 192.168.8.203 Starting Nmap 7.01 ( https://nmap.org ) at 2018-03-16 20:23 CET Nmap scan report for 192.168.8.203 Host is up (0.0028s latency). All 1000 scanned ports on 192.168.8.203 are closed

So it can be seen as solved from my side. Feel free to reopen Nmap done: 1 IP address (1 host up) scanned in 38.37 seconds