Variti vyvíja ochranu proti botom a útokom DDoS a tiež vykonáva záťažové a záťažové testy. Na konferencii HighLoad++ 2018 sme hovorili o tom, ako zabezpečiť zdroje pred rôznymi typmi útokov. Stručne povedané: izolujte časti systému, používajte cloudové služby a CDN a pravidelne aktualizujte. Bez špecializovaných firiem si ale ochranu aj tak neporadíte :)
Pred čítaním textu si môžete prečítať krátke abstrakty .
A ak vás nebaví čítať alebo si len chcete pozrieť video, záznam našej reportáže nájdete nižšie pod spojlerom.
Video záznam reportáže
Mnohé spoločnosti už vedia robiť záťažové testy, no nie všetky robia záťažové testy. Niektorí naši zákazníci si myslia, že ich stránka je nezraniteľná, pretože majú systém s vysokou záťažou a dobre chráni pred útokmi. Ukazujeme, že to nie je celkom pravda.
Samozrejme, pred vykonaním testov získame od zákazníka povolenie, podpísané a opečiatkované a s našou pomocou nie je možné na nikoho vykonať DDoS útok. Testovanie sa vykonáva v čase zvolenom zákazníkom, keď je návštevnosť jeho zdroja minimálna a problémy s prístupom neovplyvnia klientov. Navyše, keďže sa počas testovacieho procesu môže vždy niečo pokaziť, sme v neustálom kontakte so zákazníkom. To vám umožňuje nielen hlásiť dosiahnuté výsledky, ale aj niečo zmeniť počas testovania. Po ukončení testovania vždy vypracujeme správu, v ktorej poukážeme na zistené nedostatky a dáme odporúčania na odstránenie slabých stránok stránky.
Ako pracujeme
Pri testovaní napodobňujeme botnet. Keďže pracujeme s klientmi, ktorí sa nenachádzajú v našich sieťach, aby sme zabezpečili, že test neskončí hneď v prvej minúte z dôvodu spustenia limitov alebo ochrany, dodávame záťaž nie z jednej IP, ale z vlastnej podsiete. Navyše, aby sme vytvorili značnú záťaž, máme vlastný pomerne výkonný testovací server.
Postuláty
Príliš veľa neznamená dobre
Čím menšie zaťaženie dokážeme priviesť zdroj k zlyhaniu, tým lepšie. Ak dokážete, že stránka prestane fungovať pri jednej žiadosti za sekundu alebo dokonca pri jednej žiadosti za minútu, je to skvelé. Pretože podľa zákona podlosti používatelia alebo útočníci náhodou spadnú do tejto konkrétnej zraniteľnosti.
Čiastočné zlyhanie je lepšie ako úplné zlyhanie
Vždy odporúčame, aby boli systémy heterogénne. Okrem toho stojí za to ich oddeliť na fyzickej úrovni, nielen kontajnerizáciou. V prípade fyzického oddelenia, aj keď na stránke niečo zlyhá, je veľká pravdepodobnosť, že neprestane fungovať úplne a používatelia budú mať naďalej prístup aspoň k časti funkcionality.
Dobrá architektúra je základom udržateľnosti
Odolnosť zdroja voči chybám a jeho schopnosť odolávať útokom a zaťaženiam by mala byť stanovená vo fáze návrhu, v skutočnosti vo fáze kreslenia prvých vývojových diagramov v poznámkovom bloku. Pretože ak sa vkradnú fatálne chyby, je možné ich v budúcnosti opraviť, ale je to veľmi ťažké.
Nielen kód by mal byť dobrý, ale aj konfigurácia
Mnoho ľudí si myslí, že dobrý vývojový tím je zárukou bezchybnej služby. Dobrý vývojársky tím je naozaj potrebný, ale musia existovať aj dobré operácie, dobré DevOps. To znamená, že potrebujeme špecialistov, ktorí správne nakonfigurujú Linux a sieť, správne napíšu konfigurácie v nginx, nastavia limity atď. V opačnom prípade bude zdroj fungovať dobre iba pri testovaní a v určitom okamihu sa všetko preruší vo výrobe.
Rozdiely medzi záťažovým a záťažovým testovaním
Záťažové testovanie vám umožňuje identifikovať limity fungovania systému. Záťažové testovanie je zamerané na nájdenie slabín v systéme a používa sa na prelomenie tohto systému a zistenie, ako sa bude správať v procese zlyhania určitých častí. V tomto prípade zostáva povaha zaťaženia zvyčajne neznáma zákazníkovi pred začatím záťažového testovania.
Charakteristické črty útokov L7
Typy záťaže zvyčajne delíme na záťaže na úrovni L7 a L3&4. L7 je záťaž na aplikačnej úrovni, najčastejšie to znamená len HTTP, ale máme na mysli akúkoľvek záťaž na úrovni TCP protokolu.
Útoky L7 majú určité charakteristické črty. Po prvé, prichádzajú priamo do aplikácie, to znamená, že je nepravdepodobné, že sa prejavia prostredníctvom sieťových prostriedkov. Takéto útoky využívajú logiku a vďaka tomu spotrebúvajú CPU, pamäť, disk, databázu a ďalšie zdroje veľmi efektívne a s malou prevádzkou.
HTTP Flood
V prípade akéhokoľvek útoku sa záťaž ľahšie vytvára ako manipuluje a v prípade L7 to platí tiež. Nie je vždy ľahké rozlíšiť útočnú prevádzku od legitímnej prevádzky a najčastejšie sa to dá urobiť podľa frekvencie, ale ak je všetko naplánované správne, potom nie je možné z protokolov pochopiť, kde je útok a kde sú legitímne požiadavky.
Ako prvý príklad zvážte útok HTTP Flood. Graf ukazuje, že takéto útoky sú zvyčajne veľmi silné, v príklade nižšie maximálny počet požiadaviek prekročil 600 tisíc za minútu.
HTTP Flood je najjednoduchší spôsob vytvorenia záťaže. Zvyčajne to vyžaduje nejaký nástroj na testovanie záťaže, ako napríklad ApacheBench, a nastaví požiadavku a cieľ. Pri takomto jednoduchom prístupe je vysoká pravdepodobnosť, že narazíte na ukladanie do vyrovnávacej pamäte servera, ale je ľahké ho obísť. Napríklad pridanie náhodných reťazcov do požiadavky, ktoré prinúti server neustále obsluhovať novú stránku.
V procese vytvárania záťaže tiež nezabudnite na používateľského agenta. Mnoho používateľských agentov populárnych testovacích nástrojov je filtrovaných správcami systému a v tomto prípade sa zaťaženie jednoducho nedostane do backendu. Výsledok môžete výrazne zlepšiť vložením viac či menej platnej hlavičky z prehliadača do požiadavky.
Akokoľvek sú útoky HTTP Flood jednoduché, majú aj svoje nevýhody. Po prvé, na vytvorenie záťaže je potrebné veľké množstvo energie. Po druhé, takéto útoky sa dajú veľmi ľahko odhaliť, najmä ak pochádzajú z jednej adresy. V dôsledku toho sa požiadavky okamžite začnú filtrovať buď správcami systému, alebo dokonca na úrovni poskytovateľa.
Čo hľadať
Ak chcete znížiť počet žiadostí za sekundu bez straty efektívnosti, musíte ukázať trochu fantázie a preskúmať stránku. Môžete tak načítať nielen kanál alebo server, ale aj jednotlivé časti aplikácie, napríklad databázy alebo súborové systémy. Môžete tiež hľadať miesta na webe, ktoré robia veľké výpočty: kalkulačky, stránky s výberom produktov atď. Nakoniec sa často stáva, že stránka má nejaký PHP skript, ktorý vygeneruje stránku s niekoľkými stovkami tisíc riadkov. Takýto skript tiež výrazne zaťažuje server a môže sa stať cieľom útoku.
Kde hľadať
Keď skenujeme zdroj pred testovaním, najprv sa samozrejme pozrieme na samotný web. Hľadáme všetky druhy vstupných polí, ťažké súbory - vo všeobecnosti všetko, čo môže zdroju spôsobiť problémy a spomaliť jeho prevádzku. Tu pomáhajú banálne vývojové nástroje v prehliadačoch Google Chrome a Firefox, ktoré zobrazujú časy odozvy stránky.
Skenujeme aj subdomény. Existuje napríklad istý internetový obchod abc.com, ktorý má subdoménu admin.abc.com. S najväčšou pravdepodobnosťou ide o administrátorský panel s autorizáciou, ale ak ho zaťažíte, môže to spôsobiť problémy pre hlavný zdroj.
Stránka môže mať subdoménu api.abc.com. S najväčšou pravdepodobnosťou ide o zdroj pre mobilné aplikácie. Aplikáciu nájdete v App Store alebo Google Play, nainštalujte si špeciálny prístupový bod, rozoberte API a zaregistrujte testovacie účty. Problém je v tom, že ľudia si často myslia, že všetko, čo je chránené autorizáciou, je imúnne voči útokom odmietnutia služby. Vraj autorizácia je najlepšia CAPTCHA, ale nie je. Je ľahké vytvoriť 10 až 20 testovacích účtov, ale ich vytvorením získame prístup ku komplexným a neskrývaným funkciám.
Prirodzene, pozeráme sa do histórie, na robots.txt a WebArchive, ViewDNS a hľadáme staré verzie zdroja. Niekedy sa stáva, že vývojári spustili povedzme mail2.yandex.net, ale stará verzia mail.yandex.net zostáva. Tento mail.yandex.net už nie je podporovaný, nie sú mu pridelené prostriedky na vývoj, ale naďalej spotrebúva databázu. V súlade s tým môžete pomocou starej verzie efektívne využívať zdroje backendu a všetko, čo je za rozložením. Samozrejme, nie vždy sa to stáva, ale stále sa s tým stretávame pomerne často.
Prirodzene, analyzujeme všetky parametre požiadavky a štruktúru súborov cookie. Môžete, povedzme, uložiť určitú hodnotu do poľa JSON v súbore cookie, vytvoriť veľa vnorení a zabezpečiť, aby zdroj fungoval neprimerane dlho.
Zaťaženie vyhľadávania
Prvá vec, ktorá vás napadne pri prieskume stránky, je načítanie databázy, keďže vyhľadávanie má takmer každý a takmer pre každého je, žiaľ, slabo chránená. Z nejakého dôvodu vývojári nevenujú dostatočnú pozornosť vyhľadávaniu. Ale je tu jedno odporúčanie – nemali by ste robiť požiadavky rovnakého typu, pretože sa môžete stretnúť s cachovaním, ako je to v prípade HTTP záplavy.
Zadávanie náhodných dotazov do databázy tiež nie je vždy efektívne. Je oveľa lepšie vytvoriť zoznam kľúčových slov, ktoré sú relevantné pre vyhľadávanie. Ak sa vrátime k príkladu internetového obchodu: povedzme, že stránka predáva pneumatiky pre autá a umožňuje vám nastaviť polomer pneumatík, typ auta a ďalšie parametre. V súlade s tým kombinácie relevantných slov prinútia databázu pracovať v oveľa zložitejších podmienkach.
Okrem toho sa oplatí použiť stránkovanie: pre vyhľadávanie je oveľa ťažšie vrátiť predposlednú stránku výsledkov vyhľadávania ako prvú. To znamená, že pomocou stránkovania môžete mierne diverzifikovať zaťaženie.
Príklad nižšie zobrazuje zaťaženie vyhľadávania. Je vidieť, že od prvej sekundy testu pri rýchlosti desiatich požiadaviek za sekundu stránka spadla a nereagovala.
Ak sa nehľadá?
Ak sa nevyhľadá, neznamená to, že stránka neobsahuje ďalšie zraniteľné vstupné polia. Toto pole môže predstavovať autorizáciu. V súčasnosti vývojári radi vytvárajú komplexné hashe na ochranu prihlasovacej databázy pred útokom na dúhovú tabuľku. To je dobré, ale takéto hash spotrebuje veľa zdrojov CPU. Veľký tok falošných autorizácií vedie k zlyhaniu procesora a v dôsledku toho stránka prestane fungovať.
Prítomnosť všetkých druhov formulárov na pripomienky a spätnú väzbu na stránke je dôvodom na posielanie veľmi veľkých textov alebo jednoducho na vytvorenie masívnej záplavy. Stránky niekedy akceptujú priložené súbory vrátane súborov vo formáte gzip. V tomto prípade vezmeme 1 TB súbor, skomprimujeme ho na niekoľko bajtov alebo kilobajtov pomocou gzip a odošleme na stránku. Potom sa rozopne a získa sa veľmi zaujímavý efekt.
Rest API
Chcel by som venovať malú pozornosť takým populárnym službám, ako je Rest API. Zabezpečenie Rest API je oveľa náročnejšie ako bežné webové stránky. Pre Rest API nefungujú ani triviálne metódy ochrany pred heslom hrubou silou a inou nelegitímnou činnosťou.
Rest API je veľmi jednoduché prelomiť, pretože pristupuje priamo k databáze. Zlyhanie takejto služby má zároveň dosť vážne dôsledky pre podnikanie. Faktom je, že Rest API sa zvyčajne používa nielen pre hlavnú webovú stránku, ale aj pre mobilnú aplikáciu a niektoré interné obchodné zdroje. A ak toto všetko padne, potom je efekt oveľa silnejší ako v prípade obyčajného zlyhania webovej stránky.
Načítava sa ťažký obsah
Ak nám ponúknu otestovať nejakú obyčajnú jednostránkovú aplikáciu, vstupnú stránku alebo webovú stránku s vizitkou, ktorá nemá zložitú funkčnosť, hľadáme ťažký obsah. Napríklad veľké obrázky, ktoré server posiela, binárne súbory, pdf dokumentáciu – to všetko sa snažíme stiahnuť. Takéto testy dobre zaťažujú súborový systém a upchávajú kanály, a preto sú efektívne. To znamená, že aj keď server neodložíte a stiahnete veľký súbor nízkou rýchlosťou, jednoducho upcháte kanál cieľového servera a potom dôjde k odmietnutiu služby.
Príklad takéhoto testu ukazuje, že pri rýchlosti 30 RPS stránka prestala reagovať alebo vyprodukovala 500. chybu servera.
Nezabudnite na nastavenie serverov. Často sa môžete stretnúť s tým, že si človek kúpil virtuálny stroj, nainštaloval tam Apache, všetko predvolene nakonfiguroval, nainštaloval PHP aplikáciu a nižšie vidíte výsledok.
Tu sa zaťaženie dostalo na koreň a predstavovalo iba 10 RPS. Čakali sme 5 minút a server sa zrútil. Je pravda, že nie je úplne známe, prečo spadol, ale existuje predpoklad, že mal jednoducho príliš veľa pamäte, a preto prestal reagovať.
Na základe vlny
Za posledný rok-dva sa útoky vĺn stali pomerne populárnymi. Dôvodom je skutočnosť, že mnohé organizácie nakupujú určité časti hardvéru na ochranu DDoS, ktoré si vyžadujú určitý čas na zhromaždenie štatistík, aby mohli začať filtrovať útok. To znamená, že nefiltrujú útok v prvých 30-40 sekundách, pretože hromadia dáta a učia sa. Preto za týchto 30-40 sekúnd môžete na webe spustiť toľko, že zdroj bude dlho ležať, kým sa nevyčistia všetky požiadavky.
V prípade nižšie uvedeného útoku bol interval 10 minút, po ktorom prišla nová, upravená časť útoku.
To znamená, že obrana sa naučila, začala filtrovať, no prišla nová, úplne iná porcia útoku a obrana sa začala opäť učiť. V skutočnosti filtrovanie prestane fungovať, ochrana sa stane neúčinnou a stránka je nedostupná.
Vlnové útoky sa vyznačujú veľmi vysokými hodnotami na vrchole, v prípade L7 môžu dosiahnuť stotisíc alebo milión požiadaviek za sekundu. Ak hovoríme o L3 a 4, potom to môže byť stovky gigabitov prevádzky, alebo teda stovky mpps, ak počítate v paketoch.
Problémom takýchto útokov je synchronizácia. Útoky pochádzajú z botnetu a vyžadujú vysoký stupeň synchronizácie, aby sa vytvoril veľmi veľký jednorazový nárast. A táto koordinácia nie vždy funguje: niekedy je výstupom nejaký parabolický vrchol, ktorý vyzerá dosť žalostne.
Nie samotný HTTP
Okrem HTTP na L7 radi využívame aj iné protokoly. Bežná webová stránka, najmä bežný hosting, má spravidla poštové protokoly a MySQL. Poštové protokoly podliehajú menšej záťaži ako databázy, ale môžu sa tiež načítať pomerne efektívne a skončiť s preťažením CPU na serveri.
Celkom úspešne sme použili zraniteľnosť SSH z roku 2016. Teraz bola táto zraniteľnosť opravená takmer pre každého, ale to neznamená, že zaťaženie nemôže byť odoslané do SSH. Môcť. Existuje jednoducho obrovské zaťaženie autorizácií, SSH zaberá takmer celý procesor na serveri a potom sa web zrúti z jednej alebo dvoch požiadaviek za sekundu. Preto sa tieto jedna alebo dve požiadavky založené na protokoloch nedajú odlíšiť od legitímneho zaťaženia.
Mnohé pripojenia, ktoré otvárame na serveroch, tiež zostávajú relevantné. Predtým bol za to vinný Apache, teraz je za to nginx skutočne vinný, pretože je často predvolene nakonfigurovaný. Počet pripojení, ktoré môže nginx ponechať otvorené, je obmedzený, takže otvárame tento počet pripojení, nginx už neprijíma nové pripojenie a v dôsledku toho stránka nefunguje.
Náš testovací klaster má dostatok CPU na napadnutie SSL handshake. V zásade, ako ukazuje prax, botnety to niekedy radi robia. Na jednej strane je jasné, že bez SSL sa nezaobídete, pretože výsledky Google, hodnotenie, bezpečnosť. Na druhej strane, SSL má bohužiaľ problém s CPU.
L3&4
Keď hovoríme o útoku na úrovni L3&4, zvyčajne hovoríme o útoku na úrovni odkazu. Takáto záťaž je takmer vždy odlíšiteľná od legitímnej, pokiaľ nejde o SYN-flood útok. Problémom SYN-flood útokov na bezpečnostné nástroje je ich veľký objem. Maximálna hodnota L3&4 bola 1,5-2 Tbit/s. Tento druh prevádzky je veľmi náročný na spracovanie aj pre veľké spoločnosti vrátane Oracle a Google.
SYN a SYN-ACK sú pakety, ktoré sa používajú pri nadväzovaní spojenia. Preto je ťažké odlíšiť SYN-flood od legitímneho zaťaženia: nie je jasné, či ide o SYN, ktorý prišiel nadviazať spojenie, alebo je to súčasť záplavy.
UDP-potopa
Útočníci zvyčajne nemajú schopnosti, ktoré máme my, takže na organizáciu útokov možno použiť zosilnenie. To znamená, že útočník prehľadá internet a nájde buď zraniteľné alebo nesprávne nakonfigurované servery, ktoré napríklad v reakcii na jeden SYN paket odpovedajú tromi SYN-ACK. Spoofingom zdrojovej adresy z adresy cieľového servera je možné zvýšiť výkon povedzme trikrát s jedným paketom a presmerovať prevádzku na obeť.
Problém amplifikácií je, že je ťažké ich odhaliť. Medzi nedávne príklady patrí senzačný prípad zraniteľného memcached. Navyše teraz existuje veľa IoT zariadení, IP kamier, ktoré sú tiež väčšinou predvolene nakonfigurované a štandardne sú nakonfigurované nesprávne, a preto útočníci najčastejšie útočia cez takéto zariadenia.
Ťažká SYN-povodeň
SYN-flood je z pohľadu vývojára asi najzaujímavejší typ útoku. Problém je, že správcovia systému často používajú na ochranu blokovanie IP. Blokovanie IP navyše ovplyvňuje nielen správcov systému, ktorí konajú pomocou skriptov, ale bohužiaľ aj niektoré bezpečnostné systémy, ktoré sa kupujú za veľa peňazí.
Táto metóda sa môže zmeniť na katastrofu, pretože ak útočníci nahradia IP adresy, spoločnosť zablokuje vlastnú podsieť. Keď brána firewall zablokuje svoj vlastný klaster, výstup zlyhá vo vonkajších interakciách a zdroj zlyhá.
Navyše nie je ťažké zablokovať vlastnú sieť. Ak má kancelária klienta Wi-Fi sieť, alebo ak je výkon zdrojov meraný pomocou rôznych monitorovacích systémov, tak zoberieme IP adresu tohto monitorovacieho systému alebo Wi-Fi v kancelárii klienta a použijeme ju ako zdroj. Nakoniec sa zdá, že zdroj je dostupný, ale cieľové adresy IP sú zablokované. Môže tak dôjsť k zablokovaniu Wi-Fi siete konferencie HighLoad, na ktorej sa prezentuje nový produkt spoločnosti, čo so sebou prináša určité obchodné a ekonomické náklady.
Počas testovania nemôžeme použiť zosilnenie cez memcached so žiadnymi externými zdrojmi, pretože existujú dohody o odosielaní prevádzky iba na povolené adresy IP. Podľa toho využívame zosilnenie cez SYN a SYN-ACK, kedy systém na odoslanie jedného SYN odpovedá dvoma alebo troma SYN-ACK a na výstupe sa útok znásobí dvakrát alebo trikrát.
Nástroje
Jedným z hlavných nástrojov, ktoré používame na pracovné zaťaženie L7, je Yandex-tank. Ako zbraň sa používa najmä fantóm a navyše existuje niekoľko skriptov na generovanie kaziet a na analýzu výsledkov.
Tcpdump sa používa na analýzu sieťovej prevádzky a Nmap sa používa na analýzu servera. Na vytvorenie záťaže na úrovni L3&4 sa používa OpenSSL a trochu našej vlastnej mágie s knižnicou DPDK. DPDK je knižnica od spoločnosti Intel, ktorá vám umožňuje pracovať so sieťovým rozhraním, ktoré obchádza linuxový zásobník, čím zvyšuje efektivitu. Prirodzene, DPDK používame nielen na úrovni L3&4, ale aj na úrovni L7, pretože nám umožňuje vytvoriť veľmi vysoký tok zaťaženia v rozsahu niekoľkých miliónov požiadaviek za sekundu z jedného stroja.
Používame tiež určité generátory návštevnosti a špeciálne nástroje, ktoré píšeme pre špecifické testy. Ak si spomenieme na zraniteľnosť pod SSH, tak vyššie uvedený súbor nie je možné zneužiť. Ak zaútočíme na poštový protokol, vezmeme si poštové pomôcky alebo na ne jednoducho napíšeme skripty.
Závery
Na záver by som chcel povedať:
- Okrem klasického záťažového testovania je potrebné vykonať záťažové testovanie. Máme reálny príklad, keď subdodávateľ partnera vykonával iba záťažové testy. Ukázalo sa, že zdroj vydrží bežné zaťaženie. Potom sa však objavilo abnormálne zaťaženie, návštevníci stránok začali používať zdroj trochu inak a v dôsledku toho subdodávateľ ľahol. Preto sa oplatí hľadať zraniteľné miesta, aj keď ste už chránení pred DDoS útokmi.
- Je potrebné izolovať niektoré časti systému od ostatných. Ak máte vyhľadávanie, musíte ho presunúť do samostatných strojov, teda ani do Dockera. Pretože ak zlyhá vyhľadávanie alebo autorizácia, aspoň niečo bude fungovať ďalej. V prípade internetového obchodu budú používatelia naďalej hľadať produkty v katalógu, prechádzať z agregátora, nakupovať, ak už majú autorizáciu, alebo autorizovať cez OAuth2.
- Nezanedbávajte všetky druhy cloudových služieb.
- CDN používajte nielen na optimalizáciu oneskorení siete, ale aj ako prostriedok ochrany pred útokmi na vyčerpanie kanála a jednoduché zaplavenie statickej prevádzky.
- Je potrebné využívať špecializované ochranné služby. Nemôžete sa chrániť pred útokmi L3 a 4 na úrovni kanála, pretože s najväčšou pravdepodobnosťou jednoducho nemáte dostatočný kanál. Je tiež nepravdepodobné, že budete bojovať proti útokom L7, pretože môžu byť veľmi veľké. Navyše, hľadanie malých útokov je stále výsadou špeciálnych služieb, špeciálnych algoritmov.
- Pravidelne aktualizujte. To platí nielen pre jadro, ale aj pre SSH démona, najmä ak ich máte otvorené von. V zásade je potrebné aktualizovať všetko, pretože je nepravdepodobné, že by ste sami mohli sledovať určité zraniteľnosti.
Zdroj: hab.com