3min

Tags in dit artikel

, , , ,

Firefox en Chrome zijn sinds enige tijd geschikt voor DNS over HTTPS (DoH) en andere browsers zullen volgen. Dat maakt browsen veiliger, beweren de bedenkers. Infoblox vindt dit juist een gevaarlijke ontwikkeling.

DNS heeft van het begin af aan last van een securityprobleem bij het laatste ‘station’: communicatie tussen een DNS-client en de lokale DNS-server is in principe onversleuteld. Hierdoor ontstaat een risico op spoofing. Ook kunnen Internet Service Providers (ISP’s) dit onversleutelde DNS-verkeer monitoren. Toegenomen zorgen over deze monitoring van het verkeer door ISP’s heeft geleid tot standaardisatie van moderne DNS-transportprotocollen, die wél versleuteld zijn. Deze DoT- en DoH-protocollen maken het moeilijker om DNS-verzoeken te monitoren of aan te passen.

Dat is waardevol, maar bedrijven moeten zich bewust zijn van hun huidige securitymaatregelen: sluiten die aan op de nieuwe protocollen? Het Nationaal Cyber Security Centrum publiceerde al een factsheet over de nieuwe uitdagingen voor DNS-monitoring, en ik zet het een en ander graag nog even voor je op een rijtje.

DoT en DoH – hoe zat het ook alweer?

Een belangrijk onderdeel van de beveiliging van DNS zijn de DNS Security Extensions, bekend als DNSSEC. Deze zorgen ervoor dat de vertaling van domeinnaam naar IP-adres is voorzien van een digitale handtekening. Hoewel hiermee een bepaalde mate van authenticatie en integriteit wordt gecreëerd, slaat DNSSEC vaak de DNS-cliënt over: de lokale DNS-server voert de DNSSEC-check uit en communiceert het resultaat naar de DNS-client. Die laatste kan echter gespoofd worden.

Om dat probleem bij het eindstation aan te pakken, zijn er nu twee protocollen ontwikkeld: DNS over TLS (DoT) en DNS over HTTPS (DoH). Met de toevoeging van DoT en DoH is communicatie tussen clients en servers versleuteld, waardoor die communicatie privé en veilig is.

DoT maakt hierbij gebruik van een unieke TCP-poort, 853. Voor DoH is dat niet het geval: dat protocol maakt gebruik van poort 443, dezelfde poort die wordt gebruikt voor HTTPS-verkeer. Daardoor wordt het lastig DoH-verkeer van HTTPS-verkeer te onderscheiden.

Hoe DoH eerdere maatregelen buiten spel zet

Eerder werd klanten geadviseerd om direct DNS-verkeer tussen willekeurige IP-adressen en het internet te blokkeren. Hierdoor wordt sommige malware zoals DNSChanger tegengehouden en worden interne hosts gedwongen een door de IT-afdeling beheerde DNS-infrastructuur te gebruiken. Wanneer je gebruik gaat maken van DoH wordt dit echter ingewikkeld, omdat je niet de hele poort kunt blokkeren; deze wordt immers ook gebruikt voor HTTPS-verkeer. Interne hosts komen dus nog steeds terecht bij DNS-servers op het internet (dit probleem geldt niet voor DoT, omdat dat protocol gebruikmaakt van een unieke poort).

Ik twijfel er niet over dat de ontwikkelaars van DoH de beste intenties hadden: één van hun doelen was ervoor te zorgen dat gebruikers veilig kunnen browsen op delen van het internet waar meekijken met DNS-verkeer en manipulatie van DNS-antwoorden vaak voorkomt. Maar als DoH niet zorgvuldig gebruikt wordt, kan het voor enterprise networking net zo goed een bedreiging worden. Als DoH misbruikt wordt om netwerkverkeer naar een onbekende of verdachte DNS-server te leiden, is het middel erger dan de kwaal.

Aanbevelingen voor de inzet van DoT en DoH

Ik zou bedrijven aanraden al het directe DNS-verkeer, inclusief DoT en DoH, tussen interne IP-adressen en DNS-servers op het internet te blokkeren. Met deze aanpak worden gebruikers gedwongen de interne DNS-infrastructuur van het bedrijf te gebruiken, waardoor de IT-afdeling de mogelijkheid krijgt een eigen DNS-resolution policy toe te passen en problemen direct op te lossen.

Het omzeilen van de interne DNS-infrastructuur is een slecht idee, maar het oplossen van de problemen bij het laatste station van DNS is van groot belang. Goede enterprise grade DDI-oplossingen (waaronder Infoblox BloxOne Threat Defense) zijn in staat verkeer naar verdachte DNS-servers op het internet te blokkeren, en dat verkeer om te leiden naar de eigen DNS, zodat DoH toch op een veilige manier kan worden ingezet.

Dit is een ingezonden bijdrage van Maarten Robbrecht, Manager Pre-sales System Engineering Noord-Europa bij Infoblox. Via deze link vind je meer informatie over de mogelijkheden van het bedrijf.