RPKI en het DNS: beschermingsniveaus omhoog, maar nog veel ruimte voor verbetering

Dit is een gastblogpost van Raoul Linssen voor sidnlabs.nl. Raoul is bachelorstudent aan de Universiteit Twente en in deze blog geeft hij een kort overzicht van de bevindingen van zijn bacheloronderzoek. Raouls mentor was Moritz Müller, research engineer bij SIDN Labs.

Het probleem

Het Border Gateway Protocol (BGP) zorgt ervoor dat pakketten die van het ene naar het andere uiteinde van het internet worden verzonden hun bestemming kunnen bereiken. In het geval van het DNS zorgt het BGP ervoor dat als een recursieve resolver het IP-adres van een domeinnaam zoals example.nl wil weten, de query van de resolver ook bij de corresponderende autoritatieve nameserver terecht komt. Stel nou dat de query niet naar de autoritatieve nameserver voor example.nl wordt gestuurd, maar naar een andere locatie op het internet. Dan kan de query hopeloos verdwaald raken, zodat de resolver het IP-adres niet kan ophalen. Of de query zou zelfs kunnen worden beantwoord door een kwaadwillende partij die het verkeerde IP-adres verstrekt. In het eerste scenario kunnen clients gewoon niet bij example.nl komen, maar in het tweede scenario worden ze mogelijk naar een frauduleuze website gestuurd.

De oplossing

Dat tweede scenario is zeker niet uit de lucht gegrepen. Iedere dag claimen netwerken op het internet de legitieme bestemming te zijn voor adressen die niet van hen zijn, met als gevolg dat verkeer de verkeerde kant op wordt gestuurd. Meestal gebeuren dergelijke route-hijackings per ongeluk, maar soms is er opzet in het spel. Domeinnaamhouders kunnen de impact van BGP-hijacking deels mitigeren door DNS Security Extensions (DNSSEC) te implementeren. Een resolver kan dan verifiëren of inderdaad het juiste IP-adres voor example.nl is ontvangen en toepassingen opdragen geen verbinding met een adres te maken als het bijbehorende antwoord niet kan worden geverifieerd. Met het gebruik van DNSSEC wordt de kaping van de IP-ruimte zélf echter niet voorkomen. Een bijkomend probleem is dat DNSSEC-handtekeningen en -validaties nog niet wereldwijd geadopteerd zijn. De Resource Public Key Infrastructure (RPKI) moet die situatie aanpakken. Met RPKI kunnen de eigenaren van IP-adressen een verifieerbare verklaring publiceren, waarin wordt aangegeven vanuit welk netwerk zij hun IP-adresbereik aankondigen. Routers, die verantwoordelijk zijn voor de verzending van pakketten tussen netwerken op het internet, kunnen rekening houden met deze verklaringen bij het bepalen van het beste pad naar het IP-adres. Als een ongeautoriseerd netwerk claimt een IP-adres te hosten, kunnen routers de RPKI gebruiken om te detecteren dat het een valse claim betreft en de verstrekte informatie negeren. Meer informatie kun je vinden in dit voortreffelijke document.

Meting van de RPKI-implementatie

Autoritatieve nameservers die te bereiken zijn op door RPKI beschermde IP-adressen zijn daardoor mogelijk moeilijker te kapen. Hierdoor worden ook de domeinnamen waarvoor zij autoritatief zijn beschermd. RPKI wordt de laatste jaren steeds meer toegepast (zie Figuur 1), maar we wilden vooral graag weten of de netwerken waarin zich nameservers bevinden zijn beveiligd met RPKI.

Figuur 1. Adoptie van RPKI (groene lijn) 2013-2020 (bron: https://rpki-monitor.antd.nist.gov/).

In dit artikel kijken we vooral naar nameservers die autoritatief zijn voor .nl-domeinnamen, maar ook naar nameservers die verantwoordelijk zijn voor andere topleveldomeinen (TLD's) en naar de nameservers voor de root. In totaal analyseerden we in onze paper de nameservers van 11 TLD's. Eerst vroegen we het OpenINTEL-project om een lijst van autoritatieve nameservers die hun IP-adressen vermeldde en voor hoeveel domeinnamen ze autoritatief waren. Daarna gebruikten we de API van de Routing Information Service (RIS) van RIPE NCC om te valideren of de netwerken waarin de IP-adressen zich bevonden RPKI hadden uitgerold. We automatiseerden alle beschreven stappen en maakten het programma openbaar toegankelijk. Naast de hierboven geschetste procedure bevat het programma ook nog enkele andere functies voor het analyseren van de implementatie van RPKI.

.nl is bijna halverwege

We zien dat 47% van de nameservers die autoritatief zijn voor .nl-domeinnamen onderdeel zijn van netwerken beveiligd met RPKI. Dat is iets beter dan het gemiddelde van 45% en veel beter dan het percentage voor autoritatieve nameservers van .com-domeinen (23%). In het DNS kunnen domeinnamen meerdere nameservers hebben. Daarom is een domeinnaam als example.nl alleen volledig beschermd als alle bijbehorende nameservers zich bevinden in netwerken waarop RPKI is geïmplementeerd. Voor .nl is dat het geval voor 41% van de domeinnamen; 29% heeft ten minste één nameserver die beschermd is en 30% is helemaal niet beschermd.

Andere TLD's en de root blijven achter

Het DNS is een hiërarchisch naamgevingssysteem. Dit betekent dat het niet voldoende is om alleen je eigen nameservers te beveiligen. Een resolver heeft ook de nameservers van het TLD en de root-servers nodig bij het ophalen van het IP-adres van een domein als example.nl. SIDN heeft, als beheerder van .nl, 2 van de 3 autoritatieve nameservers voor .nl in netwerken geplaatst die RPKI ondersteunen. Dit weerspiegelt de algemene tendens dat country code TLD's werken met nameservers in beveiligde netwerken (48% van de nameservers van ccTLD's bevindt zich in dergelijke netwerken). Het algemene gemiddelde bedraagt 27%. Van alle TLD's hebben er maar 190 volledig beschermde nameservers, met .de (Duitsland) en .ru (Rusland) als leidende voorbeelden. De root-servers, de meest kritieke nameservers in het DNS, hebben een grotere achterstand. Alleen de servers van de K-root, die worden beheerd door RIPE, zijn volledig beschermd. Dat is een punt van zorg, omdat een aanvaller dus prefixes van de root kan kapen en zo het verkeer voor álle domeinnamen kan omleiden.

Volgende stappen

We kunnen zien dat de implementatie van RPKI toeneemt, maar dat er nog steeds ruimte is voor verbetering. Het feit dat veel domeinnamen dezelfde autoritatieve nameservers gebruiken werkt echter in ons voordeel. Tijdens ons onderzoek constateerden we dat we door RPKI op maar 3 prefixes te implementeren de RPKI-implementatie in .com met 16% konden opvoeren, waardoor 39% van de nameservers beschermd was. Voor .nl-domeinnamen is de top 3 van onbeveiligde prefixes verantwoordelijk voor 3,7%. Na afloop van het onderzoek hebben we meerdere eigenaren van grotere onbeveiligde IP-ruimtes benaderd om te proberen hen te bewegen RPKI te implementeren. Daarop heeft een van hen zijn IP-ruimte voorzien van een handtekening. SIDN heeft contact opgenomen met de provider van haar nameservers met de vraag RPKI ook te implementeren op de laatste nog onbeschermde .nl-nameserver.

Het grotere geheel

Het implementeren van RPKI op netwerken is slechts een onderdeel van het beschermen van het DNS tegen route-hijacking. Daarnaast moeten routers verklaringen over de oorsprong van IP’s gaan valideren met RPKI. Een eerste studie laat zien dat er in dat opzicht nog veel werk aan de winkel is. Als alleen de nameservers van een domein beschermd zijn, blijft het bovendien mogelijk om de IP-adressen van de onderliggende dienst te kapen. Zo kan www.example.nl verwijzen naar een webserver die zich niet in een beveiligd netwerk bevindt en dus kwetsbaar is voor BGP-hijacking. Ons advies is dan ook om RPKI te implementeren op alle netwerken en niet alleen op de netwerken waarin zich DNS-componenten bevinden. Verder is RPKI slechts één stuk van de puzzel als het gaat om een veilig routeringsbeleid. Het MANRS-initiatief (Mutually Agreed Norms for Routing Security) heeft een lijst van aanvullende maatregelen opgesteld die netwerkbeheerders kunnen nemen om hun netwerken en de netwerken van anderen te beschermen. Tot slot, DNSSEC vervult nog steeds een belangrijke rol in de bescherming van domeinnamen en moet dan ook blijven worden ingezet. Download de volledige paper.