DNSSEC

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 16 juli 2021; kontroller kräver 5 redigeringar .

DNSSEC ( Eng.  Domain Name System Security Extensions ) är en uppsättning IETF -tillägg till DNS- protokollet som låter dig minimera attacker associerade med IP-adressförfalskning när du löser domännamn . Det syftar till att ge DNS-klienter (engelsk term resolver) autentiska svar på DNS-frågor (eller autentisk information om att data saknas) och säkerställa deras integritet. Den använder kryptografi med publik nyckel. Tillgängligheten av data och förfrågningars konfidentialitet är inte säkerställd. Att säkerställa DNS-säkerhet är avgörande för den övergripande Internetsäkerheten.

Beskrivning

Ursprungligen utvecklades inte Domain Name System (DNS) för säkerhetsändamål, utan för att skapa skalbara distribuerade system. Med tiden blir DNS-systemet mer och mer sårbart. Angripare omdirigerar enkelt användarförfrågningar med symboliskt namn till dummyservrar och får på så sätt tillgång till lösenord, kreditkortsnummer och annan konfidentiell information. Användarna själva kan inte göra något åt ​​detta, eftersom de i de flesta fall inte ens misstänker att begäran omdirigerades - posten i webbläsarraden och själva webbplatsen är exakt samma som användaren förväntar sig att se dem. DNSSEC är ett försök till säkerhet samtidigt som det är bakåtkompatibelt.

DNSSEC designades för att skydda klienter från falska DNS-data, till exempel de som genereras av DNS-cacheförgiftning . Alla svar från DNSSEC är digitalt signerade. Vid verifiering av en digital signatur verifierar DNS-klienten informationens riktighet och integritet.

DNSSEC krypterar eller ändrar inte datahantering och är kompatibel med tidigare versioner av det nuvarande DNS-systemet och applikationerna. DNSSEC kan också certifiera information som allmänt kryptografiska certifikat som lagras i DNS CERT-posten . RFC 4398 beskriver hur man distribuerar dessa certifikat, inklusive via e-post, vilket gör att DNSSEC kan användas som ett globalt distribuerat lager av signeringsnyckelcertifikat.

DNSSEC tillhandahåller inte datasekretess; i synnerhet är alla DNSSEC-svar autentiserade men inte krypterade. DNSSEC skyddar inte direkt mot DoS- attacker, även om det gör det indirekt på något sätt. Andra standarder (icke-DNSSEC) används för att tillhandahålla en stor mängd data som skickas mellan DNS-servrar.

DNSSEC-specifikationen ( DNSSEC-bis ) beskriver det aktuella DNSSEC-protokollet. Se RFC 4033 , RFC 4034 och RFC 4035 .

Historik

Inledningsvis hade domännamnssystemet inga mekanismer för att skydda mot utbyte av information i serversvaret, eftersom säkerhetshoten från det moderna Internet inte var relevanta vid tiden för dess utveckling (i början av 1980-talet). Samtidigt bedömde kunderna riktigheten av den information som mottogs enbart av tvåbyte-förfrågningsidentifieraren. Således behövde angriparen iterera över 65536 värden för att "förgifta cachen". Detta innebar att data i DNS-systemet är korrupta (avsiktligt eller på grund av ett misstag), och DNS-servern cachar dem för att optimera prestandan (cachen blir "förgiftad") och börjar leverera denna icke-autentiska data till sina klienter. Redan 1990 identifierade Steve Bellovin allvarliga säkerhetsbrister . Forskning inom detta område har påbörjats och har varit i full gång sedan rapportens publicering 1995 [1] .  

Den första upplagan av DNSSEC RFC 2065 publicerades av IETF 1997. Försök att implementera denna specifikation ledde till den nya specifikationen RFC 2535 1999. Det var planerat att implementera DNSSEC baserat på IETF RFC 2535 .

Tyvärr hade IETF RFC 2535-specifikationen allvarliga problem med att skala till hela Internet. År 2001 stod det klart att denna specifikation var olämplig för stora nätverk. Under normal drift blev DNS-servrar ofta osynkroniserade med sina föräldrar (övre domäner i hierarkin). Detta var vanligtvis inte ett problem, men med DNSSEC aktiverat kan avsynkroniserad data få en oavsiktlig DoS-effekt. Säker DNS är mycket mer beräkningsintensiv, och med större lätthet än "klassisk" DNS kan den ta upp alla datorresurser.

Den första versionen av DNSSEC krävde en kommunikation med sex meddelanden och en stor mängd data för att implementera ändringar i barnet (alla DNS-zoner för barnet måste överföras helt till föräldern, föräldern gör ändringarna och skickar tillbaka dem till barnet ). Dessutom kan ändringar av den offentliga nyckeln få en katastrofal effekt. Till exempel, om ".com"-zonen ändrade sin nyckel, skulle 22 miljoner poster behöva skickas (eftersom alla poster i alla efterföljare måste uppdateras). Således kunde DNSSEC i form av RFC 2535 inte skalas till storleken på Internet.

Dessa komplexiteter ledde i sin tur till uppkomsten av nya specifikationer ( RFC 4033 , RFC 4034 , RFC 4035 ) med grundläggande ändringar av DNSSEC (DNSSEC-bis), vars nya version eliminerade huvudproblemet med den tidigare implementeringen och även om i den nya specifikationen måste kunderna göra ytterligare åtgärder för att kontrollera nycklar, det visade sig vara ganska lämpligt för praktisk användning.

2005 dök den aktuella upplagan av DNSSEC upp, som alla arbetar med. En milstolpe hände 2008, när Dan Kaminsky visade världen att du kan förgifta cachen på 10 sekunder. DNS-programvaruleverantörer har svarat genom att slumpmässigt välja den utgående porten för frågan utöver fråge-ID. Längs vägen började tvister om implementeringen av DNSSEC.

DNSSEC-ändringen, kallad DNSSEC-bis (namnet gavs för att skilja DNSSEC-bis från den ursprungliga DNSSEC-metoden i RFC 2535 ) använder DS-principen ( delegation signer )  för att tillhandahålla ett extra lager av indirekt delegering vid överföring av zoner från förälder till barn . I det nya tillvägagångssättet, när man ändrar den publika nyckeln, skickas endast ett eller två meddelanden till administratören av överordnad domän istället för sex: arvtagaren skickar en sammanfattning (fingeravtryck, hash) av den nya publika nyckeln till föräldern. Föräldern lagrar helt enkelt den publika nyckelidentifieraren för vart och ett av barnen. Det innebär att en mycket liten mängd data kommer att skickas till föräldern istället för att en enorm mängd data utbyts mellan barnet och föräldern.

Signering och validering av DNS-data skapar ytterligare overhead, vilket negativt påverkar nätverks- och serverprestanda. Till exempel, i genomsnitt är DNSSEC-zonen (en uppsättning domännamn på en viss nivå som ingår i en specifik domän) 7-10 gånger större än själva DNS-systemet. Att generera och verifiera signaturer kräver betydande CPU-tid. Signaturer och nycklar tar upp en storleksordning mer utrymme på disken och i RAM-minnet än själva data.

Hur det fungerar

Funktionsprincipen för DNSSEC bygger på användningen av digitala signaturer . Administratören har ett register över att matcha domännamnet och IP-adressen. DNSSEC sätter var och en av dem i strikt överensstämmelse med en speciell, strikt definierad sekvens av tecken, som är en digital signatur. Huvuddragen hos en digital signatur är att det finns öppna, allmänt tillgängliga metoder för att verifiera äktheten av en signatur, men att generera en signatur för godtyckliga data kräver att den hemliga signeringsnyckeln är tillgänglig. Därför kan varje deltagare i systemet verifiera signaturen, men i praktiken kan bara den som har den hemliga nyckeln signera ny eller ändrad data.

I teorin är det ingenting som förbjuder en hackare att beräkna den hemliga nyckeln och plocka upp en signatur, men i praktiken, för en tillräckligt komplex och lång nyckel, kan en sådan operation inte utföras inom rimlig tid med de befintliga beräkningsverktygen och matematiska algoritmerna.

Med en hemlig nyckel är det inte svårt att beräkna en digital signatur. Sådant är arbetet med asymmetriska krypteringssystem med offentlig nyckel som ligger till grund för digitala signaturalgoritmer.

Låt oss säga att en användare kommer åt webbplatsen wikipedia.org. Följande händer:

  1. Användaren begär ett domännamn från resolvern;
  2. Resolvern begär wikipedia.org från DNS-servern (det fanns till exempel ingen information om domänen i cachen på lokala servrar och begäran nådde leverantörens server);
  3. Om det inte finns någon information i cachen för leverantörens servrar, omdirigeras begäran till rotservern, DO-biten ställs också in, vilket informerar om att DNSSEC används;
  4. Rotservern rapporterar att abcnet-servern är ansvarig för organisationszonen. Servern skickar sedan en uppsättning NS-poster för org-zonen, KSK-sammandrag för org-zonen (DS-poster) och en signatur (en RRSIG-post) för NS- och DS-posterna;
  5. Resolvern validerar den mottagna ZSK genom att verifiera att signaturen som skapas av rotzonen KSK matchar. Upplösaren verifierar sedan den digitala signaturen för rotzonens DS-poster som finns i RRSIG-posten. Om allt är korrekt här, litar servern på de mottagna sammandragen och kontrollerar med deras hjälp signaturen för DNSKEY-posten för den lägre nivån - org-zonen;
  6. Nu, efter att ha mottagit adressen till servern som är ansvarig för organisationszonen (server abcnet), vidarebefordrar resolvern samma begäran till den;
  7. Abcnet-servern rapporterar att servern som är ansvarig för wikipedia.org-zonen har adressen d.org. Den skickar också Signing Key Set (ZSK) för organisationszonen signerad med den privata KSK för organisationszonen och KSK-sammanfattningen av wikipedia.org-zonen signerad med ZSK för organisationszonen;
  8. Resolvern jämför hash som tas emot från rotservern med vad den beräknat på egen hand från KSK för organisationszonen som tagits emot från abcnet-servern, och om den matchar börjar den lita på denna KSK. Efter det verifierar resolver signaturerna för nycklarna från organisationszonen och börjar lita på organisationszonens ZSK. Upplösaren kontrollerar sedan KSK för zonen wikipedia.org. Efter alla dessa kontroller har resolvern sammanfattningen (DS) av KSK för zonen wikipedia.org och adressen till d.org-servern där information om zonen wikipedia.org lagras;
  9. Slutligen anropar upplösaren d.org-servern för webbplatsen wikipedia.org, och ställer därvid in lite på att den använder DNSSEC;
  10. d.org-servern förstår att wikipedia.org-zonen är på sig själv och skickar ett svar till resolvern som innehåller wikipedia.org zone signing key set (ZSK) signerad med wikipedia.org-zonen KSK och adressen signerad med wikipedia. org zon ZSK webbplats wikipedia.org;
  11. Liksom i punkt 7 kontrollerar resolvern KSK för zonen wikipedia.org, ZSK för zonen wikipedia.org och adressen till webbplatsen wikipedia.org;
  12. Om incheckningen i punkt 10 lyckas, returnerar resolvern till användaren ett svar som innehåller adressen till webbplatsen wikipedia.org och en bekräftelse på att svaret har verifierats (AD-bitar).

Om något inte kan valideras kommer resolvern att returnera ett servfail-fel.

Den sålunda bildade förtroendekedjan reduceras till rotdomänen och rotzonsnyckeln.

DS -posten (Delegation of Signing ) innehåller en hash av arvtagarens domännamn och dess KSK. DNSKEY -posten innehåller den offentliga delen av nyckeln och dess identifierare (ID, typ och hashfunktion används).

KSK (Key Signing Key) betyder nyckelsigneringsnyckel (långtidsnyckel), och ZSK (Zone Signing Key) betyder zonsigneringsnyckel (långtidsnyckel). Med hjälp av KSK verifieras ZSK, som används för att signera rotzonen. Rotzonen ZSK skapas av PTI ( IANA funktionella divisionen av ICANN ), som är tekniskt ansvarig för att sprida DNS-rotzonen. Enligt ICANN:s procedur uppdateras rotzonen ZSK fyra gånger om året.

Rotzonsignatur

För att fullständigt validera all data som överförs med DNSSEC, krävs en kedja av förtroende från rotzonen (.) av DNS. Implementeringen av en korrekt signerad rotzon på alla rot-DNS-servrar kan orsaka kollaps av det moderna internet, så IETF arbetade med ICANN för att utveckla en steg-för-steg-procedur för att implementera en signerad rotzon och en nyckeldistributionsmekanism . Proceduren drog ut på tiden i mer än 8 månader och inkluderade en steg-för-steg-introduktion till DNS-servrarna först i rotzonen, signerad med en ogiltig elektronisk signaturnyckel . Detta steg var nödvändigt för att tillhandahålla testning av servrar under belastning, för att upprätthålla bakåtkompatibilitet med äldre programvara och för att lämna möjligheten att återgå till en tidigare konfiguration.

I juni 2010 fungerade alla rotservrar korrekt med en zon signerad med en ogiltig nyckel. I juli höll ICANN en internationell konferens tillägnad proceduren för att generera elektroniska signaturnycklar, som sedan signerades av rotzonen.

Den 15 juli 2010 ägde undertecknandet av rotzonen rum och implementeringen av den undertecknade zonen på servrarna började. Den 28 juli tillkännagav ICANN [2] att denna process slutförts. Rotzonen signerades digitalt och spreds i DNS-systemet.

Den 31 mars 2011 undertecknades den största zonen på Internet (90 miljoner domäner) - .com [3] .

Nyckelinfrastruktur

ICANN har valt en modell där signeringen av zonen sköts under kontroll av representanter för internetgemenskapen (Trusted community representative, TCR). Representanter valdes ut bland dem som inte var associerade med DNS-rotzonshantering. De folkvalda representanterna fungerade som Crypto Officers (CO) och Recovery key shareholders (RKSH). CO:erna fick fysiska nycklar för att möjliggöra genereringen av ZSK EDS-nyckeln, och RKSH:erna har smartkort som innehåller delar av nyckeln (KSK) som används inuti den kryptografiska utrustningen. Vissa medier har dragit slutsatsen att förfaranden som kräver närvaro av CO eller RKSH kommer att utföras i händelse av nätverksnödsituationer [4] . I enlighet med ICANN:s rutiner kommer dock COs att vara involverade varje gång en zonsigneringsnyckel (ZSK) genereras, upp till 4 gånger per år, och RKSH förmodligen aldrig, eller i händelse av förlust av CO-nycklar eller en komprometterad rotzon [5] .

Nuvarande tillstånd

Från och med oktober 2013 finns det 81 ccTLD:er och 13 generiska DNSSEC-signerade domäner (utan IDN:er) i rotzonen , vilket ger en kedja av förtroende för andranivådomäner. 2011, med hjälp av DNSSEC (NSEC3 opt-out), undertecknades .su- zonen relaterad till Ryssland, och i slutet av oktober 2012 började publiceringen av användarskapade DS-poster i den. [6] I slutet av 2012 signerades den ryska domänen .ru och dess DS-poster publicerades i rotzonen [7] .

Ändra KSK för rotzonen

Den 11 oktober 2018 inträffade den första rotzonens KSK-rotation sedan rotzonssigneringen 2010. Nyckelrotationen, som ursprungligen var planerad till oktober 2017, försenades av ICANN när det stod klart att ett betydande antal (cirka 2 %) av upplösare var använder samma nyckel för validering av DNSSEC-signaturkedjan. Under året har några tekniska lösningar implementerats i Bind, PowerDNS, Knot och andra DNS-serverpaket, en storskalig kampanj genomfördes för att informera allmänheten om nyckelrotation, och som ett resultat, i september 2018, ICANN Styrelsen beslutade att genomföra nyckelrotation. Det fanns inga betydande problem med nyckelrotation.

Implementeringsproblem och brister

Implementeringen av DNSSEC har försenats kraftigt av anledningar som:

  1. Utveckling av en bakåtkompatibel standard som kan skalas till storleken på Internet;
  2. Oenighet mellan nyckelaktörer om vem som ska äga toppdomäner (.com, .net);
  3. DNS-servrar och klienter måste stödja DNSSEC;
  4. Uppdaterade DNS-resolvers som kan fungera med DNSSEC måste använda TCP;
  5. Varje klient måste skaffa minst en betrodd publik nyckel innan den kan börja använda DNSSEC;
  6. Ökad belastning på nätverket på grund av en allvarligt (6-7 gånger) ökad trafik från förfrågningar;
  7. Ökad belastning på serverprocessorn på grund av behovet av att generera och verifiera signaturer, så att vissa underdrivna DNS-servrar kan behöva bytas ut;
  8. Ökade lagringskrav för att adressera information eftersom signerad data tar mycket mer utrymme;
  9. Det är nödvändigt att skapa, testa och förfina mjukvaran för både server- och klientdelarna, vilket kräver tid och testning i skalan av hela Internet;
  10. Stubbupplösare är inte skyddade från cacheförgiftning - validering sker på sidan av den rekursiva servern, klienten får endast ett svar med AD-biten inställd;
  11. Risken för en DNS Amplification-attack har ökat kraftigt.

De flesta av dessa problem löses av den tekniska Internetgemenskapen.

DNSSEC programvara

Serversidan

De två vanligaste DNS-serverimplementeringarna, BIND och NSD  , stöder DNSSEC (10 av 13 rotservrar använder BIND, de återstående 3 använder NSD). Det finns också stöd för PowerDNS , Unbound och några andra DNS-servrar.

Klientsidan

På grund av det faktum att det fanns väldigt få servrar på vilka DNSSEC-tillägget distribuerades, skapades också väldigt lite slutanvändarprogramvara med DNSSEC-stöd. Microsofts operativsystem har dock redan DNSSEC integrerat. I Windows Server 2008  - RFC 2535 , i Windows 7 och Windows Server 2008 R2 - den aktuella versionen av DNSSEC-bis.

Windows XP och Windows Server 2003 stöder RFC 2535 , men de kan bara identifiera paket från servrar med DNSSEC, det är där deras kapacitet slutar.

Speciellt nämns DNSSEC-Tools- projektet , som är en uppsättning applikationer, tillägg och plugin-program som låter dig lägga till DNSSEC-stöd till webbläsaren Firefox , Thunderbird e- postklient , proftpd , ncftp FTP - servrar och några andra applikationer [8] .

Användningen av DNSSEC kräver programvara på både server- och klientsidan.

Anteckningar

  1. ↑ "Using the Domain Name System for System Break-Ins" Arkiverad 26 februari 2008 på Wayback Machine av Steve Bellovin , 1995   (länk ej tillgänglig)
  2. ↑ Meddelande om DNSSEC Root Signing . Hämtad 30 juli 2010. Arkiverad från originalet 7 augusti 2010.
  3. ↑ Distribuera säkerhetstillägg i .com toppnivådomän
  4. ↑ Sex programmerare delade ut "nycklar för att starta om internet" . Hämtad 5 oktober 2010. Arkiverad från originalet 23 augusti 2010.
  5. ↑ DNSSEC för rotzonen . Hämtad 5 oktober 2010. Arkiverad från originalet 28 oktober 2011.
  6. ↑ DNSSEC i RU-CENTER (otillgänglig länk) . Hämtad 5 november 2012. Arkiverad från originalet 8 november 2012. 
  7. ↑ Graf över antalet signerade domäner i .RU och .РФ . Hämtad 24 mars 2013. Arkiverad från originalet 10 juni 2015.
  8. ↑ DNSSEC-tillägg till DNS för förbättrad säkerhet . Tillträdesdatum: 31 mars 2013. Arkiverad från originalet 24 mars 2013.
  9. ↑ DNSSEC i Windows Server . Hämtad 17 november 2009. Arkiverad från originalet 29 juli 2016.

Länkar

RFC:er