Veilig DoH-gebruik nog niet gemakkelijk

Want stel je voor dat binnen je organisatie potentieel iedere applicatie andere protocollen kan gebruiken buiten je bedrijfs-resolver om!

DNS is een essentieel onderdeel van het internet maar is tot op heden een van de minst veilige actief gebruikte protocollen. Bedrijven als Google en Cloudflare introduceren publieke DoH-oplossingen ter beveiliging, maar deze zijn niet geschikt voor zakelijk gebruik. Daarom adviseerde de NSA onlangs uit veiligheidsoverwegingen een interne DoH-bedrijfs-resolver te gebruiken.

DNSSEC biedt bescherming tegen spoofing, maar dit geldt niet voor het laatste stukje tussen de DNS-client en de DNS-resolver. Het gebruik van DoH/DoT biedt voor deze ‘last mile’ betere bescherming van de integriteit en de vertrouwelijkheid van data-uitwisseling.

Daarnaast is het voor bedrijven niet wenselijk dat gevoelige informatie via externe resolvers van Google, Cloudflare of een andere publieke DoH-server gaat die buiten de controle van de organisatie valt. Dit brengt ook een groter risico met betrekking tot malware met zich mee: al in 2019 - krap een jaar nadat de eerste DoH-tests in browsers werden uitgerold - werd malware ontdekt (Godlua) die publieke DoH-resolvers als command-and-control mechanisme gebruikte.

Maar hoe breng je het advies in de praktijk? Dat is makkelijker gezegd dan gedaan.

De anekdote over mijn telefoon geeft de potentiële nachtmerrie aan die dreigt voor administrators en hoe securityrisico’s kunnen toenemen doordat securitycontroles ongewild omzeild worden. Organisaties kunnen een aantal, elkaar aanvullende, maatregelen nemen om ongewenst DoH-verkeer naar publieke DoH servers te blokkeren. Een van deze maatregelen is het toevoegen van een IP-feed aan de firewall. Sommige firewalls bieden dit als standaardfeature. Daarnaast kan ook SSL-decryptie worden ingezet om DoH-verkeer te traceren. Tenslotte kun je de interne DNS-resolver gebruiken om queries naar publieke DoH-servers (bijvoorbeeld dns.google) en zogenaamde canary domains (een mechanisme dat bijvoorbeeld Firefox gebruikt om te bepalen of er gebruik gemaakt mag worden van DoH) te blokkeren. Ongewenst DoT-verkeer is eenvoudiger te blokkeren doordat er gebruik wordt gemaakt van een toegewijde port (853).

Vervolgens moet je zorgen dat alle aangesloten apparatuur waar mogelijk je eigen, interne DoH-resolver gebruikt. En in de woorden van Moritz Müller, research engineer bij SIDN Labs: “Dit klinkt makkelijker dan het is.”

Zowel in browser als OS

Het belangrijkste uitgangspunt is dat je controle moet hebben over de applicatie-instellingen en dat je dit zo veel mogelijk op OS-niveau zou moeten doen. Anders wordt troubleshooting al snel een eindeloze klopjacht. Gelukkig zien we naast de reeds aanwezige DoT/DoH-ondersteuning in browsers ook ontwikkelingen in de implementatie van deze protocollen op OS-niveau.

Apple biedt met MacOS Big Sur en iOS 14 al volledige DoH-ondersteuning. Apple biedt daarnaast de mogelijkheid aan domeineigenaren om via een nieuw type DNS-record (HTTPS of TYPE65) via DNS te publiceren welke DoH-server voor resolving gebruikt moet worden. Deze oplossing is niet onomstreden, omdat dit een nieuwe manier kan opleveren om interne resolvers te omzeilen. Bij Microsoft wordt DoH momenteel ondersteund in een preview-versie van Windows 10, waar het in te stellen is via de Registry Editor. Zowel Microsoft als Apple bieden mogelijkheden om de te gebruiken interne DoH-resolver te laten afhangen van de IP-adressen die door DHCP worden uitgegeven.

Voor Linux is er tot slot (nog) geen standaard aan te wijzen. De DoT-ondersteuning in een specifieke systeemdienst (‘systemd-resolved’) komt in de buurt, maar er is een legio aan opties beschikbaar voor client-servers.

De implementatie van interne DoH-resolvers is complex, maar de uitdaging is te overkomen. Door de gebruikte operating systems in de basis goed in te richten en ongewenst gedrag op applicatieniveau goed te blokkeren, kunnen beheerders het laatste gat in DNS-beveiliging dichten - zonder dat het een hoofdpijndossier wordt.