DoS DNS poisoninggal

A tavalyi év nagy it-biztonsági szenzációja volt a Dan Kaminsky-féle DNS-poisoning támadás és a körülötte szerveződött hype. Gyors áttekintés: Kaminsky több-kevesebb huzavona és titkolózás-találgatás-kiszivárogtatás után bejelentett egy olyan sebezhetőséget, amely lehetővé teszi a meglévő DNS infrastruktúra tervezési hiányosságain alapulóan valamely DNS-szerverben tetszőleges bejegyzéshez tartozó IP-cím megváltoztatását tetszőleges címre.

Kaminsky felvette a kapcsolatot a legelterjedtebb DNS-szoftvereket fejlesztő cégekkel, hogy patcheljék a termékeiket, mielőtt kiszabadul a szellem a palackból. Ez nagyrészt meg is történt, viszont a történetnek még sajnos korántsincs vége: a patchek telepítése opcionális, emiatt százával (tízezrével) lehetnek "odakint" DNS-szerverek, amelyek nincsenek javítva. Egy 2008 novemberében készült felmérés szerint az akkori DNS-szerverállomány 1/4-e továbbra sem volt patchelve (!).

Mit jelent mindez a gyakorlatban? Elsősorban azt, hogy a poisoning támadás sikeres kivitelezése esetén továbbra is lehetséges DNS alapokon eltéríteni egy-egy DNS-szerver által kiszolgált hálózati szegmens forgalmát, ezáltal példátlanul hatékony DoS-támadást indítani - mint ahogy az meg is történt egyik ügyfelünk hálózatában.

Az üzemeltetők figyelmét az keltette fel, hogy a webszerver(klaszter) terhelése hirtelen két nagyságrenddel megnőtt, emiatt a legitim kérések kiszolgálása sok esetben TCP-s timeoutot elérő ideig tart - ezáltal gyakorlatilag elérhetetlenné téve az internet felől a központi webes rendszert. A logok megvizsgálása után kiderült, hogy három-négy IP-tartományból érkeznek a kérések, viszont ami különös volt az érkező HTTP-kérésekben, az a HOST mező tartalma: lényegében mindegyik fals kérés a google.com felé irányult, ennek ellenére a központi load balancer internet felől elérhető IP-címére érkeztek.

Több lehetőség is felmerült a helyzet kezelésére.

• Az érintett, mérgezett cache-ű DNS-szerver üzemeltetőinek küldtek egy e-mailt, hogy tájékoztassák őket a helyzetről - sajnos a megkeresésre a mai napig nem érkezett válasz, cserébe a szervert sem patchelték fel azóta sem.
• Felmerült a lehetőség, hogy IP-szinten tűzfalazzák a "veszélyes" IP-tartományokat - ezt hamar elvetették, ugyanis legitim forgalom is érkezik az érintett szegmensekből.
• A megoldás végül is az lett, hogy üzembe állítottak egy squid proxy-t a load balancer előtt, és a proxy a Host mező tartalma alapján minimális erőforrásigénnyel eldobálta a nem megfelelő kéréseket, csak a legitimeket engedte tovább. Ezzel a megoldással néhány óra alatt sikerült normalizálni a helyzetet.
  

A nem megfelelő helyre érkező kérések áradata még egy napig fennállt (feltehetőleg ekkorra járt le a mérgezett bejegyzés TTL-je), és nem ismétlődött meg azóta sem. A tanulság az, hogy egy súlyos, széles körben érvényes sebezhetőség a kezdeti hype és pánik elcsitulta után is tud problémát okozni.