OPNsense Forum
Archive => 21.7 Legacy Series => Topic started by: Nikotine on September 16, 2021, 04:58:45 pm
-
I have setup DNS over TLS with Cloudflare servers and I want all my local clients to use that DNS provider.
I have a NAT port forward rule that redirects all DNS queries to the firewall.
It is working on a firewall group, containing all my VLANs.
(https://i.imgur.com/MGJcJZE.jpg?1)
I have setup my pc to use 8.8.8.8 as DNS server, to test.
(https://i.imgur.com/YTJTeYH.jpg?1)
The firewall logs show that the DNS requests are forwarded to localhost (I am 10.25.9.10).
Immediately after I see the request go out to Cloudflare.
(https://i.imgur.com/4uVHaZZ.jpg?1)
Yet dnsleaktest.com shows that I'm still using Google's DNS servers...
(https://i.imgur.com/YoUV7ls.jpg?1)
I'm doing ipconfig /flushdns in between tests.
How can I close this leak?
-
Which browser are you using? Chrome may be bypassing your settings and using Google's DNS servers regardless of what you have specified on the network.
I'd try with either FireFox or Vivaldi and see if you can duplicate the results just to rule out DoH hidden in a browser setting.
-
To be more specific, chrome could be using DoH = DNS over Https, which would bypass your redirect of port 53 traffic.
Also consider that you may need to block/redirect ports 784 / 853 (?) For DNS over Quic / TLS traffic.
-
Which browser are you using? Chrome may be bypassing your settings and using Google's DNS servers regardless of what you have specified on the network.
I'd try with either FireFox or Vivaldi and see if you can duplicate the results just to rule out DoH hidden in a browser setting.
This is in Chrome and you are right, it doesn't happen in Firefox!
To be more specific, chrome could be using DoH = DNS over Https, which would bypass your redirect of port 53 traffic.
Also consider that you may need to block/redirect ports 784 / 853 (?) For DNS over Quic / TLS traffic.
But looking at the logs, it seems the request to 8.8.8.8 goes out via port 53, which I'm already redirecting. So how is Chrome reaching its DNS server?
-
I actually don't use Chrome (can't stand Google's stuff). However, based on this thread I think you can manually change Chrome's DNS here.
https://support.google.com/chrome/thread/115313308/how-to-change-chrome-secure-dns-settigs?hl=en
-
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.
-
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.
-
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
-
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.
-
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.
-
Old post but if ram is an issue, ditch suricata. Almost 0 use cases for home usage. Well, Ill say it is 0. Its fun to learn and manage and all that but know that its useless for most people. You aren't being exploited, you have a firewall that's default blocking incoming connections, if you are concerned, geoblock from aliases, and use firehol blocklists to deny certain ip ranges only if you run a website or something. if you don't, you have no benefits from any of that. On a 620 you have a pretty weak CPU as well so I would definitely stay away from suricata. Just my 2c :)
-
jclendineng
But, if you have services facing the public? Then would it not be beneficial to also use Suricata / IDS?
I have a lot of these coming on my public facing ports these days, which I think Suricata handles pretty well :)
2034647 blocked xxx.xxx.xxx.xxx 54658 yyy.yyy.yyy.yyy 80 ET EXPLOIT Apache log4j RCE Attempt (http ldap) (CVE-2021-44228)
-
jclendineng
But, if you have services facing the public? Then would it not be beneficial to also use Suricata / IDS?
I have a lot of these coming on my public facing ports these days, which I think Suricata handles pretty well :)
2034647 blocked xxx.xxx.xxx.xxx 54658 yyy.yyy.yyy.yyy 80 ET EXPLOIT Apache log4j RCE Attempt (http ldap) (CVE-2021-44228)
Yes :) that's why I said unless you run a website or something. I do run many public services as well as semi-public for mostly myself, so I do use suricata. My point was more that if he is a *typical* home user and running on that old old hardware, suricata may not be the best option as it will eat resources that could be used for other things. I have 2 of those t620's laying around and most modern SBC's can outperform these days, its super old. I agree, if you run services externally, definitely use a SIEM or whatnot. I would play the devils advocate though, for personal services, a properly configured firewall and services behind it will be plenty secure without suricata if OP decides not to use it. Updated dependencies and properly secured services will be great, but conversely, if you only run suricata thinking its enough, without worrying about the exposed services etc, that's not really secure. Suricata (snort as well for that matter, any IPS/IDS) requires tweaking and an understanding that if you don't you will have a ton of false positives. You have to babysit the ruleset, and understand why you need it and what its doing and not doing. If someone were to just turn it on WAN and not do that, it probably won't do to much good. Suricata isn't this magical security suite, its a glorified signature based scanner.
-
I think another way to force all DNS traffic over dedicated servers is to combine the already mentioned NAT portforward rule with a NAT outbound rule.
This is also described in this thread: https://forum.opnsense.org/index.php?topic=15472.msg71345#msg71345
With this setup, I think, Suricata is not necessary to block all DNS traffic via DoT, DoH. This should save a little bit of performance, especially on older hardware.
This combination I run on my system and it looks like its working. Also when I run the DNS leak test, only my classified DNS servers are listed.