Ah, I think I can explain what @nrm604 is asking for, because I would like this option, too!
As an example, Fortigate firewalls have an option to do URL filtering on HTTPS URLs. Obviously, this doesn’t actually do proper URL filtering, since you can’t see inside the URL. What it does do is have an option to look at the SNI of the URL and if it meets criteria (blocklists, custom blacklist), it will block the site. The reason Fortigate has this as an option is so you can do blocking without needing a proxy set up.
To re-state, this isn’t proper URL filtering any more. However, it does allow blocking access to sites that are blacklisted. I think, perhaps, performing the blocking at DNS resolution (say, a PiHole) probably accomplishes the same task. But I think it would be really nice to at least have this as an option.
As far as I know, IPBlock lists/ libloc blocks ASNs also. From timie to time there are discussions about blocking of IPs not found in the various IP blocking lists. The solution is mostly, that not the single IP is blocked but the ASN the IP belongs to.
The original request is about blocking by squid, means blocking web access.
The usual process of accessing web pages is
client requests a HTTP(S) connection to a FQDN
the FQDN is resolved by DNS to an IP
connection is established to this IP
To block the access to unwanted pages you can use blocking mechanisms of squid ( demands, the client uses the squid proxy ) or you deny the resolution of the FQDN to the real IP ( by means of the DNS resolver of IPFire device, the usage by the client can easily be forced ).
The latter approach is exactly the way PiHole ( on another LAN device ) or the RPZ functionality of unbound ( inside the IPFire device ) work.
actually I take back my initial suggestion on eBPF, if the SSL request is initiated from your server behind ipfire, you still need some kind of proxy/squid or MITM in ipfire, ipfire has no visibility to the SSL header since ipfire works at netfilter/iptables layer which simply forward the SSL request based on layer 3/4 iptables firewall rules. eBPF has hooks on XDP/TC layer where eBPF program could be attached to decode the SSL request that is in raw packet or SKB form, but this kind of eBPF program is hard to write and hard to pass eBPF verifier which make sure eBPF program to be safe to run, for example someone attempted here c - BPF verification error when trying to extract SNI from TLS packet - Stack Overflow.
it is possible to have eBPF based proxy to achieve this, I haven’t found any existing one, this is an interesting request worth doing some research
DNS denies can be easily implemented by RPZ lists for unbound ( IPFire’s DNS ‘server’ ).
IPFire’s standard policy is ‘allow traffic from WAN, if the connection is initiated from LAN’. Therefore suppressing unwanted connections can be done by suppressing DNS resolution. IMO
XDP does the same thing as RPZ list then, except XDP performs better than unbound since the DNS query has to travel through all the stack from driver to netfilter to UDP stack to unbound. XDP also uses Longest Prefix Match Trie Map, easier to block one domain and it’s sub domain
I think green0 network user could bypass ipfire unbound if the user configure an external DNS server say 8.8.8.8 instead of using ipfire’s , the ipfire unbound will not be able to process the DNS query. for XDP, as long as user use green0 IP as their gateway, every packet including DNS query has to pass through XDP, and it will be blocked by XDP.
Then if you want to follow up further with your XDP approach with IPFire you need to complete the development mailing list conversation you were having with @ms but you never came back to answer the questions that were raised in that thread.
As this is central to the security and core functionality of IPFire it needs to be fully discussed and understood that it is not going to allow any security issues with how the firewall works.
That may well involve a lot of back and forth discussion to get clarification on all questions etc.