- DNSSEC dodaje digitalne potpise i lanac povjerenja DNS-u kako bi se osigurala autentičnost i integritet odgovora.
- Praktična sigurnost zahtijeva potpisane zone, validaciju resolvera i pravilno upravljanje KSK i ZSK ključevima.
- DNSSEC ne šifrira upite niti sprječava DoS; prijedlozi poput E-DNSSEC-a također nastoje osigurati povjerljivost DNS prometa.
Internet je izgrađen na nekoliko ključnih komponenti koje gotovo nikada ne vidimo, ali koje su tu svaki put kada otvorimo preglednik. Jedna od najvažnijih je Sistem imena domena (DNS), a kada govorimo o DNSSEC-u i sigurnosti na lokalnoj mreži , zapravo govorimo o jačanju te osnove kako bismo spriječili lažna preusmjeravanja, lažiranje i druge ozbiljne napade.
Ranije je prioritet bio jednostavno osigurati da sve funkcionira; danas znamo da to nije dovoljno. DNS je nastao 80-ih bez razmatranja masovnih cyber napada, ali sada nam je potreban ne samo za razrješavanje imena već i za validaciju autentičnosti i integriteta svakog odgovora . Tu nastupa DNSSEC, a u novije vrijeme i prijedlozi poput E-DNSSEC-a, koji imaju za cilj dodavanje i povjerljivosti - ključni faktor ako ste zabrinuti za sigurnost svoje lokalne ili korporativne mreže.
Šta je DNS i zašto je toliko važan za sigurnost?
Sistem domenskih imena (DNS ) je telefonski imenik interneta: on prevodi lako pamtljiva imena (kao što je www.example.com) u numeričke IP adrese koje računari razumiju (na primjer, 192.168.2.15 ili IPv6 adresa). Bez ovog mehanizma, morali bismo pamtiti brojeve umjesto imena, što je potpuno nepraktično.
Ova infrastruktura je organizirana kao distribuirana baza podataka u strukturi stabla , s korijenskom zonom na vrhu, nakon čega slijede domene najvišeg nivoa (TLD-ovi kao što su .es, .com, .org), a ispod toga domene i poddomene. Svaki dio ove baze podataka naziva se " zona " i nalazi se na jednom ili više autoritativnih imenskih servera, koji objavljuju "službene" informacije za svaku domenu.
Kada vaš računar, mobilni telefon ili bilo koji drugi uređaj želi pristupiti web stranici, počinje upitom prema stub resolveru , koji je dio operativnog sistema. Ovaj resolver šalje upit rekurzivnom DNS serveru (obično serveru vašeg internet provajdera, vaše kompanije ili javnom serveru poput Google Public DNS-a , OpenDNS-a ili Quad9-a). Ovaj rekurzivni server zatim traži odgovor upitom nekoliko autoritativnih servera dok ne pronađe tačnu IP adresu.
Rekurzivni resolveri keširaju odgovore koje prime kako bi ubrzali naredne upite. Ovo je vrlo efikasno, ali također otvara vrata napadaču da "otruje DNS keš" i ubaci lažne podatke , tako da se mnogi naredni zahtjevi rješavaju s ovim manipuliranim informacijama, a da korisnik to ne primijeti.
Glavni problem je što, u svom originalnom dizajnu, DNS nema robustan način za provjeru autentičnosti odgovora . Resolver u suštini provjerava da li odgovor dolazi s iste IP adrese koju je upitao, ali ta izvorna IP adresa se može relativno lako lažirati. To omogućava napade tihog preusmjeravanja na lažne stranice koje oponašaju, na primjer, web stranicu vaše banke.
Sigurnosna ograničenja tradicionalnog DNS-a
DNS protokol je kreiran u eri kada sigurnost nije bila primarna briga. Zato sada znamo da DNS upiti i odgovori putuju kao običan tekst , bez enkripcije, i da se podaci zapisa mogu falsificirati bez dodatne zaštite.
Ovo otvara vrata za nekoliko vrsta napada, a najznačajniji su trovanje DNS keša i napadi tipa "čovjek u sredini". U oba slučaja, napadač ubacuje krivotvorene odgovore usput, uzrokujući da korisnici završe na web stranicama pod njihovom kontrolom, a da ne primijete ništa neobično, budući da naziv domene prikazan u pregledniku ostaje legitiman.
Zamislite da pristupate web stranici vaše banke: vaš računar traži IP adresu domene banke od rekurzivnog servera, ali napadač je prevario server da prihvati lažni odgovor s IP adresom identične web stranice koju oni kontroliraju . Korisnik unosi svoje podatke za prijavu, misleći da je sve normalno, a sajberkriminalac ih prima u običnom tekstu za kasnije korištenje na pravoj stranici.
Mehanizmi poput potpisa transakcija (TSIG) , definiranih u RFC 2845, služe za zaštitu određenih operacija između DNS servera (na primjer, prijenos zona između glavnog i podređenog servera i dinamička ažuriranja). TSIG omogućava dvjema mašinama koje dijele tajni ključ kako bi provjerile identitet druge strane i integritet poruka u tranzitu.
Međutim, TSIG ima vrlo ograničen opseg: ne autentifikuje "pravo" porijeklo DNS podataka ; samo osigurava da razmjena između dva specifična servera nije mijenjana. Ako su originalne informacije u zoni već bile kompromitovane ili manipulisane prije nego što su stigle do tih servera, TSIG ih neće detektovati. Stoga, iako se često koristi za zonske transfere, ne rješava osnovni problem autentičnosti objavljenih DNS podataka.
Šta je DNSSEC i kako doprinosi sigurnosti?
Kao odgovor na sve ove slabosti, razvijena su proširenja sigurnosti sistema domenskih imena (DNSSEC) . DNSSEC ne zamjenjuje klasični DNS, već ga proširuje slojem sigurnosti koji omogućava provjeru da li su primljeni podaci legitimni i da nisu izmijenjeni.
DNSSEC se zasniva na kriptografiji javnog ključa (asimetrična kriptografija) . Svaka DNS zona ima par ključeva: privatni ključ, koji se čuva u tajnosti, i javni ključ, koji je objavljen na samom DNS serveru. Vlasnik zone koristi privatni ključ za digitalno potpisivanje zapisa u toj zoni; javni ključ se koristi za provjeru tih potpisa.
Kada rekurzivni server upita domenu koristeći DNSSEC, zajedno s uobičajenim informacijama (na primjer, IP adresom povezanom s imenom), on također prima digitalne potpise i javne ključeve potrebne za validaciju . Rekurzivni server provjerava potpise u odnosu na objavljene javne ključeve; ako je provjera uspješna, podaci se smatraju autentičnim i nepromijenjenim od kada su potpisani.
Ako validacija ne uspije, resolver shvata da nešto nije u redu (na primjer, pokušaj lažiranja ili manipulacije tokom prenosa) i odgovara klijentu kodom greške, obično SERVFAIL . Na ovaj način, korisnik ne prima potencijalno zlonamjerne podatke, iako će iz njihove perspektive vidjeti samo da se stranica "ne učitava" ili prikazuje grešku.
DNSSEC također uvodi koncept lanca povjerenja , koji iskorištava postojeću DNS hijerarhiju. Korijenska zona potpisuje ključeve domena najvišeg nivoa (kao što su .es, .com), ovi zauzvrat potpisuju ključeve svojih poddomena i tako dalje, tako da se bilo koja domena može validirati korištenjem jedne tačke povjerenja: javnog ključa korijenske zone.
KSK i ZSK ključevi, zapisi i lanac povjerenja
Radi bolje organizacije sigurnosti, DNSSEC koristi dvije različite vrste ključeva: Ključ za potpisivanje ključa (KSK) i Ključ za potpisivanje zone (ZSK) . Iako su tehnički isti (kriptografski gledano), njihova funkcija je različita unutar sistema.
ZSK ključ se koristi za potpisivanje svih zapisa resursa u zoni (A, AAAA, MX, itd.). Obično se često rotira kako bi se smanjio rizik, jer bi svako kompromitovanje ovog ključa uticalo na sve zapise u zoni. KSK, s druge strane, se prvenstveno koristi za potpisivanje samog ključa zone (ZSK), a njegov heš se objavljuje kao DS (Delegation Signer) zapis u matičnoj zoni.
Zahvaljujući ovoj podjeli uloga, promjena ZSK-a je jednostavnija: samo generirajte novi ZSK, potpišite ga s KSK-om, objavite ga u DNSKEY zapisima zone i pustite resolvere da ažuriraju svoje informacije. Nema potrebe dirati matičnu zonu, jer DS nastavlja pokazivati na isti KSK, koji ostaje stabilan duže vrijeme.
DNSSEC dodaje nekoliko vrsta specifičnih zapisa DNS protokolu, dizajniranih za podršku potpisivanju i validaciji podataka. Među najvažnijima su DNSKEY, RRSIG, DS, NSEC/NSEC3 i NSEC3PARAM . Svi oni vam omogućavaju izgradnju logike autentifikacije bez promjene osnovnog rada upita.
DNSKEY zapis pohranjuje javni ključ zone , koji je neophodan za provjeru potpisa. RRSIG zapis sadrži digitalni potpis povezan sa određenim skupom zapisa ("Skup zapisa resursa"). DS zapis je heš DNSKEY-a podređene zone, koji je objavljen u roditeljskoj zoni i služi kao karika u lancu povjerenja.
NSEC i NSEC3 zapisi se koriste za obezbjeđivanje autentificiranog poricanja postojanja ; to jest, za kriptografsko dokazivanje da naziv domene ili zapis ne postoji, sprječavajući napade koji pokušavaju ubaciti lažne odgovore koji ukazuju da nešto ne postoji kada zapravo postoji (ili obrnuto).
Lanac povjerenja i validacija DNSSEC odgovora
Takozvani lanac povjerenja u DNSSEC-u gradi se povezivanjem DNSKEY i DS zapisa od korijena do domene koju želimo validirati . Početna tačka je javni ključ korijenske zone, koji djeluje kao sidro povjerenja i obično se konfiguriše direktno u rekurzivnim resolverima.
Na primjer, ako želite validirati domenu poput mywebsite.es, logičan proces bi bio: resolver vjeruje javnom ključu korijena, koji potpisuje .es ključ; .es zona objavljuje DS zapis koji odgovara KSK ključu mywebsite.es; validacijom tog DS-a s .es ključem, resolver vjeruje DNSKEY-u mywebsite.es i, odatle, može provjeriti RRSIG-ove na svim svojim zapisima.
Ako važeći potpis nedostaje u bilo kojoj tački lanca ili ako DS (Data Signature - Potpis podataka) nije prisutan tamo gdje bi trebao biti, lanac povjerenja je prekinut. U tom slučaju, rekurzivni server koji vrši validaciju ne smatra podatke sigurnim i, ovisno o svojoj konfiguraciji, ili ne odgovara sa traženim zapisima ili označava odgovor kao nevažeći.
Ovaj hijerarhijski odnos također znači da, da bi DNSSEC bio zaista efikasan, nije dovoljno potpisati samo vašu zonu : matična zona (na primjer, .es) i korijenska zona također moraju biti potpisane i njihovi DNS zapisi moraju biti ispravno objavljeni. Trenutno su DNS korijenska zona i gotovo svi generički domeni najvišeg nivoa (gTLD) i mnogi domeni najvišeg nivoa s nacionalnim kodom (ccTLD) već potpisani.
Kada rekurzivni server sa omogućenom DNSSEC validacijom otkrije da se potpis ne podudara ili da nedostaje link, odgovor koji vraća klijentu obično je popraćen kodom greške RCODE SERVFAIL. Ovo može biti zbunjujuće za krajnjeg korisnika („web stranica ne radi“), ali sa sigurnosnog stanovišta, to je zaštitna mjera protiv potencijalno manipuliranih podataka.
DNSSEC također uvodi dvije ključne funkcije: autentifikaciju porijekla podataka , koja omogućava provjeru da li zapisi zaista dolaze iz očekivane zone, i zaštitu integriteta , koja osigurava da informacije nisu mijenjane otkako ih je vlasnik zone potpisao svojim privatnim ključem.
Napadi koje je DNSSEC ublažio i njihov odnos prema TLS/HTTPS-u
Implementacija DNSSEC-a pomaže u zaštiti od nekoliko uobičajenih prijetnji. Prvo, izuzetno otežava lažiranje DNS odgovora , jer bi napadač morao generirati važeće potpise bez poznavanja privatnog ključa zone, što je kriptografski nemoguće ako se ključevima ispravno upravlja.
Nadalje, DNSSEC smanjuje rizik od trovanja keš memorije na rekurzivnim serverima sprječavanjem prihvatanja manipuliranih odgovora koji ne prođu validaciju potpisa. Također komplicira MITM (man-in-the-middle) napade na DNS promet, u kojima napadač modificira odgovore u tranzitu: ako odgovor ne prođe validaciju, resolver ga odbacuje.
Međutim, važno je razumjeti šta DNSSEC ne radi. Ova proširenja nisu dizajnirana za šifriranje sadržaja upita ili odgovora . Sav DNS promet, čak i s DNSSEC-om, i dalje putuje u običnom tekstu, osim ako ne koristite druge komplementarne tehnologije (kao što su DoT, DoH ili rješenja tipa E-DNSSEC). DNSSEC se fokusira na osiguravanje da je ono što primate autentično i da nije izmijenjeno, a ne na skrivanje onoga što tražite.
Ovo ga jasno razlikuje od protokola poput TLS-a i HTTPS-a . Dok HTTPS šifrira promet između preglednika i web servera kako bi spriječio treće strane da špijuniraju ili mijenjaju komunikaciju, DNSSEC jednostavno potpisuje DNS podatke kako bi otkrio lažiranje podataka. Stranica može imati HTTPS bez DNSSEC-a ili DNSSEC bez HTTPS-a, ali kombinacija oba nudi mnogo sveobuhvatniju zaštitu od lažiranja podataka i špijuniranja.
Organizacije poput ICANN-a i IETF-a godinama promoviraju široko rasprostranjeno usvajanje DNSSEC-a od strane registara, registratora, internet provajdera i mrežnih operatera. Cilj je da se potpiše sve više zona i da ih više resolvera aktivno validira, tako da prosječan korisnik može imati koristi od ovih kriptografskih garancija bez poduzimanja ikakvih posebnih radnji.
DNSSEC u .es domenama i obaveze vlasnika
U konkretnom slučaju Španije, jedinica za domene ".es" kojom upravlja Red.es već dugo uključuje dodatne tehnologije i procedure za poboljšanje kvalitete i sigurnosti DNS usluge pod državnim kodom .es. Među tim mjerama je i implementacija DNSSEC sigurnosnog protokola u skladu sa IETF specifikacijama.
.es domene su odgovorne za potpisivanje .ES zone najvišeg nivoa i dobijanje autorizacije od DNS korijena, čime se integrišu u globalni lanac povjerenja. To znači da ako posjedujete .es domenu, možete iskoristiti ovu infrastrukturu da biste osigurali svoju domenu pomoću DNSSEC-a.
Kao vlasnik domene, opći postupak za omogućavanje DNSSEC-a uključuje osiguravanje da vaši autoritativni DNS serveri objavljuju potpisanu zonu. Obično to podrazumijeva generiranje javnog ključa za vašu zonu, potpisivanje zapisa, objavljivanje DNS ključa, a zatim slanje materijala ključa (ili samog DS zapisa) registru ili vašem registraru kako bi mogli kreirati odgovarajući DS zapis u matičnoj zoni.
U praksi, mnogi provajderi DNS hostinga i registratori već nude prilično jednostavnu opciju za omogućavanje DNSSEC-a, ponekad jednako lako kao označavanje polja u kontrolnoj tabli. Međutim, s ovom funkcionalnošću mogu biti povezani mali godišnji troškovi, ovisno o provajderu i nivou usluge.
Nakon što je zona potpisana i Sistem domenskih imena (DNS) uspješno objavljen, vaša domena postaje dio DNSSEC lanca povjerenja. Od tog trenutka, DNS rezolucije za vašu domenu mogu biti kriptografski validirane od strane resolvera koji imaju omogućenu DNSSEC validaciju, povećavajući povjerenje korisnika i smanjujući rizik od napada lažiranja.
DNSSEC na lokalnoj mreži: validacija od strane korisnika
Iz perspektive krajnjeg korisnika ili kompanije koja je zabrinuta za sigurnost svoje lokalne mreže, ključno pitanje je: šta je potrebno da biste imali koristi od DNSSEC-a? Dobra vijest je da ne morate ništa konfigurisati na svakom računaru pojedinačno , sve dok vaš rekurzivni DNS server (onaj koji vaši računari koriste) validira DNSSEC.
Da biste to uradili, sve što vam je potrebno je da vaš DNS provajder (vaš internet provajder, javni resolver ili interni DNS vaše organizacije) ima rekurzivni server sa omogućenom i pravilno konfigurisanom DNSSEC validacijom . Gotovo svi moderni resolveri podržavaju DNSSEC godinama; omogućavanje obično uključuje samo nekoliko promjena u njihovoj konfiguracijskoj datoteci i dodavanje root trust sidra.
Nakon što je validacija omogućena, kada jedan od vaših računara na lokalnoj mreži upita potpisanu domenu, rekurzivni resolver provjerava sve potpise i lanac povjerenja prije vraćanja odgovora. Ako se nešto ne podudara, ne vraća nikakve zapise i korisnik vidi grešku, što ga efektivno sprječava da se poveže na potencijalno lažnu stranicu.
Da biste provjerili da li je vaša domena zaštićena DNSSEC-om, dostupno je nekoliko online alata, kao što su DNSSEC Analyzer i drugi uslužni programi za validaciju . Kada unesete svoju domenu, trebali biste vidjeti zapise kao što su RRSIG (kriptografski potpisi), DNSKEY (javni ključevi) i DS (hash DNSKEY-a u roditeljskoj zoni). Ako alat pokaže da ne postoji digitalni potpis povezan sa zapisima, vaša domena će se smatrati "nepotpisanom" ili "nesigurnom".
Ako nakon ove provjere utvrdite da vaša domena ili DNS serveri koje koristite na lokalnoj mreži ne koriste prednosti DNSSEC-a, preporučljivo je da kontaktirate svog pružatelja usluga ili internet provajdera kako biste zatražili njegovu aktivaciju. Ako ne nude ovu opciju, možda je dobro vrijeme da razmislite o prelasku na pružatelja usluga koji podržava DNSSEC validaciju, čime se povećava nivo sigurnosti i za vašu kompaniju i za vaše klijente.
Ograničenja DNSSEC-a: privatnost i drugi aspekti
Uprkos svim svojim prednostima, DNSSEC nije čarobni štapić za sve probleme sigurnosti DNS-a. Ključni problem je što ne pruža povjerljivost upita . DNS paketi, čak i sa DNSSEC-om, i dalje putuju kao običan tekst, tako da svako ko ima pristup saobraćaju (na primjer, na neosiguranoj javnoj Wi-Fi mreži ) može vidjeti koje se domene pretražuju.
Također ne nudi kontrolu pristupa niti specifičnu odbranu od napada uskraćivanja usluge (DoS ili DDoS) . U stvari, dodavanjem više podataka (potpisa, ključeva, dodatnih zapisa), povećava se veličina DNS odgovora, što se može iskoristiti u napadima pojačavanja ako infrastruktura nije pravilno konfigurirana i zaštićena.
S druge strane, DNSSEC uvodi određenu operativnu složenost: parovi ključeva moraju se upravljati, ZSK i KSK se moraju rotirati, objavljivanje DS-a u matičnoj zoni mora biti koordinirano i mora se osigurati da nema neusklađenosti koje prekidaju lanac povjerenja. Greška u ovim procedurama može uzrokovati da domena prestane ispravno validirati, što generira prividne prekide usluge.
Unutar samog DNSSEC procesa, postoje kontrolni bitovi u porukama (kao što je CD bit u upitima i AD bit u odgovorima) koji utiču na način na koji se validacija vrši i izvještava. Napadač koji bi mogao manipulisati ovim bitovima u nesigurnom okruženju mogao bi pokušati da degradira zaštitu koju nudi rekurzivni resolver. Stoga se preporučuje da se komunikacija između resolvera i klijenata koji koriste DNSSEC odvija preko sigurnih kanala.
Uprkos ovim ograničenjima, DNSSEC ostaje ključna komponenta za jačanje autentičnosti i integriteta DNS-a. Međutim, da bi se otišlo korak dalje i garantovala povjerljivost upita, potrebno ga je kombinovati s drugim tehnologijama ili se razvijati prema naprednijim rješenjima.
E-DNSSEC: Prema autentificiranom i šifriranom DNS-u
Kako bi se riješio jaz u privatnosti koji je ostavio DNSSEC, predložen je koncept E-DNSSEC-a (DNSSEC enkriptirano) . Ideja iza ovog pristupa je dodavanje enkripcije DNSSEC upitima tako da, pored autentifikacije i potpisivanja, budu i zaštićeni od inspekcije treće strane tokom putovanja preko interneta ili kroz lokalnu mrežu.
Cilj E-DNSSEC-a je kombinovanje svojstava DNSSEC-a (autentičnost i integritet) sa mehanizmima šifrovanja koji pružaju povjerljivost za upite između DNSSEC klijenta i DNSSEC servera . Ovo povećava ukupnu sigurnost DNS servisa, sprečavajući spoljne posmatrače da vide koja se imena domena razrešavaju.
Konceptualni proces bi uključivao analizu upita na rekurzivnom serveru, šifriranje prije slanja autoritativnom serveru, a zatim dešifriranje i obradu normalno korištenjem DNSSEC-a . Odgovor bi se, zauzvrat, mogao vratiti potpisan i šifriran nazad rekurzivnom serveru ili klijentu, održavajući povjerljivost tokom cijelog procesa.
Ova kombinacija bi osigurala da je DNS poruka sigurna od početka do kraja procesa razrješenja: autentificirana i s integritetom zahvaljujući DNSSEC-u, te zaštićena od znatiželjnih očiju zahvaljujući dodatnoj enkripciji. U kontekstu lokalne ili poslovne mreže, takav pristup bi se mogao integrirati s drugim rješenjima za perimetarsku sigurnost.
Danas su prijedlozi poput E-DNSSEC-a dio šireg napora za jačanje privatnosti DNS-a , uz tehnologije kao što su DNS preko TLS-a (DoT) i DNS preko HTTPS-a (DoH). Osnovni smjer je jasan: DNS budućnosti mora biti i autentičan i povjerljiv, i nije dovoljno samo brzo razrješavati imena; to se mora raditi i sigurno.
U okruženju u kojem postoje sve sofisticiraniji sajber napadi, lažna predstavljanja i prijetnje usmjerene na osnovnu infrastrukturu, posjedovanje DNSSEC-a je već važan sigurnosni zahtjev za svaku ozbiljnu domenu, a prelazak na šifrirana rješenja poput E-DNSSEC-a ili sličnih nameće se kao logičan sljedeći korak ka daljnjem jačanju zaštite mreža, uključujući i lokalne mreže.
Cijeli ovaj ekosistem - od klasičnog DNS-a do DNSSEC-a i šifriranih rješenja poput E-DNSSEC-a - pokazuje da DNS sigurnost nije opcionalni dodatak, već ključna komponenta internet arhitekture i svake moderne lokalne mreže. Posjedovanje resolvera koji validiraju, potpisanih zona, dobro održavanih lanaca povjerenja i, u budućnosti, šifriranih kanala za upite, čini svu razliku između izložene mreže i infrastrukture pripremljene za trenutne i buduće izazove.
Indeks
- 1 Šta je DNS i zašto je toliko važan za sigurnost?
- 2 Sigurnosna ograničenja tradicionalnog DNS-a
- 3 Šta je DNSSEC i kako doprinosi sigurnosti?
- 4 KSK i ZSK ključevi, zapisi i lanac povjerenja
- 5 Lanac povjerenja i validacija DNSSEC odgovora
- 6 Napadi koje je DNSSEC ublažio i njihov odnos prema TLS/HTTPS-u
- 7 DNSSEC u .es domenama i obaveze vlasnika
- 8 DNSSEC na lokalnoj mreži: validacija od strane korisnika
- 9 Ograničenja DNSSEC-a: privatnost i drugi aspekti
- 10 E-DNSSEC: Prema autentificiranom i šifriranom DNS-u
