Variti vyvíjí ochranu proti botům a útokům DDoS a také provádí zátěžové a zátěžové testy. Na konferenci HighLoad++ 2018 jsme hovořili o tom, jak zabezpečit zdroje před různými typy útoků. Stručně řečeno: izolujte části systému, používejte cloudové služby a CDN a pravidelně aktualizujte. Bez specializovaných firem si ale ochranu stejně neporadíte :)
Před čtením textu si můžete přečíst krátké abstrakty .
A pokud vás nebaví číst nebo se jen chcete dívat na video, záznam naší reportáže je níže pod spoilerem.
Video záznam reportáže
Mnoho společností již ví, jak provádět zátěžové testy, ale ne všechny provádějí zátěžové testy. Někteří naši zákazníci si myslí, že jejich stránky jsou nezranitelné, protože mají systém s vysokou zátěží a dobře chrání před útoky. Ukazujeme, že to není tak úplně pravda.
Samozřejmě před provedením testů získáme od zákazníka svolení, podepsané a orazítkované a s naší pomocí nelze DDoS útok na nikoho provést. Testování se provádí v čase zvoleném zákazníkem, kdy je provoz jeho zdroje minimální a problémy s přístupem neovlivní klienty. Navíc, protože se během procesu testování může vždy něco pokazit, jsme se zákazníkem neustále v kontaktu. To vám umožní nejen hlásit dosažené výsledky, ale také něco změnit během testování. Po ukončení testování vždy vypracujeme zprávu, ve které upozorníme na zjištěné nedostatky a dáme doporučení k odstranění slabých stránek webu.
Jak pracujeme
Při testování emulujeme botnet. Vzhledem k tomu, že pracujeme s klienty, kteří se nenacházejí v našich sítích, abychom zajistili, že test neskončí hned v první minutě z důvodu spuštění limitů nebo ochrany, nedodáváme zátěž z jedné IP, ale z vlastní podsítě. Navíc, abychom vytvořili značné zatížení, máme vlastní poměrně výkonný testovací server.
Postuláty
Příliš mnoho neznamená dobře
Čím menší zátěž dokážeme přivést zdroj k selhání, tím lépe. Pokud dokážete, že web přestane fungovat na jeden požadavek za sekundu nebo dokonce jeden požadavek za minutu, je to skvělé. Protože podle zákona podlosti uživatelé nebo útočníci náhodně spadnou do této konkrétní zranitelnosti.
Částečné selhání je lepší než úplné selhání
Vždy doporučujeme, aby byly systémy heterogenní. Navíc stojí za to je oddělit na fyzické úrovni, a to nejen kontejnerizací. V případě fyzického oddělení, i když na webu něco selže, je velká pravděpodobnost, že nepřestane fungovat úplně a uživatelé budou mít nadále přístup alespoň k části funkcionality.
Dobrá architektura je základem udržitelnosti
Odolnost zdroje vůči chybám a jeho schopnost odolávat útokům a zatížení by měla být stanovena ve fázi návrhu, ve skutečnosti ve fázi kreslení prvních vývojových diagramů v poznámkovém bloku. Protože pokud se vloudí fatální chyby, je možné je v budoucnu opravit, ale je to velmi obtížné.
Nejen kód by měl být dobrý, ale také konfigurace
Mnoho lidí si myslí, že dobrý vývojový tým je zárukou bezchybné služby. Dobrý vývojový tým je opravdu nutný, ale musí existovat také dobré operace, dobré DevOps. To znamená, že potřebujeme specialisty, kteří budou správně konfigurovat Linux a síť, správně psát konfigurace v nginx, nastavovat limity atd. V opačném případě bude zdroj dobře fungovat pouze při testování a v určitém okamžiku se vše ve výrobě zlomí.
Rozdíly mezi zátěžovým a zátěžovým testováním
Zátěžové testování vám umožňuje identifikovat limity fungování systému. Zátěžové testování je zaměřeno na nalezení slabých míst v systému a používá se k prolomení tohoto systému a zjištění, jak se bude chovat v procesu selhání určitých částí. V tomto případě zůstává povaha zátěže zákazníkovi obvykle neznámá před zahájením zátěžového testování.
Charakteristické rysy útoků L7
Typy zátěže rozdělujeme obvykle na zátěže na úrovni L7 a L3&4. L7 je zátěž na aplikační úrovni, nejčastěji to znamená pouze HTTP, ale máme na mysli jakoukoli zátěž na úrovni TCP protokolu.
Útoky L7 mají určité charakteristické rysy. Za prvé přicházejí přímo do aplikace, to znamená, že je nepravděpodobné, že se projeví prostřednictvím síťových prostředků. Takové útoky využívají logiku a díky tomu velmi efektivně a s malým provozem spotřebovávají CPU, paměť, disk, databázi a další zdroje.
HTTP Flood
V případě jakéhokoli útoku se zátěž snáze vytváří než manipuluje a v případě L7 to platí také. Není vždy snadné odlišit provoz útoku od legitimního provozu a nejčastěji to lze provést podle frekvence, ale pokud je vše správně naplánováno, nelze z protokolů pochopit, kde je útok a kde jsou legitimní požadavky.
Jako první příklad zvažte útok HTTP Flood. Z grafu je patrné, že takové útoky jsou obvykle velmi silné, v příkladu níže přesáhl špičkový počet požadavků 600 tisíc za minutu.
HTTP Flood je nejjednodušší způsob, jak vytvořit zatížení. Obvykle to vyžaduje nějaký nástroj pro testování zátěže, jako je ApacheBench, a nastaví požadavek a cíl. S takto jednoduchým přístupem je vysoká pravděpodobnost, že narazíte na mezipaměť serveru, ale je snadné to obejít. Například přidáním náhodných řetězců k požadavku, což donutí server neustále obsluhovat novou stránku.
Nezapomeňte také na user-agent v procesu vytváření zátěže. Mnoho uživatelských agentů populárních testovacích nástrojů je filtrováno správci systému a v tomto případě se zátěž jednoduše nedostane do backendu. Výsledek můžete výrazně vylepšit vložením více či méně platné hlavičky z prohlížeče do požadavku.
Jakkoli jsou útoky HTTP Flood jednoduché, mají také své nevýhody. Za prvé, k vytvoření zátěže je zapotřebí velké množství energie. Za druhé, takové útoky lze velmi snadno odhalit, zvláště pokud pocházejí z jedné adresy. V důsledku toho začnou požadavky okamžitě filtrovat buď správci systému, nebo dokonce na úrovni poskytovatele.
Co hledat
Chcete-li snížit počet požadavků za sekundu bez ztráty efektivity, musíte ukázat trochu fantazie a prozkoumat web. Můžete tak načíst nejen kanál nebo server, ale také jednotlivé části aplikace, například databáze nebo souborové systémy. Můžete také hledat místa na webu, která provádějí velké výpočty: kalkulačky, stránky pro výběr produktů atd. Nakonec se často stává, že web má nějaký PHP skript, který vygeneruje stránku o několika stovkách tisíc řádků. Takový skript také výrazně zatěžuje server a může se stát cílem útoku.
Kde hledat
Když skenujeme zdroj před testováním, nejprve se samozřejmě podíváme na samotný web. Hledáme nejrůznější vstupní pole, těžké soubory - obecně vše, co může zdroji způsobit problémy a zpomalit jeho provoz. Zde pomáhají banální vývojové nástroje v prohlížečích Google Chrome a Firefox, které zobrazují doby odezvy stránky.
Skenujeme také subdomény. Existuje například určitý internetový obchod abc.com, který má subdoménu admin.abc.com. S největší pravděpodobností se jedná o administrátorský panel s autorizací, ale pokud jej zatížíte, může to způsobit problémy hlavnímu zdroji.
Web může mít subdoménu api.abc.com. S největší pravděpodobností se jedná o zdroj pro mobilní aplikace. Aplikaci najdete v App Store nebo Google Play, nainstalujte si speciální přístupový bod, rozeberte API a zaregistrujte testovací účty. Problém je v tom, že lidé si často myslí, že cokoli, co je chráněno autorizací, je imunní vůči útokům typu Denial of Service. Údajně je autorizace nejlepší CAPTCHA, ale není. Je snadné vytvořit 10–20 testovacích účtů, ale jejich vytvořením získáme přístup ke komplexním a neskrývaným funkcím.
Samozřejmě se podíváme do historie, na robots.txt a WebArchive, ViewDNS a hledáme staré verze zdroje. Někdy se stane, že vývojáři spustili řekněme mail2.yandex.net, ale stará verze mail.yandex.net zůstává. Tento mail.yandex.net již není podporován, nejsou mu přiděleny vývojové prostředky, ale nadále spotřebovává databázi. V souladu s tím můžete pomocí staré verze efektivně využívat zdroje backendu a vše, co je za rozložením. To se samozřejmě nestává vždy, ale stále se s tím setkáváme poměrně často.
Samozřejmě analyzujeme všechny parametry požadavku a strukturu souborů cookie. Můžete například uložit nějakou hodnotu do pole JSON uvnitř souboru cookie, vytvořit mnoho vnoření a zajistit, aby zdroj fungoval nepřiměřeně dlouho.
Vyhledávací zatížení
První věc, která vás při průzkumu webu napadne, je načíst databázi, protože téměř každý má vyhledávání a téměř pro každého je bohužel špatně chráněna. Vývojáři z nějakého důvodu nevěnují vyhledávání dostatečnou pozornost. Jedno doporučení zde ale je – neměli byste zadávat požadavky stejného typu, protože se můžete setkat s cachováním, jako je tomu u HTTP floodu.
Náhodné dotazy do databáze také nejsou vždy efektivní. Mnohem lepší je vytvořit si seznam klíčových slov, která jsou pro vyhledávání relevantní. Pokud se vrátíme k příkladu internetového obchodu: řekněme, že web prodává pneumatiky pro automobily a umožňuje vám nastavit poloměr pneumatik, typ automobilu a další parametry. Kombinace relevantních slov tedy přinutí databázi pracovat v mnohem složitějších podmínkách.
Kromě toho se vyplatí používat stránkování: pro vyhledávání je mnohem obtížnější vrátit předposlední stránku výsledků vyhledávání než první. To znamená, že pomocí stránkování můžete zatížení mírně diverzifikovat.
Níže uvedený příklad ukazuje zatížení vyhledávání. Je vidět, že hned od první vteřiny testu při rychlosti deseti požadavků za vteřinu web spadl a nereagoval.
Pokud neprobíhá vyhledávání?
Pokud neprobíhá vyhledávání, neznamená to, že web neobsahuje další zranitelná vstupní pole. Toto pole může být autorizace. V dnešní době vývojáři rádi vytvářejí složité hashe, aby ochránili přihlašovací databázi před útokem rainbow table. To je dobré, ale takové hashe spotřebovávají spoustu zdrojů CPU. Velký tok falešných autorizací vede k selhání procesoru a v důsledku toho web přestane fungovat.
Přítomnost všech druhů formulářů pro komentáře a zpětnou vazbu na webu je důvodem, proč tam posílat velmi rozsáhlé texty nebo jednoduše vytvořit masivní záplavu. Někdy weby přijímají přiložené soubory, včetně souborů ve formátu gzip. V tomto případě vezmeme 1TB soubor, zkomprimujeme jej na několik bajtů nebo kilobajtů pomocí gzip a odešleme na web. Poté se rozepne a získá se velmi zajímavý efekt.
Rest API
Rád bych věnoval malou pozornost tak populárním službám, jako je Rest API. Zabezpečení Rest API je mnohem obtížnější než běžné webové stránky. Pro Rest API nefungují ani triviální metody ochrany proti heslové hrubé síle a jiné nelegitimní činnosti.
Rest API je velmi snadné prolomit, protože přistupuje přímo k databázi. Selhání takové služby má přitom pro podnikání docela vážné důsledky. Faktem je, že Rest API se obvykle používá nejen pro hlavní web, ale také pro mobilní aplikaci a některé interní obchodní zdroje. A pokud toto vše padne, pak je efekt mnohem silnější než v případě prostého selhání webu.
Načítání těžkého obsahu
Pokud je nám nabídnuto otestovat nějakou běžnou jednostránkovou aplikaci, vstupní stránku nebo web s vizitkou, který nemá komplexní funkcionalitu, hledáme těžký obsah. Například velké obrázky, které server posílá, binární soubory, pdf dokumentace – to vše se snažíme stáhnout. Takové testy dobře načítají systém souborů a ucpávají kanály, a proto jsou účinné. To znamená, že i když server neodložíte a stáhnete velký soubor nízkou rychlostí, jednoduše ucpete kanál cílového serveru a pak dojde k odmítnutí služby.
Příklad takového testu ukazuje, že při rychlosti 30 RPS web přestal reagovat nebo způsobil 500. chybu serveru.
Nezapomeňte na nastavení serverů. Často se můžete setkat s tím, že si člověk koupil virtuální stroj, nainstaloval tam Apache, vše defaultně nakonfiguroval, nainstaloval PHP aplikaci a níže vidíte výsledek.
Zde zátěž šla na kořen a činila pouhých 10 RPS. Čekali jsme 5 minut a server se zhroutil. Je pravda, že není úplně známo, proč spadl, ale existuje předpoklad, že měl prostě příliš mnoho paměti, a proto přestal reagovat.
Na základě vlny
V posledním roce nebo dvou se staly vlnové útoky docela populární. To je způsobeno skutečností, že mnoho organizací nakupuje určité kusy hardwaru pro ochranu DDoS, které vyžadují určitý čas na nashromáždění statistik, aby bylo možné útok začít filtrovat. To znamená, že nefiltrují útok v prvních 30-40 sekundách, protože shromažďují data a učí se. Proto za těchto 30–40 sekund můžete na webu spustit tolik, že zdroj bude ležet po dlouhou dobu, dokud nebudou všechny požadavky vymazány.
V případě níže uvedeného útoku byl interval 10 minut, po kterém přišla nová, upravená část útoku.
To znamená, že se obrana naučila, začala filtrovat, ale přišla nová, úplně jiná porce útoku a obrana se zase začala učit. Filtrování ve skutečnosti přestane fungovat, ochrana se stane neúčinnou a stránka je nedostupná.
Vlnové útoky se vyznačují velmi vysokými hodnotami na špičce, v případě L7 mohou dosáhnout sto tisíc nebo milion požadavků za sekundu. Pokud mluvíme o L3 a 4, pak to může být stovky gigabitů provozu, nebo tedy stovky mpps, pokud počítáte v paketech.
Problémem takových útoků je synchronizace. Útoky pocházejí z botnetu a vyžadují vysoký stupeň synchronizace k vytvoření velmi velkého jednorázového nárůstu. A tato koordinace ne vždy vyjde: někdy je výstupem nějaký parabolický vrchol, který vypadá dost pateticky.
Nejen HTTP
Kromě HTTP na L7 rádi využíváme další protokoly. Běžný web, zejména běžný hosting, má zpravidla poštovní protokoly a MySQL. Poštovní protokoly jsou zatěžovány méně než databáze, ale lze je také načítat poměrně efektivně a skončit s přetíženým CPU na serveru.
S použitím zranitelnosti SSH z roku 2016 jsme byli docela úspěšní. Nyní byla tato chyba zabezpečení opravena téměř pro každého, ale to neznamená, že zatížení nelze odeslat do SSH. Umět. Je tu prostě obrovská nálož autorizací, SSH zabere téměř celý CPU na serveru a web pak zkolabuje z jednoho nebo dvou požadavků za sekundu. V souladu s tím nelze tyto jeden nebo dva požadavky založené na protokolech odlišit od legitimního zatížení.
Mnoho připojení, která otevíráme na serverech, také zůstává relevantních. Dříve za to byl vinen Apache, nyní je za to nginx ve skutečnosti vinen, protože je často konfigurován ve výchozím nastavení. Počet připojení, která může nginx ponechat otevřená, je omezený, takže otevíráme tento počet připojení, nginx již nepřijímá nové připojení a v důsledku toho web nefunguje.
Náš testovací cluster má dostatek CPU k útoku na SSL handshake. V zásadě, jak ukazuje praxe, botnety to někdy také rády dělají. Na jednu stranu je jasné, že se bez SSL neobejdete, protože výsledky Google, hodnocení, bezpečnost. Na druhou stranu, SSL má bohužel problém s CPU.
L3&4
Když mluvíme o útoku na úrovních L3&4, obvykle mluvíme o útoku na úrovni spojení. Taková zátěž je téměř vždy odlišitelná od legitimní, pokud se nejedná o SYN-flood útok. Problémem SYN-flood útoků na bezpečnostní nástroje je jejich velký objem. Maximální hodnota L3&4 byla 1,5-2 Tbit/s. Tento druh provozu je velmi obtížně zpracovatelný i pro velké společnosti, včetně Oracle a Google.
SYN a SYN-ACK jsou pakety, které se používají při navazování spojení. Proto je obtížné odlišit SYN-flood od legitimního zatížení: není jasné, zda se jedná o SYN, který přišel za účelem navázání spojení, nebo o součást záplavy.
UDP-povodeň
Útočníci obvykle nemají schopnosti, které máme my, takže k organizaci útoků lze použít zesílení. To znamená, že útočník prohledá internet a najde buď zranitelné nebo nesprávně nakonfigurované servery, které například v reakci na jeden SYN paket odpoví třemi SYN-ACK. Falšováním zdrojové adresy z adresy cílového serveru je možné jedním paketem zvýšit výkon řekněme třikrát a přesměrovat provoz na oběť.
Problém se zesílením je v tom, že je obtížné je detekovat. Mezi nedávné příklady patří senzační případ zranitelného memcached. Navíc teď existuje spousta IoT zařízení, IP kamer, které jsou také většinou defaultně nakonfigurovány a defaultně jsou nakonfigurovány špatně, proto útočníci nejčastěji útočí právě přes taková zařízení.
Obtížná SYN-povodeň
SYN-flood je z pohledu vývojáře asi nejzajímavější typ útoku. Problém je v tom, že správci systému často používají k ochraně blokování IP. Blokování IP navíc ovlivňuje nejen systémové administrátory, kteří jednají pomocí skriptů, ale bohužel i některé zabezpečovací systémy, které se pořizují za hodně peněz.
Tato metoda se může změnit v katastrofu, protože pokud útočníci nahradí IP adresy, společnost zablokuje vlastní podsíť. Když brána firewall zablokuje svůj vlastní cluster, výstup selže v externích interakcích a zdroj selže.
Navíc není těžké zablokovat vlastní síť. Pokud má kancelář klienta Wi-Fi síť, nebo je-li výkon zdrojů měřen pomocí různých monitorovacích systémů, pak vezmeme IP adresu tohoto monitorovacího systému nebo Wi-Fi kanceláře klienta a použijeme ji jako zdroj. Nakonec se zdá, že zdroj je dostupný, ale cílové IP adresy jsou blokovány. Může tak dojít k zablokování Wi-Fi sítě konference HighLoad, kde se nový produkt společnosti prezentuje, a to s sebou nese určité obchodní a ekonomické náklady.
Během testování nemůžeme použít zesílení přes memcached s žádnými externími zdroji, protože existují dohody o odesílání provozu pouze na povolené IP adresy. Podle toho využíváme zesílení přes SYN a SYN-ACK, kdy systém na odeslání jednoho SYN odpoví dvěma nebo třemi SYN-ACK a na výstupu se útok znásobí dvakrát nebo třikrát.
Nástroje
Jedním z hlavních nástrojů, které používáme pro pracovní zátěž L7, je Yandex-tank. Jako zbraň se používá zejména fantom a navíc existuje několik skriptů pro generování nábojů a pro analýzu výsledků.
Tcpdump se používá k analýze síťového provozu a Nmap se používá k analýze serveru. Pro vytvoření zátěže na úrovni L3&4 se používá OpenSSL a trocha našich vlastních kouzel s knihovnou DPDK. DPDK je knihovna od Intelu, která umožňuje pracovat se síťovým rozhraním, které obchází linuxový stack, čímž zvyšuje efektivitu. DPDK samozřejmě používáme nejen na úrovni L3&4, ale také na úrovni L7, protože nám umožňuje vytvořit velmi vysoký tok zatížení v rozsahu několika milionů požadavků za sekundu z jednoho stroje.
Používáme také určité generátory provozu a speciální nástroje, které píšeme pro konkrétní testy. Pokud si vzpomeneme na zranitelnost pod SSH, pak výše uvedenou sadu nelze zneužít. Pokud napadneme poštovní protokol, vezmeme poštovní utility nebo na ně jednoduše napíšeme skripty.
Závěry
Na závěr bych chtěl říci:
- Kromě klasického zátěžového testování je nutné provádět zátěžové testování. Máme reálný příklad, kdy subdodavatel partnera prováděl pouze zátěžové zkoušky. Ukázalo se, že zdroj vydrží běžné zatížení. Pak se ale objevila abnormální zátěž, návštěvníci stránek začali využívat zdroj trochu jinak a v důsledku toho subdodavatel ulehl. Proto se vyplatí hledat zranitelná místa, i když jste již chráněni před DDoS útoky.
- Je nutné izolovat některé části systému od ostatních. Pokud máte vyhledávání, musíte jej přesunout na samostatné stroje, tedy ani do Dockeru. Protože pokud selže vyhledávání nebo autorizace, alespoň něco bude fungovat dál. V případě internetového obchodu budou uživatelé nadále vyhledávat produkty v katalogu, přecházet z agregátoru, nakupovat, pokud jsou již autorizováni, nebo autorizovat prostřednictvím OAuth2.
- Nezanedbávejte všechny druhy cloudových služeb.
- Použijte CDN nejen k optimalizaci zpoždění sítě, ale také jako prostředek ochrany proti útokům na vyčerpání kanálu a jednoduše zahlcení do statického provozu.
- Je nutné využívat specializované ochranné služby. Nemůžete se chránit před útoky L3&4 na úrovni kanálu, protože s největší pravděpodobností jednoduše nemáte dostatečný kanál. Je také nepravděpodobné, že budete odrážet útoky L7, protože mohou být velmi velké. Navíc vyhledávání malých útoků je stále výsadou speciálních služeb, speciálních algoritmů.
- Pravidelně aktualizujte. To platí nejen pro jádro, ale také pro SSH démona, zvláště pokud je máte otevřené ven. V zásadě je potřeba vše aktualizovat, protože je nepravděpodobné, že byste sami mohli sledovat určité zranitelnosti.
Zdroj: www.habr.com