Bug #4023
closed
allowed networks in Unbound inadequate
100%
Description
Unbound defaults to only answering queries from 127.0.0.1, and you add specific allowed networks to permit queries. This is nice in that it should prevent taking part in many DNS reflection DDoS attacks, for those who use way too permissive of firewall rules or stupid port forwards.
Currently this list is automatically built including the interface IPv4 subnet of all interfaces where it's enabled. This is missing quite a few possibilities where typical use cases will be refused.
1) IPv6
2) VIPs
3) static routes
4) VPNs
maybe others. I need to think through this one a bit more to have a good resolution. Thinking just allow RFC1918 by default for v4, and figure out something for v6.
Updated by Phillip Davis about 10 years ago
At the moment it allows all local-connected subnets, including WAN/s. For example in some of my situations we have a rooftop ISP wireless device which connects to their tower. All the small businesses connected to the tower can reach each other - the ISP does nothing to lock that down. So it would be nicer if my pfSense unbound did not allow any incoming queries on the WAN (public IP) interface.
(Yes, I realize that the firewall rules prevent that anyway, but we are thinking here about what happens when the network admin has put some "dumb" pass rule in place)
1) The code could just put entries for locally-connected non-WAN-style interfaces. That is probably the most fully-locked-down thing, and make people with static routes and VPNs to other parts of their intranet add those in the DNS Resolver, Access Lists page.
or
2) Otherwise, for IPv4, it seems reasonable to put all the private address space by default and that will help 99.9% of users, and not expose any DNS resolver to the public internet. Then also have code to add all locally-connected non-WAN-style interfaces that are not already in private address space, so people with public subnets inside their pfSense will have those work with DNS resolver for free.
Neither should be difficult to code.
Updated by Chris Buechler about 10 years ago
- Status changed from New to Confirmed
Updated by Chris Buechler almost 10 years ago
one update to use the same list of networks as automatic outbound NAT uses, that's the best internal networks list that exists for v4.
Updated by Chris Buechler almost 10 years ago
- % Done changed from 0 to 80
v4 should be good now. I removed the interface subnets for all enabled interfaces, since that's potentially excessively permissive and is now redundant.
v6, I left the interface subnets as is for the moment, plus static routes via get_staticroutes().
That's potentially missing a variety of things (IPsec, OpenVPN, dynamic routing protocols), but it's easy to manually configure ACLs for those who need it.
Two outstanding things here:
1) skip v6 interface subnet if it has a gateway
2) add a checkbox to the advanced screen to disable all auto-adding of access-control
Updated by Chris Buechler almost 10 years ago
- Status changed from Confirmed to Feedback
- % Done changed from 80 to 100
this should be good, leaving for more testing.