DNSSEC ( Eng. Domain Name System Security Extensions ) er et sæt IETF -udvidelser til DNS -protokollen , der giver dig mulighed for at minimere angreb forbundet med IP-adresse-spoofing, når du løser domænenavne . Det har til formål at give DNS-klienter (engelsk term resolver) autentiske svar på DNS-forespørgsler (eller autentiske oplysninger om manglende data) og sikre deres integritet. Den bruger offentlig nøglekryptering. Tilgængeligheden af data og fortroligheden af anmodninger er ikke sikret. At sikre DNS-sikkerhed er afgørende for den overordnede internetsikkerhed.
Oprindeligt blev Domain Name System (DNS) ikke udviklet til sikkerhedsformål, men for at skabe skalerbare distribuerede systemer. Med tiden bliver DNS-systemet mere og mere sårbart. Angribere omdirigerer nemt brugeranmodninger med symbolsk navn til dummy-servere og får dermed adgang til adgangskoder, kreditkortnumre og andre fortrolige oplysninger. Brugerne kan ikke selv gøre noget ved dette, da de i de fleste tilfælde ikke engang har mistanke om, at anmodningen blev omdirigeret - indtastningen i browserlinjen og selve webstedet er nøjagtig det samme, som brugeren forventer at se dem. DNSSEC er et forsøg på sikkerhed, mens det er bagudkompatibelt.
DNSSEC blev designet til at beskytte klienter mod falske DNS-data, såsom dem, der genereres af DNS-cache-forgiftning . Alle svar fra DNSSEC er digitalt signeret. Ved verificering af en digital signatur verificerer DNS-klienten oplysningernes rigtighed og integritet.
DNSSEC krypterer eller ændrer ikke dataadministration og er kompatibel med tidligere versioner af det nuværende DNS-system og applikationer. DNSSEC kan også certificere oplysninger såsom generelle kryptografiske certifikater gemt i DNS CERT-posten . RFC 4398 beskriver, hvordan disse certifikater distribueres, herunder via e-mail, hvilket gør det muligt at bruge DNSSEC som et globalt distribueret lager af signeringsnøglecertifikater.
DNSSEC giver ikke databeskyttelse; især er alle DNSSEC-svar autentificeret, men ikke krypteret. DNSSEC beskytter ikke direkte mod DoS- angreb, selvom det på en eller anden måde gør det indirekte. Andre standarder (ikke-DNSSEC) bruges til at levere en stor mængde data, der sendes mellem DNS-servere.
DNSSEC-specifikationen ( DNSSEC-bis ) beskriver den aktuelle DNSSEC-protokol. Se RFC 4033 , RFC 4034 og RFC 4035 .
Oprindeligt havde domænenavnesystemet ikke mekanismer til at beskytte mod substitution af information i serversvaret, da sikkerhedstruslerne fra det moderne internet på tidspunktet for dets udvikling (i begyndelsen af 1980'erne) ikke var relevante. Samtidig vurderede kunderne rigtigheden af de oplysninger, der blev modtaget udelukkende af to-byte anmodnings-id'en. Således var angriberen nødt til at iterere over 65536 værdier for at "forgifte cachen". Dette betød, at dataene i DNS-systemet er beskadiget (med vilje eller på grund af en fejl), og DNS-serveren cacher dem for at optimere ydeevnen (cachen bliver "forgiftet") og begynder at servere disse ikke-autentiske data til sine klienter. Tilbage i 1990 identificerede Steve Bellovin alvorlige sikkerhedsfejl . Forskning på dette område er begyndt og har været i fuld gang siden udgivelsen af rapporten i 1995 [1] .
Den første udgave af DNSSEC RFC 2065 blev udgivet af IETF i 1997. Forsøg på at implementere denne specifikation førte til den nye specifikation RFC 2535 i 1999. Det var planlagt at implementere DNSSEC baseret på IETF RFC 2535 .
Desværre havde IETF RFC 2535-specifikationen alvorlige problemer med at skalere til hele internettet. I 2001 blev det klart, at denne specifikation var uegnet til store netværk. Under normal drift blev DNS-servere ofte ude af synkronisering med deres forældre (øverste domæner i hierarkiet). Dette var normalt ikke et problem, men med DNSSEC aktiveret kunne desynkroniserede data have en utilsigtet DoS-effekt. Sikker DNS er meget mere beregningsintensiv, og med større lethed end "klassisk" DNS kan den optage alle computerressourcer.
Den første version af DNSSEC krævede en seks-meddelelseskommunikation og en stor mængde data for at implementere ændringer til barnet (alle barnets DNS-zoner skal være fuldstændigt overført til forælderen, forælderen foretager ændringerne og sender dem tilbage til barnet ). Derudover kan ændringer af den offentlige nøgle have en katastrofal effekt. For eksempel, hvis ".com"-zonen ændrede sin nøgle, så skulle der sendes 22 millioner poster (fordi alle poster i alle efterfølgere skulle opdateres). DNSSEC i form af RFC 2535 kunne således ikke skaleres til internettets størrelse.
Disse kompleksiteter førte til gengæld til fremkomsten af nye specifikationer ( RFC 4033 , RFC 4034 , RFC 4035 ) med grundlæggende ændringer til DNSSEC (DNSSEC-bis), hvis nye version eliminerede hovedproblemet ved den tidligere implementering, og selvom i den nye specifikation skal kunderne foretage yderligere handlinger for at kontrollere nøgler, det viste sig at være ganske velegnet til praktisk brug.
I 2005 udkom den aktuelle udgave af DNSSEC, som alle arbejder med. En skelsættende begivenhed skete i 2008, da Dan Kaminsky viste verden, at man kan forgifte cachen på 10 sekunder. DNS-softwareleverandører har reageret ved tilfældigt at vælge den udgående port for forespørgslen ud over forespørgsels-id'et. Undervejs begyndte stridigheder om implementeringen af DNSSEC.
DNSSEC-ændringen, kaldet DNSSEC-bis (navnet blev givet for at skelne DNSSEC-bis fra den oprindelige DNSSEC-tilgang i RFC 2535 ) bruger DS-princippet ( delegation signer ) til at give et ekstra lag af indirekte delegering ved overførsel af zoner fra forælder til barn . I den nye tilgang, når den offentlige nøgle ændres, sendes der kun én eller to beskeder til administratoren af det overordnede domæne i stedet for seks: arvingen sender et sammendrag (fingeraftryk, hash) af den nye offentlige nøgle til forælderen. Forælderen gemmer blot den offentlige nøgle-id for hvert af børnene. Det betyder, at en meget lille mængde data vil blive sendt til forælderen i stedet for, at der udveksles en enorm mængde data mellem barnet og forælderen.
Signering og validering af DNS-data skaber yderligere overhead, hvilket påvirker netværks- og serverydeevnen negativt. For eksempel er DNSSEC-zonen (et sæt domænenavne på et bestemt niveau inkluderet i et specifikt domæne) i gennemsnit 7-10 gange større end selve DNS-systemet. Generering og verificering af signaturer bruger betydelig CPU-tid. Signaturer og nøgler optager en størrelsesorden mere plads på disken og i RAM end selve dataene.
Funktionsprincippet for DNSSEC er baseret på brugen af digitale signaturer . Administratoren har en registrering af at matche domænenavnet og IP-adressen. DNSSEC sætter hver af dem i nøje overensstemmelse med en speciel, strengt defineret sekvens af tegn, som er en digital signatur. Hovedtræk ved en digital signatur er, at der er åbne, offentligt tilgængelige metoder til at verificere ægtheden af en signatur, men generering af en signatur for vilkårlige data kræver, at den hemmelige signeringsnøgle er tilgængelig. Derfor kan hver enkelt deltager i systemet verificere signaturen, men i praksis er det kun den, der har den hemmelige nøgle, der kan signere nye eller ændrede data.
I teorien er der intet, der forbyder en hacker at beregne den hemmelige nøgle og hente en signatur, men i praksis, for en tilstrækkelig kompleks og lang nøgle, kan en sådan operation ikke udføres inden for rimelig tid med de eksisterende computerværktøjer og matematiske algoritmer.
Med en hemmelig nøgle er det ikke svært at beregne en digital signatur. Sådan er arbejdet med asymmetriske offentlige nøglekrypteringssystemer, der ligger til grund for digitale signaturalgoritmer.
Lad os sige, at en bruger får adgang til webstedet wikipedia.org. Følgende sker:
Hvis noget ikke kan valideres, vil resolveren returnere en servfail-fejl.
Den således dannede tillidskæde reduceres til roddomænet og rodzonenøglen.
DS -posten (Delegation of Signing ) indeholder en hash af arvingens domænenavn og dets KSK. DNSKEY -posten indeholder den offentlige del af nøglen og dens identifikatorer (ID, type og hash-funktion brugt).
KSK (Key Signing Key) betyder Key Signing Key (Long-Term Key), og ZSK (Zone Signing Key) betyder Zone Signing Key (Long-Term Key). Ved hjælp af KSK verificeres ZSK, som bruges til at signere rodzonen. Root Zone ZSK er skabt af PTI ( IANA funktionelle division af ICANN ), som er teknisk ansvarlig for at udbrede DNS-rodzonen. I henhold til ICANN's procedure opdateres Root Zone ZSK fire gange om året.
For fuldt ud at validere alle data, der overføres ved hjælp af DNSSEC, kræves en tillidskæde fra rodzonen (.) af DNS. Implementeringen af en korrekt signeret rodzone på alle rod-DNS-servere kan forårsage kollaps af det moderne internet, så IETF arbejdede sammen med ICANN for at udvikle en trin-for-trin procedure til implementering af en signeret rodzone og en nøgledistributionsmekanisme . Proceduren trak ud i mere end 8 måneder og omfattede en trin-for-trin introduktion til DNS-serverne først i rodzonen, signeret med en ugyldig elektronisk signaturnøgle . Dette trin var nødvendigt for at levere test af servere under belastning, for at opretholde bagudkompatibilitet med ældre software og for at give mulighed for at rulle tilbage til en tidligere konfiguration.
I juni 2010 fungerede alle rodservere korrekt med en zone signeret med en ugyldig nøgle. I juli afholdt ICANN en international konference dedikeret til proceduren for generering af elektroniske signaturnøgler, som efterfølgende blev underskrevet af rodzonen.
Den 15. juli 2010 fandt signeringen af rodzonen sted, og implementeringen af den signerede zone på serverne begyndte. Den 28. juli annoncerede ICANN [2] færdiggørelsen af denne proces. Rodzonen blev digitalt signeret og udbredt i DNS-systemet.
Den 31. marts 2011 blev den største zone på internettet (90 millioner domæner) - .com [3] underskrevet .
ICANN har valgt en model, hvor signeringen af zonen styres under kontrol af repræsentanter for internetsamfundet (Trusted community representative, TCR). Repræsentanter blev udvalgt blandt dem, der ikke var tilknyttet DNS-rodzonestyring. De valgte repræsentanter fungerede som Crypto Officers (CO) og Recovery key shareholders (RKSH). CO'erne fik fysiske nøgler for at muliggøre generering af ZSK EDS-nøglen, og RKSH'erne er i besiddelse af chipkort, der indeholder dele af nøglen (KSK), der bruges inde i det kryptografiske udstyr. Det er blevet konkluderet af nogle medier, at procedurer, der kræver tilstedeværelse af CO eller RKSH, vil blive udført i tilfælde af netværksnødsituationer [4] . I overensstemmelse med ICANN's procedurer vil CO'er dog blive involveret hver gang en zonesigneringsnøgle (ZSK) genereres, op til 4 gange om året, og RKSH sandsynligvis aldrig, eller i tilfælde af tab af CO-nøgler eller en kompromitteret rodzone [5] .
Fra oktober 2013 er der 81 ccTLD'er og 13 generiske DNSSEC-signerede domæner (uden IDN'er) i rodzonen , hvilket giver en kæde af tillid til domæner på andet niveau. I 2011 blev .su -zonen relateret til Rusland underskrevet med hjælp fra DNSSEC (NSEC3 opt-out), og i slutningen af oktober 2012 begyndte udgivelsen af brugeroprettede DS-poster i den. [6] I slutningen af 2012 blev det russiske domæne .ru underskrevet , og dets DS-records blev offentliggjort i rodzonen [7] .
Den 11. oktober 2018 fandt den første Root Zone KSK rotation sted siden Root Zone Signing i 2010. Nøglerotationen, der oprindeligt var planlagt til oktober 2017, blev forsinket af ICANN, da det blev klart, at et betydeligt antal (ca. 2%) af resolvere var bruger den samme nøgle til validering af DNSSEC-signaturkæden. I løbet af året blev nogle tekniske løsninger implementeret i Bind, PowerDNS, Knot og andre DNS-serverpakker, en storstilet kampagne blev gennemført for at informere den brede offentlighed om nøglerotation, og som et resultat, i september 2018, blev ICANN Bestyrelsen besluttede at gennemføre nøglerotation. Der var ingen væsentlige problemer med nøglerotation.
Implementeringen af DNSSEC er blevet meget forsinket af årsager som:
De fleste af disse problemer løses af det tekniske internetfællesskab.
De to mest almindelige DNS-serverimplementeringer, BIND og NSD , understøtter DNSSEC (10 ud af 13 rodservere bruger BIND, de resterende 3 bruger NSD). Der er også understøttelse af PowerDNS , Unbound og nogle andre DNS-servere.
På grund af det faktum, at der var meget få servere, hvorpå DNSSEC-udvidelsen blev installeret, blev der også oprettet meget lidt slutbrugersoftware med DNSSEC-understøttelse. Microsofts operativsystemer har dog allerede DNSSEC integreret. I Windows Server 2008 - RFC 2535 , i Windows 7 og Windows Server 2008 R2 - den aktuelle version af DNSSEC-bis.
Windows XP og Windows Server 2003 understøtter RFC 2535 , men de kan kun genkende pakker fra servere med DNSSEC, det er her deres muligheder slutter.
Særligt nævnes DNSSEC-Tools- projektet , som er et sæt applikationer, tilføjelser og plug-ins, der giver dig mulighed for at tilføje DNSSEC-understøttelse til Firefox -browseren, Thunderbird - mailklienten , proftpd , ncftp FTP - servere og nogle andre applikationer [8] .
Brugen af DNSSEC kræver software på både server- og klientsiden.
| Grundlæggende TCP / IP-protokoller efter lag af OSI-modellen | |
|---|---|
| Fysisk | |
| kanaliseret | |
| netværk | |
| Transportere | |
| session | |
| Repræsentation | |
| Anvendt | |
| Andet anvendt | |
| Liste over TCP- og UDP-porte | |
| Internetsikkerhedsmekanismer _ | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Kryptering og trafikfiltrering _ |
| ||||||||||||||
| Godkendelse | |||||||||||||||
| Computerbeskyttelse |
| ||||||||||||||
| IP-telefonisikkerhed |
| ||||||||||||||
| Trafikanonymisering | |||||||||||||||
| Trådløs sikkerhed | |||||||||||||||