DNSSEC

Versiunea actuală a paginii nu a fost încă examinată de colaboratori experimentați și poate diferi semnificativ de versiunea revizuită la 16 iulie 2021; verificările necesită 5 modificări .

DNSSEC ( Eng.  Domain Name System Security Extensions ) este un set de extensii IETF la protocolul DNS care vă permite să minimizați atacurile asociate cu falsificarea adreselor IP atunci când rezolvați numele de domenii . Acesta are ca scop furnizarea clienților DNS (termen resolver în engleză) cu răspunsuri autentice la interogările DNS (sau informații autentice despre faptul că lipsesc date) și să asigure integritatea acestora. Utilizează criptografia cu cheie publică. Disponibilitatea datelor și confidențialitatea solicitărilor nu sunt asigurate. Asigurarea securității DNS este esențială pentru securitatea generală a Internetului.

Descriere

Inițial , sistemul de nume de domeniu (DNS) nu a fost dezvoltat în scopuri de securitate, ci pentru a crea sisteme distribuite scalabile. În timp, sistemul DNS devine din ce în ce mai vulnerabil. Atacatorii redirecționează cu ușurință cererile utilizatorilor prin nume simbolic către servere fictive și astfel obțin acces la parole, numere de card de credit și alte informații confidențiale. Utilizatorii înșiși nu pot face nimic în acest sens, deoarece în cele mai multe cazuri nici măcar nu bănuiesc că cererea a fost redirecționată - intrarea din linia browserului și site-ul în sine sunt exact aceleași pe care utilizatorul se așteaptă să le vadă. DNSSEC este o încercare de securitate în timp ce este compatibil cu versiunea inversă.

DNSSEC a fost conceput pentru a proteja clienții de datele DNS false, cum ar fi cele generate de otrăvirea cache-ului DNS . Toate răspunsurile de la DNSSEC sunt semnate digital. La verificarea unei semnături digitale, clientul DNS verifică corectitudinea și integritatea informațiilor.

DNSSEC nu criptează sau modifică gestionarea datelor și este compatibil cu versiunile anterioare ale actualului sistem DNS și aplicațiilor. DNSSEC poate certifica, de asemenea, informații precum certificatele criptografice de uz general stocate în înregistrarea DNS CERT . RFC 4398 descrie modul de distribuire a acestor certificate, inclusiv prin e-mail, ceea ce permite DNSSEC să fie utilizat ca depozit distribuit la nivel global de certificate de cheie de semnare.

DNSSEC nu oferă confidențialitatea datelor; în special, toate răspunsurile DNSSEC sunt autentificate, dar nu criptate. DNSSEC nu protejează direct împotriva atacurilor DoS , deși o face indirect într-un fel. Alte standarde (non-DNSSEC) sunt utilizate pentru a furniza o cantitate mare de date care sunt trimise între serverele DNS.

Specificația DNSSEC ( DNSSEC-bis ) detaliază protocolul DNSSEC actual. A se vedea RFC 4033 , RFC 4034 și RFC 4035 .

Istorie

Inițial, sistemul de nume de domeniu nu avea mecanisme de protecție împotriva înlocuirii informațiilor în răspunsul serverului, deoarece la momentul dezvoltării sale (la începutul anilor 1980), amenințările de securitate ale internetului modern nu erau relevante. În același timp, clienții au apreciat corectitudinea informațiilor primite numai de către identificatorul de solicitare pe doi octeți. Astfel, atacatorul trebuia să repete peste 65536 de valori pentru a „otrăvi cache-ul”. Aceasta a însemnat că datele din sistemul DNS sunt corupte (intenționat sau din cauza unei greșeli), iar serverul DNS le memorează în cache pentru a optimiza performanța (cache-ul devine „otrăvit”) și începe să servească aceste date neautentice clienților săi. În 1990, Steve Bellovin a identificat  defecte serioase de securitate . Cercetările în acest domeniu au început și sunt în plină desfășurare de la publicarea raportului în 1995 [1] .

Prima ediție a DNSSEC RFC 2065 a fost publicată de IETF în 1997. Încercările de implementare a acestei specificații au condus la noua specificație RFC 2535 în 1999. Sa planificat implementarea DNSSEC pe baza IETF RFC 2535 .

Din păcate, specificația IETF RFC 2535 a avut probleme serioase cu scalarea la întregul Internet. Până în 2001, a devenit clar că această specificație nu era potrivită pentru rețelele mari. În timpul funcționării normale, serverele DNS au devenit adesea nesincrone cu părinții lor (domeniile superioare din ierarhie). Aceasta nu a fost de obicei o problemă, dar cu DNSSEC activat, datele desincronizate ar putea avea un efect DoS neintenționat. DNS securizat este mult mai intens din punct de vedere al calculului și, cu o ușurință mai mare decât DNS-ul „clasic”, poate ocupa toate resursele de calcul.

Prima versiune a DNSSEC a necesitat o comunicare cu șase mesaje și o cantitate mare de date pentru a implementa modificările copilului (toate zonele DNS ale copilului trebuie să fie complet transferate părintelui, părintele face modificările și le trimite înapoi copilului ). În plus, modificările aduse cheii publice ar putea avea un efect dezastruos. De exemplu, dacă zona „.com” și-a schimbat cheia, atunci ar trebui trimise 22 de milioane de înregistrări (pentru că toate înregistrările din toți succesorii trebuiau actualizate). Astfel, DNSSEC sub forma RFC 2535 nu a putut fi scalat la dimensiunea Internetului.

Aceste complexități, la rândul lor, au condus la apariția unor noi specificații ( RFC 4033 , RFC 4034 , RFC 4035 ) cu modificări fundamentale ale DNSSEC (DNSSEC-bis), a căror nouă versiune a eliminat principala problemă a implementării anterioare și, deși în noua specificație, clienții trebuie să facă acțiuni suplimentare pentru verificarea cheilor, s-a dovedit a fi destul de potrivit pentru utilizare practică.

În 2005 a apărut actuala ediție a DNSSEC, cu care lucrează toată lumea. Un eveniment marcant a avut loc în 2008, când Dan Kaminsky a arătat lumii că poți otrăvi cache-ul în 10 secunde. Furnizorii de software DNS au răspuns selectând aleatoriu portul de ieșire pentru interogare, în plus față de ID-ul interogării. Pe parcurs, au început dispute cu privire la implementarea DNSSEC.

Modificarea DNSSEC, numită DNSSEC-bis (numele a fost dat pentru a distinge DNSSEC-bis de abordarea originală DNSSEC în RFC 2535 ) folosește principiul DS ( semnatar de delegare )  pentru a oferi un strat suplimentar de delegare indirectă atunci când se transferă zone de la părinte la copil . În noua abordare, la schimbarea cheii publice, doar unul sau două mesaje sunt trimise administratorului domeniului părinte în loc de șase: moștenitorul trimite părinte un digest (amprentă, hash) al noii chei publice. Părintele stochează pur și simplu identificatorul cheii publice pentru fiecare dintre copii. Aceasta înseamnă că o cantitate foarte mică de date va fi trimisă părintelui în loc să fie schimbată o cantitate imensă de date între copil și părinte.

Semnarea și validarea datelor DNS creează cheltuieli suplimentare, care afectează negativ performanța rețelei și a serverului. De exemplu, în medie, zona DNSSEC (un set de nume de domenii de un anumit nivel incluse într-un anumit domeniu) este de 7-10 ori mai mare decât sistemul DNS în sine. Generarea și verificarea semnăturilor consumă timp CPU semnificativ. Semnăturile și cheile ocupă un ordin de mărime mai mult spațiu pe disc și în RAM decât datele în sine.

Cum funcționează

Principiul de funcționare al DNSSEC se bazează pe utilizarea semnăturilor digitale . Administratorul are o înregistrare a potrivirii numelui de domeniu și adresei IP. DNSSEC pune fiecare dintre ele în strictă conformitate cu o secvență specială, strict definită de caractere, care este o semnătură digitală. Caracteristica principală a unei semnături digitale este că există metode deschise, disponibile public pentru verificarea autenticității unei semnături, dar generarea unei semnături pentru date arbitrare necesită ca cheia secretă de semnare să fie disponibilă. Prin urmare, fiecare participant în sistem poate verifica semnătura, dar în practică doar cel care deține cheia secretă poate semna date noi sau modificate.

În teorie, nimic nu interzice unui hacker să calculeze cheia secretă și să ridice o semnătură, dar în practică, pentru o cheie suficient de complexă și lungă, o astfel de operație nu poate fi efectuată într-un timp rezonabil cu instrumentele de calcul și algoritmii matematici existenți.

Cu o cheie secretă, calcularea unei semnături digitale nu este dificilă. Aceasta este munca sistemelor de criptare asimetrice cu chei publice care stau la baza algoritmilor de semnătură digitală.

Să presupunem că un utilizator accesează site-ul wikipedia.org. Se întâmplă următoarele:

  1. Utilizatorul solicită un nume de domeniu de la resolver;
  2. Resolverul solicită wikipedia.org de la serverul DNS (de exemplu, nu existau informații despre domeniu în cache-ul serverelor locale și cererea a ajuns la serverul furnizorului);
  3. Dacă nu există informații în cache-ul serverelor furnizorului, cererea este redirecționată către serverul rădăcină, se setează și bitul DO, informând că se utilizează DNSSEC;
  4. Serverul rădăcină raportează că serverul abcnet este responsabil pentru zona organizației. Serverul trimite apoi un set de înregistrări NS pentru zona organizației, rezumate KSK pentru zona organizației (înregistrări DS) și o semnătură (o înregistrare RRSIG) a înregistrărilor NS și DS;
  5. Resolverul validează ZSK-ul primit prin verificarea faptului că semnătura făcută de zona rădăcină KSK se potrivește. Resolverul verifică apoi semnătura digitală a înregistrărilor DS din zona rădăcină conținute în înregistrarea RRSIG. Dacă totul este corect aici, atunci serverul are încredere în rezumatele primite și verifică cu ajutorul lor semnătura înregistrării DNSKEY de la nivelul inferior - zona organizației;
  6. Acum, după ce primește adresa serverului responsabil pentru zona organizației (server abcnet), rezolutorul îi trimite aceeași cerere;
  7. Serverul abcnet raportează că serverul responsabil pentru zona wikipedia.org are adresa d.org. De asemenea, trimite setul de chei de semnare (ZSK) al zonei organizaționale semnat cu KSK privat al zonei organizaționale și rezumatul KSK al zonei wikipedia.org semnat cu ZSK al zonei organizației;
  8. Resolverul compară hash-ul primit de la serverul rădăcină cu ceea ce a calculat singur de la KSK-ul zonei organizaționale primit de la serverul abcnet și, dacă se potrivește, începe să aibă încredere în acest KSK. După aceea, rezolutorul verifică semnăturile cheilor din zona org și începe să aibă încredere în ZSK-ul zonei org. Resolverul verifică apoi KSK-ul zonei wikipedia.org. După toate aceste verificări, resolverul are digest-ul (DS) al KSK-ului zonei wikipedia.org și adresa serverului d.org unde sunt stocate informații despre zona wikipedia.org;
  9. În cele din urmă, soluția apelează serverul d.org pentru site-ul wikipedia.org și, făcând acest lucru, stabilește puțin că folosește DNSSEC;
  10. Serverul d.org înțelege că zona wikipedia.org este pe ea însăși și trimite un răspuns către resolver care conține setul de chei de semnare a zonei wikipedia.org (ZSK) semnat cu zona wikipedia.org KSK și adresa semnată cu wikipedia. org zone ZSK site wikipedia.org;
  11. De asemenea, ca la punctul 7, rezolutorul verifică KSK-ul zonei wikipedia.org, ZSK-ul zonei wikipedia.org și adresa site-ului wikipedia.org;
  12. Dacă verificarea punctului 10 are succes, rezolutorul returnează utilizatorului un răspuns care conține adresa site-ului wikipedia.org și confirmarea că răspunsul a fost verificat (bit AD setat).

Dacă ceva nu poate fi validat, soluția va returna o eroare servfail.

Lanțul de încredere astfel format este redus la domeniul rădăcină și cheia zonei rădăcină.

Înregistrarea Delegației de semnare ( DS ) conține un hash al numelui de domeniu al moștenitorului și KSK-ul acestuia. Înregistrarea DNSKEY conține partea publică a cheii și identificatorii acesteia (ID, tip și funcție hash utilizată).

KSK (cheie de semnare a cheii) înseamnă cheie de semnare a cheii (cheie pe termen lung), iar ZSK (cheie de semnare a zonei) înseamnă cheie de semnare a zonei (cheie pe termen lung). Cu ajutorul KSK, se verifică ZSK, care este folosit pentru a semna zona rădăcină. Zona rădăcină ZSK este creată de PTI ( divizia funcțională IANA a ICANN ), care este responsabilă din punct de vedere tehnic pentru propagarea zonei rădăcină DNS. Conform procedurii ICANN, Root Zone ZSK este actualizată de patru ori pe an.

Semnătura zonei rădăcină

Pentru a valida pe deplin toate datele transferate folosind DNSSEC, este necesar un lanț de încredere din zona rădăcină (.) a DNS-ului. Implementarea unei zone rădăcină semnate corespunzător pe toate serverele DNS rădăcină ar putea provoca colapsul internetului modern, așa că IETF a colaborat cu ICANN pentru a dezvolta o procedură pas cu pas pentru implementarea unei zone rădăcină semnate și a unui mecanism de distribuție a cheilor . Procedura a durat mai mult de 8 luni și a inclus o introducere pas cu pas la serverele DNS, mai întâi din zona rădăcină, semnată cu o cheie de semnătură electronică nevalidă . Acest pas a fost necesar pentru a oferi testarea serverelor sub încărcare, pentru a menține compatibilitatea cu software-ul mai vechi și pentru a lăsa posibilitatea de a reveni la o configurație anterioară.

Până în iunie 2010, toate serverele rădăcină funcționau corect cu o zonă semnată cu o cheie nevalidă. În iulie, ICANN a susținut o conferință internațională dedicată procedurii de generare a cheilor de semnătură electronică, care a fost ulterior semnată de zona rădăcină.

Pe 15 iulie 2010 a avut loc semnarea zonei rădăcină și a început implementarea zonei semnate pe servere. Pe 28 iulie, ICANN a anunțat [2] finalizarea acestui proces. Zona rădăcină a fost semnată digital și propagată în sistemul DNS.

Pe 31 martie 2011 a fost semnata cea mai mare zona de pe Internet (90 de milioane de domenii) - .com [3] .

Infrastructură cheie

ICANN a ales un model în care semnarea zonei este gestionată sub controlul reprezentanților comunității Internet (Reprezentantul comunității de încredere, TCR). Reprezentanții au fost selectați dintre cei care nu sunt asociați cu gestionarea zonei rădăcină DNS. Reprezentanții aleși au fost ofițeri cripto (CO) și acționari cheie ai Recuperării (RKSH). CO-urilor au primit chei fizice pentru a permite generarea cheii ZSK EDS, iar RKSH-urile dețin carduri inteligente care conțin părți ale cheii (KSK) utilizate în interiorul echipamentului criptografic. S -a ajuns la concluzia unor instituții de presă că procedurile care necesită prezența CO sau RKSH vor fi efectuate în caz de urgențe în rețea [4] . Cu toate acestea, în conformitate cu procedurile ICANN, CO vor fi implicați de fiecare dată când este generată o cheie de semnare a zonei (ZSK), de până la 4 ori pe an, iar RKSH probabil niciodată, sau în cazul pierderii cheilor CO sau a unei zone rădăcină compromisă. [5] .

Starea actuală

În octombrie 2013, există 81 de ccTLD-uri și 13 domenii generice semnate de DNSSEC (fără IDN-uri) în zona rădăcină , oferind astfel un lanț de încredere pentru domeniile de nivel al doilea. În 2011, cu ajutorul DNSSEC (NSEC3 opt-out), a fost semnată zona .su aferentă Rusiei, iar la sfârșitul lunii octombrie 2012 a început publicarea înregistrărilor DS create de utilizatori în aceasta. [6] La sfârșitul anului 2012, domeniul rusesc .ru a fost semnat , iar înregistrările sale DS au fost publicate în zona rădăcină [7] .

Schimbarea KSK a zonei rădăcină

Pe 11 octombrie 2018, a avut loc prima rotație a zonei rădăcină KSK de la semnarea zonei rădăcină în 2010. Rotația cheii, programată inițial pentru octombrie 2017, a fost amânată de ICANN când a devenit clar că un număr semnificativ (aproximativ 2%) de soluții erau folosind aceeași cheie pentru validarea lanțului de semnături DNSSEC. Pe parcursul anului au fost implementate unele soluții tehnice în pachetele Bind, PowerDNS, Knot și alte servere DNS, s-a desfășurat o campanie de amploare de informare a publicului larg despre rotația cheilor și ca urmare, în septembrie 2018, ICANN Consiliul de administrație a decis să implementeze rotația cheie. Nu au existat probleme semnificative cu rotația cheilor.

Probleme și deficiențe de implementare

Implementarea DNSSEC a fost mult întârziată din motive precum:

  1. Dezvoltarea unui standard compatibil cu versiunea inversă care poate fi scalat la dimensiunea Internetului;
  2. Dezacorduri între jucătorii cheie cu privire la cine ar trebui să dețină domenii de nivel superior (.com, .net);
  3. Serverele și clienții DNS trebuie să accepte DNSSEC;
  4. Rezolvatorii DNS actualizați care pot funcționa cu DNSSEC trebuie să utilizeze TCP;
  5. Fiecare client trebuie să obțină cel puțin o cheie publică de încredere înainte de a putea începe să utilizeze DNSSEC;
  6. Sarcina crescuta in retea datorita unui trafic crescut serios (de 6-7 ori) din solicitari;
  7. Încărcare crescută pe procesorul serverului datorită necesității de a genera și verifica semnături, astfel încât unele servere DNS cu putere redusă ar putea fi nevoie să fie înlocuite;
  8. Cerințe de stocare crescute pentru adresarea informațiilor, deoarece datele semnate ocupă mult mai mult spațiu;
  9. Este necesar să se creeze, să testeze și să perfecționeze software-ul atât al părții server, cât și al clientului, ceea ce necesită timp și testare la scara întregului Internet;
  10. Solutoarele stub nu sunt protejate de intoxicația cache - validarea are loc pe partea serverului recursiv, clientul primește doar un răspuns cu bitul AD setat;
  11. Pericolul unui atac de amplificare DNS a crescut brusc.

Cele mai multe dintre aceste probleme sunt rezolvate de comunitatea tehnică de Internet.

Software DNSSEC

Partea serverului

Cele mai comune două implementări de server DNS, BIND și NSD  , acceptă DNSSEC (10 din 13 servere rădăcină folosesc BIND, restul de 3 folosesc NSD). Există, de asemenea, suport pentru PowerDNS , Unbound și alte câteva servere DNS.

Partea client

Datorită faptului că erau foarte puține servere pe care a fost implementată extensia DNSSEC, a fost creat și foarte puțin software pentru utilizatorul final cu suport DNSSEC. Cu toate acestea, sistemele de operare Microsoft au deja integrat DNSSEC. În Windows Server 2008  - RFC 2535 , în Windows 7 și Windows Server 2008 R2 - versiunea actuală a DNSSEC-bis.

Windows XP și Windows Server 2003 acceptă RFC 2535 , dar pot recunoaște numai pachetele de pe serverele cu DNSSEC, aici se termină capacitățile lor.

Mențiune specială este făcută de proiectul DNSSEC-Tools , care este un set de aplicații, suplimente și plug-in-uri care vă permit să adăugați suport DNSSEC la browserul Firefox , clientul de e-mail Thunderbird , proftpd , serverele ncftp FTP și alte aplicații. [8] .

Utilizarea DNSSEC necesită software atât pe partea serverului, cât și pe partea clientului.

Note

  1. ↑ „Using the Domain Name System for System Break-Ins” Arhivat 26 februarie 2008 la Wayback Machine de Steve Bellovin , 1995   (link nu este disponibil)
  2. ↑ Anunț de semnare rădăcină DNSSEC . Consultat la 30 iulie 2010. Arhivat din original la 7 august 2010.
  3. ↑ Implementarea extensiilor de securitate în domeniul de nivel superior .com
  4. ↑ Şase programatori au înmânat „chei pentru a reporni Internetul” . Consultat la 5 octombrie 2010. Arhivat din original pe 23 august 2010.
  5. ↑ DNSSEC pentru zona rădăcină . Consultat la 5 octombrie 2010. Arhivat din original pe 28 octombrie 2011.
  6. ↑ DNSSEC în RU-CENTER (link inaccesibil) . Consultat la 5 noiembrie 2012. Arhivat din original pe 8 noiembrie 2012. 
  7. ↑ Graficul numărului de domenii semnate în .RU și .РФ . Preluat la 24 martie 2013. Arhivat din original la 10 iunie 2015.
  8. ↑ Extensie DNSSEC la DNS pentru securitate îmbunătățită . Data accesului: 31 martie 2013. Arhivat din original pe 24 martie 2013.
  9. ↑ DNSSEC în Windows Server . Consultat la 17 noiembrie 2009. Arhivat din original la 29 iulie 2016.

Link -uri

RFC -uri