Dan Kaminsky egy eddig új sebezhetőséget fedezett fel a DNS protokollban, ami a legtöbb implementációt érinti. A hiba pontos mibenléte augusztusig még titokban marad, viszont addig is célszerű feltenni a javításokat. A DNS protokoll egyébként több sebből vérzik, számos problémáról itt lehet olvasni:

http://www.kb.cert.org/vuls/id/800113

Az alábbi kérdésekkel és válaszokkal megpróbálom jobban érthetővé tenni az egész problémakört:

K: Mi a cache poisoning támadás?
V: A támadó hamis bejegyzéseket tud bejuttatni a DNS szerverbe, amit az majd szolgáltatni fog. A támadó a hamis bejegyzésekkel elérheti, hogy áldozatai az eredetileg elérni kívánt rendszer helyett a támadó által irányítotthoz kapcsolódjanak.

K: Hogy működik a cache poisoning támadás?
V: Ennek több módszere ismert, néhány régi módszer már nem működik. Manapság a legelterjedtebb módszer, hogy amikor egy DNS szerver kérdez, akkor a valódi válasz helyett a támadó hamisítványokat küld vissza gyors egymásutánban, így az egyik jó eséllyel bejuthat (a DNS szerver azt hiszi, hogy az általa feltett kérdésre kapta meg a választ).

K: Miért javasolják, hogy tiltsuk le a rekurzív módot?
V: A rekurzív mód azt jelenti, hogy a kliens egy kérésére a DNS szerver lejátssza a teljes többlépcsős kérés/válasz folyamatot. Ha ez a mód tiltott, akkor a DNS szerver nem kérdez a kliens helyett, így nem is támadható.

K: Ez a hiba csak a DNS szervereket érinti?
V: A hiba igazából a protokollban található, hasonló módon támadhatóak maguk az egyes kliensek is.

K: Mikor tiltható le a rekurzív mód?
V: Az interneten szolgáltató DNS szerverekben célszerű ezt megtenni, intranet esetén viszont nem mindig egyértelmű. Ha a kliensek maguk akarják intézni a kéréseket, az számos hátránnyal járhat: megnövekedett hálózati forgalommal és nagyobb késleltetéssel (ugyanis a kliensek általában nem cache-elnek), a kliens resolver ugyanúgy támadható lehet (ha nem sokkal jobban). Az intranetet célszerű úgy kialakítani, hogy legyenek forwarding DNS szerverek, amik rekurzívak. Amennyiben más DNS szerverek is vannak, ott viszont tiltsuk le a rekurzív kéréseket. A klienseknek lehetőleg a forwarding szervereket adjuk meg.

K: Mitől ilyen könnyű hamisítani a válaszokat?
V: A DNS protokollt annak idején nem készítették fel támadások ellen. A protokoll egy 16 bites tranzakciós azonosítót tartalmaz, aminek a célja pusztán a kérések és válaszok összerendelése volt. Ez általános esetben bőven elég, támadások ellen viszont kevés. A sávszélesség növekedésével nyilvánvalóvá vált, hogy könnyű brute-force-olni (átlagosan 32768 hamis válasz elküldése egyáltalán nem kivitelezhetetlen).

K: Lehet ennél még rosszabb is?
V: Amennyiben a tranzakciós azonosító generálása elégtelen, úgy az átlagosan 32768 hamis válasz helyett 8-10 is elég lehet. Ez már igencsak komoly probléma (a sikeres támadás esélye hihetetlenül megnövekszik).

K: Miért veszélyes, ha a forwarding DNS szerver többször is rákérdez ugyanarra a rekordra, amíg az előző válasz nem érkezett vissza?
V: Ilyenkor az ún. születésnap-paradoxon miatt a támadó esélye jelentősen növekedhet (http://hu.wikipedia.org/wiki/Születésnap-paradoxon).

K: Lehet egyáltalán védekezni ellene?
V: A kérések forrásportjának véletlenszerű megválasztása segíthet, ez ugyanis kb. 16 bitnyi véletlenszerűséget visz a játékba (a tranzakciós azonosító segítségével ez már 32 bit). Ez sem kijátszhatatlan, de sokkal jobb, mint az eredeti helyzet volt. A DNSSEC használata megoldás lenne, de ez még nem elég elterjedt.

K: Akkor miért nem használták eddig ezt?
V: A kliensek implementációjakor erre nem figyeltek (ott mindig a legelső szabad portot használták), a DNS szerverek pedig sokszor fix portról kérdeztek.

K: Miért volt jó, hogy fix portról ment a kérés?
V: Ha nem állapottartó csomagszűrőt használtunk, akkor a változó portú DNS kérések szűrése rémálom volt. A DNS szerver 1024-65535 portjaira bármilyen külső UDP forgalmat engedélyezni kellett, így ha pl. NFS futott rajta, az kívülről is elérhető volt.

K: Mit ajánlanak védekezésként?
V: Elsősorban a javítást kell telepíteni, másodsorban ahol lehet, célszerű letiltani a rekurzív kéréseket az ismeretlen kliensek számára. Ahol fixen be lett varrva a kérés port (pl. bind esetén a query-source paraméterrel), ott ezt célszerű eltávolítani (csak figyelni kell a helyes tűzfalazásra is).

Mátó Péter, Faragó János, Zámbó Marcell, Zrubecz László

2004 május

Hibaelhárítás Linux és Unix rendszereken

Időnként előfordul, hogy egy szerver vagy munkaállomás használata közben valamilyen rendellenes működést tapasztalunk. Rendszertelenül lefagy vagy kattogó hangot ad a gép, vinnyog a hangkártya, egy program nem akar elindulni, csak áll, és nem csinál semmit, vagy épp ellenkezőleg, csinál valamit, csak nem azt, amit várunk tőle. Előfordul, hogy egy szervernek fogadnia kellene egy kapcsolatot, de nem teszi. Bosszantó. Kevésbé tapasztalt felhasználók ilyen esetben segítséget kérnek, vagy rosszabb esetben feladják, és nem használják az adott programot. Pedig általában van megoldás, csak hibaelhárítási gyakorlat kell hozzá. Ezt az iskolában sajnos nemigen tanítják, holott talán ez lenne az egyik legfontosabb tárgyalandó téma. A tanulmány összefoglalja, milyen problémák fordulhatnak elő egy rendszeren, azokat milyen eszközökkel, módszerekkel lehet felderíteni és elhárítani.
A tanulmány a 2004. évi GNU/Linux konferencia közönség által legjobbnak választott előadásához készült kísérőanyag. Mindenkinek melegen ajánljuk, aki Linux vagy más Unix rendszereket használ. Sok bosszúságtól kíméli meg az embert ...

Borbély Zoltán, Faragó János, Török Márton

2002

Tipikus programozási hibák

A tanulmány a BMF-en évi rendszerességgel megtartott "Bevezetés az informatikai biztonságba" című tárgy egyik előadásához készült segédanyagként. A tanulmány általános bevezető a programozók által figyelmetlenségből vagy tudatlanságból okozott biztonsági hibák természetébe. Szó esik a programfüggetlen biztonsági hibákról, a fordítóprogramot igénylő nyelvek leggyakrabban elkövetett és az értelmezett nyelvek néhány tipikus hibájáról. A tanulmány terjedelménél fogva nem ismertetheti meg az olvasót minden lehetséges hibával, azonban a feldolgozott hibák nagyon jó áttekintést és szemléletet adnak. Programfejlesztőknek kötelező olvasmány.

Több más szerző között Mátó Péter

2004

Az informatikai hálózati infrastruktúra biztonsági kockázatai és kontrolljai

Ez a tanulmány az IHM-MTA Kutatási Program keretében végzett 'Internet védelmi rendszer struktúrájának kidolgozása' című kutatási projekt (Sorszám: E4, Iktatószám: 4671/4/2003) része. A teljes dokumentum hatalmas terjedelmű, és elkészítésében több, a saját témakörének elismert, jeles szakértője is részt vett. Mátó Pétert az a megtiszteltetés érte, hogy részt vehetett a tanulmány elkészítésében két fejezet megírásával. A teljes szerzőlista a dokumentumban megtalálható.

Mátó Péter

1999-2003

Hogyan legyél Linux guru

A rövid és végletekig tömör összefoglalóból megtudhatják az érdeklődők, hogy mire van szüksége egy kezdőnek ahhoz, hogy középhaladó Linux guruvá váljon. A szükséges parancsok megfelelő paraméterei is fel vannak tüntetve, így nem kell a kezdőknek minden parancs kapcsolóinak százait végignéznie és reménykednie, hogy a lényegesebbeket sikerül megjegyezni. Természetesen egy ilyen sűrű javaslat nem lehet teljes, de a szerző tapasztalata szerint ha valaki az összeírt parancsok felsorolt kapcsolóit képes használni, és a javasolt könyveket elolvassa, akkor önállóan képesnek kell lennie a szintén javasolt feladatok megoldására, és így egyfajta jártasság megszerzésére. A Linux mély ismerete természetesen komoly tapasztalatot igényel, de ez idővel megszerezhető.