DNS hamisítás szerepe, működése, védekezés Benda Szabolcs G-5S5A Peller Nándor G-5i10 Sőregi Gábor G-5S5A
Bevezetés
Az interneten levő hálózati eszközök, számítógépek mindegyikének egyedi azonosítója, (4 byte-on tárolt) IP címe van. A felhasználók azonban olyan neveket szeretnek használni, amelyek könnyebben megjegyezhetők, mint egy ilyen hosszú szám, és a névből következtetni tudnak a gép, a szolgáltatás helyére, a szolgáltatás típusára is. Ezért kezdettől fogva neveket rendeltek az IP címekhez. Amikor az internet még csak pár ezer számítógépből állt, ezt a név-cím hozzárendelést egy folyamatosan növekvő fájl, host táblázat tartalmazta.
A TCP/IP Internet Domain nevek A gépek száma az Interneten gyorsan növekszik, centralizált rendszer nem képzelhető el, mert központi adatbázis naprakészen tartása lehetetlen lenne, túl nagy lenne hálózati terhelés, nagy teljesítményű szerverekre lenne szükség
DNS I.
Ezért egy decentralizált rendszert kellett kialakítani, amelyben a nevek és a címek kezelése kisebb szervezetekben történik. Hierarchikus név-elrendezést alakítottak ki, amelyeket domain neveknek nevezünk. A névteret a legfelsőbb szinttől (top level) partícionálták, és a nevek kezelését az egyes partíciókban kijelölt hatóságokra bízták. A legfelsőbb szintű nevek két eltérő elnevezés hierarchiát engednek meg: földrajzi és szervezeti.
DNS II.
A földrajzi partícionálás a gépeket az ország alapján osztja szét, ahol az országot a 2 betűs országkód azonosítja: hu, us, de, uk, stb. A szervezeti partícionálás az intézményeket a tevékenysége alapján sorolja az alábbi partíciók valamelyikébe.(pl. COM Profitorientált intézmények, MIL Katonai szervezetek stb.)
DNS III.
A legfelsőbb szintű partíciókat tovább partícionálták a hozzájuk tartozó intézmények alapján. Egy-egy intézmény tehát a com, edu, gov, …, vagy hu, us, de, uk, … domain-ek valamelyikébe tartozik. Az intézmények domain neve pedig például: banki.hu, novell.com, stb. Ha szükséges az intézmények domain-je még tovább partícionálható.
DNS zóna
A fa szerkezet egyes részeit, ágait, nevezzük zónának. Tehát a zóna : a fa egyben kezelt része. A zónákat minden esetben minimum két szervernek kell hirdetni, láttatni:
Az elsődleges szerver az úgy nevezett adminisztrátori munkákat végző szerver, ezen történik minden módosítás. A másodlagos szerver az elsődleges szerver tükrözését végzi. A tükrözés mikéntjét az elsődleges szerveren határozzuk meg.
Az egyes al zónák külön szervereknek kiutalhatóak. pl: .hu TLD egyik ilyen al zónája az axelero, vagy az ihd mely ki van osztva .hu zóna kezelőitől másoknak.
Domain név feloldás
A nevek feloldását egy elosztott számítógépes rendszer biztosítja, amely független, együttműködő névszerverekből (name server) áll.
A névszerver elvégzi a név-cím megfeleltetést. A kliens szoftver, amelyet név feloldónak (name resolver) nevezünk egy, vagy több névszerverhez fordul, amikor egy név lefordítására van szüksége.
A névszerverek elrendezése a domain hierarchiának felel meg.
Minden domain rendelkezik egy (vagy több) név szerverrel, amelyet domain felügyeleti hatósága üzemeltet. A gyökér (root) szerver a legfelsőbb szintű domain-eket ismeri, és tudja, hogy melyik domain-t melyik név szerver oldja fel. A következő szinten lévő név szerverek a saját al-domain-jeiket oldják fel, és tudják, hogy melyik al-domain-t melyik név szerver oldja fel, és így tovább.
Domain név feloldás Gyökér (névtelen)
.
Name server Számítógép
Root_NS edu
com
hu
Hu_NS
Com_NS banki
novell
WWW
Novell_NS
PC
WWW PC
Domain név feloldás
elte
bme
Banki_NS
= www.novell.com = pc.banki.hu
Domain név feloldás pc.banki.hu keresi a "www.novell.com" IP címét. pc ismeri a banki.hu domain name szerverének IP címét (Banki_NS) Pc megkérdezi a Banki_NS-t (az IP címe alapján), hogy mi a "www.novell.com" gép IP címe. A Banki_NS először megnézi, hogy a keresett név az általa felügyelt domain-ben van-e. Ha igen elvégzi a feloldást. Ha nem (példánkban ez a helyzet) megkérdezi a Root_NS-t, hogy mi a "com" domain name szerverének IP címe. A Banki_NS megkérdezi a Com_NS-t, hogy mi a "novell.com" domain name szerverének IP címe. A Banki_NS megkérdezi a Novell_NS-t, hogy mi a "www.novell.com" gép IP címe. A Banki_NS megválaszolja a pc.banki.hu gépnek a "www.novell.com" gép IP címét.
BIND - Berkeley Internet Name Domain
A kaliforniai Berkeley egyetem által kifejlesztett és terjesztett DNS kiszolgáló, amely a világon leggyakrabban használt címfeloldó program. A program elsősorban linux OS-re készült, de van pl. NT-s változata is. Fejlesztését az Internet Software Consortium támogatja, és a BIND 'apukája', Paul Vixie koordinálja. A BIND program forráskódban is szabadon letölthető az ftp.isc.org szerverről.
A DNS üzenetek formátuma
A DNS szerverek az RFC1035 szabványban meghatározott formában kommunikálnak egymással. Az üzenetek formátuma: +-----------------------------------+ | Fejrész | +-----------------------------------+ | Kérdés | +-----------------------------------+ | Válasz rekordok szekciója | +-----------------------------------+ | Autoritás rekordok szekciója | +-----------------------------------+ |Más (additional) rekordok szekciója| +-----------------------------------+
DNS hamisítás
A támadó több ponton is támadhatja a domain név szerver rendszert.
A magasabb szintű szerverek általában igen jól védettek, mivel kizárólag a domain-név szolgáltatást adják, felhasználóik gyakorlatilag nincsenek. Nagyobb a sikeres támadás esélye a lokális szerverek ellen. A helyi hálózatokban rendszerint többfunkciós szerverek adják a domain név szolgáltatást is. Ha a támadó a hatalmába tud keríteni egy ilyen lokális szervert, akkor a hálózat gépeinek kérdéseire tetszés szerinti IP címeket adhat válaszul. A támadó a hamisított IP címen berendezhet egy olyan szervert, amely a kapcsolatfelvétel során úgy viselkedik a felhasználó felé, mint az eredeti szerver. Ebben a helyzetben már többféle visszaélés lehetséges. A támadó például hamisíthat egy weblapot, és így megtudhatja a felhasználó azonosítóját, jelszavát.
Veszélyek I.
Hamis lehet a szerverre vagy a kliensre vonatkozó adat A hamis DNS adatok becsempészésére több hely is kínálkozik:
a kliens által használt, 'látó' DNS szerver IP címét hamisítani lehet a kliens által használt, 'látó' DNS szerver cache-ébe hamis adatokat lehet bele csempészni Például: a 'mienk.vala.hol' névszerverét, vagy IP címét illetéktelenek vehetik birtokba a 'mienk.vala.hol' névszerverétől jövő csomagokat módosíthatják, kicserélhetik
Támadási technikák DNS cache mérgezés Példa: A kliens.vala.hol névszerverétől olyan kérés érkezik, amihez gonosz.vala.hol névszerverét kell megkérdeznie a válaszért, akkor ebben a válaszban lehet ragadvány adatként a 'szerver.vala.hol'-ra vonatkozó hamis adat. Ezután a kliens.vala.hol névszerver cache-eli, és így a következő kérésnél hamis adatot ad a pc.kliens.vala.hol-nak. Erre a támadásra a 4.9.6 változat óta érzéketlen a Bind program.
Támadási technikák DNS válasz ID jóslás
Minden egyes DNS kéréshez egy 16 bites ID mező tartozik. Ha az ID megjósolható, akkor egy támadó egyszerűen hamis válasz csomagokat küldhet a kérdező szervernek, amit az elfogad, és cache-el.
Erre a támadásra is érzéketlenek a legújabb Bind változatok: véletlenszerűen generálják az ID-t.
Így is mód lehet arra, hogy egy kliens ugyanarra a kérdésre vonatkozó válasz csomagokkal árassza el a szervert úgy, hogy azokban csak az ID mező különbözik.
Ez ellen úgy védekeznek az újabb Bind változatok, hogy ha egy kérdésre sok választ kapnak, akkor egyiket sem veszik figyelembe.
Mit tehetünk ?
Használjuk a legfrissebb Bind változatot. Újabb és újabb hibákra, hiányosságokra derül fény, ezért ajánlatos mindig upgradeelni. A konfigurációban vezessünk be korlátozásokat Figyeljük a saját naplófájljainkat, mások tapasztalatát: a biztonsági fórumokat
Újabb biztonsági elemek a DNS-ben
Titkosítás és digitális aláírás Klasszikus, szimmetrikus, és a nyilvános kulcsú titkosítást. Átmenet a biztonságos DNS üzembe zökkenőmentes
Domain Name System Security Extensions - DNSSEC A DNSSEC javaslat nyilvános kulcsú titkosításon alapuló kiterjesztéseket tartalmaz, újabb DNS rekordokat vezet be: KEY rekord, nyilvános kulcsok tárolására. SIG rekord, DNS rekordok, illetve zónák aláírására. Az aláírás a KEY rekorddal definiált kulcsokkal történik. NXT rekord, annak hiteles igazolására, hogy bizonyos rekordok nem léteznek.
A KEY rekord A KEY rekord struktúrája:
Kulcsok kezelése
Kulcsrekordok definiálása speciális programmal
Bind -> dnskeygen ( publikus/titkos kulcspár generálása)
Hálózaton kívüli gép
A SIG rekord
Ez a rekord szolgál DNS adatok hitelesítésére, digitális aláírására. (RRset)
A SIG rekord struktúrája:
Bonyodalom a cache-sel
Meddig kell a cache-ben tartani egy rekordot?
TTL nem - aláírás érvényessége igen → rekord eldobása Aláírás érvényessége nem – SIG rekord TTL igen → rekord eldobása
Az RFC2535 azt ajánlja, hogy az aláírás érvényességi ideje a TTL 4-16 szorosa legyen.
Az NXT rekord
A rekord formátuma:
Új állapotok
Adat megérkezett
Aláírás
Adat
IGEN
Érvényes
Hiteles
IGEN
Várunk rá
Függő
IGEN
Nem lehet hozzá kapni
Bizonytalan
IGEN
Nem igazolta az adatot
Hibás
Új bitek a DNS üzenetek fejrészében
A DNS üzenetek fejrészében két eddig kihasználatlan bitet lefoglal a DNSSEC specifikáció.
AD (Authentic Data) a szerver felől
CD (Checking Disabled) a rezolver felől
A DNSSEC következménye
Rekordok számának növekedése A DNS szerverek számolási igénye nagyságrendekkel nő. Rendszeradminisztrátornak munkájának jelentős növekedése
A TSIG javaslat
DNS tranzakciók hitelesített közlekedése két szereplő között.
DNSSEC (Nyilvános kulcs) ↔ TSIG (Szimmetrikus kulcs)
DNS üzenet → ujjlenyomat
Kulcs kezelés
Probléma:
a szimmetrikus kulcs tárolása a szimmetrikus kulcs eljuttatása a partnerhez
A TSIG rekord
DNS üzenet felhasználása, új rekord típus
Rekord két paramétere (algoritmus neve, 2 idő adat)
Alkalmazható kérdésre, és válaszra egyaránt
Összefoglalás A DNS rendszer biztonságáért most is sokat tehetünk megfelelő konfigurálással, odafigyeléssel. Több ponton folyik ígéretes munka a hitelesített DNS kommunikációra. Az új ajánlások implementációja most folyik, forráskódban is hozzáférhető az Internet Software Consortium ftp szerverén: ftp.isc.org. A feladat nem egyszerű, és várható, hogy több ponton egészen másképpen kell a jövőben a DNS szervereknek és DNS adminisztrátoroknak működniük.
Forrás
MTA Sztaki - Az informatikai hálózati infrastruktúra biztonsági kockázatai és kontrolljai
Pásztor Miklós MTA SZTAKI/ASZI - Az internet DNS Elv és konfiguráció
Pásztor Miklós MTA SZTAKI/ASZI
- DNS biztonság - jelen és jövő
