A DNSSEC ( Eng. Domain Name System Security Extensions ) a DNS - protokoll IETF -kiterjesztéseinek halmaza, amely lehetővé teszi az IP-címhamisításhoz kapcsolódó támadások minimalizálását a tartománynevek feloldásakor . Célja, hogy a DNS-kliensek (angol terminusfeloldó) hiteles válaszokat adjon a DNS-lekérdezésekre (vagy hiteles információt a hiányzó adatok tényéről), és biztosítsa azok integritását. Nyilvános kulcsú titkosítást használ. Az adatok elérhetősége és a kérések bizalmas kezelése nem biztosított. A DNS biztonságának biztosítása kritikus fontosságú az általános internetbiztonság szempontjából.
A Domain Name System (DNS) kezdetben nem biztonsági célokat szolgált, hanem méretezhető elosztott rendszerek létrehozására. Idővel a DNS-rendszer egyre sebezhetőbbé válik. A támadók egyszerűen átirányítják a felhasználói kéréseket szimbolikus névvel álszerverekre, és így hozzáférnek jelszavakhoz, hitelkártyaszámokhoz és egyéb bizalmas információkhoz. A felhasználók maguk nem tehetnek ez ellen, hiszen a legtöbb esetben nem is sejtik, hogy a kérést átirányították - a böngészősor bejegyzése és maga az oldal pontosan megegyezik azzal, amit a felhasználó elvár. A DNSSEC egy kísérlet a biztonságra, miközben visszafelé kompatibilis.
A DNSSEC célja az volt, hogy megvédje az ügyfeleket a hamis DNS-adatoktól, például a DNS-gyorsítótár-mérgezés által generáltoktól . A DNSSEC-től érkező összes válasz digitálisan aláírt. A digitális aláírás ellenőrzésekor a DNS-ügyfél ellenőrzi az információ helyességét és integritását.
A DNSSEC nem titkosítja és nem módosítja az adatkezelést, és kompatibilis a jelenlegi DNS-rendszer és alkalmazások korábbi verzióival. A DNSSEC olyan információkat is képes hitelesíteni, mint például a DNS CERT rekordban tárolt általános célú kriptográfiai tanúsítványok . Az RFC 4398 leírja, hogyan terjesztheti ezeket a tanúsítványokat, beleértve az e-mailt is, amely lehetővé teszi a DNSSEC használatát az aláírási kulcs tanúsítványok globálisan elosztott tárolójaként.
A DNSSEC nem biztosít adatvédelmet; különösen az összes DNSSEC-válasz hitelesített, de nem titkosított. A DNSSEC nem véd közvetlenül a DoS támadások ellen , bár valamilyen módon közvetetten megteszi. Más szabványokat (nem DNSSEC) használnak a DNS-kiszolgálók közötti nagy mennyiségű adat biztosítására.
A DNSSEC specifikáció ( DNSSEC-bis ) részletezi az aktuális DNSSEC protokollt. Lásd: RFC 4033 , RFC 4034 és RFC 4035 .
A domain névrendszer kezdetben nem rendelkezett olyan mechanizmusokkal, amelyek megvédték volna a szerver válaszában szereplő információk helyettesítését, mivel a fejlesztés idején (az 1980-as évek elején) a modern internet biztonsági fenyegetései nem voltak relevánsak. Az ügyfelek ugyanakkor kizárólag a kétbájtos kérésazonosító alapján ítélték meg a kapott információk helyességét. Így a támadónak több mint 65536 értéket kellett ismételnie, hogy "megmérgezhesse a gyorsítótárat". Ez azt jelentette, hogy a DNS-rendszerben lévő adatok megsérülnek (szándékosan vagy tévedésből), és a DNS-szerver gyorsítótárba helyezi azokat a teljesítmény optimalizálása érdekében (a gyorsítótár "megmérgeződik"), és elkezdi kiszolgálni ezeket a nem hiteles adatokat az ügyfeleknek. Steve Bellovin még 1990-ben súlyos biztonsági hibákat azonosított . A kutatás ezen a területen megkezdődött, és a jelentés 1995-ös megjelenése óta teljes lendülettel folyik [1] .
A DNSSEC RFC 2065 első kiadását az IETF adta ki 1997-ben. A specifikáció megvalósítására tett kísérletek az új RFC 2535 specifikációhoz vezettek 1999-ben. A tervek szerint az IETF RFC 2535 alapú DNSSEC-t implementálták volna .
Sajnos az IETF RFC 2535 specifikációnak komoly problémái voltak a teljes internetre való skálázással. 2001-re világossá vált, hogy ez a specifikáció nem alkalmas nagy hálózatokra. A normál működés során a DNS-kiszolgálók gyakran nem szinkronizálódnak a szüleikkel (a hierarchia felső tartományaival). Ez általában nem jelentett problémát, de ha a DNSSEC engedélyezve van, a deszinkronizált adatoknak nem szándékos DoS hatása lehet. A biztonságos DNS sokkal számításigényesebb, és könnyebben, mint a „klasszikus” DNS, lefoglalja az összes számítási erőforrást.
A DNSSEC első verziója hat üzenetből álló kommunikációt és nagy mennyiségű adatot igényelt a módosítások végrehajtásához a gyermeken (a gyermek összes DNS-zónáját teljesen át kell adni a szülőnek, a szülő hajtja végre a változtatásokat és visszaküldi őket a gyermeknek ). Ezenkívül a nyilvános kulcs megváltoztatása katasztrofális hatással járhat. Például, ha a „.com” zóna megváltoztatja a kulcsát, akkor 22 millió rekordot kell elküldeni (mivel az összes utódban minden rekordot frissíteni kellett). Így az RFC 2535 formájú DNSSEC-et nem lehetett az internet méretéhez igazítani.
Ezek a bonyolultságok pedig új specifikációk ( RFC 4033 , RFC 4034 , RFC 4035 ) megjelenéséhez vezettek a DNSSEC alapvető változtatásaival (DNSSEC-bis), amelyek új verziója megszüntette a korábbi megvalósítás fő problémáját, és bár az új specifikációban az ügyfeleknek további műveleteket kell végrehajtaniuk a kulcsok ellenőrzéséhez, ez meglehetősen alkalmasnak bizonyult a gyakorlati használatra.
2005-ben jelent meg a DNSSEC aktuális kiadása, amellyel mindenki dolgozik. 2008-ban mérföldkőnek számító esemény történt, amikor Dan Kaminsky megmutatta a világnak, hogy 10 másodperc alatt megmérgezheti a gyorsítótárat. A DNS-szoftver-szállítók úgy válaszoltak, hogy a lekérdezés azonosítója mellett véletlenszerűen kiválasztották a kimenő portot a lekérdezéshez. Útközben viták kezdődtek a DNSSEC megvalósításával kapcsolatban.
A DNSSEC-változtatás, az úgynevezett DNSSEC-bis (a név a DNSSEC-bis megkülönböztetésére kapott az RFC 2535 eredeti DNSSEC-megközelítésétől ) a DS ( Delegation Signer ) elvet használja, hogy egy további közvetett delegálási réteget biztosítson a zónák szülőről gyermekre való átvitelekor. . Az új megközelítésben a nyilvános kulcs megváltoztatásakor hat helyett csak egy-két üzenetet küldenek a szülődomain adminisztrátorának: az örökös az új nyilvános kulcs kivonatát (ujjlenyomat, hash) küldi el a szülőnek. A szülő egyszerűen eltárolja a nyilvános kulcs azonosítóját minden egyes gyermek számára. Ez azt jelenti, hogy nagyon kis mennyiségű adatot küldenek a szülőnek, ahelyett, hogy hatalmas mennyiségű adatot cserélnének a gyermek és a szülő között.
A DNS-adatok aláírása és érvényesítése további többletterhelést jelent, ami negatívan befolyásolja a hálózat és a szerver teljesítményét. Például a DNSSEC zóna (egy adott tartományban meghatározott szintű tartománynevek halmaza) átlagosan 7-10-szer nagyobb, mint maga a DNS-rendszer. Az aláírások generálása és ellenőrzése jelentős CPU-időt igényel. Az aláírások és kulcsok egy nagyságrenddel több helyet foglalnak el a lemezen és a RAM-ban, mint maguk az adatok.
A DNSSEC működési elve a digitális aláírások használatán alapul . Az adminisztrátor rendelkezik egy rekorddal a domain név és az IP-cím egyezéséről. A DNSSEC mindegyiket szigorúan követi egy speciális, szigorúan meghatározott karaktersorozattal, ami egy digitális aláírás. A digitális aláírás fő jellemzője, hogy léteznek nyílt, nyilvánosan elérhető módszerek az aláírások hitelességének ellenőrzésére, de tetszőleges adatokhoz aláírás létrehozásához az aláírási titkos kulcs rendelkezésre állása szükséges. Ezért a rendszer minden résztvevője ellenőrizheti az aláírást, de a gyakorlatban csak az írhat alá új vagy megváltozott adatokat, aki rendelkezik a titkos kulccsal.
Elméletileg semmi sem tiltja, hogy a hacker kiszámítsa a titkos kulcsot és felvegye az aláírást, de a gyakorlatban egy kellően összetett és hosszú kulcs esetén a meglévő számítástechnikai eszközökkel és matematikai algoritmusokkal nem hajtható végre egy ilyen művelet ésszerű időn belül.
Titkos kulccsal a digitális aláírás kiszámítása nem nehéz. Ilyenek az aszimmetrikus nyilvános kulcsú titkosítási rendszerek, amelyek a digitális aláírási algoritmusok hátterében állnak.
Tegyük fel, hogy egy felhasználó felkeresi a wikipedia.org webhelyet. A következő történik:
Ha valamit nem lehet érvényesíteni, a feloldó szervfail hibát ad vissza.
Az így kialakult bizalmi lánc a gyökértartományra és a gyökérzóna kulcsra redukálódik.
A Delegation of Signing ( DS ) rekord tartalmazza az örökös domain nevének és KSK-jának kivonatát. A DNSKEY rekord tartalmazza a kulcs nyilvános részét és azonosítóit (azonosító, típus és hash függvény).
A KSK (Key Signing Key) kulcsaláíró kulcsot (hosszú távú kulcsot), a ZSK (zóna aláíró kulcsot) pedig zóna aláíró kulcsot (hosszú távú kulcsot) jelent. A KSK segítségével ellenőrzik a ZSK-t, amely a gyökérzóna aláírására szolgál. A Root Zone ZSK-t a PTI (az ICANN IANA funkcionális részlege ) hozza létre, amely technikailag felelős a DNS gyökérzóna terjesztéséért. Az ICANN eljárása szerint a Root Zone ZSK-t évente négyszer frissítik.
A DNSSEC segítségével továbbított összes adat teljes körű érvényesítéséhez egy bizalmi láncra van szükség a DNS gyökérzónájából (.). A megfelelően aláírt gyökérzóna megvalósítása az összes gyökér DNS-kiszolgálón a modern Internet összeomlását okozhatja, ezért az IETF az ICANN -nel együttműködve lépésről lépésre dolgozott ki egy aláírt gyökérzóna és egy kulcselosztási mechanizmus megvalósítására szolgáló eljárást . Az eljárás több mint 8 hónapig elhúzódott, és lépésről lépésre bemutatta a gyökérzóna első DNS-kiszolgálóját, érvénytelen elektronikus aláírási kulccsal aláírva . Erre a lépésre azért volt szükség, hogy biztosítsák a terhelés alatti kiszolgálók tesztelését, a régebbi szoftverekkel való visszamenőleges kompatibilitás fenntartását és a korábbi konfigurációra való visszaállítás lehetőségét.
2010 júniusáig minden gyökérszerver megfelelően működött egy érvénytelen kulccsal aláírt zónával. Júliusban az ICANN nemzetközi konferenciát tartott az elektronikus aláírási kulcsok generálására vonatkozó eljárásról, amelyet ezt követően a gyökérzóna aláírt.
2010. július 15- én megtörtént a gyökérzóna aláírása és megkezdődött az aláírt zóna megvalósítása a szervereken. Július 28-án az ICANN bejelentette [2] ennek a folyamatnak a befejezését. A gyökérzónát digitálisan aláírták és a DNS rendszerben terjesztették.
2011. március 31- én aláírták az internet legnagyobb zónáját (90 millió domain) - .com [3] .
Az ICANN olyan modellt választott, ahol a zóna aláírását az internetes közösség képviselői (Trusted Community képviselő, TCR) irányítják. A képviselőket azok közül választották ki, akik nem kapcsolódnak a DNS gyökérzóna kezeléséhez. A megválasztott képviselők Crypto Officers (CO) és Recovery Key részvényesek (RKSH) voltak. A CO-k fizikai kulcsokat kaptak a ZSK EDS kulcs generálásához, és az RKSH-k birtokában vannak a kriptográfiai berendezésben használt kulcs (KSK) részeit tartalmazó intelligens kártyák . Egyes sajtóorgánumok arra a következtetésre jutottak, hogy hálózati vészhelyzet esetén a CO vagy az RKSH jelenlétét igénylő eljárásokat hajtanak végre [4] . Az ICANN eljárásainak megfelelően azonban a CO-kat minden egyes zóna-aláíró kulcs (ZSK) generálásakor bevonják, évente legfeljebb 4 alkalommal, az RKSH-t pedig valószínűleg soha, vagy a CO-kulcsok elvesztése vagy egy kompromittált gyökérzóna esetén. [5] .
2013 októberéig 81 ccTLD és 13 általános DNSSEC-aláírt tartomány (IDN nélkül) található a gyökérzónában , így bizalmi láncot biztosít a második szintű tartományok számára. 2011-ben a DNSSEC (NSEC3 opt-out) segítségével aláírták az Oroszországhoz kapcsolódó .su zónát , 2012. október végén pedig megkezdődött benne a felhasználók által készített DS rekordok publikálása. [6] 2012 végén aláírták az orosz .ru domaint , melynek DS-rekordjait a gyökérzónában tették közzé [7] .
2018. október 11-én megtörtént az első gyökérzóna KSK-rotáció a 2010-es gyökérzóna aláírás óta. Az eredetileg 2017 októberére tervezett kulcsrotációt az ICANN elhalasztotta, amikor kiderült, hogy a feloldók jelentős része (körülbelül 2%-a) ugyanazt a kulcsot használja a DNSSEC aláírási lánc érvényesítéséhez. Az év során a Bind, PowerDNS, Knot és más DNS szervercsomagokban megvalósult néhány technikai megoldás, nagyszabású kampányt folytattak a nagyközönség tájékoztatására a kulcsrotációról, ennek eredményeként 2018 szeptemberében az ICANN Az igazgatóság a kulcsrotáció bevezetéséről döntött. A kulcsok elforgatásával nem volt jelentős probléma.
A DNSSEC megvalósítása nagymértékben késik az alábbi okok miatt:
A legtöbb ilyen problémát a technikai internetes közösség oldja meg.
A két leggyakoribb DNS-kiszolgáló megvalósítása, a BIND és az NSD , támogatja a DNSSEC-et (13 gyökérszerverből 10 BIND-ot használ, a maradék 3 pedig NSD-t). A PowerDNS , Unbound és néhány más DNS-kiszolgáló is támogatott.
Tekintettel arra, hogy nagyon kevés szerveren telepítették a DNSSEC kiterjesztést, nagyon kevés DNSSEC-támogatással rendelkező végfelhasználói szoftver is készült. A Microsoft operációs rendszerei azonban már integrálták a DNSSEC-et. Windows Server 2008 - RFC 2535 , Windows 7 és Windows Server 2008 R2 rendszerben - a DNSSEC-bis jelenlegi verziója.
A Windows XP és a Windows Server 2003 támogatja az RFC 2535 -öt , de csak a DNSSEC-cel rendelkező kiszolgálókról tudják sikeresen felismerni a csomagokat, itt véget is érnek a képességeik.
Külön említést érdemel a DNSSEC-Tools projekt , amely olyan alkalmazások, kiegészítők és beépülő modulok készlete, amely lehetővé teszi DNSSEC támogatás hozzáadását a Firefox böngészőhöz, a Thunderbird levelezőklienshez , a proftpd -hez , az ncftp FTP - kiszolgálókhoz és néhány más alkalmazáshoz . [8] .
A DNSSEC használatához szoftverre van szükség mind a szerver, mind a kliens oldalon.
| Alapvető TCP / IP protokollok az OSI modell rétegei szerint | |
|---|---|
| Fizikai | |
| csatornázott | |
| hálózat | |
| Szállítás | |
| ülés | |
| Reprezentáció | |
| Alkalmazott | |
| Egyéb alkalmazva | |
| A TCP és UDP portok listája | |
| Internet biztonsági mechanizmusok | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Titkosítás és forgalomszűrés _ |
| ||||||||||||||
| Hitelesítés | |||||||||||||||
| Számítógép védelem |
| ||||||||||||||
| IP telefonbiztonság |
| ||||||||||||||
| Forgalom anonimizálása | |||||||||||||||
| Vezetéknélküli Biztonság | |||||||||||||||