Doh and chat gpt
-
@JonathanLee DoH does not work like you apparently think it does. The best you can really do to block it, which you should be doing, is DNSBL and IPBL known-DoH providers.
Your DNS forwarder or caching stub resolver (meaning dnsmasq or Unbound) should be configured to only query a trusted DoT provider (or providers) of your choosing.
-
@tinfoilmatt Yes exactly that is why I was wondering where the RFC was to perform the NSA recommendations, hence to use only an approved DoH outbound, it's not currently possible and we are given no options to do so. If there was an RFC to control the DoH outbound maybe we could do that. Again to have DoH working in unbound might give us an advantage as it would be under development for if and when they have and ability to do the "NSA" based recommendations.
-
@JonathanLee Let me try a different way: you do not want to be using, nor do you want any of your devices to be using DoH whatsoever.
-
@johnpoz I cant agree more with you, I guess my question is why would the NSA recommend we do that "use a single enterprise based DoH server when required" its not possible and if they recommend it where is the RFC to be able to do this? There is none that I know of anyway, also IDS I think does not have a category to alert on DoH use too, so it's like the NSA making a recommendation that has no possible solution currently outside of the wackamole solution.
-
@JonathanLee The NSA is recommending that, in a large enough enterprise where LAN segments are susceptible to sniffing from the inside, that DoH be implemented for local (meaning local to the enterprise LAN) network host DNS queries.
-
This assumes that the network operator/s or admin/s would continue to maintain full visibility over DNS traffic (in plaintext) on the LAN.
-
@tinfoilmatt But they are also making references to command and control over DoH externally, meaning outbound also right? I mean internally we could set it up with Unbound @johnpoz and I talked about this a couple years ago, requires some certificates, but outbound has no real catch all solution, outside of MIME blocking on get requests, again once you do this Microsoft goes crazy because they have some ones they want left alone.
-
@JonathanLee I believe they refer to the fact that malicious actors operating C2 servers are able to conceal LAN activity by designing their malware to query DoH servers under their control. To the LAN operator, this traffic would appear to simply be regular ol' HTTPS (and therefore encrypted) traffic.
-
@tinfoilmatt Maybe a containerized instance of something was able to do this.
-
@JonathanLee said in Doh and chat gpt:
It is safe to say that that if they recommend to do this ...
I found one paragraphe that I understood and agreed with :
NSA recommends that an enterprise network’s DNS traffic, encrypted or not, be sent only to the designated enterprise DNS resolver. This ensures proper use of essential enterprise security controls, facilitates access to local network resources, and protects internal network information. All other DNS revolvers should be disabled and blocked.
For me, this is a good advise. Let's all agree that this just is my opinion.
This paragraph also explain (again : for me) why pfSense adopted unbound, and left the forwarder, (dnsmasq) as it is a resolver and it support DNSSEC.
The fist paragraphe (I dismiss the intro paragraphe) :
DNS translates domain names in URLs into IP addresses, making the internet easier to navigate. However, it has become a popular attack vector for malicious cyber actors. DNS shares its requests and responses in plaintext, which can be easily viewed by unauthorized third parties. Encrypted DNS is increasingly being used to prevent eavesdropping and manipulation of DNS traffic.
Wasn't this partially solved a couple of years ago ?
Short story :
Enable DNSSEC on your web site (mail server, any resource) - activate DNSSEC on the pfSense*-unbound site and from now on the DNS info you receive can't be tampered with.
Example : visit this test site : https://www.test-domaine.fr - I own this site for demonstration purposes. This domain name server is DNSSEC secured.
So when our resolver unbound resolves this domain name, from top (root servers) to bottom (a domain name server), the entire revolver process will be signed and everything adds up, the answer is accepted and unbound will give it to your requesting LAN client.Afaik, initially, the US was slow in accepting DNSSEC, and I really did understand why : "There must be something better as that ?!" but years passed and nothing better was found, so, not long ago, it became mandatory for all 'official' domain names even in the US. Example www.usa.gov.
If you like the visual graphs : www.usa.gov.DNSSEC doesn't hide. It's not a "don't see me watching p#rnhb.com" solution.
It's a tool that makes sure that when you want to visit p#rnhb.com, you get p#rnhb.com, and not a spoofed web site.
Spoofing p#rnhb.com is one thing, if your bank's domain name gets spoofed, then you will have "issues" very fast.
DNSSEC promises you just one thing : "You'll get a exact answer when you do a DNS request". It will be the domain (site) you want to visit, and nothing else.
The 'hiding' and 'flying below the radar' web surfing is for those who have sensible formation to hide, and this isn't valid for what ? 99 % of us.I tend to see DNSSEC as 'chain singing'. If it breaks, then sell your bitcoins right now, as they will break minutes later ^^( and post/warn us here as fast as possible, so we can sit on the front row as this will bring some economic fireworks with it )
DoH just hides the DNS traffic. Maybe not for the 3 letter agencies like the NSA ?! - It maybe just me : if the NSA advises to used DoH, what does that really mean ?
After all : the NSA wants info [with the "no matter what" authorization], that is their main goal. They care way less about 'your' security' or our 'private rights', these are just optional.Btw : I'm not against their (NSA) existence, every country has one. Afaik, we need them.
Edit : @netgate : really ? can some one sign that netgate.com domain please ? It's not rocket science anymore. Visit the registrar, check "Enable DNSSEC" and be done.
Or do it the manual way, as I did it, if you host your own domain names (Me, running a hotel, can do it, so consider the trick as mangeable ^^)@JonathanLee said in Doh and chat gpt:
but how do you make sure your clients are configured to only use that one DoH server?
Afaik : there is no DHCP option (even RFC ?) yet that asks for a DoH type of DNS server.
Also : 99 % of all routers out their are the crappy ISP routers. They might host a dsn forwarder, not something that hands out DoH DNS servers.
This means that a device with 'some' OS might be hard locked to an existing, know upfront, probably hard-coded into its firmware, DoH server IP (and domain name !!).
For what I know : If you want to use a DoH DNS solution on your system, you have to enter it by yourself.This tells me :
that "Microsoft 11" has its own list with 'Microsoft' DoH servers - the "automatique mode", or you can enter one of yourself.
By default, the Microsoft OS will obtain it's (classic) DNS IP by asking it during the DHCP lease request.@JonathanLee said in Doh and chat gpt:
there is no settings on iMac or on Windows etc and or browsers to lock down to a single DoH
Group some Windows Microsoft devices together, make them member of a Microsoft domain, get a domain controller, and use the Domain Policy editor (or whatever its called), and can set set whatever you want. Including mandatory DoH. No RFC needed.
