DNS heeft van oudsher te maken met een “last mile” security-probleem: de communicatie tussen een DNS-client en zijn lokale DNS-server verloopt vrijwel altijd onversleuteld en is daardoor gevoelig voor spoofing, interceptie enzovoorts. Twee voorgestelde mechanismen om dat probleem aan te pakken, DNS over TLS (“DoT”) en DNS over HTTPS (“DoH”), kunnen beide gebruikt worden om de bestaande DNS infrastructuur van de organisatie te omzeilen. Vanuit security-standpunt is dat echter niet de beste oplossing. In dit blog leg ik uit hoe DoT en DoH werken en doe ik aanbevelingen om de security-problemen van DNS-clients aan te pakken.
DoT en DoH wat?
DNSSEC, de DNS Security Extensions, voegen weliswaar authenticatie en data integriteit checks toe aan DNS, maar gaan gewoonlijk voorbij aan de DNS-client. De lokale DNS-server voert DNSSEC-validatie uit en controleert de authenticiteit en de integriteit van de data, maar speelt het resultaat vervolgens door naar de DNS-client op een manier die kwetsbaar is voor spoofing. De DPRIVE (DNS PRIVate Exchange) werkgroep van de IETF heeft twee oplossingen ontwikkeld voor dit “last mile” probleem van DNS: DNS over TLS, ook wel bekend als “DoT”, vastgelegd in RFC 7858, en DNS over HTTPS, beter bekend als “DoH”, vastgelegd in RFC 8484.
Zowel DoT als DoH hebben belangrijke functionaliteiten: de communicatie tussen DNS-clients en DNS-servers wordt met DoT en DoH versleuteld, zodat data-privacy en -integriteit worden gewaarborgd. DNS-clients kunnen DNS-servers naar wens met beide protocollen authentiseren.
DoT maakt gebruik van een unieke TCP-poort: 853. DoH daarentegen maakt gebruik van TCP-poort 443, die ook gebruikt wordt voor ander HTTPS-verkeer. Dat maakt het erg lastig om DoH van ander HTTPS-verkeer te onderscheiden.
Gewoonlijk adviseren we klanten direct DNS-verkeer tussen willekeurige interne IP-adressen en het internet te blokkeren. Dat voorkomt dat bepaalde typen malware, zoals DNSChanger, hun werk kunnen doen, en het dwingt interne hosts een door IT beheerde DNS infrastructuur te gebruiken. Die interne DNS infrastructuur kan bijvoorbeeld een Name Resolution Policy toepassen die gebruik maakt van beveiligingsmechanismen zoals Response Policy Zones (RPZ’s). Helaas maakt DoH het heel moeilijk te voorkomen dat interne hosts DNS-servers op het internet queryen. (DoT is eenvoudig te blokkeren omdat het een unieke bekende poort gebruikt.)
Sommige applicaties die DoH ondersteunen, negeren bovendien bewust lokale DNS-client configuraties. De Firefox browser van Mozilla biedt bijvoorbeeld in sommige versies een experimentele ondersteuning voor DoH. Als dat aan staat, negeert Firefox alle lokale DNS-configuraties en stuurt DNS-queries direct over HTTPS naar Cloudflare. Daarmee omzeilt het alle lokale beveiligingsmechanismen, zoals RPZ’s. Bovendien wordt zo de DNS-resolutie van gebruikers onzichtbaar voor de interne IT-organisatie. Het maakt het ook nog eens een stuk ingewikkelder om DNS-problemen op te sporen, omdat nu één applicatie op een apparaat (Firefox, in dit geval) andere DNS-servers gebruikt dan andere applicaties.
De motieven van de DoH ontwikkelaars waren goed: hun doel was webbrowsen veiliger te maken op delen van het internet waar DNS-verkeer afluisteren en DNS-responses manipuleren helaas vaak voorkomt. Maar voor gebruik op bedrijfsnetwerken is het niet de meest geschikte benadering.
Implementatieaanbevelingen voor DoT en DoH
Bedrijven doen er goed aan direct DNS-verkeer tussen interne IP-adressen en DNS-servers op het internet te blokkeren, inclusief DoT, DoH en Cloudflare. Dat dwingt gebruikers als het goed is de interne DNS-infrastructuur van hun organisatie te gebruiken, waardoor de interne IT-afdeling DNS resolution policies kan toepassen en mogelijke problemen kan oplossen.
Standaard DNS- en DoT-verkeer tussen interne IP-adressen is simpel te blokkeren. Dit soort firewall-regels zouden voldoende moeten zijn:
# Allow queries from authorized internal DNS servers to the Internet
allow tcp/udp in/out <authorized internal DNS server 1> on port 53
…
# Deny queries from other internal IP addresses to the Internet
deny tcp/udp in/out to all IP addresses on port 53
deny tcp/udp in/out to all IP addresses on port 853
DoH blokkeren is lastiger, omdat een firewall het niet kan onderscheiden van HTTPS, maar de volgende firewall-regels zouden moeten werken:
# Block DoH to Cloudflare
deny tcp/udp in/out to 1.1.1.1 on port 443
deny tcp/udp in/out to 1.0.0.1 on port 443
deny tcp/udp in/out to 2606:4700:4700::1111 on port 443
deny tcp/udp in/out to 2606:4700:4700::1001 on port 443# Block DoH to Google Public DNS
deny tcp/udp in/out to 8.8.8.8 on port 443
deny tcp/udp in/out to 8.8.4.4 on port 443
deny tcp/udp in/out to 2001:4860:4860::8888 on port 443
deny tcp/udp in/out to 2001:4860:4860::8844 on port 443
Het DNS “last mile” probleem moet worden opgelost. Daarom werkt Infoblox nauw samen met het Internet Systems Consortium, onze partner, om DoT-ondersteuning toe te voegen aan een volgende versie van BIND, en vervolgens aan Infoblox NIOS.
Dit is een ingezonden bijlage van Cricket Liu, Chief DNS Architect bij Infoblox. Via deze link vind je meer informatie over de mogelijkheden van het bedrijf.
5 uur geleden
