Has anyone successfully configured a router or a DNS server to only allow WAN IP addresses or FQDNs from an allowed list? I currently perform the opposite using my router and DNS filtering on a Pi-Hole but I don’t see an option to do this. I had considered replacing my router’s OS with OpenWRT or DDWRT but I don’t recall that being an option in the firewall a decade ago when I ran it.
For anyone curious, this is for building an intranet for a child that has extremely limited access to the WAN side.
This would be easier to do in the browser or at least on the client device. While it should be possible to do a whitelist like this at a firewall level the problem is that you would need to whitelist not just the domain name of whatever websites you want to allow but the FQDN of every server it pulls data from, which is fiddly enough but then you have to deal with CDNs which make that impossible in some cases.
I can’t make these controls in the browser because they can be bypassed by software and multiple devices would need this configuration, and some of those devices may not have browsers accessible for configuration.
I intend to monitor all the traffic related to a specific site and to actively allow only that traffic. This isn’t a problem as I do the exact opposite already for DNS filtering.
The opposite is easy as you only need to block the primary domain, but to whitelist a site you need to specify the FQDN of every server the site needs.
A web proxy would work better but you’d need to be able to deal with HTTPS
I appreciate the suggestions Dexter_Kane but I’m not looking for alternate filtering methods. I’m looking for someone who has implemented this control or something similar.
You can set up squid transparently with minimal fuss, then you can use the university of Toulouse filter lists with ufdbguard, for your project you can set your own whitelists.
Doesn’t depend on any client setup/software.
Would caution that you will need to block UDP on ports 443 and 80 to ensure clients can’t use quic and bypass the squid filter that way (and obviously firewall will need to be locked tight outgoing anyway to stop any vpn or other tunneling).
Thank you, Ruklaw. I’ll look into it ASAP. I’m hoping to branch a sub-network with these controls in place so embedded systems are ideal, but this might work out. I’ve never heard of it.
You said it was only for one child? And indeed it is equivalent to a small lock on a door. However, we’re dealing with children who do not understand how this stuff works so an overcomplicated solution isn’t really what you need here in my opinion.
I.E If you had a system orchestration tool, like SaltStack, you could actually scale and enforce this btw.
Hope this helps! At least in the interim, while you ponder a more sophisticated solution.
This is 2020. Children don’t have 1 device, they have many. And I won’t even begin to speculate on future networked devices… terrifying. I’m looking to implement a solution that will persist beyond the early years, but don’t underestimate a child’s capacity to bypass security features in an age where they can look up tutorials on YouTube, while at school, on their friend’s phone.
The trouble with problems like this is that so few want to go through all the effort to implement it properly. The quick fix is rarely the permanent one. In other words, if it’s worth doing, it’s worth doing right. With all due respect, I won’t be modifying a host file.
On a device where I want a child to explore and learn all the potentials of an operating system, I want them to have root. That’s why I want to limit their WAN access on a physical layer. Think of it like a play room where everything is made of foam. They’re in a safe space where they can learn without injuring themselves.
DNS whitelisting is not going to work, at least not by itself. If they have root, they can just change the DNS server, or add in manual entries to hosts.
AFAIK, then your only other option is to go to IP whitelisting.
IP whitelisting would be leaky. Even if you set it up, I can off the top of my head think of a way or two to get around it. Say if they want their friend’s home IP unblocked so they can play a game together, then they install OpenVPN, and their friend does as well, and boom, block circumvented. And you can’t block the port, they could just switch to the same port as the game uses. Or they could just go to starbucks or anywhere that has open wifi.
Hmmm I read and read …
Do you already have an initial domain / address whitelist?
Are you sure you want to do this on the dns layer?
If we base it on dns and lists black ALL / white specific addresses, then you have to make sure that the child is not able to carry out dns requests under the table.
On the router / firewall, block all traffic for port 53 and udp for 443/80, tcp 853.
Force dns network traffic of devices only to your NS, at least pihole.
But the child can still use DOH / DOT or VPN / socks / TOR to release dns traffic to another server.
TOR addresses can be blocked on fw, there are lists.
You can try to block VPN / SOCKS on fw, but you can get around it to some extent.
DOH can be reduced to some extent by blacklisting known public servers and blocking them on fw / dns.
Teretically, it can be done to some extent … but it all depends on the child’s determination to get around it.
PS
If we are talking only about dns, in some situations the child will still be able to access the forbidden network resources via IP, although the scale here is rather limited in many cases.
Alternatively, you can create a script that polls for the IP for the domains and adds them to the blacklist on fw. But in the case of CDNs it will be an unwinnable fight.
And of course, the child can always create a HOST file with generated addresses for domains and bypass the dns level controls. Then you would have to block ALL IPs and only allow IPs that are actually returned for domains from whitelist and give them as Ip whitelist for FW. Doable but a bit of script writing… Look at ipset and write a simple script which will do domain lookup and update allowed list for iptables.
The end result would be full control at the dns level and traffic only to IP’s that currently pihole returns for domains.
I’m actually thinking of blocking this based on IP and DNS, now. I ordered a WRT-compatible router after fumbling with a Pi and a switch for a few days and I’ll be blocking with IPTables. I will also run a Pi-Hole on this sub-network for scalability. That will handle DoH as a pass-through, when the option becomes available. I’ll see what I can come up with. So far though, it appears no one who has commented has actually performed this action.
I have no experience with children on a leash. However, I have experience with the network.
I have given you a solution that will do exactly what you want but need to be assembled. You want a product from ikea … it will need assembly. If you’re looking for a ready-made solution, it’s fine, but then we need to talk about $$$ and we’ll make you this project exactly tailored to your requirements.
The matter can be solved in several ways. I gave you one that is very easy to implement.
If implemented correctly, it would give you full control over dns queries and limit completely network traffic to the indicated protocol, port, and IP addresses that would be returned for domains from the whitelist.
A child would not have a chance of getting out of this control 99 out of 100 times.
You want to have paronoic controls …
Pi-Hole:
Domain and subdomain whitelist.
Blacklist, dot filter in RegEx.
Script:
Here the script needs to get a list of domains from the whitelist (pihole) and ask the local dns (pihole) for the current IP, then generate iptables rules and reload.
You can do it manually but it will be terribly ineffective, because many addresses are returned in rotation from cdn’s, so the best solution is automation and frequent polling.
Firewall:
It must get the above rules that will be acceptable for OUT and specify the destination IP, TCP protocol and ports 443 and optionally 80.
Fixed rule for external DOH but only for local IP pihole.
Finally, the rule that blocks everything for OUT.
Done.
No device will go either on the domain or IP address to addresses that are not defined by you.
But if you don’t like this solution, well …
