Abstract
En ting er, at måske vil de virksomheder, som eksempelvis ikke har en webshop, og dermed ingen pengestrøm på via deres website, måske fravælge DNSSEC?. Disse virksomheder, der ofte ser lidt let på de udvidede sikkerhedsmuligheder, der findes – men måske kan de også have fordel af DNSSEC? Eksempelvis kan DNSSEC sikrede sites få bedre ranking hos søgemaskiner – ud over at få forbedret sikkerhed.
En anden ting er at virksomheder, organisationer og brancher er (langt) mere udsatte. Disse har et alvorligt syn på sikkerhed, men ved måske ikke hvor vigtigt det er at beskytte DNS opslag eller hvor nemt det er?
Er du i en af nævnte virksomhedstyper, eller måske blot interesseret i sikkerhed, så sæt dig til rette – måske med en god kop af din yndlings bean. Så tager vi dig med på rejse gennem et hav af forkortelser, teknik, statistik, ”nye” tiltag og viser, hvor lidt der skal til for at sikre dig og dine kunder med DNSSEC.
Når vi indledningsvis sætter spørgsmål ved store virksomheders relevans ift. artiklens scope, er det fordi kun 1.8% af Danske websites er sikret med DNSSEC (DIFO – Dansk Internet Forum, 2017). I forhold til de lande vi normalt sammenligner os med ser statistikken ud som følger:
Så det er indlysende, at alle (store, små, private og offentlige) organisationer har interesse i DNSSEC som en beskyttelse af deres domæner.
Hvad er DNSSEC?
Domain Name System Security Extensions (DNSSEC) er en måde så man kan sikre sine brugere at de får den rigtige information når brugerne tilgår dit domæne
Sådan virker det
For at forklare hvordan DNSSEC virker, må vi starte med en forklaring af de nye records, der er tilføjet ifm. indførelsen af DNSSEC.
Nye records
For at kunne håndtere sikkerheden, bliver man nødt til at have nogle digitale signerede keys, så man har noget at validere imod. Hertil er der indført 4 nye record typer:
I de næste afsnit gennemgår vi hvert enkelt og ser på hvordan de fungerer og hvad de gør ifm. DNSSEC.
RRsets (Ressource Record set)
Første skridt for at sikre en zone med DNSSEC er at gruppere de DNS resource records af samme type (f.eks. MX-, A- eller AAAA-records) til ét samlet RRset. Hvis vi tager zonen lb-kurser.dk som eksempel og denne har 4 A records vil illustrationen se nogenlunde således ud:
Når vores A records er grupperet til et enkelt A RRset, kan vi signere denne digitalt. Dette betyder, at alle records signeres som én helhed, hvilket igen betyder, at de naturligvis også skal valideres som en helhed – altså RRsettet. Derfor vil et request også skulle hente alle records ned, inden valideringen kan finde sted.
Dette har naturligvis den ulempe, at der skal laves nye signaturer, hvis der tilføjes eller fjernes en/flere records fra zonen, som f.eks. lb-kurser.dk – men heldigvis er der normalvis ikke hverken daglige eller endda månedlige ændringer i disse records.
ZSK (Zone-Signing Keys)
Hver zone har et par af signeringsnøgler (Zone-Signing Key pair). Den private del af denne benyttes til signering af hvert RRset, mens den offentlige del benyttes til at verificere signaturen.
Dette kan vi illustrere på følgende måde.
Den operatør, der administrerer zonen, skal altså lave digitale signaturer for hvert RRset ved brug af den private ZSK. Disse skal gemmes i navne serveren (DNS´en) som RRSIG-records med nøglens ID, hash mv.
På denne måde viser operatøren, hvordan DNS records fra hans/hendes server skal se ud.
Derudover skal den offentlige ZSK nøgle også gøres tilgængelig i DNS´en, så DNS resolveren har mulighed for at verificere signaturen. Den offentlige ZSK tilføjes serveren i en DNSKEY record.
Når en DNS resolver laver et request på en specifik record type (f.eks. en A-record som i eksemplet) sender navne serveren både resursen (RRset) og signaturen (RRSIG). Resolveren kan så hente zonens DNSKEY record indeholdende den offentlige ZSK og med disse 3 dele kan RRsettet verificeres.
Igen er processen illustreret for at give et visuelt indtryk af processen.
Vi kan på den måde sige, at såfremt vi har tillid til zonens DNSKEY record, kan vi have tillid til alle zonens records idet processen er den samme for hver enkelt record-type.
Processen indtil videre er i sig selv relativ simpel, men på nuværende tidspunkt kan vi ikke garantere gyldigheden af DNSKEY idet vi endnu ikke har en metode til validering af den offentlige ZSK.
Derfor skal vi nu se på endnu en ny record type, som introduceres med DNSSEC.
KSK (Key-Signing Key)
KSK består også af et ”key pair” og den offentlige KSK benyttes til at signere zonens offentlige ZSK (som er gemt i en DNSKEY record). Man kan faktisk sige, at KSK laver den samme proces som ZSK benytter for at verificere et RRset.
Når den offentlige KSK har signeret den offentlige ZSK, laver den signaturen (RRSIG) for den specifikke DNSKEY.
Ligesom den offentlige ZSK, offentliggør navneserveren den offentlige KSK i en anden DNSKEY record som giver os DNSKEY RRSET som vist ovenfor. Både den offentlige KSK og den offentlige ZSK er signeret af den private KSK. Resolvers kan så bruge den offentlige KSK til validering af den offentlige ZSK.
For at give et overblik over validerings processen, indtil videre, kommer her en opsummering af de forskellige steps.
1. En forespørgsel på den ønskede record type returnerer det ønskede RRset, men returnerer samtidig den korrekte RRSIG record.
2. Forespørgsel på DNSKEY record indeholdende offentlig ZSK og offentlig KSK, som også returnerer RRSIG for DNSKEY RRset.
3. Verificér RRSIG af den efterspurgte RRset med den offentlige ZSK
4. Verificér RRSIG af DNSKEY RRset med den offentlige KSK.
Sætter vi illustrationerne sammen ser det således ud:
Når vi nu har hele processen ser det umiddelbart ikke ud af meget, men vi skal huske på, at denne proces kun sikrer for vores zone (lb-kurser.dk).
Der er ikke langt til tanken om, hvor stor belastning vores udbyders DNS server udsættes for, når vi har mange besøgende på vores site, for der ligger jo en masse oplysninger i en DNS server, som besvarer forespørgsler for en stor mængde sites. Men heldigvis kan nogle verificerede records, keys og signaturer caches, så det ikke er hele processen, der skal gennemgås ved hver enkelt forespørgsel.
Belastning af DNS´en er en del af grunden til, at der både er en KSK og en ZSK. Det er besværligt at udskifte en KSK fordi KSK benyttes af parent zone til verificering af Child zonen, dvs. vores zone (lb-kurser) verificeres af Parent-zone, som er .dk-zonen. Operatøren for .dk zonen er DK Hostmaster, og hvis vi skal skifte vores KSK, skal DK Hostmaster ligeledes lave en revalidering af deres ”Delegation Signer” DS (som vi kommer nærmere ind på i næste afsnit). Så udskiftning af en KSK, kræver altså både ændringer fra operatøren fra lb-kurser samt DK Hostmaster.
For at simplificere processen i at udskifte en kompromitteret nøgle blev ZSK tilføjet.
Fordi den er ”lokal” giver det os mulighed for at benytte en mindre nøgle uden at gå på kompromis med sikkerheden på serveren, og dermed minimerer vi også den mængde data, der udveksles ved forespørgsler.
Som nævnt tidligere er den indtil videre skitserede proces kun en del af det store hele. Der mangler nogle vigtige dele idet KSK på nuværende tidspunkt kun signeres af sig selv, og det er der ikke meget sikkerhed i. Det er her vi går ud over vores egen zone, og dermed ud på det uendelige Internet.
DS (Delegation Signer Records)
DNSSECs DS records job er ganske enkelt, at overføre tilliden fra en Parent zone til en Child zone.
Dette sker ved en zone operatør (som DK Hostmaster) laver en hash af den DNSKEY som indeholder den offentlige ZSK og giver den til den zone der ligger over (altså Parent zone) så den kan blive udgivet som en DS record.
Vi kan illustrere det på følgende måde – husk, vi nu går op i DNS hierarkiet.
Hver gang en resolver forespørger på en Child zone, kommer der også en DS record fra Parent zone og det er faktisk på denne måde, at resolveren ved, at der er DNSSEC på Child zonen.
For at validere Child zonens offentlige ZSK laver resolveren også en hash og sammenligner disse.
Matcher disse hash værdier kan resolveren stole på ZSK´en og dermed på alle records i hele zonen og dette er det smarte, for indtil videre har det været ret meget arbejde der skal til for DNS serveren. Men det hele giver meget bedre mening når alle records er valideret ved at validere en enkelt record.
NSEC/NSEC3
Vi har nu gennemgået RRsets, RRSIG, DNSKEY og DS records. De sidste hedder NSEC og NCES3, og dem går vi lidt hurtigt igennem.
NSEC er faktisk ikke ny. Den benyttes til at signere ikke eksisterende sub-domæner, man kan faktisk sige, at den signerer null værdier, for nu at se det i et kendt perspektiv.
NSEC3 løser nogle potentielle trusler/sikkerheds huller, som desværre blev synliggjorte med introduktionen af NSEC.
Tillid, hele vejen
Nu har vi alle dele der skal til for et fungerende DNSSEC system. Vi skal blot sætte de forskellige dele sammen.
Den proces vi beskrev tidligere mellem Child zone og Parent zone, sker igen og igen indtil toppen er nået. Vi har valideret alle nøgler indtil videre og det eneste vi mangler er et overblik samt en forståelse af, hvordan toppen bliver signeret.
Root
I sidste ende, ender vi naturligt nok i toppen af DNS hierarkiet, hvilket (lidt omvendt) kaldes root zonen. Denne zone er ikke meget anderledes end de underliggende i den forstand, at den også skal have sin egen KSK og dermed også DNSKEY.
Havde den ikke dette, ville vi ikke kunne validere og dermed ikke være sikre på tilliden til alle underliggende zoner.
Root zonen signeres af nogle udvalgte personer bl.a. fra ICANN (Internet Corporation For Assigned Names and Numbers) og ISC (Internet Systems Consortium), som mødes ”in person” og signerer den nye nøgle, hvorefter den gamle slettes. Alt dette finder sted på fastsatte datoer, som f.eks. offentliggøres på ISC.org.
Her er et uddrag af den proces, der er i gang for at udskifte root zonens KSK. Det giver et indblik i, hvor stor en operation der skal til.
Fordele vs. Ulemper
Når nu der er så få, der rent faktisk benytter sig af DNSSEC til at sikre deres domæne, kunne man få den tanke, at det var forbundet med en masse bugs eller andre risici.
Det er dog ikke tilfældet, men som med alt andet, er der fordele og ulemper. Der er også mange, der har en mening om, hvorvidt det overhovedet er ”besværet” værd.
Fordele
Vi har været omkring de fordele det giver i form af sikkerhed og det er da også klart, at et domæne med DNSSEC er langt bedre sikret imod angreb som phishing, omdirigering og man-in-the-middle angreb end et domæne uden.
Ulemper (Amplification)
For at forstå ulemperne eller den risiko, der opstår med DNSSEC, eller rettere: den risiko der forhøjes for et domæne med DNSSEC skal vi have fat i den måde hvorpå sikkerheden forhøjes.
Egentlig kan man sige, at det er lidt af et paradoks, for selve risikoen kommer af de algoritmer der benyttes, fordi de er stærkere end de var tidligere (og dermed længere/større), ligesom der med de nye record typer er flere nøgler.
Når man får et respons tilbage efter et DNS lookup, er størrelsen mange gange større end tidligere, og dette kan en angriber udnytte til at få sine requests ”amplified” mange gange. Derved kan angriberen vha. et ganske få antal maskiner sende massive datamængder i et DDoS angreb.
Denne risiko har dog altid eksisteret eftersom den opstod sammen med indførelsen af DNS i tidernes morgen. Men grundet RSA som krypteringsalgoritme, hvor de sikre nøgler bliver større og større, bliver risikoen altså også større ved brug af DNSSEC.
Der findes mange krypterings teknologier, men især peges der på Eliptic Curve Cryptography (ECC).
ECC giver mere sikkerhed end RSA men med kortere nøgler og signaturer. En typisk ECC signatur i DNSSEC er op til 4 gange mindre end tilsvarende fra RSA.
I den følgende illustration har vi lavet et eksempel på først er lookup og derefter en dataudveksling.
Eftersom DNS bliver kaldt internettets telefonbog har vi videreført den analogi (men bibeholdt IP adresser i stedet for telefonnumre)
Aktivering af DNSSEC – så nemt er det
På de følgende sider gennemgår vi aktivering af DNSSEC for domænet; lb-kurser.dk. På denne måde får vi et klart billede af processen og hvor lidt der kræves.
Vi har opdelt processen i 3 dele.
- Aktivering hos din udbyder
- Opsætning af krypteringsnøgler hos DK Hostmaster
- Test DNSSEC på domænet
Del 1: GratisDNS (eller anden udbyder)
1. Log ind hos din DNS udbyder og find domænets DNS indstillinger
2. Klik ”Primær DNS”
3. Find domænet på den liste der vises (hvis du har flere domæner hos denne udbyder). Klik på ”DNSSEC”
4. Læs teksten på siden og sikre, at det er det korrekte domæne. Når du har bekræftet, at domænet er det korrekte, klikker du på ”Click here to activate”
5. Herefter re-loader siden og DNSSEC er aktiveret.
Del 2: DK Hostmaster
1. Login på DK Hostmaster
2. Under Domænenavne finder du domænet, som vist her:
3. Klik på domænenavnet og scroll ned til sektionen DNSSEC-service
4. Klik på ”Vælg” under Administrer og vælg ”Hent DNSSEC-nøgle(r)”
5. Vælg nøgle type og kryptering. Det anbefales at tage den mindste, men sikre metode så pakkerne ikke bliver for store, men heller ikke bliver usikre som SHA-1
Bemærk, nøgleID´et (17329) vil ændre sig for hver nøgle
Vi vælger derfor SHA-2 på 256 bit og klikker ”Videre”
6. Bekræft ændringerne, hvorefter vi får en kvittering på ændringerne.
Del 3: Valideringscheck
Efter ændringerne hos DK Hostmaster, kan vi gå tilbage til DNS udbyderen og se de nye informationer for vores domæne:
Efter et stykke tid er opdateringen sendt igennem netværket og spredt til diverse DNS servere, hvorefter ændringen vil være fuldført.
Vi tester det hos Verisign umiddelbart efter oprettelsen ved at gå ind på dnssec-debugger.verisignlabs.com. (Verisign er DK Hostmasters pendant for .com, .net og andre TLD´er)
Vi kan se, alt er ok – lige bortset fra den manglende DS (Delegation Signer) som fejler fordi de records der efterspørges fra parent zonen (.dk zonen) ikke findes endnu. Disse findes ikke før DK Hostmaster har processeret og valideret den nye ændring og lagt den i deres DNS.
Herefter sker der en gradvis udbredelse af de nye records når der kommer nye forespørgsler.
For god ordens skyld tester vi lb-kurser.dk et stykke tid senere, nogle dage senere faktisk.
Som antaget tidligere ligger de nye records nu i DK-zonen, hvor de skal, og dermed er aktiveringen af DNSSEC på lb-kurser.dk nu fuldført.
Hvordan ser det ud hvis der ikke er DNSSEC på et domæne?
Forskellen ses kun i den nederste del af ovenstående analyse, hvilket giver god mening idet DK zonen er uændret, uanset hvilket domæne vi laver en forespørgsel på.
Referencer
DIFO – Dansk Internet Forum. (2017, 06). Rapport om udvikling og tendenser. Retrieved from DK Hostmaster: https://www.dk-hostmaster.dk/sites/default/files/2017-09/dk-rapport_enkeltsider_FINAL.pdf
Grepular.com. (n.d.). https://www.grepular.com. Retrieved from https://www.grepular.com: https://www.grepular.com/Understanding_DNSSEC
ICANN. (n.d.). Internet Corporation For Assigned Names and Numbers. Retrieved from icann.org: https://www.icann.org/resources/pages/ksk-rollover
Internet Systems Consortium. (2017, 11 02). ics.org. Retrieved from ics.org: https://www.isc.org/downloads/bind/bind-keys/
ISO Training Institute. (2017, Januar 23). Cyber Security – How DNSSEC WORKS. Retrieved from YouTube: https://www.youtube.com/watch?v=bFTVhMCNVPQ