8 ms·
>NSA recommends that an enterprise network’s DNS traffic, encrypted or not, be sent only to the designated enterprise DNS resolver. its either a slow day at th
by nimbius 6y ago
>NSA recommends that an enterprise network’s DNS traffic, encrypted or not, be sent only to the designated enterprise DNS resolver.
its either a slow day at the NSA or federal agencies have become so intellectually bankrupted by the cloud that they consider proclamations of the fundamentals of DNS and networking to be some sort of sage wisdom.
- freeone3000 6y agoSomebody has to recommend the basic stuff, otherwise it's just rumor. This is a topical addition to a list of DNS recommendations.
- TedDoesntTalk 6y agoNow you can point to that and say “We use the best DNS practices as recommended by the NSA.”
- belorn 6y agoI read that to mean: Do not allow doh to tunnel all your dns traffic out to cloudflare regardless of the promise of encryption. Send it only to the designated enterprise DNS resolver, ie the one under control by the enterprise. All other DNS resolvers should be disabled and blocked, ie all those public dns resolvers.
- salawat 6y agoIn other words "MitM everything". It gets so tiresome. I used to think the people who called out tyranny everywhere were just nuts, but it never ceases to amaze that everything nowadays keeps going "centralize and control".
- wmf 6y agoSending your DNS queries to a resolver that you control is hardly MITM. In this case "you" is a company.
- StreamBright 6y agoWhat he means is that NSA and related has the ability to MITM HTTPS while another actors do not, probably.
- userbinator 6y ago...and in the case of people using DNS-based adblocking and such, "you" is... yourself.
- vaduz 6y ago> Sending your DNS queries to a resolver that you control is hardly MITM. That's if your users are well-behaved and follow the rules. To stop the users from being badly behaved, NSA recommends blocking connectivity to well-known IP addresses of the public DoH resolvers (e.g. Cloudflare) and TLS inspection to stop connections that try to go to less well known ones, including via ODoH, which means your TLS inspection device must understand the protocol. To do TLS inspection at that level you need to MitM all HTTPS traffic going everywhere, as you need to read all HTTPS traffic to any possible host, as any of them may be a DoH resolver or relay. Q.E.D.
- deathgrips 6y agoYou seem to be implying that a company should not know what kind of web requests are coming from its computers.
- vaduz 6y ago> You seem to be implying that a company should not know what kind of web requests are coming from its computers. Please point out where I made that claim. All I am saying is that the way "knowing what kind of web requests" - and DNS request in this case - is achieved is by becoming a third party in supposedly two party encrypted communication. The company certainly has the authority to do so (check your local laws, though, as there are some exceptions) - but it is MitM in function and practice, if not in name. "TLS inspection" and "data loss prevention" are simply common euphemisms for the technique. It's also not new, MitM proxies and for that matter endpoint introspection (e.g. keyloggers at the user machine) have been in use for decades in the enterprise, and have been making their way into BYOD private machines as well via various MDM tooling. Using your company DNS server as the grandparent has mentioned is not MitM. Inspecting all traffic by all devices in your company to try to enforce the use of said DNS server requires MitM, though.
- VWWHFSfQ 6y agoNo you're misunderstanding what the recommendation is. If a company runs their own DoH or even regular DNS or AD resolvers, then the company's client computers (the laptops their employees take home) should not be querying any old resolver hard-coded in their web browser (Firefox, CloudFlare) for internal company domain addresses. That's literally all this is saying. It's good corporate IT policy anyway and it's only being reiterated with DoH.
- salawat 6y agoOh, to be able to buy that anymore. I don't see anyone implementing it that way though. I see it being implemented in a way whereby all DNS activity must go through the corp resolver first, essentially giving full tracking history of 99% of users. Yes, it already happens with corporate proxies, and yes, I'm sour about that too... To be clear, I'm not blaming any NetOps here. It's just... Why is it so tempting? The things you can do with that type of data, it almost seems like you have to be superhuman in terms of keeping people away from it. Maybe I"m just too damn enchanted by just delivering packets to enable people... But when you get pushes from agencies suggesting "Hey, add a by definition awesome logging and tapping point" it really ruins my day. And yes, I run a network too. No. I don't give a darn what my users do with it as long as the servers are up and fine, and the global riffraff stay out. I don't know. Just overly grumpy I guess.
- VWWHFSfQ 6y agoTo be honest, I have no idea what point you're trying to make. Here it is: * Companies have internal (intranet) network services * Companies operate their own DNS (DoH) resolvers * They also have global (internet) employees * The devices those employees use have hard-coded DNS (DoH) resolvers (Google, CloudFlare) * Don't let them use the hard-coded DNS (DoH) resolvers * Make sure their machine uses the company DNS (DoH) resolver. I know people think that DNS-over-HTTP makes everything private and secure, but it doesn't. Google and CloudFlare still see every single DNS query from everyone.
- deathgrips 6y ago>And yes, I run a network too. No. I don't give a darn what my users do with it as long as the servers are up and fine, and the global riffraff stay out. You don't care if your users get hacked? Would you mind telling me what company you work for?
- grayfaced 6y agoIn light of SolarWinds hack, I think it's fair to say that DoH is a real threat. Putting that volume of machines under the control of a single "trusted" network provider is very bad idea.
- nobody9999 6y ago> In other words "MitM everything". >It gets so tiresome. I used to think the people who called out tyranny everywhere were just nuts, but it never ceases to amaze that everything nowadays keeps going "centralize and control". The recommendations are for enterprise networks, although they're also reasonable (although not really accessible to the non-technical) for individuals who care about their privacy as well. An enterprise network isn't (or shouldn't be) some sort of individual free-for-all. In fact, good security practice recommends (although this isn't universally implemented) that all perimeter network traffic, regardless of type, be proxied (or MitM'd, as you put it) to protect from both intrusions and exfiltration of data. Are you claiming that Enterprise networks should allow external resolvers to be used on internal resources willy-nilly? In fact, good security practice demands that devices that aren't authenticated (e.g., with 802.1x) shouldn't be granted access to internal resources at all. On the flip side, internal devices shouldn't rely on external infrastructure resources either. This isn't censorship or some sort of fascistic control mechanism. Rather, it's an appropriate organization response to extant and potential threats to their IT infrastructure and data.
- blondin 6y agounless i am reading this wrong, they are not saying don't send your requests to Cloudfare, Apple, etc. i am not entirely privy to all this, but aren't they entreprise grade DNS resolvers?
- Spooky23 6y agoThey are high quality services, not controlled by the company. It’s pretty obvious that allowing unloggable DNS traffic in an enterprise is a bad idea. It makes ex filtration trivial.
- salawat 6y agoExfiltration already is trivial DNS or not. Just admit that you want to be able to eavesdrop on all activity whatsoever. What, you think that anyone looking to get something out undetected isn't using raw IP's?
- Spooky23 6y agoOn my network? Absolutely, ability to inspect packets is absolutely essential. On a public network? Different story. I’ve personally been engaged in incident response and in many scenarios DNS is a control mechanism for malware, or uses it for various purposes. It’s often a key piece of evidence for reconstruction of an incident. Raw IPs can be used as well, but that doesn’t negate my point.
- 0xquad 6y ago>Raw IPs can be used as well, but that doesn’t negate my point. And in fact if you have enterprise-wide visibility on DNS requests, you have the opportunity to detect the use of an IP that was not returned in a request. Making it immediately suspect.
- jorblumesea 6y agoSecurity recommendations aren't supposed to be brilliant insights. They're just best practices.
- 737min 6y agoExactly right. Many security problems are due to forgoing the simple things in favor of exotic.
- rasengan 6y agoSpecifically, they are saying that in a home/personal environment, it makes sense to use DoH with a public resolver like cloudflare, but in enterprise, you will not be able to maintain tight control over internal use as browsers role out with DoH by default unless you block those public resolvers and enforce policy to use the enterprise resolver. It doesn't matter unless you care about these tight controls though even in enterprise.
- StreamBright 6y agoIt is going to be super hard to block DoH since it is indistinguishable from normal HTTPS traffic. If you MITM the HTTPS connection the browser can detect that and refuse to use the connection. Many companies are in this situation that MITMing HTTPS is not working very well. I think Google enforces HSTS[1]. Not sure how that works with DOH. I also think that we need browsers that do not have any other means of DNS resolution than the good old operating system wide /etc/resolv.conf (or similar). I am not going to fight with Google if I have the right to have my own DNS server or not. They are taking the open internet inch by inch. This is the last drop. 1. https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
- rasengan 6y agoThat's a good point -- I wasn't really thinking about the practicability since it's not something I had much interest in. That said, I guess either blackholing the DNS so it can't initially be resolved, or even figuring out any and all IP addresses it resolves to and blackholing those IPs would be a start. I agree, however, that it should be possible to run your own _______. That's what the internet was meant to be.
- XorNot 6y agoAt an enterprise level the browser configuration is controlled by the IT department. Your MITM CA certificate is going to be forced into the trusted list everywhere.
- 6y ago
- 0xquad 6y agoThey are responding to the very recent emergence of applications (like Firefox) that (optionally) use their own encrypted DNS, thus bypassing the enterprise's ability to apply security policy based on DNS. (Visibility on DNS is also useful to help detect some malware.) I'll allow it.
- vaduz 6y agoIt's clearly also spurred by the attempts to further obfuscate the use of DoH via Oblivious DoH [0] - though they don't go into much details on it. [0] https://news.ycombinator.com/item?id=25344358 https://news.ycombinator.com/item?id=25344358
- Daho0n 6y ago>thus bypassing the enterprise's ability I think you could change it to read " bypassing the NSA's ability" and find the real reason behind this.
- 0xquad 6y agoThey aren't recommending you don't use DoH. Just that you don't allow individual apps to bypass your enterprise resolver. In fact I use the same strategy at home (with DoT) to enforce ad and tracker blocking. It's just common sense really. From the document: >[...] NSA recommends that the enterprise DNS resolver supports encrypted DNS, such as DoH, and that only that resolver be used in order to have the best DNS protections and visibility.