How to Use DNS Over TLS Server Option
-
@johnpoz Yes, a possibly hostile LAN
-
@ProfessorManhattan said in How to Use DNS Over TLS Server Option:
hostile LAN
For my own curiosity, could you explain how a lan that you control? You for sure control the router pfsense.. How exactly the L2 your devices connected to so outside your control that it could be hostile?
If hostile lan is the case - then you should actually VPN from your client to pfsense, and send all traffic through the vpn..
Please explain the scenario where it makes sense to put my dns inside a tunnel, but NOT all traffic.. Especially when the L2 is now hostile.. DNS would be the least of my concerns on a hostile L2..
-
I talked to a guy in the coffee shop who knows a guy who said his father-in-law read somewhere...
Come on people, it is possible to do better than this. If you don't trust a device, don't put it on your network. Take it back to best-buy and get your money back. Oh yeah, don't let your neighbors 13 year old use your wifi.
-
This post is deleted! -
@jwj said in How to Use DNS Over TLS Server Option:
I talked to a guy in the coffee shop who knows a guy who said his father-in-law read somewhere...
This is clearly in the top right corner of gartner for where and how to get your security information ;)
-
@johnpoz said in How to Use DNS Over TLS Server Option:
@jwj said in How to Use DNS Over TLS Server Option:
I talked to a guy in the coffee shop who knows a guy who said his father-in-law read somewhere...
This is clearly in the top right corner of gartner for where and how to get your security information ;)
In all honesty I've taken the less than smart path a time or two. You set me straight more than once. It happens...
-
@johnpoz Without encrypted DNS, anyone on the network can listen for DNS requests and know exactly what everyone is looking at. Also, every network is potentially hostile IMO.
We are in the days of botnet hackers. I'm inclined to believe that there are advanced botnets around that are powered by sophisticated 0-day exploits (after all, some can rebuild a pre-existing hack and include it in their malware). IMO, the more bizarre security measures you have in place, the less likely the bot will be able to adjust to your system.
Anyway, I guess this feature exists in pfSense but I can not figure out how to get it working.
-
@JeGr Hey JeGr, I think this is the issue. Can you point me to a guide that shows how I can add a .crt to /etc/ssl/certs to make this work?
-
@ProfessorManhattan said in How to Use DNS Over TLS Server Option:
anyone on the network can listen for DNS requests and know exactly what everyone is looking at.
So you are using a HUB for you network.. Switches do not allow for just sniffing traffic between other ports on that switch.. So unless you are exploiting or admin that switch.. Sorry host C (hacker) can not see traffic that A (pc) sends to B (dns) via unicast.. Now sure he could see broadcast traffic.. So if your using say mdns to resolve what websites (nobody does - mdns is a local discovery form of dns) your going to - which sorry pfsense not going to response to mdns..
And even in wifi, you can not just sniff every clients traffic.. Because each client has their own unique key, while sure it is from the PMK, but the PTK Pairwise Transient Key is different for unicast traffic. If you want to make sure that can not happen then you use wpa2-enterprise where it would not be possible to get the specific PTK info..
But even when just use wpa2-psk, they would have to snag the specific handshake for that client to derive their PTK used when that client talking to the AP
PTK = PRF (PMK + Anonce + SNonce + Mac (AA)+ Mac (SA))When you don't want that sort of thing to even be possible, then you just use wpa2-enterprise. Which is easy enough to setup using the radius package of pfsense.
So even when another client A is on the same wifi, your not going to see what user B is sending to the dns server..
Before you think its so freaking easy anyone can just click an app on their phone and see all the dns traffic happening on said network... I suggest you give it a try ;)
There is little reason to encrypt your dns traffic on your LAN.. Other than hey you want to slow shit down and make it harder to troubleshoot.. Or you just want to play with in your lab sort of thing.. But it has really zero use case where it would make any sense to actually do it.
-
@ProfessorManhattan said in How to Use DNS Over TLS Server Option:
the more bizarre security measures you have in place
I'll give you an easy one.
Block every incoming connection on your LAN, except : a list with well known VPN providers and the TCP/UDP ports they use.
This will enforce that client devices (PC's and the like) will really have to use the software proposed by the VPN provider they choose. Only with a VPN link to this VPN provider people can use your LAN : every LAN client is walled in, you not doing nothing (the close to perfect admin position) to achieve a certain level of security. Just put a note on your office door : the list with accepted VPN providers (and ask them a small fee while your at it ^^ )
The VPN connection URL should be IP based, not FQDN, so you can even block DNS traffic on your LAN.Done.
Now, when botnets are fighting on your LAN for total control because they broke the 4096 bit VPN encryption( ;) ), the world outside has been already set back several centuries. -
This new recipe doc I added this week should cover all the bases:
https://docs.netgate.com/pfsense/en/latest/recipes/dns-over-tls.html
-
Still have the issue of putting the dns servers like that in the general setup, pfsense itself "can" use those and those connections will not be using tls.
So The SKY will fall in the and the black helicopters will surround you as you "leak" dns ;) when pfsense looks to see if there is an update available.
-
@johnpoz said in How to Use DNS Over TLS Server Option:
Still have the issue of putting the dns servers like that in the general setup, pfsense itself "can" use those and those connections will not be using tls.
I didn't see any existing issue on Redmine for that feature, so I added one:
https://redmine.pfsense.org/issues/10931
-
Sure it will make these tls users happy.. Because the sky would fall for sure if isp saw something doing a query in the clear for netgate.com something..
Much better to hand that over to cloudflare directly - which is more trustworthy ;) They would never in a million years think to monetize any user info...
-
The ultimate solution to this issue is going to have to come from modernized privacy laws. That will only happen if we stop allowing telco's to do as they please. As it stands telco's ask the FCC if they may disregard the rules and Ajit Pai says sure. Look, surveillance capitalism is easy money, everyone wants their piece of the
Paipie.DoT is the same as building a bank vault around your jar of pennies while the crooks are taking your gold bars out the back door.
But if you insist just do this:
Put localhost only in general settings dns servers.
Add this (cloudflare, change hosts to your own liking) to the DNS resolver custom settings:
server:
forward-zone:
name: "."
forward-ssl-upstream: yes
forward-addr: 1.1.1.1@853
forward-addr: 1.0.0.1@853
forward-addr: 2606:4700:4700::1111@853
forward-addr: 2606:4700:4700::1001@853Add whatever NAT rules you want to to catch naughty hosts as documented in the pfsense book.
Do a packet capture on WAN and you will only see traffic on port 853.
(pfblockerng has an option under reports alert settings tab: "Select the DNS server for the DNSBL Whitelist CNAME lookup" that may cause some port 53 traffic)
-
I added the option I mentioned above to 2.5.0, so now all you have to do is go to System > General and set DNS Resolution Behavior to Use local DNS (127.0.0.1), ignore remote DNS Servers.
https://redmine.pfsense.org/issues/10931
Also cleaned up a giant mess in DNS-related code throughout the code base.
-
For anybody else trying to get this to work, follow this guide:
https://docs.netgate.com/pfsense/en/latest/recipes/dns-over-tls.html
And then if you're using systemd-resolved (Ubuntu, Arch Linux etc.), then modify /etc/systemd/resolved.conf by changing:
#DNSOverTLS=
To:
DNSOverTLS=opportunistic
Using opportunistic is the only time when I saw port 853 getting requests on the firewall. After setting it up this way, I no longer saw any requests on port 53. I tried using Stubby but was unable to get it working. The Arch Linux wiki says you're supposed to also set DNS={{ router_ip }}#router.domain.name. However, I got it working without specifying this. It may be because I used ACME to get a certificate. The hostname/domain you're using with ACME should probably match the information provided in General Setup.
@jimp said in How to Use DNS Over TLS Server Option:
https://docs.netgate.com/pfsense/en/latest/recipes/dns-over-tls.html
