It can distinguish between two different names on the same IP address.
2 Likes
Ah right. This is useful indeed.
Im just curious, which usage case to solve here, as there are tools like adblock, for example, available already. Or simple adblock.
Yes, I am trying to solve the same problem that adblock is solving. I want to ban a list of domain names to do ad blocking and parental control. But I want to make it more robust, to the level that an untrusted client of average skills (think a smart-ish teenager or a not-too-sophisticated malware/ad publisher) cannot bypass it.
For example with adblocker, an average-skilled untrusted user can use simply a website like this, get the IP and access a banned website.
Maybe there's another way that could work : could the router keep a list of the IPs that have been resolved by it, and discard any message sent to an IP that is not part of that list? That would allow me to be confident that the user has not found a way to bypass my own chosen DNS.
Whitelisting domains allows traffic to their IPs even if those are shared with blacklisted domains.
This is the only possible way to implement whitelisting while using IP sets.
1 Like
Right, that's what I thought.
I thought about this solution :
- I have a list of domains to whitelist
- I do not pre-resolve
- I have set up a secure DNS resolution mechanism, and tried to block others (but the blocking is not foolproof). As my DNS service is called to a domain name that is whitelisted, this populates a list of resolved, allowed IPs.
- The firewall will reject any packet with an IP that is not on this list.
This solution is still not 100% secure (an attacker aware of the white list could still use a malicious server that has the same IP), but it is more secure, as the attack surface is now reduced.
This solution is slightly more secure than pre-resolving, because now the attacker would need to 1) resolve against goodDomainWithIP0 and 2) use IP0 to access badDomainWithIP0. Whereas with the pre-resolution, it is slightly more likely for an attacker to stumble upon an IP that was whitelisted.
What do you think if this solution? Is there a way in OpenWrt to retrieve the list of resolved IP to block IP based on that?
1 Like
Populate IP sets with the whitelisted domains.
Disable LAN to WAN forwarding.
Change the filtering rules to allow traffic to the whitelisted domains.
uci set firewall.@forwarding[0].enabled="0"
uci set firewall.filter_fwd.target="ACCEPT"
uci set firewall.filter6_fwd.target="ACCEPT"
uci commit firewall
/etc/init.d/firewall restart
Yep, you can skip preresolving the whitelisted domains.
That should minimize the possible side-effects.
However note that modern sites depend on multiple domains.
So, allowing all the required domains is a huge pile of work.
1 Like
HUGE. a simple load of like a front page of a news site might hit 35 different domains.
2 Likes
Then why so complicated ?
Use "squid" to block http/https-access by IP in general.
For non transparent (explicit) proxy, relatively simple.
Possible, for transparent (intercepting) proxy, too, by checking SNI.
Non-trivial to do so, though.
1 Like
Besides:
I doubt, many domains also have a valid cert for their hosting IP.
So, access by IP via https (which is more or less standard, unfortunately) should not be possible, anyway.
May be, you worry too much ?
1 Like
Thanks a lot, that looks great. Is there a way to update dynamically (as and when a domain is resolved) the filter_fwd and filter6_fwd list, for immediate use by fw3?
Yes... maybe I can write a simple script that retrieves all the necessary domain names for sites that I want to allow, and add them to a list. Probably some manual work to remove the ads domain names, but this might be tractable.
I donât really know these technologies, as I am new to them. So you are likely right, but from reading their documentation, it seemed to me that a setup fw3 + dnsmasq â ipset was simpler than using squid. I purchased a good quality router, but the docs seemed to say squid required external storage. Maybe not using caching will not make this necessary (not clear) but even so, if feels that setting up a non-transparent proxy is more work than a firewall and a dns resolver. Again, with so little experience, I might be wrong.
Ah thatâs very interesting. Thanks for highlighting that point, I was not aware of the distinction of certificate for IP, versus certificate for domain name. From googling this, it indeed seems certificate for IPs are the exception, not the norm. Obviously, it does not really solve the use case, as the untrusted user could simply access the http service of the bad ip, but itâs good to know.
Haha, maybe. Itâs a subjective question though. In any case, I find very little downside in trying to do things in the best possible way. In fact, I am learning a lot right now (thanks to all you guysâ help!) about a really cool technology (openWrt) and about a super important area of computer science (networking) that I donât know enough about.
The fact that my network will be even more secure because of it is also an excellent goal in my mind. If you feel I worry too much, letâs just call the increased security a pleasant side effect to a great learning experience 
1 Like
Oh waw, that seems perfect! Using only 1 process is so much cleaner (removing all the worries about communication, race conditions, etc.). Thanks for sharing, I will definitely explore that option.
And thanks as well to the developer who added this feature!
Yep, it should populate the IP sets dynamically by default.
1 Like
Great, thanks.
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.