Ha a DNS-ről van szó, Cricket Liu szó szerint megírta a könyvet. Ő volt a társszerzője az O’Reilly “DNS and BIND” című könyvének mind az öt kiadásának, amelyet általában a Domain Name Systemhez kapcsolódó összes dologról szóló végleges útmutatónak tartanak. Cricket jelenleg az Infoblox infrastruktúráért felelős vezetője.
A DNS egyértelműen a számítógépes hálózatok kritikus eleme, de vannak esetek, amikor ezeket az eszközöket rosszhiszeműségre is fel lehet használni. Az e heti New Tech Forumban Cricket megvizsgálja a DNS-alapú DDoS-támadások növekvő problémáját és az ellenük való védekezést. — Paul Venezia
DNS-alapú DDoS-támadások: Hogyan működnek és hogyan lehet megállítani őket
A DNS-alapú DDoS (distributed denial-of-service attack) az egyik leggyakoribb pusztító támadássá vált az interneten. De hogyan is működnek? És mit tehetünk az ellenük való védekezés érdekében?
Ebben a cikkben ismertetem, hogy a DDoS-támadások hogyan használják ki és hogyan veszik célba a DNS-infrastruktúrát. Azt is megmutatom, mit tehetsz, hogy megvédd magad és másokat.
A nagy hamisítás
A DNS-infrastruktúrát használó DDoS-támadás generálása rendkívül egyszerű: A támadók lekérdezéseket küldenek az interneten található névkiszolgálóknak, és ezek a névkiszolgálók válaszokat küldenek vissza. Ahelyett azonban, hogy saját IP-címükről küldenék a lekérdezéseket, a támadók meghamisítják a célpont címét, ami lehet egy webkiszolgáló, egy útválasztó, egy másik névkiszolgáló vagy az internet szinte bármely csomópontja.
A DNS-lekérdezések meghamisítása különösen egyszerű, mivel azokat általában UDP-n (a kapcsolat nélküli User Datagram Protocol) keresztül továbbítják. Egy tetszőleges IP-címről DNS-lekérdezést küldeni körülbelül olyan egyszerű, és nagyjából ugyanolyan hatású, mintha valaki másnak a feladó címét írnánk egy képeslapra.
A lekérdezések meghamisítása azonban nem elég a célpont ellehetetlenítéséhez. Ha az ezekre a lekérdezésekre adott válaszok nem lennének nagyobbak, mint maguk a lekérdezések, egy támadó ugyanolyan jól tenné, ha hamisított lekérdezésekkel árasztaná el a célpontot. Nem, a célpontot ért kár maximalizálása érdekében minden egyes lekérdezésnek nagyon nagy választ kell visszaadnia. Kiderült, hogy ezt nagyon könnyű előidézni.
Az EDNS0, a DNS 1999-ben bevezetett kiterjesztéseinek megjelenése óta az UDP-alapú DNS-üzenetek rengeteg adatot képesek szállítani. Egy válasz akár 4096 bájt is lehet. A legtöbb lekérdezés viszont kevesebb mint 100 bájt hosszúságú.
Egykor viszonylag nehéz volt ekkora méretű választ találni az internet névterében. Most azonban, hogy a szervezetek elkezdték a DNSSEC, azaz a DNS Security Extensions bevezetését, ez sokkal könnyebbé vált. A DNSSEC a névtérben lévő rekordokban titkosítási kulcsokat és digitális aláírásokat tárol. Ezek pozitívan óriásiak.
A blogomon láthat egy példát az isc.org zóna DNSSEC rekordokat tartalmazó válaszára. A válasz mérete 4077 bájt, szemben egy mindössze 44 bájtos lekérdezéssel.
Most képzelje el, hogy támadók az internet minden tájáról elküldik ezt a hamisított lekérdezést a webszerver IP-címéről az isc.org névkiszolgálóknak. Minden egyes 44 bájtos lekérdezésre az Ön webkiszolgálója 4077 bájtos választ kap, ami majdnem 93-szoros erősítési tényezőt jelent.
Végezzünk egy gyors számítást, hogy kiderítsük, milyen súlyos lehet a helyzet. Tegyük fel, hogy minden támadónak viszonylag szerény, 1 Mbps sebességű internetkapcsolata van. Ezen a kapcsolaton keresztül másodpercenként körülbelül 2840 44 bájtos lekérdezést tud küldeni. Ez a lekérdezési folyam közel 93 Mbps sebességű választ eredményezne a webkiszolgálóra. Minden 11 támadó 1 Gbps-ot képvisel.
Honnan találnának az antiszociális támadók 10 barátot, akik segítenének nekik a támadás végrehajtásában? Tulajdonképpen nincs is rá szükségük. Egy több ezer számítógépből álló botnetet fognak használni.
A végső hatás pusztító. A negyedéves globális DDoS-támadási jelentésében a Prolexic (egy DDoS-csökkentő vállalat) egy nemrégiben egy ügyfél elleni DNS-alapú támadásról számolt be, amely meghaladta a 167 Gbps sebességet. A Prolexic továbbá arról is beszámolt, hogy az átlagos DDoS-támadások sávszélessége egyetlen negyedév alatt 718 százalékkal 48 Gbps-ra nőtt.
De várjunk csak! Nem lehetne az isc.org névszervereket úgy módosítani, hogy felismerjék, hogy ugyanazt az adatot kérik le újra és újra, ugyanarról az IP-címről? Nem tudnák elfojtani a támadást?
Kétségtelenül megtehetik. De az isc.org névszerverek nem az egyetlenek, amelyeket egy támadó arra használhat, hogy felerősítse a forgalmát. Persze, vannak más hiteles névkiszolgálók is, amelyeket a támadó használhat, de még rosszabbak a nyílt rekurzív névkiszolgálók.
A nyílt rekurzív névkiszolgáló egyszerűen egy olyan névkiszolgáló, amely bármilyen IP-címről érkező rekurzív lekérdezéseket feldolgoz. Elküldhetem neki ezt a lekérdezést az isc.org adataira, és válaszol nekem, és te is megteheted ugyanezt.
Nem sok nyitott rekurzív névszerver lehet az interneten. A rekurzív névkiszolgáló feladata, hogy a DNS-kliensek, például a laptopodon vagy az okostelefonodon lévő kliensek nevében adatokat keressen az internet névterében. A rekurzív névkiszolgálókat felállító hálózati rendszergazdák (például az Ön informatikai osztálya) általában egy adott közösség (például Ön és munkatársai) általi használatra szánják. Hacsak nem olyan szolgáltatásokat futtatnak, mint az OpenDNS vagy a Google Public DNS, nem azt tervezik, hogy Moldova polgárai használják őket. Ezért a közhasznú, biztonságra törekvő és főleg hozzáértő rendszergazdák a rekurzív névkiszolgálókon olyan hozzáférés-szabályozást konfigurálnak, amely a használatukat az engedélyezett rendszerekre korlátozza.
Ezek ismeretében mekkora problémát jelenthetnek a nyílt rekurzív névkiszolgálók? Elég nagy. Az Open Resolver Project 33 millió nyitott rekurzív névkiszolgálót tartalmazó listát gyűjtött össze. A hackerek annyi hamisított lekérdezést indíthatnak ezek közül, amennyit csak akarnak, hogy az isc.org adatokat a webkiszolgálóra, a névkiszolgálóra vagy a határkeresztező routerre zúdítsák, amíg az meg nem fullad.
Így működnek a DNS-alapú DDoS-támadások. Szerencsére van néhány módszer a leküzdésükre.
Hogyan vészeljük át a vihart
Az első teendő a DNS-infrastruktúrájának eszközzel való felszerelése, így tudni fogja, ha támadás éri. Túl sok szervezetnek fogalma sincs arról, hogy mekkora a lekérdezési terhelésük, így soha nem tudnák meg, ha egyáltalán támadás érné őket.
A lekérdezési terhelés meghatározása olyan egyszerű lehet, mint a BIND beépített statisztikai támogatásának használata. A BIND névkiszolgáló például az rndc stats futtatásakor, vagy egy beállítható statisztikai időközönként adatokat tölt ki a statisztikai fájljába. A statisztikákból megvizsgálhatja a lekérdezési arányt, a socket hibákat és a támadás egyéb jeleit. Ne aggódjon, ha még nem tudja biztosan, hogyan fog kinézni egy támadás — a DNS megfigyelésének célja részben az, hogy létrehozzon egy alapszintet, hogy azonosítani tudja, mi az abnormális.
Következő lépésként nézze meg az internetre néző infrastruktúráját. Ne korlátozza magát a külső hitelesítő névkiszolgálókra; vizsgálja meg a kapcsoló- és útválasztó infrastruktúráját, a tűzfalakat és az internetkapcsolatokat. Határozza meg az esetleges egyetlen hibapontokat. Határozza meg, hogy könnyen (és költséghatékonyan) ki tudja-e küszöbölni őket.
Ha lehetséges, fontolja meg a külső irányadó névkiszolgálók széleskörű földrajzi elosztását. Ez természetesen segít elkerülni az egyetlen hibapontokat, de akkor is segít, ha nem támadják meg. Egy rekurzív névkiszolgáló, amely felold egy tartománynevet az Ön egyik zónájában, megpróbálja lekérdezni a hozzá legközelebbi tekintélyes névkiszolgálót, így a földrajzi eloszlás általában jobb teljesítményt biztosít ügyfelei és levelezőpartnerei számára. Ha ügyfelei bizonyos földrajzi területeken csoportosulnak, a leggyorsabb válaszok biztosítása érdekében próbáljon meg a közelükben elhelyezni egy hiteles névkiszolgálót.
A DoS-támadások elleni küzdelem talán legalapvetőbb módja az infrastruktúra túlbiztosítása. A jó hír az, hogy a névkiszolgálók túlellátása nem feltétlenül költséges; egy alkalmas névkiszolgáló másodpercenként több tíz- vagy akár több százezer lekérdezést is képes kezelni. Nem tudja, mekkora a névkiszolgálói kapacitása? Használhat olyan lekérdezőeszközöket, mint a dnsperf, a névkiszolgálók teljesítményének tesztelésére – lehetőleg egy, a gyártó névkiszolgálókhoz hasonló tesztplatformot használva egy laboratóriumban, nem pedig magukat a gyártó szervereket.
A névkiszolgálók túlellátásának mértékéről való döntés szubjektív: Mennyit ér az online jelenléte? Vannak-e az internetre néző infrastruktúrájának más összetevői, amelyek előbb fognak meghibásodni, mint a névkiszolgálók? Nyilvánvalóan vakmerőség pénzt költeni arra, hogy első osztályú DNS-infrastruktúrát építsünk ki egy határrouter vagy tűzfal mögött, amely jóval azelőtt meghibásodik, hogy a névszerverek megizzadnának.
Ha a pénz nem számít, hasznos lehet tudni, hogy a DNS-infrastruktúra elleni legkorszerűbb DDoS-támadások meghaladhatják a 100 Gbps-ot.
Az Anycast használata szintén segíthet a DDoS-támadásoknak való ellenállásban. Az Anycast egy olyan technika, amely lehetővé teszi, hogy több kiszolgáló egyetlen IP-címen osztozzon, és különösen jól működik a DNS esetében. Valójában az internet gyökérnévkiszolgálói már évek óta használják az Anycastot, hogy a gyökérzónák adatait az egész világon elérhetővé tegyék, miközben a gyökerek listája egyetlen UDP-alapú DNS-üzenetbe belefér.
Az Anycast alkalmazásához a névkiszolgálókat támogató hosztoknak dinamikus útválasztási protokollt, például OSPF-et vagy BGP-t kell futtatniuk. Az útválasztási folyamat hirdetni fog a szomszédos útválasztóknak egy útvonalat egy új, virtuális IP-címre, amelyen a névkiszolgálója hallgatja. Az útválasztási folyamatnak elég okosnak kell lennie ahhoz, hogy leállítsa az útvonal hirdetését, ha a helyi névkiszolgáló nem válaszol. Az útválasztási démont a névkiszolgáló állapotához ragaszthatja saját fejlesztésű kóddal — vagy vásárolhat olyan terméket, amely ezt elintézi Ön helyett. Az Infoblox NIOS, nem véletlenül, tartalmaz Anycast támogatást.
Hogyan védekezik az Anycast a DDoS támadások ellen? Nos, tegyük fel, hogy hat külső névkiszolgálója van két Anycast csoportban (azaz három osztozik egy Anycast IP-címen, három pedig egy másikon). Mindegyik csoportnak van egy tagja az Egyesült Államokban, egy Európában és egy Ázsiában. Az Ön ellen DDoS-támadást indító állomás az internet bármely pontjáról egyszerre csak az egyik csoport egy tagjának küldhet forgalmat – és így csak ezt támadhatja -. Hacsak a támadók nem tudnak egyszerre annyi adatforgalmat küldeni Észak-Amerikából, Európából és Ázsiából, hogy elárasszák az Ön infrastruktúráját, nem fognak sikerrel járni.
Végre van egy mód arra, hogy jelentős tőkebefektetés nélkül kihasználja a széles földrajzi eloszlás és az Anycast előnyeit egyszerre: Használjon felhőalapú DNS-szolgáltatót. Az olyan cégek, mint a Dyn és a Neustar saját Anycast névkiszolgálókat üzemeltetnek a világ különböző pontjain található adatközpontokban. Ön fizet nekik azért, hogy fogadják a zónáit, és válaszoljanak az adataira vonatkozó lekérdezésekre. És továbbra is fenntarthatja a zónaadatok feletti közvetlen ellenőrzést, ha megkéri a szolgáltatót, hogy konfigurálja névkiszolgálóit másodlagosként a zónái számára, és töltse be az adatokat az Ön által kijelölt és házon belül kezelt fő névkiszolgálóról. Csak győződjön meg róla, hogy a főszervert rejtve futtatja (azaz nincs rá mutató NS rekord), különben fennáll annak a veszélye, hogy egy támadó egyetlen hibapontként veszi célba.
Egy óvatosságra int a felhőalapú DNS-szolgáltatók használatával kapcsolatban: A legtöbbjük legalább részben az Ön zónáiban lévő adatokra vonatkozó lekérdezések száma alapján számlázza ki a névkiszolgálójukat. Egy DDoS-támadás esetén ezek a lekérdezések drámaian megnövekedhetnek (teljesen az Ön ellenőrzésén kívül és egyáltalán nem az Ön javára), ezért győződjön meg róla, hogy rendelkeznek-e rendelkezéssel a DDoS-támadások kezelésére anélkül, hogy a forgalom költségeit Önre hárítanák.
Hogyan kerülheti el, hogy cinkossá váljon a DDoS-támadásokban
Most már tudja, hogyan konfigurálhatja DNS-infrastruktúráját úgy, hogy ellenálljon egy DDoS-támadásnak. Majdnem ugyanilyen fontos azonban annak biztosítása, hogy ne legyen cinkos egy más ellen irányuló DDoS-támadásban.
Emlékszik arra a leírásra, hogy a DNS-kiszolgálók hogyan képesek felerősíteni a forgalmat? A támadók mind a nyílt rekurzív névkiszolgálókat, mind a tekintélyes névkiszolgálókat erősítőként használhatják, hamisított lekérdezéseket küldve, amelyek hatására a névkiszolgálók a lekérdezésnél több mint százszor nagyobb válaszokat küldenek tetszőleges internetes célpontoknak. Ön természetesen nem akar egy ilyen támadás célpontja lenni, de nem is akar bűnrészes lenni. A támadás a névszerverek erőforrásait és a sávszélességet is igénybe veszi. Ha a célpont intézkedéseket tesz az Ön névkiszolgálójáról a hálózatára irányuló forgalom blokkolására, akkor a támadás befejezése után előfordulhat, hogy a célpont nem lesz képes feloldani az Ön zónáiban lévő tartományneveket.
Ha nyílt rekurzív névkiszolgálót üzemeltet, a megoldás egyszerű: Ne tegye. Nagyon kevés olyan szervezet van, amelyiknek indokolt a rekurzív lekérdezésekre nyitott névkiszolgáló futtatása. A Google Public DNS és az OpenDNS kettő jut eszembe, de ha ezt olvassa, akkor gondolom, hogy valószínűleg nem ezek közé tartozik. A többieknek hozzáférési ellenőrzéseket kell alkalmazniuk a rekurzív névkiszolgálóikra, hogy biztosítsák, hogy csak az engedélyezett lekérdezők használják őket. Ez valószínűleg azt jelenti, hogy a DNS-lekérdezéseket a belső hálózatunkon lévő IP-címekre kell korlátozni, ami könnyen megvalósítható bármelyik névkiszolgáló implementációjánál, amely megéri a pénzét. (A Microsoft DNS-kiszolgáló nem támogatja a lekérdezések IP-cím alapú hozzáférés-ellenőrzését. Olvasson bele, amit akar.)
De mi van, ha autoriter névkiszolgálót futtat? Nyilvánvalóan nem korlátozhatja azokat az IP-címeket, amelyekről lekérdezéseket fogad — vagy legalábbis nem nagyon (megtagadhatja a nyilvánvalóan hamis IP-címekről, például az RFC 1918-as címekről érkező lekérdezéseket). De a válaszokat korlátozhatja.
Két régi internetes “fehér kalapos”, Paul Vixie és Vernon Schryver rájött, hogy a hiteles névkiszolgálókat erősítésre használó DDoS-támadások bizonyos lekérdezési mintákat mutatnak. A támadók ugyanarról a hamisított IP-címről (vagy címblokkról) újra és újra ugyanazt a lekérdezést küldik a névszervereknek, maximális erősítésre törekedve. Egyetlen jól működő rekurzív névkiszolgáló sem tenne ilyet. A választ gyorsítótárazná, és nem kérdezne újra, amíg a válaszban szereplő rekordok élettartama le nem telik.
Vixie és Schryver egy okos mechanizmust dolgozott ki, a Response Rate Limiting (RRL) nevű rendszert, amely lehetővé teszi a hiteles névkiszolgáló számára, hogy nyomon kövesse, milyen gyakran küldte ugyanazt a választ ugyanannak a lekérdezőnek. Ha ez az arány meghalad egy beállítható küszöbértéket, a névkiszolgáló egy meghatározott időtartamra leállítja az adott válasz küldését a lekérdezőnek. Ha a lekérdező többé nem küldi ugyanazt a kérdést a tekintélyes névkiszolgálónak, a tekintélyes névkiszolgáló abbahagyja a válasz elnyomását. A végeredmény az, hogy a hiteles névkiszolgáló soha nem fog a küszöbértéknél nagyobb arányú választ küldeni a lekérdezőnek, ami használhatatlanná teszi egy DDoS-támadásban.
Az RRL a 9.9.4-es verzióban került be a BIND névkiszolgálókba, és már néhány más névkiszolgáló implementáció is támogatja, köztük az NSD és a Knot. Ahogy az emberek frissítik névkiszolgálóikat újabb verziókra vagy az RRL-t támogató új implementációkra, ez fokozatosan megnehezíti a támadók számára a DNS-infrastruktúra erősítőként való használatát.
Remélem, ez a beszélgetés segített megérteni, hogy a DNS-infrastruktúrát hogyan veszik célba és hogyan használják ki a DDoS-támadások során, és hogyan tud a legjobban ellenállni a DDoS-támadásoknak, és hogyan tudja biztosítani, hogy névkiszolgálói ne vegyenek részt egy ilyen támadásban.
Az Új Technikai Fórum lehetőséget biztosít a feltörekvő vállalati technológiák felfedezésére és megvitatására, méghozzá soha nem látott mélységben és szélességben. A válogatás szubjektív, azon technológiák kiválasztása alapján, amelyeket fontosnak és az InfoWorld olvasói számára legérdekesebbnek tartunk. Az InfoWorld nem fogad el marketingszövegeket publikálásra, és fenntartja a jogot, hogy minden közreműködő tartalmat szerkesszen. Minden megkeresést a [email protected].
Ez a cikk, “The ultimate guide to preventing DNS-based DDoS attacks,” eredetileg az InfoWorld.com-on jelent meg. A legfrissebb üzleti technológiai hírekért kövesse az InfoWorld.com-ot a Twitteren.