Archive > 21.7 Legacy Series

DNS leaks, even after DNS catch-all port forward

<< < (2/3) > >>

Nikotine:
Yeah I can manually change it if I want, but what I'm testing here in fact is to see if I can force my IOT devices to use only my DNS settings.
If it's that easy for Chrome to circumvent it, then my hopes are low for the IOT devices.

BTW, Wireshark shows a lot of traffic to 8.8.8.8 on port 443, so I guess they are indeed using encryption.
I'll test with blocking 8.8.8.8 and 8.8.4.4 altogether.

opnfwb:
As this is only a port based rule, it will be easy for any device to circumvent it using either DoH or DoT. DoT may be somewhat easier to block since it doesn't piggyback on a common port (853). However, DoH will be nearly impossible to stop without some kind of packet inspection/proxy in the middle of the IoT devices to filter their traffic.

Greelan:
With DoH, you can filter by destination IP, by using one of the lists that are available online of public DoH servers. Not 100% foolproof, but better than nothing

jclendineng:
Sensei can block DNS, DoT, and DoH.  I would block all 3, then whitelist the specific dns over tls server you wish to use, though this may break some iot devices if they refuse to use the one you supply.  Worth a shot anyways.

Edit: I did this and this does work.  Blocks DNS, DoT and DoH. It blocked my pihole and gateway so I whitelisted my subnets in cidr format (1.1.1.0/26 or whatever) so anything DNS (http, tls or 53) is allowed to pihole/gateway but blocked anywhere else.  So far it seems that all DNS is blocked, all my eufy cams are showing blocked to dns.google (google DoH) so its working. 

Nikotine:
Thanks, I'll have to experiment with that as well.
I didn't have Sensei enabled before, but I just did a RAM upgrade today of my HP T620+ and it's handling Sensei and Suricata a lot better now.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version