Hello all and TIA for any guidance. New guy still learning.
Single home network. Zyxel 5000K Centurylink modem.
DNS servers are Quad9 now as set in PiHole
Pihole latest version 5.3.1, 5.5, 5.8.1, set as DNS and DCHP server. UFW installed and configured enough to get it working with pihole 3b+. My main network is the modem, the Pihole and my win10/linux Mint dual boot PC. Other devices removed until I get this sorted out.
Expected Behaviour:
Pihole consistently blocks everything in accordance with my lists and filters.
Actual Behaviour:
Pihole blocks most bad traffic it seems, but DOH devices can get out onto the net, and when they do my pihole stops filtering net traffic until modem reboot, at which time it goes back to normal.
I've read countless walkthroughs RE how to configure different firewalls to redirect all traffic back through the pihole after a DoH device bypasses it. In spite of several tries I could not get those rules into UFW, almost certainly r/t my own lack of know how. I did disable DoH on my browsers.
Alternatively, I would like to use UFW to just outright DENY or BLOCK any traffic at all through 8.8.8.8 or 8.8.4.4 until I can get a more capable firewall. I use Quad9 so I'm guessing I can block google DNS directly without killing my connection? I'm not too concerned about breaking DoH devices for now. I have an ad-free life, and any device that elects to rock that boat risks being turned into dust with a belt sander.
Sorry this is long and I hope it's in the right place. If we need the -d for this let me know and I'll figure out how to attach that. I think knowing how to tell UFW to handle this issue
(or just block google altogether) will make the world right again. Pihole works great outside of this issue.
Do you have control of the configuration of the DoH devices, or is the target server for the DoH devices nailed in, presumably to something like 8.8.8.8 and or 8.8.4.4.
Harry
Thank you for the fast response! Much appreciated.
I had a ROKU, but I have decided not to return it to service. Just the fact that it constantly tries to steal data and inflict ads upon me is uncomfortable. When it succeeded against my best efforts (presumably via DoH) it earned a one way ticket out. I have no use for a device that continually strives to be such a bad actor. I should be able to replace it with a Pi4 thanks to Widevine. My folks just got a ROKU last week, it actually turns on the TV and shows ads, several times a day. Go turn it off and not long after, right back on showing ads again. That was enough to blacklist any ROKU device from my home.
But, my network could still see various other transient DoH devices and I want to be setup for that. There are sometimes game consoles here and other various devices folks bring around when visiting. I do not care about breaking the function of a DoH device anywhere near as much as I care about even one Kb of data coming or going without first (and without fail) going through the Pihole.
I think this was related to the modem, I found DCHP was switched on in the modem again (I have it enabled on Pihole instead). I turned it off... again, rebooted everything and so far I'm golden, but the ROKU has not been on the network since. When the ROKU did show me ads, I got on windows PC and typed "google" and it opened! This is a google free household, anything with even a gentle aroma of Google is aggressively blocked. I hypothesize that the DoH ROKU is the culprit since it has not happened since I removed it from the network.
I know I still need to be setup for DoH devices that could coincidentally end up temporarily on my network. I really want to enjoy the fix that those with other firewalls enjoy. I also hope to learn as I go.
I'm not sure how to enter that devices settings, I have read in many places that those DoH devices seem to almost invariably use 8.8.8.8 and 8.8.4.4. and are hard coded. I'm okay to block google 100% but I feel like a better solution is to force all that traffic back through the pihole, but if that wont work with UFW I'd like to see how to block 8.8.8.8 and 8.8.4.4 in UFW until I can get a firewall capable of honoring the necessary rules to close that DoH loophole for good while funneling everything through pihole.
I tried not to make the responses too long, but I want to make sure I'm offering enough info to pain the picture. It probably also illustrates that I do not yet have a firm fluent grasp on networking and firewalls but it's fun to learn and I'm glad I found this forum.
I'm learning more about this every day. Again, thank you!
DNS-over-HTTPS (DoH) cannot be blocked or redirected by means of a firewall. It is using HTTPS as transport protocol, so you'd had to break encryption to do so.
What a firewall can do is block access to known IP addresses of DNS servers, rendering clients using such a DNS server incapable of DNS resolution.
It would then depend on the client whether it would fall back to plain DNS, or whether it would cease working altogether.
If you do not know the IP (or name) of a DoH server that a client is using, then that client would always be able to by-pass Pi-hole via DoH.
Not related to pihole, but since it's allowed (moderators also post), here is my solution.
I started consolidating DoH lists almost a year ago, generating IPv4 and IPv6 lists to use on a capable firewall. Apparently some domains resolve to a different IP in different regions, so I added the database I use to generate the lists to GitHub
You can read more in this document (may need to whitelist users.telenet.be)
notes:
Lists and database updated daily
Exceptions are important! For example linuxquestions.org will NOT function correctly without the exception.
It has been confirmed this solution can also be used on OpnSense.
Please report possible new lists as an issue here, will always investigate.
Assuming that is possible, does anyone know if the trojan devices verify that the certificate they get back from the DoH server is actually from google, or will a valid DoH response from a server at the address they are expecting suffice??
Those networks can be physical, with a second interface in the Pihole server, or logical via vlan separation and vlan definitions on the Pihole interface (and vlan management possible on the switch that implements the network).
The key point is that traffic from the untrusted devices must go via the Pihole.
The Pihole needs to be configured as a router, via a sysctl setting, and the router needs a route to point traffic for the untrusted network via the Pihole.
The Pihole needs to be configured to support HTTPS.
The Pihole would need nftables installed, and a one_to_one NAT translation set up on the untrusted network interface for the addresses we wish to overide, to the Pihole address.
The Pihole needs to function as the DHCP server for the untrusted network.
The performance limit will be the bandwidth available via the Pihole, so modest only.
You also need to be able to configure the untrusted devices to accept the Pihole's self signed certificate, or configure an acceptable certificate on the Pihole.
Depending on how crappy the trojan devices are, they may look for Google/whatever in the OU in the certificate, in which case they are very fragile, and will simply fail unless they get access to Google.
Suffice to say I have not tested this set up, and will not be connecting any such crap to my network.
This makes sense to me. Thank you (all) for a logical responses. Given the choices I'm happy to block the google DNS completely for now. I think I now better understand how DoH really works.
From what I've read virtually all the commercially prepared devices revert to 8.8.8.8/4.4. for DoH. I now get that this is not necessarily so but I feel like at least blocking the above mentioned DNS would put a huge dent in devices successfully exhibiting this behavior. Again, I would MUCH rather break a device than allow it to peek around the curtains.
Still keen to learn firewall basics I flashed an old laptop with pfsense and got it up and running with pfblockng. Sadly the power brick was creaking audibly, so had to stop on that hardware. I'm still trying to become clear on how/why/why not redirect ALL traffic from say 8.8.8.8/4.4 back through the pihole (or just block it). I understand that only works if the devices hard codes point to 8.8.8.8/4.4.
Once I get the Pihole and UFW setup, I hope to backup the SD card and make an identical spare Pi that can be swapped in quick should one fail. With said spare I can with confidence start playing with VPNs and other stuff, with impunity as far as crashing my network goes. I have a short stack of extra Pi 3b+ and an urge to gain an understanding on all these things as I move away from commercial, and towards open source solutions for everything.
The only remaining question I have is how can I use UFW to block 8.8.8.8/8.8.4.4. for now? Also if anyone can suggest any entry level reading on firewall basics I'd be grateful for a link. Most of what I have found is just outside my scope of knowledge.
Need more info about the actual network you have to provide detailed advice.
Note if a trojan device can connect to your router, unless the blocklist is managed by the router itself, a firewall will not help. Firewalls only affect traffic that passes through them.
The network I sketched out above does this by having only the path through the RPi connecting the trojans to the internet.
Once you have captured the trojan traffic, selectively dropping traffic for 8.8.8.8 and 8.8.4.4 is trivial.
nftables, the modern replacement for iptables, is what underlies UFW and similar tools. You can use it to directly blackhole traffic to/from ip addresses/network ranges. Also NAT those addresses to whatever DoH server you want them to actually connect to.
The Debian page also references some "firewall" apps that provide a high level control of nftables.
I am using PiOS with UFW, when I started reading up on IPtables and knew that short of being spoon fed commands I would need to learn more about firewalls before I could effectively use it. I did not know until now that nftables was a thing, and a thing I would be working with instead of iptables. I'm glad, also glad that some wrappers are available. Thank you for the handy nftables link!
Oh, thank you for sketching that! Being a visual learner this post made some things dawn on me that perhaps should have been obvious. I see it now, I get how a rogue device can simply use the modem/router to sidestep a firewall that is installed with the pi. I also see that your setup seems to do what I want, but with a perfectly logical approach which had eluded me until now. I saved your post and pic to my comp for future reference, I hope that is okay. I will now base my setup on your fantastic guidance.
A couple quick points of clarification if I may, in your sketch the PC is on the trusted side. My PC dual boots Linux Mint 20.1 and sadly, Win10. Maybe my distrust for the Windows OS is outside the context of your network sketch and the pihole still protects it, but just to be sure should I move my PC to the untrusted side and maybe not have the trusted portion? I'm quite short on trust. As long as I have an MS OS I would like to treat the PC as a bad actor as well.
Current setup is very simple. Centurylink modem with a hard wired PC and Pihole. Modem points to pihole as DNS server and right off to the internet. Any other devices connect wirelessly to the modem. I now see how this is pretty far from ideal.
I just found an old PC (not a laptop this time) that I plan to flash with PFsense and an extra LAN card for separate WAN and LAN interfaces. Can said PC/firewall be used in the router slot on the sketch/assume routing duties. I see how a dedicated firewall at the end of the network is superior to relying on a firewall residing on the pihole, which the current modem/router can handily be told to ignore. Is it time for me to dust off the ol' Linksys wrt54 as a dedicated wireless router to give wirelessly connected devices something on the safe side of the firewall to connect to, rather than the modem, which maybe I should not be trusting as a router at all.
It may surprise you that I have more dumb questions, a bottomless well of some real eye-rollers to be sure. I think I can answer some of those by going to read up on switches and how they work into it. Sorry about all the unpacking here, but this is really helping, and ideally I hope it could help other entry level readers with like goals. Thanks so much for taking the time to make this stuff friendly to the less IT savvy. It really is incredibly helpful.
