We provide intelligent IoT Engines attached to edge devices - PLCs, electrical equipment, sensors, anything we can connect to. One client has equipment that is moved between oil field drill sites. We provide local control and also data log and upload their operating equipment data to their dispatch servers over cellular via our VPN. We juggle multiple local LANs/Mesh WiFi through each of our dual ported cellular routers; works great.
Recently they added satellite trailers to the mix as some locations have no cell coverage. We now also dynamically detect/reroute to the satellite links when present and shut off the cellular. Their field hands need to route their phones and tablets through our infrastructure but... in one week they created $ 4000US in data overages (Netflix, porn, etc) and my client is panicking. The company phone providers locked down the phones to approved apps only but of course the field guys are bypassing the simple blocks.
I researched and seems earlier Pi-hole firewalls can't restrict all traffic to whitelists only. Not sure if Pi-hole 5 changes things but we would like to use them. We can nest our existing router firewalls with PTP LAN connections to new Pi4Bs with PiHoles or maybe Squid and then relay via WiFi for the phones, so the phones can't bypass with direct IP addressing. Am I barking up the wrong tree here?
Pi-hole is not a security tool - specifically, it is not a firewall.
Pi-hole is a filtering DNS forwarder, it sees only DNS traffic (which is just a fraction of your entire traffic).
As such, it can be quite easily by-passed by manual client configurations, e.g. by changing on-device DNS settings or by enabling DNS-over-HTTPS (DoH) in your browser (which most browsers support now, more and more start setting it as default).
You could partially mitigate this by having your router or gateway redirecting DNS traffic to a DNS filter like Pi-hole, but DoH's use of HTTPS means that it won't be affected by redirection. Pi-hole provides the correct canary domain to have certain browser families (Firefox) fall back to conventional DNS, but those may be interfered with on the client side as well (though this affords a more elaborated approach).
You'd have to look for tools like firewalls that will block traffic effectively at the gateway level, where a user cannot circumvent it.
With all that said: If you want Pi-hole to block all DNS requests by default, you could create a respective blocklist regex, and then allow only those domains you know your software is using.
If you'd want to allow normal internet sessions on top of that, I'd imagine such a list with allowed domains will be quite a challenge to maintain.
This is great information and advice, thanks. We do run firewalls at the cellular - satellite split; my thinking is allowing the whitelisted DNS entries and block everything else. Redirecting all DNS (including hard coded 8.8.8.8 queries) back to the Pi-hole ahead of the firewalls should do what we need. Any traffic not going thru there we will just block as contrary to their policy of company apps only; no need to support "normal" internet sessions. Thanks again for your help.
Just be aware that if this is a BYOD setup then redirecting/dropping TCP/UDP 53 is not enough anymore. Thanks to DoH there's no way to tell if TLS traffic is DNS or http anymore.
Edit: Sorry, I think this just echo's Bucking_Horn's previous post.
Understood; since we only have to let whitelisted domains thru I'll have the firewalls block everything else, and use a Point-to-Point 1:1] LAN connection between the gateway and the Pi-hole unit. This should block any DoH end-around runs, right?
DoH means the browser sends DNS queries along with the HTML queries over the same 443 TCP port secured by TLS.
You wouldnt be able to distinct HTML from DNS (no packet filtering possible).
Dont know exactly what you mean by Point-to-Point but Pi-hole whitelisting has no effect over what domains come through DoH.
You may be able to try and block the DoH endpoint domain names but you'll miss the bare IP connections https://1.2.3.4 and anything hidden by eSNI. That kind of stuff would need TLS decryption to see in to the packets.
DoH is a ripe, steaming, putrid pile of donkey dung. DoT is the option that should have been chosen.
By Point to Point I mean a direct Cat6/7 cable between the router/cell modem with the firewall(its a dual LAN router with port isolation) and the 4B with the Pi-hole DNS resolver. Then by enabling a firewall in the 4B as well all traffic will be force-choked thru the 4B. Only whitelisted traffic needs to be passed to the cell modem for uplinking and EVERYTHING else(including Port 443-based traffic) can be blocked to keep it off the Sat link.
It may work but I have a feeling it won't be successful. The only way for you to see what the TLS payloads are is to be able to decrypt the packets. That means either creating your own Certificate Authority, pushing certs to all the client devices and browsers and setting them to trust your CA. A Pi 4 is powerful but doing deep packet inspection and live decryption is going to slow everything to a crawl. (Well, it is a sat uplink so maybe speed won't be an issue.)
You mentioned that the phones were locked down, do you have full control of the client devices? If so then you should be able to set admin templates that disables DoH, which may make things vastly easier.
Honestly, the easiest solution is to set company policy on what is acceptable and then fine/charge/end employment of anyone violating the policy. My first "real" software job was a gig for a hydrocracker plant, you're not going to outsmart the field crew.
I would concur that DPI is probably not viable in this application with this hardware. Another company manages the phones so I'll push to have them disable DoH.
I agree we can only do so much and then log the rest of the traffic noting source MAC addresses. The volume of traffic from a given phone will be the smoking gun plus any destination logging we can do. That was actually our first recommendation, but they just want to stop traffic, not necessarily catch offenders.
Question: We already know one way they have been bypassing phone security restrictions is by enabling their phone's hotspots; if DoH is disabled on the phones can they still use the hotspot method to get DoH thru from laptops/tablets?
