DoS/DDoS - uvaha

DoS/DDoS – uvaha

UPOZORNENIE: Autor nasledujuceho textu je dislektik a za vsetky gramaticke chyby sa vopred ospravedlnuje. Ak niekto z radov PU na blackhole.sk opravi gramaticke chyby v tomto clanku, zaplatim mu tolko piv, kolko dokaze vypit. Clanok je pisany v style Request for Comments. Komenty rad prijmem pod tymto clankom. Ak nie ste clenom posadky blackhole.sk, poslite ich prosim na adresu catcher@hysteria.sk a subject nastavte na DDDoSuvaha. Dakujem.

Pojmy:

DoS – Denial of Service – utok, ktory spociva v zahlteni cieloveho stroja falosnymi poziadavkami na sluzbu, ktoru cielovy stroj standardne poskytuje vsetkym klientom v sieti. Vysledkom utoku je neschopnost cieloveho stroja obsluzit legitimne poziadavky legitimnich klientov, pretoze je zahlteny a zamestnany obsluhovanim falosnych poziadaviek utocnika.

DDoS – Distributed Denial of Service – utok Dos je uspesny len v tom pripade, ked pocet falosnych poziadaviek, ktore dokaze utociaci stroj poslat za jednu sekundu na cielovy stroj je vyssi, nez pocet poziadaviek, ktore dokaze cielovy stroj plnohodnotne obsluzit za sekundu. Uspesnost utoku sa teda moze zvysit, ak na ciel posiela falosne poziadavky niekolko utociacich strojov s nezavislym HW a nezavislym prenosovym pasmom. To je utok DDoS. V praxi sa pocet utociacich strojov pohybuje v radovo stoviek az tisicov. Tieto utociace stroje su spravidla pripojene do jedneho botnetu a utok je teda distribuovany a decentralizovany, ale centralne ovladany a koordinovany.

BotNet – siet nezavislych strojov topologicky a geograficky decentralizovanych. Kazdy stroj poskytuje podstatnu cast svojho vypoctoveho vykonu a prenosoveho pasma smerom do siete, ktore ma k dispozicii. Drviva vacsina DDoS utokov v blizkej minulosti bola vedena zo siestich znamych botnetov. Dosledky kazdeho z nich boli viac, ci menej katastrofalne.

Ako sa chranit?

Za momentalnych podmienok, ktore v sieti Internet prevladaju, je odpoved jednoducha – nijako. Tato uvaha ma vsak za ulohu vysvetlit priciny absencie sposobov plnej ochrany pred touto pliagou, niciacou hodnoty vybodovane a starostlivo udrziavane na sieti Internet. Dalsim poslanim tejto uvahy je navrhnut riesenie na baze “zdravej vyzivy a prevencie” namiesto “liekov proti bolesti”.

Neuspesni kandidati na sposob ochrany pred DoS/DDoS

Prvym sposobom ochrany bol samotny fakt, ze stroj poskytujuci sluzby, ktore su citlive na utok typu DoS, mal k dispozicii omnoho vacsi vypoctovy vykon a prenosove pasmo, ktore mal k dispozicii na prijimanie poziadaviek a odosielanie odpovedi, bolo omnoho sirsie, ako pasmo na posielanie poziadavkov, ktore mal k dispozicii hociktory zo strojov, v ulohe klienta, na tej istej sieti. Trhliny v tomto rieseni su zjavne hned na druhy ci treti pohlad. Majitel hociktoreho stroja v ulohe klienta mohol svoj stroj upravit tak, aby mal k dispozicii vyssi vypoctovy vykon, ako stroj v ulohe poskytovatela sluzby (poznamka - vypoctovy vykon v tomto pripade nie je velmi dolezity. Na posielanie jedneho falosneho requestu od falosneho klienta totiz je potrebny mensi vypoctovy vykon, ako na jeho obsluzenie na strane servera). Majitel tohoto stroja tiez mohol od poskytovatela pripojenia do siete ziskat sirsie prenosove pasmo na odosielanie falosnych poziadaviek. Sirka tohoto pasma mohla dokonca prevysit sirku prenosoveho pasma na prijimanie poziadavkov na strane posklytovatela sluzby (budeme mu dalej vraviet ‘server’ alebo ‘ciel’). Netreba sa cudovat, toto riesenie totiz nebolo navrhovane ako ochrana pred DoS/DDoS, ale ako riesenie na obsluzenie nadmerneho poctu legitimnych poziadavkov v case spickoveho vyuzivania sluzieb ciela legitimnymi uzivatelmi klientskych strojov v sieti. Myslim, ze ani netreba prilis pripominat, ako bolo toto riesenie strhnute zo svojich, uz aj tak vratkych noziciek, samotnou charakteristikou utokov typu DDoS.

Dalsim riesenim bola uprava riesenia pre iny problem – packet filtering. Hovori sa tomu tiez firewall. Samotny packet filtering neposkytuje ziadnu ochranu pred utokmi DoS a DDoS. Packet filtering totiz funguje na baze analyzy packetov a nasledneho ukonu na packete hned po jeho prijati kernelom. Packet filter porovnava vysledky analyzy prijateho packetu s pravidlami, ktore su prednastavene administratorom a vysledkom tohoto procesu je jeden z nasledujucich ukonov:

Accept – packet bude posunuty do bufferu socketu, ktory bol vytvoreny funkciou socket alebo socketpair v beziacom procese, ktory bol predtym funkciou bind spriahnuty s portom, ktory figuruje v hlavicke predmetneho packetu. Packet je potom obsluzeny samotnou aplikaciou standardne.

Reject – packet nebude posunuty do vyssie spominaneho bufferu, ale bude zniceny a jeho odosielatelovi sa odosle nejaka forma spravy o tom, ze jeho packet nebol prijaty cielovou aplikaciou/sluzbou na cielovom stroji.

Drop – packet nebude posunuty do vyssie spominaneho buffer-a, ale bude zniceny a jeho odosielatelovi nebude zaslana ziadna sprava

Priklad:

Programom ping posleme niekolko ICMP packetov zo stroja A na stroj B. Ak je packet filter na stroji B nastaveny tak, ze packety ICMP splnaju podmienky pre ukon accept, packet bude prijaty strojom B a nalezite spracovany. Stroj B potom posle stroju A iny packet s vysledkom spracovania a my mozeme vidiet, ze stroj B je funkcny a za aky dlhy cas sme prijali odpoved na nas packet. Ak je packet filter na stroji B nastaveny tak, ze packety ICMP splnaju podmienky pre ukon reject, stroj B packet nespracuje, ale ho znici a posle stroju A spravu “destination host unreachable” (packet filter moze totiz bezat na inom stroji po ceste). Ak sa jedna o ukon drop, stroj B (alebo packet filter beziaci na inom stroji medzi A a B) packet znici a neposle o tom ziadnu spravu na stroj A. My potom chvilu nevidime nic a potom nam program ping nejakym sposobom oznami, ze nedostal ziadnu odpoved (ping timeout).

V tomto bode uvahy si musime uvedomit, ze falosne poziadavky odosielane z utociaceho na cielovy stroj, zasadne splnaju podmienky pre ukon accept. Packet filter totiz nedokaze rozoznat falosnu poziadavku od legitimnej poziadavky. Riesenie vsak existuje – mozeme packet filter upravit/pridat mu funkcionalitu, ktora mu umozni analyzovat packety v sirsom kontexte. Nebude analyzovat jednotlive packety, ale skupiny packetov. DoS/DDoS packety sa totiz daju lahko odhalit. Spravidla prichadza na cielovy stroj velke mnozstvo rovnakych poziadaviek, z jednej alebo viacerych IP adries a sposob, akym prichadzaju, je nezlucitelny s realnym vyuzivanim danej sluzby. Takto teda vieme rozoznat falosne poziadavky od legitimnych. Teraz nam uz len staci do packet filtru implementovat system, ktory bude automaticky a dynamicky menit pravidla packet filtra na zaklade vysledkov analyzy nie jednotlivych packetov, ale velkych skupin packetov.

Priklad:

Vidime, ze na webserver nam za sekundu prislo 20 HTTP poziadaviek na jeden a ten isty html subor z jednej IP adresy, pricom samotne packety, ktore tieto poziadavky obsahuju, su identicke. To znamena, ze sa nejedna o legitimne poziadavky a z toho, ze packety su uplne rovnake vyplyva, ze sa nejedna ani o NAT stroj, ktory by mohol posielat poziadavky velkeho mnozstva klientov na jeho lokalnej sieti zo svojej externej IP adresy na cielovy stroj s beziacim httpd. Vzhladom k tymto vysledkom analyzy velkej skupiny packetov mozeme nastavit packet filtru nove pravidlo, ktore tieto packety neprepusti dalej. Tu este treba zdoraznit, ze v tomto pripade su z hladiska sietovej priepustnosti ukony Accept a Reject relativne rovnocenne, nakolko ukon reject posiela spravu naspat a tym obsadzuje prenosove pasmo urcene na prenasanie odpovedi na legitimne poziadavky legitimnych klientov. V tomto pripade teda musime packet filer nastavit tak, aby sa pri detekcii DoS/DDoS utoku vytvorilo nove pravidlo, na zaklade ktoreho budu predmetne packety, nesuce falosne poziadavky dropnute, cim sa usetri vypoctovy vykon spotrebovany packet filtrom na vygenerovanie spravy o neprijati packetu a sirka pasma, ktora by bola potrebna na odoslanie spravy o neprijati packetu.

Riesenie by sme teda mali, podme sa nan ale pozriet zblizka a hned zistime, ze v praxi je nedostatocne. Packet filter totiz potrebuje vypoctovy vykon na analyzu jadnotlivych packetov. Cim viac packetov prijme, tym viac vypoctoveho vykonu spotrebuje na ich analyzu. Dostatocne velky botnet teda moze byt schopny poslat na ciel take mnozstvo falosnych poziadaviek, ze packet filter nestihne packety, ktore tieto poziadavky nesu, zanalyzovat, pricom vsak pouzije cely vypoctovy vykon, ktory ma k dispozicii. V dosledku toho nebude mat sluzba, ktora na cieli primarne bezi, dostatok vypoctoveho vykonu na obsluzenie legitimnych poziadavkov a DoS/DDoS utok sa tym stane uspesnym. Profesionalne riesenia vsak nezdruzuju packet filter a sluzbu samotnu na jednom stroji. Vacsinou sa jedna o sustavu strojov, pricom packet filter bezi na nezavislom stroji pred strojom, na ktorom bezi primarna sluzba. Takato implementacia eliminuje problem spotrebovania celeho vypoctoveho vykonu packet filtrom a stroj, na ktorom bezi primarna sluzba, ma vzdy k dispozicii dostatok vykonu na obsluzenie legitimnych poziadaviek.

Na dalsi problem v tejto nekonecnej retazi problemov narazime, ak sa zamyslime nad packet filtrom, ktory bezi na nezavislom stroji. Ten ma k dispozicii urcity vypoctovy vykon, ktory pouziva podla momentalnej potreby na analyzu packetov a na vykonavanie ukonov, vyplyvajucich z analyzy (accept, reject, drop). Ak ale dostane take mnozstvo packetov, ze pri plnom zatazeni procesora stale nestiha analyzovat vsetky prichadzajuce packety, uschovava si tie, ktore prave nemozu byt analyzovane v bufferi, ktory sa schematicky nachadza medzi kernelom a analyzatorom. Tento buffer je zasadne typu FIFO a ma istu velkost (moznost tuto velkost dynamicky menit je irelevantna, nakolko ju nemozeme zvacsit na nekonecne mnozstvo bytov). Vezmime tiez v uvahu fakt, ze DoS/DDoS utok prebieha konstantne, pricom vsak buffer packet filtera je navrhnuty pre riesenie kratkodobych spickovych situacii velkeho zatazenia. Moze sa teda stat, ze tento buffer sa naplni a potom nastane jedna z nasledujucich moznosti:

Prva: buffer pretecie na vstupe a packety, ktore don dalej prudia sa stracaju. Cely system sa chova tak, ako keby packety neanalyzoval, ale na vsetky by pouzil ukon drop (to vsak len v pripade, ze vstup buffera je proti preteceniu nalezite osetreny a data sa naozaj stracaju namiesto toho, aby sa zapisovali do nealokovanych alebo inymi programmi alokovanych casti pamate, co by sposobilo ine, zrejme vacsie problemy z hladiska funkcnosti celeho systemu a okrem toho by to poskytlo priestor pre cielene zapisovanie pripravenych dat do nepatricnych casti pamate a nasledne zneuzitie systemu – to je ale ina tema, zvedavci nech si vygooglia clanok “Smashing the stack for fun and profit”). Z hladiska priepustnosti a dostupnosti sluzby je to nemyslitelne a preto zrejme nastane moznost

Druha: buffer pretecie na vystupe (co je vlastne dosledok spatnej vazby medzi vstupom buffera a vstupom analyzatora) a analyzator prestane packety analyzovat, ale vsetky podrobi jednemu zo svojich troch moznych ukonov (accept, reject, drop). Z hladiska zachovania trochu vyssie spominanej priepustnosti a dostupnosti sluzby to bude zrejme pravidlo allow, cim sa packet filter na kratku chvilu zmeni na obycajny kus kabla, ktory packety prenasa. Za tuto kratku chvilu sa uvolni skoro cely jeho vypoctovy vykon. Packet filter splachne (flush) svoj vstupny buffer, podla moznosti mu bude nejakym sposobom poslany signal 1 (sighup), cim svoju cinnost zahaji znovu s prazdnym bufferom a pracuje dalej. Treba dodat, ze sighup nemusi byt potrebny, nakolko sa usetril vypoctovy vykon potrebny na analyzu packetov a vsetky packety dostanu zelenu a pokracuju na stroj s primarnou sluzbou.

Pocas tejto kratkej chvile vsak stroj, na ktorom bezi primarna sluzba, dostane velke mnozstvo falosnych poziadaviek, spotrebuje cely svoj vypoctovy vykon na ich nezmyselne obsluzenie a pritom zaplni vsetky svoje buffre a DoS/DDoS utok je uspesny. Snad netreba pripominat fakt, ze perioda prichadzania falosnych packetov na vstup buffera packet filtera moze byt natolko kratka, ze tento proces resetu packet filtra a kratkodobeho zahltenia primarnej sluzby moze nastat aj niekolkokrat za sekundu a DoS/DDoS utok bude zase co? Bude zase uspesny. Kazdy zo siestich velkych botnetov fungujucich v dnesnej dobe na internete je tohoto schopny pri utoku na akykolvek system na internete okrem jedneho, o ktorom ale bude rec neskor.

Anycast

Dalsie riesenie sa vola anycast. Nenechajte sa zmylit wikipediou – anycast nema nic spolocne s broadcastom, multicastom a unicastom. Samotna myslienka je sice podobna, ale z hladiska siete sa nachadza na uplne inej urovni (a inej vrstve). Anycast je system triedenia packetov prichadzajucich na jeden system. Packety sa mozu delit geograficky, topologicky alebo na zaklade momentalneho stavu celeho systemu a jemu prislusnej siete. Cely trik spociva v tom (a teraz budeme anycast aplikovat na nas packet filter z predchadzajucej kapitoly), ze packety, ktore maju prichadzat na jeden stroj, sa podla geografickej polohy odosielatela, alebo podla jeho topologickej polohy, alebo podla momentalneho stavu (zataze) ciela a jemu prislusnej siete, smeruju na rozne stroje namiesto toho, aby smerovali na jeden stroj. Botnety su geograficky a topologicky decentralizovane, takze pouzitim anycastu sa dosiahne, ze packety smerujuce na jeden system, vlastne prichadzaju na rozne systemy, cim sa zataz celeho systemu rovnomerne rozlozi na viac strojov. Na tomto principe funguje sluzba DNS. Je to jedina sluzba, jediny funkcny system na Internete, ktory je imunny voci utokom DoS a DDoS v plnom rozsahu. Riesenim anycast a pouzitim protokolu BGP sa dosahuje stav, ked nie je mozne zahltit alebo pretazit ani jeden z korenovych DNS serverov Internetu. Podme sa ale pozriet, za aku cenu.

Preco je DNS nepriestrelna sluzba?

Pretoze sa do nej investovalo naozaj velmi, ale velmi vela milionov dolarov. Jednotlive korenove DNS servery su vlastne velke serverove farmy, z ktorych kazda stala obrovske financne prostriedky a stale poziera znacne prostriedky, potrebne na svoju bezproblemovu prevadzku. Cele toto riesenie je financovane vsetkymi pouzivatelmi siete Internet. Kazdy, kto pouziva Internet plati poplatky, z ktorych cast je priamo alebo nepriamo pouzita na chod sluzby DNS. Ako uz citatel asi pochopil, je nemozne anycast na baze protokolu BGP (alebo podobneho) implementovat na vsetky systemy Internetu – bolo by to proste prilis drahe. A okrem toho to aj tak neriesi cely problem, pretoze je mozne, ze poloha a IP adresa jednotlivych serverov, spolupracujucich na baze anycast, by sa dala zistit a utok DoS/DDoS by bol vedny priamo na jednotlive stroje, cim by sa dosiahla uspesnost DoS/DDoS utoku len v istej casti siete prislusneho systemu. Napriklad by google fingoval vsade, okrem Slovenska (toto by mohlo nastat aj z hladiska topologickeho, namiesto geografickeho).

K comu sme teda dosli?

Dokonala ochrana proti DoS/DDoS utoku existuje, ale nemozeme si ju dovolit, Existuje vsak ine riesenie, ktore je v podstate riesenim nepriamym. Ak nam totiz vadi, ze trava na travniku je prilis vysoka, mozeme ju par krat do roka pokosit, ale mozeme tiez zabetonovat cely travnik, cim problem uplne eliminujeme. Zakladnym prostriedkom existencie hrozby DoS/DDoS utokov je existencia botnetov. Botnety sa skladaju z domacich a kancelarskych PC s operacnym systemom od spolocnosti Microsoft (poznamka: vyhradzujem si pravo zmazat akykolvek komentar k tejto uvahe, ktory co i len naznakom spomenie moznost, ze chyba nie je v Microsofte - nemam totiz cas vysvetlovat, preco je to tak, ak tomu este niekto nerozumie, nech si precita ventylove clanky zo serie "How it's made" a "Why I hate Microsoft" uverejnene na blackhole.sk). Problem je v tom, ze na drvivej vacsine domacich a kancelarskych pocitacov je nainstalovany Windows, o ktory sa nikto poriadne nestara. Taketo pocitace su nakazene malwarom, ktory ich pripoji do botnetu a umozni ich zneuzitie na (nielen) DDoS utoky (poznamka: drviva vacsina spamu je odoslana z takto zneuzitych pocitacov.

Ako to vyriesit?

To je tazka otazka, ale mozno by pomohla osveta. Mozno by pomohlo, keby poskytovatelia pripojenia k Internetu pristupovali k svojej ulohe zodpovednejsie a okrem tvorby zisku, by sa zaoberali aj bezpecnostou. Mozno by pomohlo, keby spolocnost Microsoft pristupovala zodpovednejsie k vyvoju svojho operacneho systemu. Mozno by pomohlo, keby spolocnost Microsoft zamestnala par programatorov, ktori by ich nosny produkt profesionalne prekopali podla standardu POSIX. Windows je doteraz stale postaveny na standarde MULTICS a to sposobuje, ze sa cely system topi v komplexite a chyby sa vlecu a vlecu od 3.11 az do Longhornu... Spolocnost Apple prerobila svoj operacny system (od verzie X je to uz cisty POSIX) a pomohlo to (nie ze by pedtym mal MacOS problemy s virusmi) a MacOS sa stal lepsim systemom. Viete si predstavit, aky by bol svet krasny, keby Microsoft takto jedneho dna uviedol na svet operacny system dosledne zalozeny na standarde POSIX? Ja osobne by som mal kludnejsi spanok. Viete si predstavit svet bez virusov? Svet bez spamu? Svet bez hrozby DoS/DDoS Ja ano! Takyto svet by sa mi pacil!

To vsak nie je jednoduche. Mozno sa pamatate na tento clanok:

http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html

Napisal ho byvaly zamestnanec spolocnosti Microsoft a pojednava o sposobe vyvoja operacneho systemu Microsoft Vista. Ak si tento clanok cely precitate, pochopite, ze mozeme byt radi, ze operacne systemy od tejto spolocnosti vobec funguju tak, ako funguju. Sposob, akym su vyvijane, je totiz velmi zlozity a matuci. O rozdieloch medzi vyvojom opensource software a vyvojom komercnych aplikacii pojednava tiez legendarna kniha "The Cathedral and the Bazaar" od hackera Erica S Raymonda. Nechcem zboznovat opensource (poznamka: sam totiz zastavam nazor, ze Linux sa komercnym UNIXom este stale nedokaze vyrovnat (z hladiska bezpecnosti a stability) a stale uprednostnujem AIX a BSD pred Linuxom vsade, kde je to len mozne), ale prax naozaj ukazuje, ze open source funguje lepsie, ako "katedralny" vyvoj komercnych aplikacii, ktorych zmyslom, koniec koncov, je v prvom rade tvorba zisku a nie funkcnost a stabilita.

Casto sa stretavam s ludmi, ktori tvrdia, ze "Na linuxe mi nefunguje zvuk" alebo "neviem napalovat tak jednoduchym sposobom, ako vo Windows" alebo "Open Office este stale nie je dost dobry" a velmi ma znepokojuje, ze prehliadaju ovela dolezitejsie aspekty a to najma bezpecnost. Ano, Skodovka sa stale soferovala lahsie ako Lada, lebo bola lahsia o par stovak kg, ale co bolo bezpecnejsie? Co bolo silnejsie? Ktora z tychto dvoch automobiliek vyrabala auto s vykonom 80 konskych sil v sedemdesiatych rokoch? Bola do Skoda? Nie! Bola to Lada!

Momentalnu situaciu znacne vylepsuje snaha antivirovych a antimalwareovych spolocnosti, ktorych obchodnou prioritou je vyrabat kvalitny software - uzivatelia sa totiz riadia rebrickami, ktore su relativne neoklamatelne - toto vyplyva z antiviroveho a antimalwareoveho trhu, ktory je oproti trhu s OS velmi zdravy a prevlada v nom duch dravej konkurencie. Do boja proti hrozbe DoS/DDoS a tiez spamu by sa este mohli pripojit ISP a Microsoft. Svet by bol hned vonavejsi :>

10. marca 2008

Tomas Catcher Tudja

Opravy:

Na zaklade podnetu od pX som konecne pochopil co je FIFO a co je LIFO a co je buffer a co je heap (to je dost hanba, ze som to pochopil az teraz na stare kolena :>) Chyba v clanku je patricne opravena. Dakujem za comment a prosim dalsich citatelov, aby upozornili na dalsie chyby.