Spoločnosť Variti vyvíja ochranu pred botmi a DDoS útokmi, a tiež vykonáva stresové a záťažové testovanie. Na konferencii HighLoad++ 2018 sme sa venovali tomu, 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 sa aktualizujte. Bez špecializovaných firiem na ochranu sa však aj tak neobídete 🙂
Pred prečítaním textu sa môžete oboznámiť s krátkymi myšlienkami .
A ak nemáte radi čítanie alebo jednoducho chcete vidieť video, záznam našej prednášky je nižšie pod spoilerom.
Záznam prednášky
Mnohé firmy už vedia vykonávať záťažové testovania, ale nie všetky robia stresové testovania. Niektorí naši klienti si myslia, že ich stránka je odolná, pretože majú highload systém a ten dobre chráni pred útokmi. My však ukazujeme, že to nie je celkom pravda.
Samozrejme, pred vykonaním testov získavame povolenie od klienta, s podpisom a pečiatkou, a s našou pomocou nie je možné vykonať DDoS útok na nikoho. Testovanie sa uskutočňuje v čase, ktorý si zvolí klient, keď je návštevnosť jeho zdroja minimálna, aby problémy s prístupom neodrážali na zákazníkoch. Okrem toho, keďže počas testovania sa vždy môže niečo pokaziť, máme stály kontakt s klientom. To umožňuje nielen informovať o dosiahnutých výsledkoch, ale aj niečo meniť v priebehu testovania. Po ukončení testovania vždy vyhotovujeme správu, v ktorej uvádzame zistené nedostatky a dávame odporúčania na odstránenie slabých miest stránky.
Ako pracujeme
Pri vykonávaní testovania emulujeme botnet. Keďže pracujeme s klientmi, ktorí nie sú umiestnení v našich sieťach, aby test neskončil v prvej minúte z dôvodu spustenia limitov alebo ochrany, zaťažujeme systém nie z jednej IP adresy, ale z našej vlastnej podsiete. Navyše na vytvorenie značnej záťaže máme vlastný dostatočne výkonný testovací server.
Postuláty
Veľa — neznamená dobre
Čím menšia záťaž dokážeme nasadiť na zdroj, tým je to lepšie. Ak sa nám podarí dosiahnuť, že stránka prestane fungovať pri jednom požiadavku za sekundu alebo dokonca pri jednom požiadavku za minútu, je to vynikajúce. Pretože podľa zákona podlosti sa používatelia alebo útočníci náhodou dostanú práve na túto zraniteľnosť.
Čiastočný výpadok je lepší ako úplný
Vždy odporúčame, aby boli systémy heterogénne. A mali by sme ich oddeliť na fyzickej úrovni, a nie len containerizovaním. Pri fyzickom oddelení, aj keď niečo na stránke zlyhá, je veľmi pravdepodobné, že celá stránka neprestane fungovať a používatelia budú mať prístup aspoň k časti funkcií.
Správna architektúra je základom odolnosti
Odolnosť zdroja a jeho schopnosť vydržať útoky a záťaže by mali byť zakotvené už v etape projektovania, v skutočnosti v etape kreslenia prvých blokových schém do notesa. Pretože ak sa vyskytujú fatálne chyby, dajú sa opraviť, ale je to veľmi náročné.
Dobrý by mal byť nielen kód, ale aj konfigurácia
Mnohí si myslia, že dobrý vývojový tím je zárukou odolnosti služby. Dobrý vývojový tím je skutočne potrebný, ale potrebná je aj dobrá prevádzka, dobrý DevOps. To znamená, že sú potrební odborníci, ktorí správne nakonfigurujú Linux a sieť, správne napíšu konfigurácie v nginx, nastavia limity a iné. Inak bude zdroj dobre fungovať len v teste, ale v produkcii sa v určitom momente všetko pokazí.
Rozdiel medzi záťažovým a stresovým testovaním
Záťažové testovanie umožňuje určiť hranice fungovania systému. Stresové testovanie je zamerané na nájdenie slabých miest systému a používa sa na to, aby tento systém rozbil a pozrel sa, ako sa bude správať počas zlyhania rôznych častí. Pri tom je charakter záťaže zvyčajne neznámy pre zákazníka do začiatku stresového testovania.
Jasné znaky L7 útokov
Typy zaťaženia zvyčajne delíme na zaťaženia na úrovni L7 a L3&4. L7 je zaťaženie na úrovni aplikácie, častejšie ho chápeme len ako HTTP, my však rozumieme akékoľvek zaťaženie na úrovni protokolu TCP.
Útoky typu L7 majú určité charakteristické znaky. Po prvé, prichádzajú priamo do aplikácie, takže ich je ťažké odraziť sieťovými prostriedkami. Takéto útoky využívajú logiku, a tým veľmi efektívne spotrebujú CPU, pamäť, disk, databázu a ďalšie zdroje aj pri nízkom prenosovom zaťažení.
HTTP Flood
Pri akomkoľvek type útoku je jednoduchšie vytvoriť záťaž ako ju spracovať, a to platí aj pre L7. Prevádzku útoku nie je vždy ľahké odlíšiť od legitímnej, a najčastejšie je to možné urobiť na základe frekvencie. Ak je všetko dobre naplánované, nie je možné z logov zistiť, kde je útok a kde legitímne požiadavky.
Ako prvý príklad si vezmeme útok HTTP Flood. Z grafu je zrejmé, že takéto útoky bývajú veľmi silné, v uvedenom príklade maximálny počet požiadaviek prekročil 600 000 za minútu.
HTTP Flood je najjednoduchší spôsob, ako vytvoriť záťaž. Zvyčajne sa na to používa nejaký nástroj na záťažové testovanie, napríklad ApacheBench, a zadávajú sa požiadavka a cieľ. Pri takomto jednoduchom prístupe je veľká pravdepodobnosť, že narazíte na caching servera, ale je to ľahké obísť. Napríklad pridaním náhodných reťazcov do požiadavky, čo donúti server neustále posielať čerstvú stránku.
Taktiež netreba zabúdať na user-agent pri vytváraní záťaže. Veľa user-agentov populárnych testovacích nástrojov je filtrovaných systémovými administrátormi, a v takom prípade môže záťaž jednoducho nedoraziť do backendu. Výsledok sa môže významne zlepšiť, ak do požiadavky vložíte viac či menej platný záhlavný údaj z prehliadača.
Napriek svojej jednoduchosti majú útoky HTTP Flood aj svoje nevýhody. Po prvé, na vytvorenie záťaže sú potrebné veľké výpočtové kapacity. Po druhé, takéto útoky sú veľmi ľahko detekovateľné, najmä ak prichádzajú z jednej adresy. V dôsledku toho sú požiadavky hneď začaté filtrovať buď systémovými administrátormi, alebo dokonca na úrovni poskytovateľa.
Na čo sa zamerať
Aby ste znížili počet požiadaviek za sekundu a pritom nestratili na efektívnosti, potrebujete trochu fantázie a preskúmať web. Môžete zaťažovať nielen kanál alebo server, ale aj jednotlivé časti aplikácie, ako sú databázy alebo súborové systémy. Môžete tiež hľadať miesta na webe, ktoré vykonávajú veľké výpočty: kalkulačky, stránky s výberom produktov a podobne. Nakoniec, často sa stáva, že na stránke je nejaký php skript, ktorý generuje stránku z niekoľkých stoviek tisíc radov. Tento skript tiež značne zaťažuje server a môže sa stať cieľom útoku.
Kde hľadať
Keď skenujeme zdroj pred vykonaním testovania, najprv sa samozrejme pozrieme na samotný web. Hľadáme všetky možné vstupné polia, ťažké súbory - proste všetko, čo môže vytvárať problémy zdroju a spomaľovať jeho fungovanie. Tu pomáhajú obyčajné vývojárske nástroje v Google Chrome a Firefox, ktoré ukazujú čas odozvy stránky.
Taktiež skenujeme subdomény. Napríklad existuje určitý online obchod, abc.com, a má subdoménu admin.abc.com. Pravdepodobne ide o administrátorskú časť s autorizáciou, ale ak na ňu pustíte záťaž, môže to spôsobiť problémy pre hlavný zdroj.
Web môže mať subdoménu api.abc.com. Pravdepodobne ide o zdroj pre mobilné aplikácie. Aplikáciu môžete nájsť v App Store alebo Google Play, nastaviť špeciálny prístupový bod, analyzovať API a zaregistrovať testovacie účty. Problém je v tom, že mnohí si často myslia, že všetko, čo je chránené autorizáciou, je imúnne voči útokom na odmietnutie služby. Akoby autorizácia bola najlepšou CAPTCHA, ale nie je. Vytvorenie 10-20 testovacích účtov je jednoduché, a po ich vytvorení získavame prístup k rozsiahlemu a nezakrytému funkčnému zázemiu.
Samozrejme, pozeráme sa na históriu, na robots.txt a WebArchive, ViewDNS, hľadáme staršie verzie zdroja. Niekedy sa stáva, že vývojári vydali, povedzme, mail2.yandex.net, a staršia verzia, mail.yandex.net, zostala. Tento mail.yandex.net prestáva byť podporovaný, nevenujú sa mu vývojové zdroje, ale i naďalej spotrebováva databázu. Podľa toho je možné efektívne využiť zdroje backendu a všetkého, čo stojí za kódovaním. Samozrejme, to sa nestáva vždy, ale s podobnými situáciami sa stretávame pomerne často.
Samozrejme, analyzujeme všetky parametre požiadavky, štruktúru cookies. Môžeme napríklad vložiť do JSON poľa vo vnútri cookies nejakú hodnotu, vytvoriť veľkú vnorenosť a spôsobiť, že zdroj bude pracovať nerozumne dlhú dobu.
Zaťaženie pri vyhľadávaní
Prvá vec, ktorá napadne pri skúmaní stránky, je zaťažiť databázu, pretože vyhľadávanie je takmer všade a mnohí to, žiaľ, robia zle chránené. Ako si mnohí vývojári nevšímajú dostatočne vyhľadávanie. Ale tu máme jednu radu — netreba robiť jednoliate požiadavky, pretože sa môžete stretnúť s cachovaním, ako v prípade HTTP flood.
Robiť náhodné požiadavky na databázu nie je vždy efektívne. Oveľa lepšie je vytvoriť zoznam kľúčových slov, ktoré sa týkajú vyhľadávania. Ak sa vrátime k príkladu internetového obchodu: povedzme, že stránka predáva automobilové pneumatiky a umožňuje nastaviť priemer pneumatík, typ automobilu a ďalšie parametre. Kombinácie relevantných slov povedú k tomu, že databáza bude pracovať v oveľa zložitejších podmienkach.
Okrem toho, je vhodné používať pagináciu: vyhľadávanie má oveľa väčšie ťažkosti pri dodávaní predposlednej stránky výsledkov ako prvej. To znamená, že pomocou paginácie môžeme do určitej miery diverzifikovať zaťaženie.
Na nižšie uvedenom príklade ukazujeme zaťaženie pri vyhľadávaní. Je vidieť, že od prvej sekundy testu s rýchlosťou desať požiadaviek za sekundu sa stránka zrútila a prestala odpovedať.
Čo ak nie je vyhľadávanie?
Ak nie je vyhľadávanie, neznamená to, že stránka neobsahuje iné zraniteľné vstupné polia. Takýmto políčkom môže byť autorizácia. Dnes vývojári radi robia zložité hashovanie, aby ochránili databázu prihlásení pred útokom pomocou rainbow tabuliek. Je to dobré, ale takéto hashe spotrebujú veľké CPU zdroje. Veľký prúd falošných autorizácií vedie k preťaženiu procesora a v dôsledku toho stránka prestane fungovať.
Prítomnosť na stránke rôznych formulárov pre komentáre a spätnú väzbu je príležitosťou zasielať tam veľmi veľké texty alebo jednoducho vytvárať masívny spam. Niekedy stránky akceptujú vložené súbory, vrátane formátu gzip. V takom prípade vezmeme súbor s veľkosťou 1TB, pomocou gzip ho stlačíme na niekoľko bajtov alebo kilobajtov a odošleme na stránku. Potom sa rozbalí a vzniká veľmi zaujímavý efekt.
Rest API
Chceli by sme venovať trochu pozornosti populárnym službám, ako je Rest API. Ochrana Rest API je oveľa zložitejšia ako ochrana bežnej webovej stránky. Pre Rest API nefungujú ani banálne spôsoby ochrany proti hrubému silu a inej nelegitímnej aktivite.
Rest API je veľmi jednoduché rozbiť, pretože sa priamo prihlasuje k databáze. Zastavenie takéhoto servera spôsobuje dosť vážne následky pre podnikanie. Ide o to, že na Rest API je zvyčajne naviazaný nielen hlavný web, ale aj mobilná aplikácia, nejaké interné obchodné zdroje. A ak to všetko zlyhá, dopad je oveľa silnejší ako v prípade, keď zlyhá jednoduchá webová stránka.
Záťaž na ťažký obsah
Ak nám ponúkajú testovať nejakú bežnú jednopageovú aplikáciu, landing page, vizitkovú stránku, ktoré nemajú zložitú funkcionalitu, hľadáme ťažký obsah. Napríklad veľké obrázky, ktoré server posiela, binárne súbory, pdf dokumentáciu – skúšame všetko toto stiahnuť. Takéto testy dobre zaťažujú súborový systém a saturujú kanály, a preto sú účinné. To znamená, že aj keď server nezložíte pri sťahovaní veľkého súboru pri nízkych rýchlostiach, jednoducho preťažíte kanál cieľového servera a nastaňuje tak odmietnutie služby.
Na príklade takejto skúšky je vidieť, že pri rýchlosti 30 RPS sa stránka prestala ozývať alebo vrátila 500. chyby servera.
Nesmiete zabudnúť ani na nastavenie serverov. Často môžete stretnúť, že niekto si kúpil virtuálny server, nainštaloval tam Apache, nastavil všetko predvolene, umiestnil php aplikáciu a nižšie môžete vidieť výsledok.
Tu zaťaženie išlo na koreň a dosiahlo iba 10 RPS. Počkali sme 5 minút a server zlyhal. Na konci, pravda, nie je známe, prečo zlyhal, ale existuje domnienka, že jednoducho spotreboval príliš veľa pamäte a prestal reagovať.
Založené na vlne
V posledných dvoch rokoch sa veľmi populárnymi stali vlnové útoky. Je to spôsobené tým, že mnohé organizácie nakupujú rôzne zariadenia na ochranu pred DDoS, ktoré potrebujú určitý čas na zber štatistík pred začatím filtrácie útoku. Inými slovami, v prvých 30-40 sekundách útok nefiltrujú, pretože zhromažďujú údaje a učia sa. V týchto 30-40 sekundách môžu na stránku spustiť toľko, že zdroj bude dlhodobo nedostupný, kým sa všetky požiadavky nevybavia.
V prípade útoku nižšie bol interval 10 minút, po ktorom prišla nová, modifikovaná dávka útoku.
Teda ochrana sa naučila, spustila filtráciu, ale prišla nová, úplne iná dávka útoku a ochrana opäť začala učenie. Fakticky, filtrácia prestáva fungovať, ochrana sa stáva neefektívnou a stránka je nedostupná.
Pre vlnové útoky sú charakteristické veľmi vysoké hodnoty na vrchole, môže dosiahnuť až sto tisíc alebo milión požiadaviek za sekundu, v prípade L7. Ak hovoríme o L3 a L4, tam môže byť stovky gigabitov prenosu, alebo, podľa toho, stovky mpps, ak počítame v paktoch.
Problém takýchto útokov spočíva v synchronizácii. Útoky idú z botnetu a na to, aby sa vytvoril veľmi veľký jednorázový vrchol, je potrebná vysoká úroveň synchronizácie. A táto koordinácia sa nie vždy podarí: niekedy vyjde nejaký parabolický vrchol, ktorý vyzerá dosť smiešne.
Nie HTTP jediné
Okrem HTTP na úrovni L7 radi využívame aj iné protokoly. Spravidla, bežný webový server, najmä obyčajný hosting, má na vonkajšej strane vystavené poštové protokoly a MySQL. Poštové protokoly sú menej náchylné na zaťaženie ako databázy, ale aj tie môžu byť účinne zaťažené a výsledkom môže byť preťažený CPU na serveri.
Pomocou zraniteľnosti SSH z roku 2016 sme dosiahli úspech. V súčasnosti je táto zraniteľnosť takmer u všetkých opravená, ale to neznamená, že na SSH nemožno aplikovať záťaž. Môže sa. Jednoducho sa podáva obrovská záťaž autorizácií, SSH spotrebuje takmer celý CPU na serveri a následne sa webová stránka skladá už od jedného až dvoch požiadaviek za sekundu. Teda týchto jeden-dva požiadavky podľa logov nemožno nijako odlíšiť od legitímnej záťaže.
Viacero pripojení, ktoré otvárame na serveroch, zostávajú relevantné. Predtým sa týmto problémom zaoberal Apache, teraz sa tým, bohužiaľ, zaoberá aj nginx, pretože sa často nastavuje predvolene. Počet pripojení, ktoré môže nginx udržať otvorené, je obmedzený, a preto pri otvorení tohto počtu pripojení už nové pripojenie nginx neprijíma, čo vedie k tomu, že stránka nefunguje.
Náš testovací klaster má dostatočný CPU na to, aby útočil na SSL handshake. V praxi to, ako ukazuje skúsenosť, robia aj botnety. Na jednej strane je jasné, že bez SSL to nejde, pretože ide o skórovanie Google, hodnotenie a bezpečnosť. Na druhej strane, bohužiaľ, sa SSL potýka s problémom s CPU.
L3&4
Keď hovoríme o útokoch na úrovniach L3&4, zvyčajne sa rozprávame o útoku na úrovni kanála. Takéto zaťaženie je takmer vždy rozlíšiteľné od legitímneho, ak nejde o útok SYN-flood. Problém s útokmi SYN-flood pre obranné prostriedky spočíva v veľkom objeme. Maximálna hodnota L3&4 bola 1,5-2 Tbit/s. Takýto trafik je veľmi ťažké spracovať dokonca aj veľkým spoločnostiam, vrátane Oracle a Google.
SYN a SYN-ACK sú pakety, ktoré sa používajú pri nadväzovaní pripojenia. Preto je ťažké rozlíšiť SYN-flood od legitímneho zaťaženia: nie je jasné, či ide o SYN, ktorý prišiel na nadviazanie pripojenia, alebo časť floodu.
UDP-flood
Zvyčajne nemajú útočníci takú výpočtovú kapacitu ako máme my, preto sa na organizáciu útokov môže používať amplifikácia. To znamená, že útočník skenuje internet a nachádza zraniteľné alebo nesprávne nastavené servery, ktoré napríklad odpovedajú troma SYN-ACK na jeden SYN-paket. Podfingovaním adresy zdroja z adresy cieľového servera je možné pomocou jedného paketu zvýšiť výkon, povedzme, trikrát a presmerovať trafik na obete.
Problémom amplifikácií je ich ťažké odhaľovanie. Medzi posledné prípady patrí známy incident so zraniteľným memcached. Navyše, v súčasnosti existuje množstvo zariadení IoT, IP kamier, ktoré sú tiež prevažne nastavené predvolene, a sú väčšinou nesprávne nastavené, preto útočníci často realizujú útoky prostredníctvom týchto zariadení.
Náročný SYN-flood
SYN-flood je možno najsledovanejší spôsob útoku z pohľadu vývojára. Problém je v tom, že systémoví administrátori často používajú blokovanie podľa IP na ochranu. Týmto blokovaním podľa IP trpia nielen administrátori, ktorí postupujú podľa skriptov, ale, bohužiaľ, aj niektoré ochranné systémy, ktoré sa kupujú za veľké peniaze.
Takáto metóda môže viesť k katastrofe, pretože ak útočníci zmenia IP adresy, potom spoločnosť zablokuje svoju vlastnú podsieť. Keď Firewall zablokuje vlastný klaster, vonkajšie interakcie sa rozpadnú a zdroj prestane fungovať.
Vlastne dosiahnuť blokovanie vlastnej siete nie je ťažké. Ak má klientova kancelária Wi-Fi sieť, alebo ak sa funkčnosť zdrojov meria pomocou rôznych monitorovacích systémov, vezmeme IP adresu tohto monitorovacieho systému alebo kancelárskej Wi-Fi siete a použijeme ju ako zdroj. Na výstupe je zdroj akoby dostupný, ale cieľové IP adresy sú zablokované. Takto môže byť zablokovaná Wi-Fi sieť konferencie HighLoad, kde sa prezentuje nový produkt spoločnosti, čo má určité obchodné a ekonomické náklady.
Počas testovania nemôžeme použiť amplifikáciu cez memcached s externými zdrojmi, pretože sú dohodnuté podmienky na prenos prevádzky len do povolených IP adries. Preto používame amplifikáciu cez SYN a SYN-ACK, keď na odoslanie jedného SYN systém odpovedá dvoma až troma SYN-ACK, a násobí sa to dvakrát až trikrát.
Nástroje
Jedným z hlavných nástrojov, ktoré používame na záťaž na úrovni L7, je Yandex-tank. Konkrétne sa ako zbraň používa fantóm, plus existuje niekoľko skriptov na generovanie nábojov a na analýzu výsledkov.
Na analýzu sieťovej prevádzky používame Tcpdump, na analýzu servera — Nmap. Na vytvorenie záťaže na úrovni L3&4 používame OpenSSL a trochu vlastnej magie s knižnicou DPDK. DPDK je knižnica od Intelu, ktorá umožňuje prácu so sieťovým rozhraním mimo Linuxového zásobníka, čím zvyšuje efektivitu. Samozrejme, DPDK používame nielen na úrovni L3&4, ale aj na úrovni L7, pretože umožňuje vytvárať veľmi vysoký tok záťaže, v rámci niekoľkých miliónov požiadaviek za sekundu z jedného stroja.
Taktiež používame určité generátory prevádzky a špeciálne nástroje, ktoré píšeme pre špecifické testy. Ak si spomenieme na zraniteľnosť pod SSH, pomocou uvedenej sady sa nedá zneužiť. Ak zaútočíme na poštový protokol, použijeme poštové utilitky alebo jednoducho na ne napíšeme skripty.
Zhrnutie
Na záver by som chcel povedať:
- Okrem klasického záťažového testovania je nevyhnutné vykonávať aj stresové testovanie. Máme reálny prípad, keď subdodávateľ partnera vykonal iba záťažové testovanie. Ukázalo sa, že zdroj zvláda štandardnú záťaž. Ale potom sa objavila nezvyčajná záťaž, návštevníci stránok začali zdroj využívať trochu inak — a nakoniec subdodávateľ zlyhal. Takže hľadanie zraniteľností je dôležité, aj keď už máte ochranu proti DDoS útokom.
- Je potrebné izolovať jedny časti systému od druhých. Ak máte vyhľadávanie, malo by byť presunuté na samostatné stroje, teda ani nie do dockera. Pretože ak vyhľadávanie alebo autorizácia zlyhá, aspoň niečo bude pokračovať v práci. V prípade internetového obchodu budú používatelia naďalej nachádzať produkty podľa katalógu, prechádzať z agregátorov, nakupovať, ak sú už prihlásení, alebo sa prihlásiť cez OAuth2.
- Nemožno zanedbať rôzne cloudové služby.
- Používajte CDN nielen na optimalizáciu sieťových latencií, ale aj ako prostriedok na ochranu pred útokmi zameranými na vyčerpanie kanála a jednoducho proti floodingom do statiky.
- Je potrebné využívať špecializované služby ochrany. Pred útokmi L3&4 na úrovni kanála sa sami neochrániť, pretože pravdepodobne nemáte dostatočný kanál. Pred útokmi L7 sa tiež ťažko brániť, pretože môžu byť veľmi rozsiahle. Navyše hľadanie malých útokov je aj tak privilégium špecializovaných služieb, špecializovaných algoritmov.
- Pravidelne sa aktualizujte. To sa týka nielen jadra, ale aj SSH daemonu, najmä ak sú otvorené na verejnosti. V podstate je potrebné aktualizovať všetko, pretože sledovať jednotlivé zraniteľnosti si pravdepodobne nebudete môcť sami.
Zdroj: habr.com
