A DNS-reflektív támadást számos elosztott szolgáltatásmegtagadási (DDoS) támadásban használják egy internetes vezeték leállítására. A támadás kétlépcsős; a támadó nagy mennyiségű kérést küld egy vagy több legitim DNS-kiszolgálóhoz, miközben a célzott áldozat hamisított forrás-IP-jét használja. A félig legitim kéréseket fogadó DNS-kiszolgáló a hamisított IP címre válaszol, ezáltal tudtán kívül olyan kérésekre adott válaszokkal indít támadást a célzott áldozat ellen, amelyeket az áldozat soha nem küldött.

Az internet tele van nyílt feloldóként kínált DNS-kiszolgálókkal, amelyek minden hozzájuk küldött kérést kiszolgálnak, egyes jelentések milliós mennyiséget említenek. Ez a hatalmas szám nagyon megnehezíti a támadás előzetes azonosítását az IP-hírnév segítségével. Ráadásul ezek a szerverek valójában törvényes szerverek, amelyek általában törvényes forgalmat küldenek, így bármely IP-reputációs szolgáltatás összezavarodik azzal kapcsolatban, hogy a természetük rosszindulatú-e vagy sem.

A legtöbb DNS-lekérdezést UDP segítségével küldik, amely protokoll nem teszi lehetővé a forrás-IP érvényesítését. Ezért a közvetítő DNS-kiszolgáló azt feltételezi, hogy a kérések az áldozattól érkeznek, és a válaszokat visszaküldi neki. Az IP-hamisítás rendkívül megnehezíti az áldozat kiszolgáló számára a támadó felderítését, mivel úgy tűnik, mintha egy legitim DNS-kiszolgáló támadná, és a támadó IP-je teljesen rejtve marad. Az IP-hamisítás érvényteleníti az IP-reputációs szolgáltatásokat is, amelyek, ha nem megfelelően vannak megírva, rossz hírnevet rendelhetnek egy legitim DNS-kiszolgálóhoz. Megszünteti továbbá a támadás forrásának azonosítására irányuló biztonsági várakozások minden követhetőségét.

A spoofing másik előnye, hogy bármilyen szervert vagy szolgáltatást képes megtámadni. A támadó felhasználhatja az áldozat nyilvános szerverének IP-jét és portját, hogy a támadást bármelyik szolgáltatáshoz küldje, ne csak egy DNS-szolgáltatáshoz. A forgalom egyszerűen sok adatnak fog tűnni, és a kiszolgálónak elemeznie és vizsgálnia kell az adatokat, hogy megbizonyosodjon arról, hogy nem legitim forgalomról van szó.

Megjegyzendő, hogy az IP-hamisítás szintén korlátja ennek a támadásnak – ha az IP-hamisítás nem lehetséges, a támadás nem indítható, mivel nincs mód arra, hogy a válaszokat az áldozat IP címére irányítsák. Ez a helyzet a NAT-ot végrehajtó router mögött lévő IoT-eszközökön futó Mirai botok esetében. A legújabb Mirai fertőzési taktikák azonban magukat az otthoni routereket célozzák meg, így megkerülve a NAT korlátozást.

A legújabb és legnagyobb előny, amely hozzájárul a reflektív DNS-áradatok pusztító potenciáljához, az erősítés, amely a DNS-bővítések (EDNS0, az RFC 2671-ben definiálva) és a DNSSec segítségével érhető el. Az EDNS0 lehetővé teszi, hogy a DNS-válasz nagyobb legyen, mint az eredetileg engedélyezett 512, míg a DNSSec lehetővé teszi a válasz hitelesítését a cache-mérgezés megakadályozása érdekében. A DNSSec működéséhez az EDNS0-ra van szükség, mivel a válaszhoz kriptográfiai adatokat ad hozzá. Mivel a DNSSec egyre népszerűbb a mai biztonságtudatos interneten, egyre több DNS-kiszolgáló támogatja az EDNS0-t, és lehetővé teszi a támadó számára, hogy nagy válaszokat érjen el a kéréseire.

A válasz lehetséges mérete – akár 4096 bájt – lehetővé teszi a támadó számára, hogy kis számú rövid kérést küldjön, míg a DNS-kiszolgáló által küldött válaszok nagymértékben felerősödnek, kimerítve az áldozat internetes vezetékét. A támadók tanulmányozhatják a DNS-kiszolgálót, és kideríthetik, hogy mely legitim lekérdezések eredményezhetnek nagy válaszokat, és a DNSSec segítségével kriptográfiai adatokkal még nagyobbá tehetik azokat. Sok esetben a válasz elérheti a maximális 4096 bájtot, ami az eredeti kérés x100-as felerősítési tényezőjét adja.

A mai nagy internetkapcsolatok mellett egy 100 M-es internetkapcsolat önmagában is képes egy szerény támadást elküldeni, és mégis kárt okozhat egy normális webhelynek. Ha azonban a támadónak lehetősége van arra, hogy ezt a hatalmas 4096 bájtos választ használja a 44 bájtos kérésére, és 100-szoros erősítést kap, akkor az áldozat kiszolgáló 10 G támadási forgalmat fog kapni, a normál forgalmi sávszélességén felül. Az ilyen forgalom miatt minden normális szolgáltatás azonnal üzemképtelenné válik. Képzeljük el, mit lehet elérni egy botnet segítségével, amely akár csak néhány ilyen botból áll.

A válasz méretét növeli az a tény, hogy az ilyen válaszok nem férnek bele egy normál IP-csomagba. Ilyen esetekben a szerverek az IP-fragmentálási lehetőséget használják, amely lehetővé teszi számukra, hogy az üzenetet több csomagra osszák. A töredezett forgalom használata a támadásban még nehezebbé teszi a támadás elhárítását – az elhárítónak az első csomag 4. rétegbeli adatait (UDP portok) egy táblázatban kell tárolnia, és ezt kell alkalmaznia az ugyanabból az üzenetből származó többi csomagra. Sok hálózati egységet gyorsan kimerít a sok töredezett forgalom, ami még hatékonyabbá teszi ezt a támadást.

Radware YouTube DNS-erősítő támadás videója grafikusan szemlélteti a reflektív DNS-támadás felépítését és lefolyását.

A DNS-reflexív támadás minden csínját-bínját megismerve egy dolog marad – hogyan lehet egy szervezetet megvédeni az ilyen támadás ellen és enyhíteni azt? Ellentétben magának a támadásnak a kifinomultságával, ennek a problémának ismert megoldása van – a DNS-tükröző támadás mérsékléséhez egy jó detektorra van szükség a helyszínen, amely gyorsan észleli a támadást és megakadályozza a leállást. Az érzékelőnek elég okosnak kell lennie ahhoz, hogy megértse, hogy az általa észlelt támadás telíti az internetkapcsolatot, és a forgalmat át kell irányítani egy felhős törlési központba. Amint a forgalom átirányításra kerül a felhős tisztítóközpontba, megtisztítják és elküldik a webhelyre.

A tisztítás maga a hasonló, legálisnak tekintett forgalom mennyiségétől függ – a webhely sok UDP-forgalmat lát? DNS forgalmat? Töredezett forgalmat? És ha igen, mi különbözteti meg a támadási forgalomtól? A legitim és a támadó forgalom szétválasztására szolgáló automatizált technika használata jó és gyors felhőcsökkentést, valamint némi nyugalmat biztosít.

További információkért olvassa el korábbi blogomat: DNS és DNS-támadások

Olvassa el a “Biztonságos környezet létrehozása az alulvédett API-k számára” című cikket, ha többet szeretne megtudni.

Töltse le most