A long time ago I used to do network security – hardening, pentesting, that sort of thing – for Sun Microsystems, and one of our key challenges was “nomadics“, that in a company of 40-thousand people, a large contingent would be equipped with PCMCIA modems and chunky laptops, remotely logging into Sun’s intranet from hotels all over the world whilst they were selling, fixing, or consulting around Sun’s huge hardware and software catalogue.
Now: the frustrated devops geek working furiously at home at 2 a.m. — performing a mission-critical migration, or fixing”#UnbreakNow” bugs — is beyond stereotypical. Developers ship code to production over their single-origin flat whites. If there’s an “office” at all, the only non-laptop “information assets” that are connected directly to it are the laserprinters … and hardly anyone’s been into the office recently, for obvious reasons.
Being “nomadic” is now so normal that it’s practically default… except at Fort Meade.
The NSA in their recent — and, to be fair, mostly sensible — white paper regarding “Adopting Encrypted DNS in Enterprise Environments”, has this to say about how companies should go about maintaining compliance / preventing random apps from accessing arbitrary nameservers:
If an enterprise wants to use DoH, ensure that the DoH clients only send queries to the enterprise DNS resolver. Disable and block all other DoH resolvers. To disable all other DoH on an enterprise network, configure network security devices at the enterprise gateway to block known DoH resolvers so hosts cannot circumvent DNS security controls and cyber threat actors cannot easily use it to hide their actions. There are several public lists of known DoH resolver domain names and IP addresses. In addition, disable DoT by blocking transmission control protocol port 853 at the enterprise gateway.
https://media.defense.gov/2021/Jan/14/2002564889/-1/-1/0/CSI_ADOPTING_ENCRYPTED_DNS_U_OO_102904_21.PDF
and…
Block unauthorized DoH resolvers and traffic
https://media.defense.gov/2021/Jan/14/2002564889/-1/-1/0/CSI_ADOPTING_ENCRYPTED_DNS_U_OO_102904_21.PDF
Enterprise administrators should understand the limitations of DHCP for devices connecting to their network. If clients use their own default DoH resolver, the clients will attempt to send DoH requests to that resolver first before the DNS resolver from the DHCP configuration is used. An enterprise that chooses to disable DoH should block known DoH resolver IP addresses and domains, so devices on the network will fail to resolve a domain name using DoH and usually revert back to traditional DNS, going through the DNS resolver assigned by DHCP.
Enterprises may monitor encrypted network traffic using TLS inspection. These enterprises should apply signatures in the devices that break and inspect the TLS traffic to block unauthorized DoH requests. Note that the TLS inspection devices must be able to properly decrypt and interpret DoH requests for this to be effective since the decrypted DNS requests would not come over port 53 like traditional DNS requests.
Now, to be fair, “I get it” — the NSA are worried about the same sort of tradeoff that I discuss in the “Year of DNS over HTTPS over Tor” paper, that with the securing and encryption of DNS there will be a consequent loss of signal, that “Indicators of Compromise” (IOCs) will become less visible, making it hard to detect Russian spies, Chinese spies, North Korean spies, or frustrated contractors who are attempting to exfiltrate data via networked means.
But they are about 10, perhaps 15 years out of date, and the pandemic may now have driven a final, large stake through the assumptions that power their perspective.
Just two little words: “enterprise gateway“
Who has an “enterprise gateway” worthy of that name, any more? I know what one is — I’ve built a few dozen in my time — and back when first I joined Surevine in 2011 the lack of a tangible “enterprise firewall” that I could poke with a finger gave me the creeps. But it made sense: so long as AWS the cloud provider was adequate at combatting DDoS, then access security was wholly a matter of security groups and credential management – and perhaps an “even more credential management” VPN for convenience.
Again, the NSA’s paper is not bad – it recommends up-to-date VPNs, it recommends DNSSEC, it even says to “Only use current TLS versions to protect against issues in the underlying HTTPS” — which is odd because the current version is TLS 1.3 which revolts against their observation, higher-up, that “DoH encrypts the DNS traffic, which prevents enterprises from monitoring DNS with these network-based tools unless they are breaking and inspecting TLS traffic“.
We even agree that admins should “ensure that the DoH clients only send queries to the enterprise DNS resolver“, and there’s the tiniest nod towards nomadism with their assumption that VPNs are “the fix”:
Enterprises … may use virtual private networks (VPN) or proxies to keep their traffic more private, especially in mobile and teleworking environments.
https://media.defense.gov/2021/Jan/14/2002564889/-1/-1/0/CSI_ADOPTING_ENCRYPTED_DNS_U_OO_102904_21.PDF
But we differ utterly upon the means of control; NSA’s mindset is framed by the risk of “invaders at the castle gate” — but most of the world’s development happens without the turrets, portcullis, boiling oil and “fetchez la vache!” of ancient lore. You can even see that in their opening frame:
NSA: “Using DoH with external resolvers can be good for home or mobile users and networks that do not use DNS security controls.” — well, duh — “For enterprise networks, however, NSA recommends using only designated enterprise DNS resolvers in order to properly leverage essential enterprise cybersecurity defenses, facilitate access to local network resources, and protect internal network information.“
Again: for most companies there is no “internal” any more.
With that observation flows the proper solution: “blocking” access to competing DoH providers is not a fix; as the (as now, poorly-named) blogpost puts it: “Blacklists Don’t Work“, they are a weak and rot-prone security architecture in general, and in specific they won’t protect a devops-, developer-, or presales-geek who’s “making do” with non-enterprise-gateway internet access from home or the local Starbucks.
The solution for “mobile users” — indeed, the solution for all “enterprise users” who work from places other than a warm office with free coffee and rich in cross-infection risk — is Mobile Device Management (MDM). The IT team should manage the apps and settings of apps upon “employee devices” — and should push back on their MDM providers if necessary management features are not being provided.
DoH is not the evil. The evil is poor management. Blocking and blocklists are inelegant solutions, unfit for nomadics, ripe for bypass, and providing exactly the same kind of false assurance (“A false sense of security; DoH is not a panacea…”) that the NSA blithely throw at DoH-in-general. The solution is in “allowlists”, permitted software, permitted configurations, and enforcement thereof.
I’m astonished that the NSA didn’t write that. I am astonished — but perhaps not surprised — to see a complete lack of reference to MDM in the NSA’s white paper. The word “manage” does not appear, although words mentioning “control” appear 13 times.
But to do so they would have to step away from their castle model, and incidentally would have to give up on attempting to popularise a meme of “the best way to address DoH is to attempt to block it.“
Postscript
Every one of my recent employments has had at least one incident where the office Wifi has “gone down”, and every single developer’s automatic response has been to flip their phone over to “tethering”, connect their laptop to that, and continue pushing to Github.
Whither “enterprise gateways” in that environment?
Leave a Reply