DNS-sikkerhedsudvidelser (DNSSEC) og cybersikkerhedsrisiko

Brancher, der indsamler brugerdata, såsom finans, sundhedspleje og regering, er højt profilerede mål for DNS-angreb, fordi dataene er overbevisende for ondsindede aktører. Inkorporering af en række sikkerhedsafhjælpninger, herunder Domain Name System Security Extensions for at forhindre spoofing-angreb, kan hjælpe en organisation med at forhindre databrud og beskytte sine brugere og deres data mod misbrug.

I denne artikel beskrives det, hvordan DNSSEC (DNS Security Extensions) skaber yderligere sikkerhed for dit domæne, tydeliggør det lovgivningsmæssige behov for DNSSEC-implementering og evaluerer risici, der er forbundet med brug af DNSSEC.

Hvad er DNSSEC?

DNS, eller Domain Name System, leverer routinginfrastrukturen til at forbinde en besøgende på webstedet til den relevante IP-adresse, der svarer til et domænenavn. DNS-sikkerhedsudvidelserne, også kendt som DNSSEC, tilbyder autenticitetsfortolkning for DNS-poster, der verificerer ressourcepostsignaturen ([.rt-script]RRSIG[.rt-script]) med en offentlig nøgle, der er gemt i posten ([.rt-script]DNSKEY[.rt-script]). På en måde henter DNSSEC en signatur for DNS-posten, der bekræfter, at et websted er autentisk gennem kryptografi med offentlig nøgle. DNSSEC udvider DNS-protokollen med kryptografisk godkendelse.

Når DNSSEC er aktiveret for dit domæne, kontrollerer en DNS-resolver DNS-dataene for en tillidskæde, der er knyttet til dit domænes godkendelsesopsætning. Løseren vil verificere, at de digitale signaturer stammer fra en zone, der er tillid til, og som kan bekræftes kryptografisk, hvilket kaldes godkendelse af dataoprindelse. Derudover giver DNSSEC dataintegritetsbeskyttelse mod DNS-cacheforgiftningsangreb for at bekræfte, at data under overførsel ikke er blevet ændret, så DNS-resolveren kan returnere det bekræftede websted til klientbrowseren. Hvis godkendelse og validering mislykkes, returnerer resolveren en fejl i stedet for webstedet.

Uden disse sikkerhedsbestemmelser kunne en resolver omdirigere en bruger til en angribers valgte websted gennem DNS-spoofing eller DNS-cacheforgiftning. Hvordan DNSSEC fungerer med dataoprindelsesgodkendelse og integritet er beskrevet i Internet Engineering Task Force (IETF)'s Request for Comments 4033 (RFC 4033).

DNSSEC bruger en tillidskæde til at hævde top-down autenticitet fra rodzonen. TLD-operatører opretter et tillidsanker til DNS-rodzonen. IANA (Internet Assigned Numbers Authority) koordinerer DNS-ressourcer, herunder rodzonestyring og nøglesigneringsnøglehandlinger for TLD-tillidsankerforbindelser. Når TLD'er giver et tillidsanker til DNS-rodzonen, kan alle domæneejere, der registrerer sig med det pågældende TLD, konfigurere DNSSEC med en tillidskæde, der løses tilbage til den signerede og bekræftede rodzone. Yderligere oplysninger om zonesignering og -løsning kan findes i IETF's RFC 4035. Hvis den signerede zone er påkrævet (som det er tilfældet ved implementering af DNSSEC), er adgangen til domænet mere begrænset, da det skal godkendes, men det er ligeledes beskyttet mod modstander-i-midten-angreb.

Selvom DNSSEC tilføjer en fordelagtig godkendelsesfunktion til domæner, er den endnu ikke bredt implementeret. APNIC Labs rapporterer, at de globale DNSSEC-valideringsrater udgør 40 %, hvoraf 8,35 % kun er delvis validering.

DNSSEC og amerikanske lovkrav

Selvom DNS-sikkerhedsudvidelser ikke er påkrævet af mange overholdelsesregler, er det en nødvendig konfiguration til USA's føderale lovgivningsmæssige behov. Mellem Federal Information Security Management Act (FISMA) og NIST's offentliggjorte standarder (herunder Special Publication 800-53 og Federal Information Processing Standard 140-2) har amerikanske føderale agenturer og tredjepartsudbydere for disse føderale agenturer en række sikkerhedsmæssige baselines at opnå. NIST SP 800-81-2 indeholder en Secure DNS Deployment Guide, der indeholder afsnit om brug af DNS-sikkerhedsudvidelser.

NIST SP 800-53 indeholder et sæt kontroller relateret til system- og kommunikationsbeskyttelse, kaldet "SC." SC-21 og SC-22 angiver forventningerne til DNS-opløsning, herunder en validering via DNSSEC eller en anden godkendt kanal i SC-21. Der ser ikke ud til at være nogen meningsfuld ændring for denne kontrol fra revision 4 til den nyligt implementerede revision 5 (rev 5).

FedRAMP-certificeringen (Federal Risk and Authorization Management Program) inkluderer DNSSEC i det påkrævede kontrolomfang, og organisationer, der bevæger sig gennem certificeringsprocessen, skal attestere deres DNSSEC-konfiguration eller acceptere risikotærsklen for ikke at implementere DNSSEC. FedRAMP-parathedsvurderingsrapporten indeholder følgende spørgsmål i forbindelse med din organisations DNSSEC-konfiguration:

  • "Understøtter systemets eksterne DNS-løsning DNS-sikkerhed (DNSSEC) for at give oprindelsesgodkendelse og integritetsverifikationsforsikringer? Dette gælder for betjeningselementerne SC-20, SC-21 og SC-22 i SSP." (afsnit 4.1)
  • "Har 3PAO [tredjepartsvurderingsorganisation] verificeret, at den eksterne DNS-server svarer med gyldige DNSSEC-svar, og at den rekursive server er inden for en FedRAMP-autoriseret grænse, foretager DNSSEC-anmodninger om domæner uden for grænsen, og at DNS-kald opretholder DNSSEC-godkendelse og integritet? [SC-20, SC-21]" (afsnit 4.2)

National Institute of Standards and Technology (NIST) anslår, at færre end 1100 amerikanske regerings IPv6-domæner med en operationel DNSSEC-implementering, 73 operationelle industriimplementeringer og 30 operationelle universitetsimplementeringer med størstedelen af universitetets DNSSEC-implementeringer usignerede (pr. 8. januar 2023).

Den begrænsede implementering af DNSSEC på verdensplan kan til dels skyldes, at det ikke er blevet påbudt af alle compliance-certificeringer. Det kan også være, at domæneejere og administratorer har accepteret risikoniveauet forbundet med ikke at bruge DNSSEC, da de kan have alternative sikkerhedsforanstaltninger til at beskytte mod risiciene.

DNSSEC og cybersikkerhedsrisici

DNSSEC tilbyder beskyttelse mod en række DNS-angreb, herunder følgende:

  • DNS-spoofing og DNS-cacheforgiftning, hvor DNS-resolveren returnerer falske oplysninger, f.eks. en angribers ondsindede websted.
  • DNS-kapring, hvor en angriber omdirigerer forespørgslen.
  • Adversary-in-the-middle-angreb (nogle gange kaldet man-in-the-middle-angreb eller person-in-the-middle-angreb), hvor en angriber opsnapper kommunikation og potentielt ændrer information under transport. Adversary-in-the-middle-angreb er begrænset på grund af DNSSEC-validering, da angriberen ikke kan signere deres aflytning med den nødvendige nøgle.

Godkendelsen og valideringen fra DNS Security Extensions tilføjer beskyttelse mod visse angrebstyper, men det er ikke den endelige strategi til forebyggelse af cyberangreb. For eksempel hjælper PKI (Public Key Infrastructure) på nettet, såsom SSL/TLS-certifikater, med at beskytte websteder og forbedre brugernes tillid til det websted, de besøger, så web-PKI nogle gange fortrænger det opfattede behov for DNSSEC. DNSSEC beskytter dog domæneejeren mod en angribers spoofing-angreb. Parring af DNSSEC med web-PKI giver supplerende sikkerhedstaktikker for både administrator og brugers ro i sindet.

DNSSEC giver også sikkerhed, der kan hjælpe med at beskytte mod DNS-tunneling, men det forhindrer ikke direkte vedhæftede data til DNS-forespørgsler. Ligeledes beskytter DNSSEC ikke mod denial-of-service-angreb eller typosquatting, så det er vigtigt at implementere en række sikkerhedsteknikker, der tager højde for bredden af angrebstyper.

Da DNSSEC genererer en signeret zone for dit domæne, kan den eksponere alle underdomæner inden for den signerede zone. Mens nogle zonedata er godartede (de fleste websteder forventes f.eks. at have et [.rt-script]www[.rt-script]-underdomæne), kan alle private login-sider eller underdomæner med intern adgang blive inspiceret og måske angrebet af en nysgerrig hacker. Bekræftelsen af DNS-svardata kan udføres på tværs af både overordnede zoner og underordnede zoner for dit domæne.

Sådan konfigureres DNSSEC

DNSSEC-konfiguration sker på domæneudbyderniveau. Domæneejeren og alle tjenesteudbydere er involveret i DNSSEC-processen: domæneejer, domæneregistrator, domæneregister og DNS-udbyder. Både registrator og registreringsdatabase skal understøtte DNSSEC.

DNSSEC-konfigurationsprocessen omfatter tre opgaver:

  1. Konfigurer DNSSEC med din DNS-udbyder, og opret de nødvendige poster.
  2. Aktivér posterne hos din domæneregistrator (i nogle tilfælde kan hostingudbyderen og domæneregistratoren være den samme organisation, f.eks. Cloudflare).
  3. Aktivér signaturvalidering på tværs af DNS-servere.

Dine ressourceposter til DNSSEC-implementering omfatter [.rt-script]A[.rt-script] eller [.rt-script]AAAA[.rt-script]-poster for din IP-adresse, [.rt-script]DNSKEY[.rt-script]-posten, [.rt-script]DS[.rt-script]-posten for delegeringsunderskriver og [.rt-script]RRSIG[.rt-script]-posten. Hvis du vil oprette en [.rt-script]DS[.rt-script]-post med din domæneregistrator, skal du også bruge nøglesignaturerne til din DNS-zone, typisk en nøglesigneringsnøgle (KSK) og en zonesigneringsnøgle (ZSK) samt nøglekode, algoritme, oversigtstype og oversigt.

Domæneregistratorer og hostingudbydere leverer ofte supportdokumentation til DNSSEC. Du kan søge direkte i udbyderens dokumentation eller bruge disse links til populære udbydere:

  • Amazon Web Services (AWS): Konfiguration af DNSSEC-signering i Amazon Route 53
  • Cloudflare: Aktiver DNSSEC
  • dnsimple: DNSSEC-vejledning
  • GoDaddy: Slå DNSSEC til eller fra
  • Google Domains: Konfigurer DNSSEC- og DNS-sikkerhed
  • Squarespace: Navneservere og DNSSEC til Squarespace-administrerede domæner

Microsoft Azure understøtter dog ikke DNSSEC i øjeblikket.

Løbende overvågning kan hjælpe dig med at holde styr på dine sikkerhedsimplementeringer, herunder den aktuelle status for din DNSSEC-konfiguration.

Sammen med andre konfigurationsrisici og softwaresårbarheder scanner UpGuard BreachSight din eksterne angrebsflade for at vurdere dine DNS-konfigurationsindstillinger. For DNS-relaterede resultater giver BreachSight to meddelelser:

  • DNSSEC er ikke aktiveret
  • 'DNS'-port åben

DNSSEC ikke aktiveret efter at finde rapporterer, at din domæneinstallation ikke er konfigureret med DNSSEC. Konfigurer DNSSEC for at godkende svar på DNS-anmodninger og bekræfte, at kun autoriserede løsninger returneres til brugerne. Ved at inkludere DNSSEC i din domænekonfiguration kan du forhindre angribere i at indsætte deres eget domæne under en DNS-opløsning.

Hvis du modtager 'DNS'-portens åbne fund, har din server ikke beskyttet DNS-porten mod offentlige trusler som DNS-cacheforgiftning, modstander-i-midten-angreb eller DNS-spoofing. DNS bruger port [.rt-script]53[.rt-script] til både UDP- og TCP-forbindelse. Din risikosøgning i UpGuard identificerer, hvilken port DNS lytter med, hvis den eksponeres for det offentlige internet. For at forhindre DNS-udnyttelse skal du lukke porten til det offentlige internet. Hvis du har brug for at opretholde en vis adgang mellem det offentlige internet og din DNS-tjeneste, kan du overveje at begrænse adgangen til hærdede servere, der regelmæssigt vedligeholdes, og implementere DNSSEC til zonebeskyttelse. Husk, at DNSSEC kan eksponere din underdomænearkitektur.

>

Nuværende UpGuard-brugere kan logge ind og få adgang til deres risikoprofil i BreachSight for at vurdere, om disse DNS-relaterede resultater påvirker deres organisation. Du kan finde flere oplysninger om andre tjenester, som UpGuard identificerer via portscanning, i vores supportartikel om Hvilke tjenester identificerer UpGuard med portscanning.