Mr. DNS : We zitten al te lang met de risico's van een onbeveiligd DNS-systeem
Een interview met Cricket Liu, mede-auteur van het standaardwerk 'DNS and BIND'
De op dit moment nog beperkte mogelijkheden voor de automatisering van het DNSSEC -beheer vormen de belangrijkste drempel voor de verdere invoering van deze beveiliging voor het DNS-systeem. Dat zegt Cricket Liu, Chief Infrastructure Officer bij Infoblox en mede-auteur van het standaardwerk 'DNS and BIND'. BIND versie 10 is een heel nieuw platform. Alle software is compleet herschreven. Tegelijkertijd heeft ISC veel functionaliteit voor de automatisering van DNSSEC aan de laatste versies van BIND 9 toegevoegd. En dat is maar goed ook. Anders waren al die BIND 9 gebruikers in de problemen gekomen. Die hadden dan naar versie 10 moeten overstappen, terwijl dat echt een heel ander systeem is.
Eerder deze maand was Cricket Liu als spreker te gast op het IPAM BootCamp evenement van SecureLink. Hoewel hij al meer dan tien jaar bij InfoBlox werkt — sinds kort als Chief Infrastructure Officer — kennen de meeste netwerk-specialisten hem natuurlijk als mede-auteur van het standaardwerk 'DNS and BIND'. Daarnaast is hij samen met collega Matt Larson verantwoordelijk voor de podcasts op 'Ask Mr. DNS'.
Je wordt wel Mr. DNS genoemd. Mogen we je ook Mr. DNSSEC noemen?
Mijn vriend Matt en ik hebben inderdaad een podcast genaamd Mr. DNS, maar dat zijn we eigenlijk geen van tweeën. Dat zijn we gezamenlijk, of misschien is dat wel een derde fictieve identiteit voor ons samen. Mr. DNSSEC zou ik mezelf ook niet willen noemen. Dat laat ik aan anderen. Maar ik ben wel al een poosje een groot voorstander van de DNSSEC-technologie.
We zitten al te lang met de risico's van een onbeveiligd DNS-systeem. En er is maar één goede manier om dat aan te pakken, en dat is DNSSEC inschakelen.
De afgelopen tijd hebben we diverse hacks gezien waarbij niet het DNS-systeem zelf maar de web-interfaces van de registrars en hun resellers werden aangevallen. Als je op die manier niet alleen de NS records maar ook het sleutelmateriaal bij de registry kunt aanpassen, dan helpt DNSSEC niet meer. Dan kun je de hele chain-of-trust omzeilen.
Zo'n aanval via een registrar lijkt inderdaad makkelijker uit te voeren dan een Kaminsky-aanval. Je kunt daarvoor gebruik maken van zwakheden in het systeem van een registrar of misschien van relatief eenvoudige social engineering. Zo weten hackers regelmatig de registry-informatie aan te passen door simpelweg een vervalste fax of iets dergelijks te sturen. Er zijn allerlei manieren om zoiets aan te pakken.
De Kaminksy-kwetsbaarheid werd al beschreven in 2008. En de route via de registrars wordt ook al jaren gebruikt. Aanvallers neigen toch naar de makkelijkste manier. Bovendien is van belang of je gericht een specifiek domein wilt aanvallen welke keuze je maakt. Als je iemand in het bijzonder op het oog hebt, maar die maakt toevallig gebruik van een sterke registrar met goed getraind personeel en een waterdichte beveiliging van hun infrastructuur, dan moet je misschien naar Kaminsky kijken. Je kunt ook eerst een kwetsbare registrar hacken en vervolgens rondkijken wat daar te halen valt. Dat is een meer opportunistische insteek.
Voorbeeld daarvan is de hack van het Australische bedrijf Melbourne IT door de Syrian Electronic Army groep (SEA) afgelopen zomer. Via een van de resellers van die registrar wisten ze enkele domeinen van The New York Times en Twitter om te leiden.
Ik geloof niet dat de ene route belangrijker is dan de andere. Ik denk dat we ze beide moeten aanpakken. Enerzijds dus de beveiliging van DNS met DNSSEC. Anderzijds de infrastructuur van de registars.
Het DNS-systeem leek altijd zo eenvoudig. Het was vooral een lijst van records die bijgehouden moest worden. Met DNSSEC is DNS niet langer een administratief systeem, maar wordt daar een ingewikkelde laag van vertrouwensketens en public key cryptografie overheen gelegd.
DNSSEC is inderdaad de meest ingewikkelde uitbreiding die we ooit op DNS hebben gehad. Als je kijkt naar de klassieke DNS-standaard zoals we die in 1983/1984 hebben gedefinieerd, dan is DNSSEC van een compleet andere orde. We hebben over de jaren heen wel andere uitbreidingen gehad. Denk aan EDNS (Extension mechanisms for DNS), waarmee diverse beperkingen van het oude DNS werden opgelost. Maar die uitbreiding is toch relatief beperkt. DNSSEC is echt enorm: nieuwe records, nieuwe processen en veel meer complexiteit.
Mijn grootste zorg is dat bij de ontwikkeling van DNSSEC nooit rekening is gehouden met het gemak van de beheerder. Sterker nog, deze nieuwe standaard lijkt wel haast vijandig tegenover hem te staan. Dat is waarom ik zo aandring bij leveranciers als Infoblox en software developers als het Internet Systems Consortium (ISC, de ontwikkelaar van BIND named) om het beheer zo veel mogelijk te automatiseren. Er zijn te veel zaken die bij DNSSEC mis kunnen gaan. Zo kun je niet van systeembeheerders verwachten dat zij zelf bijhouden wanneer sleutels verlopen en moeten worden gerold. En zo is er een hele lijst van administratieve zaken die hen uit handen moet worden genomen.
Tegelijkertijd kunnen DNS-operators het zich toch niet permiteren om te wachten tot de software voor elkaar is? Je kunt op dit moment nog experimeteren. Als je nu een fout maakt is er nog geen man overboord. Als iedereen straks valideert wordt je gelijk afgestraft. Dan betekent een foutje gelijk dat de mail gateways en de websites van je domeinen niet meer beschikbaar zijn.
Dat klopt; je moet nu van start gaan, experimenteren en leren. Inmiddels valideren Google Public DNS en Comcast (de grootste Amerikaanse internet provider voor consumenten) al. En je wilt niet wachten totdat de grote spelers je dwingen om DNSSEC op stel en sprong te implementeren. Over een paar jaar doet iedereen validatie.
Je kunt voorzichtig beginnen, met het ondertekenen van een enkele zone. Want als je een fout maakt in de configuratie, of je vergeet een keer om een sleutel te rollen, dan werkt het gelijk niet meer. Het overkomt de besten: NASA, Verisign en de beheerder van het .mil top-level domein. En je kunt bepaald niet zeggen dat er amateurs bij Verisign werken. Er is geen onderneming ter wereld waar ze zo veel van DNS weten. Zij kennen het protocol van binnen en buiten, en toch maken ze fouten.
Probleem met de Amerikaanse overheidsdomeinen is dat er een richtlijn lag dat federale overheidsorganisaties onder het .gov domein voor een bepaalde datum van DNSSEC moesten worden voorzien. Dus iedereen ondertekende op het laatste nippertje zijn domeinen. Daarbij werd veelal met een checklist voor de ondertekening gewerkt, maar werden de processen voor het vernieuwen van de handtekeningen soms vergeten. Als gevolg daarvan konden toen na een maand de initiële handtekeningen waren verlopen veel van die domeinen niet meer gevalideerd worden.
De automatisering van DNSSEC in BIND versie 9 laat nogal te wensen over. Met name het sleutelbeheer vraagt veel aandacht. PowerDNS, de favoriet van de grote providers in Nederland, lijkt dat een stuk beter te doen.
De automatisering van DNSSEC heeft in de laatste versies van BIND 9 veel aandacht gekregen. Ik zou je niet kunnen zeggen hoe die faciliteiten zich verhouden tot die van PowerDNS. Infoblox doet zijn DNS op basis van BIND, maar ik kan deze niet vergelijken met andere DNS software.
BIND versie 10 is een heel nieuw platform. Alle software is compleet herschreven. Tegelijkertijd heeft ISC veel functionaliteit voor de automatisering van DNSSEC aan de laatste versies van BIND 9 toegevoegd. En dat is maar goed ook. Anders waren al die BIND 9 gebruikers in de problemen gekomen. Die hadden dan naar versie 10 moeten overstappen, terwijl dat echt een compleet ander systeem is. Het is niet te vergelijken met een traditionele upgrade. Ook het beheer van BIND 10 is echt heel anders.
Wie op zoek is naar boeken over DNSSEC komt van een koude kermis thuis: op Amazon is op dit moment maar één boek te vinden dat specifiek over DNSSEC gaat.
DNSSEC was de afgelopen jaren toch nog een "moving target". Na de definitie van de eerste standaard zijn er regelmatig aanpassingen gedaan. Zo zijn de type-codes later nog aangepast. En daarna bleek de implementatie van NSEC op bezwaren van grote bedrijven als Verisign te stuiten. Er moesten te veel records worden toegevoegd. Bovendien klaagden de security-specialisten dat die gevoelig waren voor "name walking". Vandaar dat toen NSEC3 nog werd toegevoegd.
Dat maakt het voor mensen die boeken schrijven lastig om aan de slag te gaan. Bovendien zijn met DNSSEC ook alle tools nog sterk aan verandering onderhevig. Om een nieuwe standaard te kunnen documenteren moet je ergens een vlag kunnen neerzetten: dit is wat ik ga beschrijven. Kortom, mensen zoals ik hebben een heleboel uitvluchten waarom ze de laatste versie van DNSSEC nog niet hebben gedocumenteerd.
Ander belangrijk argument is de grootte van de doelgroep. Op dit moment zijn er nog niet zo veel gebruikers. De adoptie van DNSSEC in de VS is nog laag, dus je weet van tevoren dat je er niet rijk van gaat worden. Overigens werk ik op dit moment samen met Matt inderdaad aan een boek over DNSSEC.
Ander voorbeeld is de ontwikkeling van een verhuisprotocol waarmee domeinen naar een andere registrar kunnen worden overgedragen zonder dat daarbij de beveiliging wordt verbroken. Die verhuismethode is bedacht door de technisch specialisten van SIDN en wordt inmiddels gestandaardiseerd.
De Nederlanders lopen ver voorop met de implementatie van DNSSSEC, en voor zo'n klein landje hebben jullie ook onevenredig grote invloed op de ontwikkeling daarvan. Het was een heel goed idee om de registrars korting te geven op hun beveiligde domeinen. Dat deden jullie veel slimmer dan wij in de VS. Daar werd simpelweg een decreet uitgevaardigd dat bepaalde domeinen voor een bepaalde deadline ondertekend moesten zijn. En anders zou er wat zwaaien. Maar jullie aanpak van verleiden blijkt veel beter te werken dan onze aanpak van dreigen.
Een ander probleem dat ik op dit moment zie, is dat er geen standaard manier is om sleutelmateriaal naar de registry te uploaden. Dat is nog een ernstige tekortkoming. De meeste registrars bieden hun klanten op dit moment een webpagina, maar daarvoor moet je echt op zoek naar de URL. Bovendien wil je dat niet met de hand doen. Je kunt toch niet elke keer voor de rollover van een sleutel naar een webpagina gaan waar je je records handmatig moet invoeren. Dat moet je kunnen automatiseren. Er zijn zelfs registrars die je vragen om een mailtje te sturen als je sleutelmateriaal wilt laten registeren.
Is het probleem niet dat er nog te weinig voordelen aan de verder uitrol en implementatie van DNSSEC zitten? Moet er niet meer nadruk gelegd worden op technologieën als DANE, waarmee je een gratis alternatief hebt op basis van self-signed certificaten voor veel van die dure CA-certificaten. Welke andere technologieën zou je nog op die beveiligde infrastructuur kunnen bouwen om DNSSEC verder uit te nutten, geld te besparen en waarde te creëren voor zijn gebruikers?
Er zijn legio toepassingen die je kunt gebruiken, ervanuitgaande dat je die cryptografisch beveiligde name space al tot je beschikking hebt. Op dit moment kijken we inderdaad vooral naar de beveiliging van de informatie die sowieso al in je DNS records is opgeslagen. DANE is inderdaad een heel goed voorbeeld van een nieuwe toepassing waarmee je geld kunt besparen. Maar er zijn meer voorbeelden van dure, gevoelige en belangrijke informatie die je in het DNS-systeem kunt opslaan. Tot op heden was dat toch altijd een beetje gevaarlijk, omdat je die records niet kon valideren.
DKIM (DomainKeys Identified Mail) is ook zo'n geval. Daarmee kun je nu authenticatie-informatie opslaan in je DNS-systeem, zodat iedereen elkaar veilig kan mailen, zonder dat daarvoor eerst sleutels hoeven worden uitgewisseld.
Ik ben geen futuroloog, dus ik zou je niet kunnen zeggen waar de zakelijke kansen liggen. Maar er zijn zeker toepassingen te bedenken die we voorheen lieten liggen omdat er geen beveiligde infrastructuur was, die straks wel mogelijk zijn. Die slimme ideeën komen vanzelf.
Hoe zorgen we dat die DNSSEC-infrastructuur zo snel mogelijk van de grond komt? Voor de grote providers die het DNS-beheer voor hun klanten doen is het relatief makkelijk. Zij ondertekenen in één grote batch job honderdduizenden domeinen tegelijk. Maar hoe zit het met die laag daaronder, waar enorm veel middelgrote BIND-installaties staan.
Het makkelijkst voor mij als werknemer van Infoblox is natuurlijk om te zeggen dat ze een appliance moeten kopen. Maar daar ligt inderdaad een groot probleem. Er zullen altijd techneuten zijn die zelf hun DNS-server willen runnen en configureren. In de VS neemt het aantal mensen dat die techniek in de vingers heeft echter snel af. Ik draai nog steeds mijn eigen server, maar bij klanten zie ik dat steeds minder. Vroeger had je daar een heleboel systeembeheerders die alles wisten van TCP/IP, van UNIX- en later Linux-systeembeheer. Het beheer van een DNS-server paste heel goed bij hun werk en vaardigheden.
Dat is inmiddels wel anders. Ik zie steeds minder mensen met die achtergrond. Er zijn steeds minder mensen met een gedegen kennis van Linux, slimmerikken die met inventieve oplossingen komen. Ik heb dat aantal over de jaren heen echt af zien nemen. Die mensen sterven uit, en dat stemt mij droef, want ik was er zelf zo een. Men is tegenwoordig meer product-georiënteerd en beperkt tot grafische interfaces. Dat maakt het voor hen heel lastig om BIND te beheren.
Veel organisaties lijken inderdaad de implementatie van DNSSEC te combineren met een volledige vernieuwing van hun DNS-infrastructuur. Dat lijkt vanuit het oogpunt van risicobeheersing echter geen voordehandliggende aanpak.
Soms zal dat niet anders kunnen, maar ik ben van mening dat je de risico's van dit soort migraties inderdaad zo veel mogelijk moet beperken. En dat betekent dat je het aantal grote veranderingen zo klein mogelijk moet houden. Wij raden aan om eerst de systemen te installeren, en pas daarna de domeinen opnieuw in te richten. Maar dat zal niet altijd kunnen. Als je de opdracht hebt om DNSSEC te implementeren en je huidige servers ondersteunen dat niet, dan moet je wel. Maar ook dan kun je ervoor kiezen om eerst alles in orde te maken, en pas daarna de zones te gaan ondertekenen.
