DNS problémák, újdonságok

Tartalom

• DNS cache mérgezés
• Phishing, pharming
• A névből, ránézésre való következtetés veszélye
• Phishing, pharming és IDN
• Anycasting
• Hibás konfigurációk, ellenőrzési segédeszközök
• Digitális aláírás és titkosítás DNS szinten
• DNS újdonságok?
• Jegyzetek

Az Internet Domain Name System az internet klasszikus szolgáltatása, de legtöbbször a felhasználók előtt rejtve működik: akár a DNS az élő szervezetekben, ez is nélkülözhetetlen és bámulatos és meglepetéseket tartogató.

Ezen a helyen nincs mód arra, hogy a DNS működését ismertessük. Erre vonatkozóan bőséges anyag áll rendelkezésre a hálózaton. [1] A DNS bámulatosan egyszerű, ötletes és sikeres technológia: amikor a 80-as években Paul Mockapetris megalkotta, valószínűleg senki sem gondolta, hogy mára milliószámra regisztrálnak domain-okat, és a sok hiba dacára ilyen jól működhet. A DNS osztott adatbázis, amit több százezer számítógép szolgáltat az interneten szétszórva. Rengeteg hiba, hiányosság van az adatbázisban, a rendszer ettől mégis lényegében zökkenőmentesen működik. Nagyobb veszélyt nem ezek a hibák jelentenek, hanem az emberi visszaélések, a hálózaton tevékenykedő rosszindulatú, haszonleső és önző viselkedés.

Ebben a cikkben olyan erőfeszítésekről lesz szó, amik a hibák kiküszöbölésére és a rosszindulatú tevékenység semlegesítésére irányulnak.

DNS cache mérgezés

A DNS válaszokban a ,,látó'' DNS szerver a kérdezett néven kívül más DNS információt is kaphat, az u.n. additional és authority szekcióban. Ez egy régóta ismert támadásra ad lehetőséget, a DNS cache mérgezésre, (DNS cache poisoning). Ha kliens.go.nosz név szerverétől olyan kérés érkezik a nev.szerver.vala.hol név szerverhez, amihez szerver.gon.osz név szerverét kell megkérdeznie a válaszért, akkor ebben a válaszban lehet ragadvány adatként a 'szerver.aldo.zat'-ra vonatkozó hamis adat. Ezt azután a név szerver cache-eli, és így a következő kérésnél hamis adatot ad a pc.kliens.vala.hol-nak.

Ez a fajta támadás réges régen ismert. Frappáns leírás olvasható róla például D.J. Bernstein tollából. A legnépszerűbb név szerver, a Bind erre a támadásra a 4.9.6 változat óta érzéketlen. Annál meglepőbb, hogy manapság is van olyan név szerver program - mégpedig éppen egy kereskedelmi tűzfal termékbe integrált DNS szerver -, amiről újra és újra kiderül, hogy támadható ilyen módon. Lásd: [2] , [3] , [4] .

Meg kell tanulnunk, hogy sokszor éppen akkor vagyunk gyengébbek, támadhatóbbak, ha felfegyverkezünk valamilyen állítólagos biztonságot növelő eszközzel!

Sajnos nem egy eset van arra, hogy vélt védelmi pajzs válik ellenünk fordított fegyverré. [5]

Phishing, pharming

Phishing egy fajta számítógépes csalás: az áldozattal elhitetik, hogy például a bankjával kommunikál, miközben adatait ,,lehalásszák'': illetéktelenekhez juttatja személyes adatait, gyakran bank kártyájának számát, pénzét. A Clamav nevű GNU licenszű vírusírtó, mely igen népszerű elsősorban levelező szervereken, elsők közt szűrte az ilyen phishing támadást tartalmazó leveleket, amik a gyanútlan felhasználót arra szólítják fel, hogy látogassa meg ezt és ezt a web helyet, hogy frissítse fel, egészítse ki a banknál nyilvántartott adatait. Ilyenkor a hamis webhely természetesen megtévesztő módon hasonlít az igazira. 2004-ben az OTP üzletfeleit is érte ilyen támadás: .at alatti domain nevet és egy tengeren túli szolgáltató szerverét használták ehhez. Íme egy tipikus phishing levél:

 
Subject: PayPal Account Security Measures


 Dear PayPal User,

We recently noticed one or more attempts to log in to your PayPal account
from a foreign IP address. We have temporarily limited access to sensitive
PayPal account features. Allowing your account access to remain limited for 
an extended period of time may result in further limitations on the use of
your account and possible account closure.

If you recently accessed your account while traveling, the unusual log in
attempts may have been initiated by you. However, if you did not initiate
the log ins, please visit PayPal as soon as possible to log in and perform 
the steps necessary to restore your account access:

After filling in the information required we advise you to change your password.
Changing your password is a security measure that will ensure that you are
the only person with access to the account.


Thanks for your patience as we work together to protect your account.

Sincerely,
PayPal

Pharming olyan támadás, amikor a csaló a hamis hálózati helyre úgy juttatja el áldozatát, hogy félrevezető DNS információt használ fel. Ennek egy lehetséges módja a fent említett cache mérgezés, de nem ez az egyetlen. Ilyen módszer lehet, ha a regisztrátorral, az apuka zóna kezelőjével elhitetik, hogy a zóna név szerverei megváltoztak. Pontosan ez történt egy nagy amarikai szolgáltatóval: a regisztártori ügymenet lazasága miatt a .com zóna alatt regisztrált domaint ,,elkötötték'' és a támadó a szolgáltató minden üzletfelének levelezését és hálózati forgalmát magához terelte. [6]

Óriási a felelőssége ezért a regisztrátor szervezeteknek, fontos, hogy működésüket szigorú, nyilvános szabályok szerint folytassák, és a szabályokat betartsák. A .hu alatt kezdettől fogva szigorúbb szabályok szerint folyik a regisztrálás mint mondjuk a .com zónában. [7] Nyilvánvaló, hogy ezek a szabályok a közösség érdekét szolgálják. Időnként változnak, de mindig elérhetők a http://www.domain.hu címről indulva.

Egy másik módszer lehet, ha egyszerűen egy látó vagy egy autoritatív név szervert kerít hatalmába a támadó, és kénye-kedve szerint válaszol a kliensek kérdéseire. Az ilyen támadásra módot adhatnak nem csak a DNS hibák, hanem sok más gyengeség az internet infrastruktúrájában.

Arra is van példa, hogy egy domain név regisztrációja egyszerűen lejár, valaki lecsap rá, és a régihez megtévesztésig hasonló web helyet alakít ki az új regisztrációval, a gyanútlan visszatérő látogatók pedig pórul járnak.

A névből, ránézésre való következtetés veszélye

Könnyen be lehet csapni a felhasználót, ha az a domain névből következtet arra, hogy kivel is kommunikál, és különösen akkor, ha egy-egy sajtóhibát elnéz. Ez egészen nyilvánvaló és csak csodálni lehet, hogy mennyire nem veszik figyelembe. Néhány példa:

A név nem mondja meg, hogy kivel kommunikálunk

• A Nemzetközi Sakk Szövetség, a FIDE web lapja nem a fide.org domain alatt érhető el, hanem a fide.com alatt, pedig a FIDE nem egy kereskedelmi vállalkozás. A fide.org létezik, de más.
• Az amerikai elnöki rezidencia web lapja nem a whitehouse.com alatt érhető el, ott egészen más van.

A következő egy sorban álló domain nevek könnyen összekeverhetők, különösen akkor, ha kicsi és/vagy nehezen olvasható az írás:

ibrninfo.com ibminfo.com
kellemes.hu ke11emes.hu

Nagyobb betűkkel a különbség szembeszökő:

ibrninfo.com ibminfo.com
kellemes.hu ke11emes.hu

Látható, hogy az egymás után következő ,,r'' és ,,n'' betű könnyen m-nek olvasható, az ,,1''-es pedig könnyen ,,l'' betűnek. Sok hasonló példát lehet találni. Az olvasott név tehát félrevezethet: vannak is csalók, akik ezt használják ki.

A tévesztés elkerülése végett sokszor egy-egy intézmény tucatjával regisztrál domain neveket. Az OTP például lefoglalta a következőket:

De nem foglalta le ugyanezeket például a .com, vagy a .net alatt. Nem is lehet mindent lefoglalni, amiből a felhasználók egy vállalkozásra következtethetnek.

Láthatjuk tehát, hogy nem szabad következtetéseket levonni abból, hogy egy domain név számunkra valamilyen szervezetre vagy intézményre utal. Nagyon is lehet, hogy a domain név mögött egészen mást találunk, mint amit várnánk. Sőt: ha a web hely SSL-lel védett, az SSL-hez tartozó tanúsítványt valamilyen tanúsítványkibocsátó aláírta, akkor sem szabad ilyen következtetést levonnunk. Erre nem csak azért van okunk, mert volt rá példa, hogy az üzletileg legjobban menő tanúsítványkibocsátó illetékteleneknek adott tanúsítványt [8] [9] , hanem azért is, mert ha körültekintően jár el, akkor is kiadhatja az ,,okos'' névre szóló tanúsítványt az Ostobák és Kukák Országos Síiskolájának éppen úgy, mint az Okos kft-nek. A tanúsítványkibocsátó digitális aláírásánál biztonságosabb, ha a szolgáltató web helyéhez tartozó tanúsítvány ujjlenyomatát az irodájában vesszük át, megkapjuk közönséges levélben, vagy akár olvassuk nyilvános hirdetésekben.

Phishing, pharming és IDN

A gyanútlan felhasználó tehát könnyen és sokféleképpen áldozatul eshet ha egy domain névből következtetéseket von le. A veszélyt kétségtelenül növeli, hogy manapság nem csak latin betűk, számok és a kötőjel (u.n. LDH, letter, digit, hyphen) szerepelhet egy domain névben, hanem a nemzeti nyelvek karakterei, például kínai írásjelek. Az erre vonatkozó RFC-k 2003-ban jelentek meg [10] . Ezek az IDN, (Internationalized Domain Names) szabályok. A nemzeti karaktereket tartalmazó nevet az alkalmazás (pélául a web böngésző) konvertálja u.n. punycode formába. Ez a forma csak LDH karaktereket tartalmaz, és ebben a formában tárolják ténylegesen a név szerverek a DNS rekordokat. Például a péter.hu domain névből punycode szerint xn--pter-bpa.hu lesz. 2004 tavasza óta a .hu domain alatt is lehet magyar ékezetes neveket regisztrálni. 2005 tavaszára mintegy 170000 delegálásból több mint 10500 ilyen (kb. 6 %).

A különböző ABC-kben nagyon sok hasonló, vagy éppen egyező alakú karakter, nyomdász nyelven homograph pontosabban homoglyph van. Például a cirill r és a latin p, a cirill o és a görög omikron stb. A probléma régen ismert, szellemesen és hatásosan foglalja össze a Communication of ACM-ben 2002-ben megjelent cikk [11] .

Az IDN RFC-k kezdettől fogva figyelembe vették a homograph-ok okozta kockázatokat, és a meghatározták, milyen óvintézkedéseket kell tenni, amikor IDN domain-okat vezetünk be: erről szó van RFC3490 és RFC3491-ben és az azt kiegészítő ICANN útmutatóban [12] .

2005 februárjában azonban nagy nyilvánosságot kapott egy eset, amikor a paypal.com domaint regisztrálta valaki a közepén cirill ,,a''-val, sőt kért és kapott a domain névhez kapcsolódó SSL tanúsítványt is. [13]

Fontos látnunk, hogy a paypal.com domainnel kapcsolatos visszaélés azért vált lehetővé, mert a .com alatt nincsenek olyan szigorú regisztrálási szabályok mint az egyes nemzeti felső szintű domain-ok (country code Top Level Domain-ok, ccTLD-k) esetén. A .hu alatt például elképzelhetetlen a paypal-hoz hasonló regisztráció: a szabályok csakis magyar ékezetes karakterekkel (áéíóöőúüű) bővítették a domain névben szerepeltethető karakterek készletét. Mindazonáltal - mint láttuk - nincs kizárva, hogy félrevezeti a felhasználót a domain név!

Nem csak elektronikus és írott sajtó, hanem például a Mozilla is hevesen reagált a cirill a-val regisztrált paypal esetére : az első hírek arról szoltak, hogy a Mozilla böngészők következő változatai alapértelmezésben nem fogják támogatni az IDN domain neveket. Később - az internet közösség reakciójának köszönhetően -, a Mozilla változtatott álláspontján: továbbra is az lesz az alapbeállítás, hogy támogatják a Mozilla böngészői az IDN domain neveket. Lesz azonban a TLD-knak (Top Level Domain-ok) egy fehér és egy fekete listája. A fehér listába tartoznak azok, ahol nincs lehetőség például vegyes karakterkészlettel domaint regisztrálni, a fehérbe pedig azok, ahol a szabályok az ilyet lehetetlenné teszik. A fekete listán levő domainok alatti IDN neveknél a címsorban nem az IDN nevet, hanem a punycode-dal kódolt változatot jeleníti meg a Mozilla böngészője. Ilyen módon könnyű különbséget tenni egy csupán LDH karaktereket tartalmazó domain név és egy olyan domain név között, amely mondjuk görög karaktereket is tartalmaz. Ez azonban nem ok arra, hogy megoldottnak gondoljuk a problémát:

1. Nem nyilvánvaló például egy cirill domain nevet megkülönböztetni homograph görög párjától, például az ok.com névben az ,,ok'' lehet nem csak latin hanem görög vagy cirill karaktersorozat is.
2. Több szintű delegálás esetén a felső szintű szabály semmi garanciát nem ad az alsóbb szinteken. Hiába szigorúak a mondjuk .hu alatt a delegálási szabályok, az os.to.ba.hu alatt olyan nevet vezet be a zóna gazdája, amilyet csak akar.

Látható tehát, hogy a domain név tévesztés továbbra is könnyven lehetséges. A több szintű domain delegálás nagyon könnyen lehetővé teszi megtévesztő nevek bevezetését. A felhasználók túlnyomó többségét könnyű félrevezetni például a http://www.otp.hu-x.y.info/tartalom.html típusú url-lel. Ráadásul IDN karakterekkel a hu-x helyett hu/x is állhat, vagyis az url a még megtévesztőbb http://www.otp.hu/x.y.info/tartalom.html alakú is lehet!

Újra kell tehát hangsúlyoznunk, hogy nem szabad következtetéseket levonni abból, hogy egy domain név számunkra valamilyen szervezetre vagy intézményre utal.

Anycasting

A DNS elleni támadások közül kétségkívül a root név szerverek elleni támadás a legveszélyesebb. Az internet alapjaiban rendül meg, ha ezek hamis információt tartalmaznak, vagy akár csak DoS (Denial of Service) támadás áldozatául esnek és megbénulnak. Sajnos volt ilyen súlyos DDoS támadásra példa. [14]

A root név szervereknek nem csak akkor van jelentőségük, ha egy távoli szerverhez tartozó DNS adatra van szükségünk: ha például az HBONE-ból nem érünk el root név szervert, akkor igen hamar a .hu alatti neveket sem tudjuk feloldani, még azokat sem, amiknek a név szervere különben gond nélkül elérhető. Ennek az az oka, hogy a .hu-nak a név szervereire vonatkozó adatok is elévülnek, kiesnek a cache-ből, és nem tudjuk felfejteni, hogy mondjuk a bme.hu név szerverei hol is vannak. Vannak olyan öregek közöttünk, akik emlékeznek ilyen esetre...

A root név szerverek elleni támadások egy hatásos ellenszere az anycasting: egy-egy root név szerver IP címét az internet különböző régióiban (AS-eiben) más és más valódi hálózatra, fizikai interfészre route-olják. Ilyen módon, ha az internet egy-egy darabján le is bénul a név szerver szolgáltatás, az más részeket nem érint. A http://root-servers.org webhelyen tájékozódhatunk arról, hogy a hierarchia csúcsán álló 13 név szerver közül melyik hol is van fizikailag. Láthatjuk, hogy jóval több fizikai név szerver van, mint amennyit a root zóna első látásra mutat.

Az ISZT (Internet Szolgáltatók Tanácsa) közreműködésével 2005-ben Budapesten is beindult a root név szerver szolgáltatás. A k.root-servers.net egyik példánya Budapestre, a BIX-re (Budapest Internet eXchange) került. A név szerveren az Nlnetlabs szabad forrású terméke az NSD fut [15] . Az NSD egyik sajátsága, hogy u.n. chaos osztályú kéréssel megtudhatjuk, hogy hol is van a az a K root szerver, amivel kommunikálunk:

%dig @k.root-servers.net chaos txt id.server
id.server. 0 CH TXT "k1.bix"

Ha a válasz k1.bix, az a BIX-en levő K root szerverre utal.

A BIX-en működő root név szervernek nem csak a hálózati támadások miatt van jelentősége: ilyen módon az összes magyarországi szolgáltatóhoz hálózati és fizikai értelemben is közel van root név szerver, és a szolgáltatók hálózatában akkor sem bénulna meg a névfeloldás, ha megszakadna a szolgáltató nemzetközi kapcsolata.

Hibás konfigurációk, ellenőrzési segédeszközök

Amint már szó volt róla, sok-sok szerveren van a DNS adatbázis szétszórva, és ezt súlyosbítja a sok-sok adminisztrátor: sok a hibalehetőség. A DNS hibák sokszor csak késve, véletlenszerűen, és a hálózatnak csak bizonyos részében okoznak olyan gondot, amit a felhasználók is észrevesznek. Ezért aztán sok ellenőrző procedúra, program, ellenőrzésnek szentelt web hely van.

A http://www.generic-nic.net/dyn/mon/ webhelyen a legfelső szintű domainok folyamatos ellenőrzését követhetjük figyelemmel. A hibaüzenetek sajnos nem mindig kellően informatívak. Minden esetre meglepő, hogy még a legfelső szintű domain-ok konfigurációja közül is milyen sok hibás.

Igen részletes és nem csak a DNS ellenőrést végez a domain-ünkön ha a böngészőbe ezt írjuk:

Nagyon jó, könnyen érthető hibaüzeneteket és javaslatokat ad. Sok olyan dolgra is figyelmeztet, ami nem hiba, de ezekben az esetekben is érdemes újra megfontolnunk: nálunk miért is van valami éppen úgy beállítva.

A http://www.domain.hu/regcheck/ oldalon a .hu alatti regisztráláshoz szükséges feltételeket ellenőrizhetjük. A leggyakrabban a következő ellenőrzéseken buknak el itt a domainok:

• legalább 2 működő név szerver szükséges
• a név szerverek ugyan azt a SOA rekordot szolgáltassák
• a név szerverek közül legalább kettő különböző hálózaton legyen
• a SOA rekordban levő levelezési cím (MNAME) működjön
• a postmaster@domain.neve levelezési cím működjön

A regisztrálás után sok név szerverrel nem törődnek kellőképpen, és így a régebben bejegyzett domain-ok nem feltétlenül felelnek meg a regisztrálási követelményeknek.

A .hu zónában jelenleg 172161 delegálás van. A regisztrált domain-ek közül több mint 6 ezernek egyáltalán nincs működő név szervere, és ugyanennyinél a név szerverek közül valamelyik működik, de nem mind (lame delegálás). A 2005 márciusában végzett felmérés eredményeit az alábbi táblázat foglalja össze:

Az táblázat azt mutatja, hogy viszonylag nem rossz a .hu alatti DNS állapota a vizsgált szempontból. Egy 2004-es SIGCOMM konferencián elhangzott előadás szerint a legtöbb TLD-nél 15% körüli a lame delegálások aránya [16] . Az elmúlt időben hasonló vizsgálatokat végeztek az APNIC (Asia Pacific Network Information Centre) területén. Ott a megfelelő felelős személyeket egy automata értesítette a problémáról. A projekt 2004 augusztusában kezdődött. Ennek hatására 2005 februárjára a lame delegálások 18,6 %-ról 16,3 %-ra csökkentek [17] . Várható, hogy ha a .hu alatti lame delegálások is kedvezően változnak, ha a zóna felelősöket elektronikusan értesítjük.

Digitális aláírás és titkosítás DNS szinten

Sok éve vajúdó technológia a DNS rekordok, és zónák digitális aláírása és titkosítása. Erről szóló előadás hangzott el például a Networkshop konferencián 2000-ben [18] . A DNSSEC ajánlások nyilvános kulcsú titkosítást használnak. A javasolt megoldás alapjaiban változtatja meg nem csak a DNS programok működését (pl. többszörösére nő minden zóna mérete, többszörösére nő egy-egy DNS kérés processzorigénye, stb.), hanem a DNS adminisztrátorok feladatait is többszörösére növeli. Mindez közre játszik abban, hogy nehézkes a DNSSEC bevezetése. Még mindig az alkalmi kipróbálás fázásiában tart. Egy másik nehézség, ami sokakat visszariaszt a használatától a zóna letapogatás veszélye: hiába tiltja meg egy zóna felelős egy teljes zóna átvitelét, DNSSEC-et használó zóna esetén az egész zóna ,,letapogatható''.

A TSIG [19] szimmetrikus kulcsú titkosítást használó eszköz. Ez már valóban évek óta jól beválik. Például a PPKE.HU alatt is évek óta használjuk dinamikus zóna update biztonságosabbá tételére.

DNS újdonságok?

Összefoglalóan azt mondjatjuk, hogy ennek az írásnak a keletkezésekor a legtöbb DNS-sel kapcsolatos égető kérdés nem újdonság, inkább régiség: a cache poisoning, a DNSSEC körüli problémák már a múlt évszázadban is ismertek voltak. A DNS nagy és nehézkes rendszer. A szó minden értelmében nagy a tehetetlenség körülötte. Ezt érzékelve nem csak klasszikus internetes szervezetek mint az IETF és a RIPE, hanem újabbak is igyekeznek lendíteni a fejlődésén. Ilyen szervezet a DNS-MODA amely a W3 konzorcium mintájára képzeli el a DNS technológia előmozdítását. Az európai felső szintű domainok üzemeltetőinek szervezete a CENTR, ahol fórumot és kölcsönös segítséget találnak. A DNS folytonos viták tárgya. Sokak szerint az az egyik fő baj, hogy rég nem arra használjuk, amire eredetileg szánták: nevek és IP címek kölcsönös leképezésére [20] . Valóban sok minden másra is használatos a DNS, de aligha kifogásolható például a clamav nevű szabad vírusírtó frappáns ötlete: a current.cvd.clamav.net nevű DNS rekord ad információt arról, hogy milyen sorszámú a vírus adatbázis legfrissebb változata. Ilyen módon egyetlen UDP ütésváltással megtudhatjuk, hogy érdemes-e vírus adatbázist frissítenünk.

1. Megérthetjük, hogy mi hogyan is működik, hogyan is kellene működnie.
2. Javíthatjuk az eszközöket felelősségünk és lehetőségeink szerint.
3. Segíthetünk másoknak a megértésben és javításban.

Jegyzetek

Last modified: Wed Apr 20 12:39:20 CEST 2005