IPFire blocklist can block outgoing traffic as well. Check the Log section on the right side of WUI.
I think a lot of folks would be interested in an Ads and Tracking blocker in IPFire. Question is how to do it in a smart way?
Main issue is error handling. For example if a tracker gets blocked by DNS blocker, the error says “website not available, check your connection”, the user will complain that they have no internet at all.
The way proxy handles errors is a little different because it will tell the user that it got blocked by proxy, or you can design a custom block page.
Second issue is what blocklist to use. I haven’t seen any good Ad and tracking blocklist that could be usable by IP address Blocklist.
Most ad and tracking servers are using domain names or host names, not IP’s.
If you know your way around terminal and SSH, you could use Unbound for blocking ads and tracker servers
There are some blocklists on Github that convert a traditional Hostfile blocklist to a RPZ list that could be used by Unbound.
It will get a little complicated when tracker and ad servers use a CDN and are masking their domain name. You will need
“list of trackers that disguise the real trackers by using CNAME records”
Last thing you should have in mind is that a lot of mobile apps will use their own DNS server, in order to circumvent Adblocking. So you have to force DNS queries to IPFire using 2 Firewall rules,
As the majority of sites being visited become https then proxy filtering becomes a bit pointless as the traffic is encrypted.
The only way to filter the https traffic is to decrypt if first, then filter it and then re-encrypt it but that process is the same as “Man In The Middle” attacks use so any MITM protection stops being useful as it becomes difficult to tell what is from your own MITM process and what is coming from an attacker.
Additionally for the squid filtering there is now only one source of signatures. There used to be three sources but two of them ceased to exist. You can add your own signature source URL but no one has flagged up any suitable alternative signature lists. None of the IPFire development team has been able to identify any source of suitable signature lists either.
It might be that with the move to mostly https that http proxy filtering is dying away.
Additionally for DNS there is the challenge of DoH which many browsers have available and it looks like many intend to make it the default. The DNS resolver will then no longer be from IPFire and the request will be transmitted in encrypted form by the browser and the traffic will be indistinguishable from other https traffic. Only the end point IP will be identifiable.
Browser setups will need to be defined to use the IPFire DNS server. Firewall rules can be implemented to ensure that any DNS traffic is only allowed to go via IPFire’s DNS system but if the browser can be easily changed to use DoH those firewall rules will not be much help as they will be looking for the DNS port traffic and not HTTPS port traffic.
I posted a DoH IP Blocklist "‘DoH Protection by jpgpi250’ that could be used to block DoH servers.
Unfortunately when using it with the IPFIRE blocklist. it will block DNS DoT servers as well, not just DoH. I wonder if Proxy could block DoH even if the traffic is httpS.
Here is an example:
I think blocking DoH is only practical with DNS blocker because blocking IP 1.1.1.1 will block all DNS traffic. DoT, DoH, etc…
Blocking doh.cloudlare.com will only block DoH,
but DoT will still work.
@peppetech - The Unbound route sounds promising. The devil is in the detail. Can you describe the two required firewall rules?
I understand the IPFire developers focus on security. Blocking ads and trackers is lower down the list of priorities. However, it would be good to have a tick box that allowed ads and/or trackers to be blocked.
Hi
If you want a totally adfree android, with Apps and browsing. Then only set dnsforge.de as TLS over DNS in the android connection settings private DNS. works 100%. This DNS Server provides the best adblocking list ever I used for. You can use dnsforge also on ipfire, but last weeks I got an issue with unbound and dyndns. But for now it works like a clock.
On further investigation, there is a script, which works (I tested the download function only). I’ve raised an issue about whether the script is being maintained because someone elsewhere said it wasn’t. There’s been no reply yet.
But as has been raised elsewhere on these forums, there is the question of how you ensure clients all use IPFire as the DNS server. Some devices (chromecast was given as an example in a post) use their own DNS server (in this case 8.8.8.8). I was looking to block these sorts of devices accessing tracking servers.
I don’t know if there’s a way to force all devices on the green and blue networks to use a specific DNS. server.
Thanks @jon - that’s very helpful and another step in the right direction. I’m not sure if that technique covers sneaky devices that use DNS over TLS or HTTPS?
Unfortunately I suspect that will not be possible. DNS Over HTTPS (DOH) is where the DNS info is transmitted via HTTPS and once encrypted the DNS traffic over HTTPS will look like any other HTTPS traffic. The only option would be if you then also blocked all HTTPS traffic but that will stop any secure browsing activity, likely not what you want.
As you are no doubt aware there are hundreds if not thousands of sites, apps, devices and even device components that send encrypted data ‘home’ over HTTPS port 443. Unwanted tracking is only one aspect. I have a robot vacuum cleaner that tried take pictures and video of my home and send that data to data warehouses in Beijing and Hong Kong.
As bonnietwin said, decrypting and re-encrypting the traffic to understand or change that data, is the same as ‘Man In The Middle’ attack.
From my recent experience many sites ‘break’ or perform poorly or inconsistently when IP address blocking is employed.
I have played with whitelisting but the overhead is enormous.
It comes down to how much (data/privacy/money/time) you are willing to give away for convenience.
I will be interested to see where this topic goes and whether people who are much more knowledgable than me can find a solution.
@kenzo_ume Thank you for sharing your experience. I too thought that way. However, when I saw that DuckDuckGo (see my OP) have added a blocking feature in their Android app (as have Apple on iOS?), I wondered if this was possible for IPFire. DDG also has a whitelist feature but of the 200 apps installed on my Android only about 6 are whitelisted by DDG and everything seems to work.
DDG sets up a VPN on the phone (I assume to monitor the sites being accessed); the filtering is local, as I vaguely remember. I don’t know if the blocklist DDG uses is published.
Given that everything goes, eventually, via the RED network on IPFire, I wondered if it was possible to stop access to some IP addresses in a similar way to DDG. But I can see others have asked before and await a plug ‘n’ play solution in IPFire, a bit like the relatively new blocklist feature.
The difference is that the duckduckgo android app is a browser on your mobile device and therefore can filter all the requests before they are encrypted into the https protocol.
IPFire cannot do that as when it gets the traffic from your mobile device it is already encrypted. The only information available to IPFire is the IP address that the traffic is being sent to or coming from.
Therefore if you just want to block all traffic to/from specific IP’s then that is what the IP Blocklist capability was designed to do. The IP’s that you are interested in blocking have to be included in one of the blocklists that are available in IPFire.
However if you want to stop tracking info for a specific IP but allow the browsing activity to go on as normal on that IP, that cannot be differentiated in the encrypted traffic flow. That differentiation can only be done in the browser software on the machines where the browsing is occurring ie before encryption.
I don’t use the URL Filter myself but looking through the page I did not find doh but then I looked at the University of Toulouse blacklist and saw that it had doh listed so I am presuming that you have the Toulouse blacklist loaded.
Thinking about the process a bit more then even a DoH packet will still have a destination IP which can be filtered or blocked. So if you have an up to date list of all DoH resolvers then you can block them. What you can’t do is filter the web site urls that are being fed to the DoH resolver. As long as the DoH block list has 100% coverage then the DNS requests can be blocked from being sent out. You are correct with that.
One thing I have noticed is that in the doh lists there are domains listed that also do DoT with no differentiation between the domain for DoH or DoT so that filter might also start blocking the DoT DNS requests from Unbound, although I am not sure about that.
One example is dns.digitale-gesellschaft.ch which is listed in the Toulouse doh list but is also the hostname to use for DNS over TLS in IPFire.
Well I think at this stage of discussion there should be a setback to discuss the strategy.
There is always a trade off between blocking traffic in the firewall and/or the client.
For me blocking traffic in the firewall should be only for safety purpose which is relevant to all users.
Blocking traffic on the area of a browser at the client is more for annoyance purpose. I am aware that for all individual blocking the work goes up compared to a centralized solution. On the other hand customers annoyance by over blocking shrinks.
Personally I take care for all security relevant blocking by the firewall and for add blocking I use ublock origin on the browser. For PCs works this fine but unfortunately not for androids etc.
One should not overload and make a firewall to complicate so my personal point of view.