DDoS abi: kuidas me läbime stressi- ja koormustestid

Ettevõte Variti arendab botivastast kaitset ja DDoS-rünnakute vastu, samuti viib läbi stressi- ja koormustestimist. Konverentsil HighLoad++ 2018 rääkisime, kuidas kaitsta ressursse erinevate rünnakute eest. Lühidalt: isoleerige süsteemi osi, kasutage pilveteenuseid ja CDN-i ning uuendage regulaarselt. Kuid ilma spetsialiseeritud kaitsefirmadeta ei suuda te siiski hakkama saada 🙂

Enne teksti lugemist võite tutvuda lühikeste kokkuvõtetega konverentsi veebisaidil.
Ja kui te ei armasta lugemist või soovite lihtsalt videot vaadata, siis allpool spoliers jaotises on meie ettekande salvestus.

Ettekande video

Paljud ettevõtted oskavad juba teha koormusteste, kuid mitte kõik ei tee stressiteste. Mõned meie kliendid arvavad, et nende veebisait on haavatamatu, sest neil on highload süsteem, mis kaitseb rünnakute eest. Me näitame, et see ei ole kaugeltki tõsi.
Muidugi saame enne testide läbiviimist kliendilt loa, allkirja ja templiga, ja meie abiga ei saa DDoS-rünnakut kellelegi teha. Testimine toimub kliendi valitud ajal, kui tema ressursi külastatavus on minimaalne ja ligipääsu probleemid ei kajastu klientides. Lisaks, kuna testimise ajal võib alati juhtuda midagi ootamatut, on meil pidev kontakt kliendiga. See võimaldab mitte ainult saavutatud tulemusi edastada, vaid ka testimise käigus midagi muuta. Testimise lõppedes koostame alati aruande, kus märgime avastatud puudused ja anname soovitusi nõrkade kohtade kõrvaldamiseks veebisaidil.

Kuidas me töötame

Testimise läbiviimisel emuleerime botivõrku. Kuna töötame klientidega, kes ei asu meie võrkudes, siis et test ei lõppeks esimese minuti jooksul limiitide või kaitse aktiveerimise tõttu, suuname koormuse mitte ühelt IP-aadressilt, vaid oma alamvõrgust. Lisaks on meil piisavalt võimas testserver, et genereerida märkimisväärset koormust.

Postulaadid

Palju — ei tähenda hästi
Mida väiksem on koormus, millega suudame ressursi rikki ajada, seda parem. Kui saame saavutada, et veebisait lõpetab toimimise ühe päringu sekundis või isegi ühe päringu minutis, oleks see suurepärane. Sest Murphy seaduse kohaselt satuvad kasutajad või pahatahtlikud isikud juhuslikult just sellesse haavasse.

Osaline rike on parem kui täielik
Soovitame alati, et süsteemid oleksid heterogeensed. Ja neid tuleks jagada füüsilisel tasandil, mitte ainult konteineriseerimisega. Füüsilise eraldamise korral, isegi kui veebisaidil midagi ebaõnnestub, on tõenäosus, et see ei lakkaks täielikult toimimast, suur ja kasutajatel säilib juurdepääs vähemalt osa funktsionaalsusele.

Õige arhitektuur on stabiilsuse alus
Ressursi tõrke taluvus ja selle võime taluda rünnakuid ja koormusi peaksid olema kavandatud juba projekteerimise etapil, sisuliselt esimestel mustritel joonistades. Sest kui sisse imbuvad fataalsed vead, on hiljem nende parandamine võimalik, kuid väga keeruline.

Hea peaks olema mitte ainult kood, vaid ka konfiguratsioon
Paljud arvavad, et hea arendusmeeskond tagab teenuse tõrke taluvuse. Hea arendusmeeskond on tõepoolest vajalik, kuid vajalik on ka hea kasutus, hea DevOps. Ehk on vajalikud spetsialistid, kes konfigureerivad õigesti Linuxi ja võrgu, kirjutavad õigesti nginx’i konfiguratsioonid, seadistavad limiidid jne. Vastasel juhul töötab ressurss hästi ainult katses, kuid tootmises murdub mingi hetk kõik kokku.

Koormuse ja stressitestimise erinevused
Koormustestimine võimaldab tuvastada süsteemi toimimise piire. Stressitestimine on suunatud süsteemi nõrkade kohtade leidmisele ja seda kasutatakse selleks, et süsteemi purustada ja vaadata, kuidas see käitub teatud osade rikke korral. Samas jääb koormuse iseloom tavaliselt kliendile teadmata enne stressitestimise algust.

L7 rünnakute eripärad

Liike koormusi jagame tavaliselt L7 ja L3&4 tasemete koormusteks. L7 on rakenduse taseme koormus, mille alla mõistetakse kõige sagedamini ainult HTTP, kuid meie mõistame alla igasugust koormust TCP protokolli tasemel.
L7 rünnakutel on teatavad iseloomulikud tunnused. Esiteks, need tulevad otse rakendusse, seega ei ole neid tõenäoliselt võimalik võrgu vahenditega peegeldada. Sellised rünnakud kasutavad loogikat ja seetõttu tarbivad nad väga efektiivselt CPU-d, mälu, ketast, andmebaasi ja muid ressursse, isegi väikese liikluse korral.

HTTP Flood

Iga rünnaku korral on koormuse tekitamine lihtsam kui selle töötlemine ja L7 puhul on see samuti tõsi. Rünnaku liiklust on sageli keeruline eristada seaduslikust liiklusest ning enamikul juhtudel on võimalik seda teha ainult sageduse põhjal. Kuid kui kõik on korralikult planeeritud, on logide põhjal võimatu mõista, kus on rünnak ja kus seaduslikud päringud.
Esimese näitena vaatleme HTTP Flood rünnakut. Graafikult on näha, et sellised rünnakud on tavaliselt väga võimsad; allolevas näites ületas haripunktis tehtud päringute arv 600 000 minutis.

HTTP Flood on kõige lihtsam viis koormuse tekitamiseks. Tavaaliselt kasutatakse selleks mingit koormustestimise tööriista, näiteks ApacheBench, ja määratakse päring ja siht. Sellise lihtsa lähenemise puhul on suur tõenäosus sattuda serveri caching'usse, kuid seda on lihtne üle petta. Näiteks lisades päringusse juhuslikke kujundeid, mis sunnib serverit pidevalt uuendama lehte.
Ärge unustage, et koormuse tekitamise protsessis on oluline ka user-agent. Paljusid populaarsest testimisest kasutatavad user-agent'id filtreerivad süsteemiadministratorid, ja siis võib koormus lihtsalt mitte jõuda taustsüsteemi. Tulemusi on oluliselt võimalik parandada, lisades päringusse enam-vähem valideeritud veebibrauseri pealkirja.
Maljerpoli all lihtsuses, HTTP Flood rünnakutel on ka oma puudused. Esiteks, koormuse tekitamiseks on vaja suurt võimsust. Teiseks, sellised rünnakud on väga kergesti tuvastatavad, eriti kui nad tulevad ühest aadressist. Lõppkokkuvõttes hakkavad päringud koheselt filtreerima kas süsteemiadministraatorid või isegi teenusepakkuja tasemel.

Mida otsida

Kuna vähendada sekundis esitatavate päringute arvu, kaotamata samas efektiivsust, tuleb veidi loovust ja uurida saiti. Niisiis, koormata võib mitte ainult kanalit või serverit, vaid ka konkreetseid rakenduse osi, näiteks andmebaase või failisüsteeme. Samuti tasub otsida kohti saidil, mis teevad suuri arvutusi: kalkulaatorid, tooteotsingu lehed jne. Lõpuks juhtub tihti, et saidil on mingi php-skript, mis genereerib lehe mitmest sajast tuhandest reast. Selline skript koormab samuti serverit suurel määral ja võib muutuda rünnaku objektiks.

Kus otsida

Kui me skaneerime ressurssi enne testimise läbiviimist, vaatame kõigepealt loomulikult saiti endalt. Otsime igasuguseid sisendvälju, suuri faile — kõike, mis võib ressursile probleeme tekitada ja selle tööd aeglustada. Siin aitavad tavalised arendustooted Google Chrome'is ja Firefoxis, mis näitavad lehe vastuseaega.
Samuti skaneerime alamdomeene. Näiteks on olemas mingi veebipood, abc.com, ja sellel on alamdomeen admin.abc.com. Tõenäoliselt on see administraatorirakendus, kuid kui sellele koormust rakendada, võib see peamise ressursi jaoks probleeme tekitada.
Saidil võib olla alamdomeen api.abc.com. Tõenäoliselt on see ressurss mobiilirakenduste jaoks. Rakenduse leidmiseks võib minna App Store'i või Google Play'sse, seadistada spetsiaalne juurdepääsupunkt, analüüsida API-d ja registreerida testkonto. Probleem on selles, et tihti arvavad inimesed, et kõik, mis on autoriseerimisega kaitstud, on teenuse keelamise rünnakute suhtes haavatamatu. Oletatakse, et autoriseerimine on parim CAPTCHA, kuid see pole nii. 10–20 testkonto loomine on lihtne ja nende loomisega saame juurdepääsu keerulisele ja avatud funktsionaalsusele.
Muidugi vaatame ajalugu, robots.txt ja WebArchive'i, ViewDNS-i, otsime ressursi vanu versioone. Vahel juhtub, et arendajad käivitavad, ütleme, mail2.yandex.net, kuid vana versioon, mail.yandex.net, jääb alles. See mail.yandex.net lõpetab toe saamise, selle arendamiseks ei eraldata ressursse, kuid see jätkab andmebaasi tarbimist. Seega saab vana versiooni abil tõhusalt kasutada tagapool olevaid ressursse ja kõike, mis on seotud kujundusega. Loomulikult see ei juhtu alati, kuid me kohtame sarnaste olukordadega ikka ja jälle suhteliselt tihti.
Muidugi uurime kõiki päringu parameetreid ja küpsiste struktuuri. Saame näiteks JSON-massiivi küpsisesse mingi väärtuse ja luua suure sisemise struktuuri, sundides ressursi töötama erilise aeglusega.

Otsingu koormus

Esimene asi, mis pähe tuleb, kui uurida veebisaiti, on andmebaasi koormamine, kuna otsing on peaaegu kõigis ja enamikul neist on kahjuks nõrk kaitse. Miks arendajad jäävad otsingu piisavalt tähelepanuta? Kuid siin on soovitus — vältige ühesuguste päringute tegemist, sest võite kokku puutuda vahemäluga, nagu ka HTTP ülekoormuse korral.
Otsingu jaoks andmebaasi juhuslike päringute tegemine ei ole ka alati efektiivne. Oluliselt parem on koostada loetelu märksõnadest, mis on seotud otsinguga. Kui pöörduda tagasi näite juurde, kus veebipood müüb autoteste ja võimaldab määrata rehvide raadiust, autotype'i ja muid parameetreid. Seega kombinatsioonid asjakohastest sõnadest panevad andmebaasi töötama palju keerulisemates tingimustes.
Lisaks on soovitatav kasutada lehekülgede jagamist: otsingul on palju keerulisem näidata eelviimast otsingutulemust, kui esimest. Seega saab lehekülgede jagamise abil koormust veidi mitmekesistada.
Allpool on näidatud otsingu koormus. Nähes, et juba testi esimesel sekundil kümne päringu tasa hukkas sait ja ei vastanud.

Mis juhtub, kui otsingut ei ole?

Kui otsingut ei ole, ei tähenda see, et sait ei sisaldaks teisi haavatavaid sisendvälju. Selliseks väljad võivad olla autoriseerimine. Praegu armastavad arendajad luua keerulisi räsi, et kaitsta sisselogimise andmebaasi ründamise eest kaarelistest tabelitest. See on hea, aga sellised räsi tarbivad palju CPU ressurssi. Suur valeautoriseerimise voog toob kaasa protsessori kokkuvarisemise ja seetõttu lõpetab sait töötamise.
Erinevate kommentaari- ja tagasiside vormide olemasolu veebisaidil on põhjus saata sinna väga suuri tekste või lihtsalt luua massilist rämpsposti. Mõnikord aktsepteerivad saidid ka sissehainetud faile, sealhulgas gzip-formaadis. Sellisel juhul võtame 1TB faili, komprimeerime selle gzip abil paariks baitiks või kilobaitiks ja saadame saidile. Edasi dekompressitakse see ja saadakse väga huvitav efekt.

Rest API

Sooviksime pöörata natuke tähelepanu praegu populaarsetele teenustele, nagu Rest API. Rest API kaitsmine on palju keerulisem kui tavalise veebisaidi. Rest API jaoks ei tööta isegi tavalised paroolivõtmise ja muu ebaseadusliku tegevuse kaitsemeetodid.
Rest API-d on väga lihtne rikki minna, kuna see pöördub otse andmebaasi poole. Sellegipoolest võib sellise teenuse välja lülitamine kaasa tuua piisavalt tõsiseid tagajärgi äri jaoks. Asi on selles, et Rest API on tavaliselt seotud mitte ainult pea veebisaidiga, vaid ka mobiilirakenduste ja muude sisemiste äriallikatega. Ja kui kõik see kokku kukub, on mõju palju tõsisemat, kui lihtsalt tavalise veebisaidi rikki minek.

Raske sisu koormus

Kui meile pakutakse testida mõnda tavalist ühe lehe rakendust, maandumist või visiitkaarti, millel ei ole keerulisi funktsioone, siis otsime rasket sisu. Näiteks suured pildid, mida server edastab, binaarfailid, pdf-dokumendid - proovime kõike seda alla laadida. Sellised testid koormavad hästi failisüsteemi ja blokeerivad kanaleid, mistõttu on need tõhusad. Seega, isegi kui te ei kaota serverit, laadides alla suurt faili madalatel kiirusel, blokeerite te lihtsalt sihtserveri kanali ja siis tekib teenuse katkestus.
Sellise testi näitel on selge, et kiirusel 30 RPS peatus veebisait vastamast või andis 500. viga serveris.

Ei tohiks unustada ka serverite seadistamist. Tihti võib kohata, et inimene on ostnud virtuaalserveri, installinud sinna Apache, seadistanud kõik vaikeseadetega, paigaldanud PHP-rakenduse ja allpool võib näha tulemust.

Siin kulges koormus juurtasandil ja oli vaid 10 RPS. Ootasime 5 minutit ja server kukkus kokku. Tõepoolest, ei ole selge, miks see kukkus, aga on oletus, et see lihtsalt ületas mälu ja seetõttu lõpetas vastamise.

Lainepõhine

Viimase ühe kuni kahe aasta jooksul on laineatakid muutunud üsna populaarseks. See on tingitud sellest, et paljud organisatsioonid ostavad erinevaid seadmeid DDoS-i kaitseks, mis vajavad teatud aega statistika kogumiseks, enne kui nad hakkavad rünnakut filtreerima. See tähendab, et nad ei filtreeri rünnakut esimesed 30-40 sekundit, kuna koguvad andmeid ja õpivad. Seega võib nende 30-40 sekundi jooksul veebisaidile saata nii palju päringuid, et ressurss on pikaks ajaks maas, kuni kõik päringud on läbi töödeldud.
Antud rünnaku puhul oli vahemik 10 minutit, mille järel tuli uus, muudetud rünnaku kogus.

See tähendab, et kaitse õppis, aktiveeris filtreerimise, kuid tuli täiesti uus, täiesti erinev rünnakuvoog, ja kaitse alustas uuesti õppimist. Tegelikult lakkab filtreerimine töötamast, kaitse muutub ebaefektiivseks ja veebisait ei ole kergesti ligipääsetav.
Laineatakitele on iseloomulikud väga kõrged tipud, võivad ulatuda saja tuhande või miljoni päringuni sekundis L7 puhul. Kui rääkida L3&4-st, siis seal võivad olla sadu gigabitte liiklust või vastavalt sadu mpps, kui arvestada pakettide kaupa.
Selliste rünnakute probleem on sünkroniseerimine. Rünnakud tulevad botivõrgust ja suure sündmuse loomiseks on vajalik kõrge sünkroniseerimisaste. See kooskõlastamine ei õnnestu alati: mõnikord saadakse väljundiks mingisugune paraboliline tipp, mis näeb üsna kaunis välja.

Ei ainult HTTP

Lisaks HTTP-le L7 tasemel, me armastame ka teisi protokolle ära kasutada. Tavalise veebisaidi puhul, veelgi enam tavalise hostimise puhul, on väljas postituse protokollid ja MySQL. Postituse protokollid on koormustele vähem vastuvõtlikud kui andmebaasid, kuid neidki saab koormata üsna efektiivselt, saades väljundiks serveri kõrge CPU koormuse.
Oleme täiesti reaalselt saavutanud edu SSH 2016. aasta haavatavuse kaudu. Praegu on see haavatavus peaaegu kõigis parendatud, kuid see ei tähenda, et SSH-le ei saaks koormust anda. Saab. Lihtsalt antakse tohutu autoriseerimise koormus, SSH sööb peaaegu kogu serveri CPU ja seejärel visatakse veebisait maas juba ühest-kahest päringust sekundis. Seega neid ühte-kahte päringut logides ei saa kuidagi eristada seaduslikust koormusest.
Jätkuvalt on olemas palju ühendusi, mida avame serverites. Varem oli sellega probleeme Apache'is, nüüd eksib selles osas tihti ka nginx, kuna see on tihti vaikimisi seadistatud. Nginx'i poolt avatav ühenduste arv on piiratud, seega kui see arv täis, ei saa uus ühendus enam luua, mistõttu veebisait ei tööta.
Meie testkluster omab piisavalt CPU-d, et rünnata SSL handshake'i. Praktika näitab, et botnetid armastavad seda ka teha. Ühest küljest on selge, et SSL'ist ei saa mööda, kuna see mõjutab Google'i väljundit, järjestust ja turvalisust. Teisest küljest on SSL-il kahjuks probleem CPU kasutuse poolest.

L3&4

Kui räägime L3&4 taseme rünnakutest, räägime tavaliselt kanalitaseme rünnakutest. Selline koormus on peaaegu alati eristatav legaalsest, kui tegemist ei ole SYN-flood rünnakuga. SYN-flood rünnakute probleemiks kaitsevahendite jaoks on suur maht. Maksimaalne L3&4 maht oli 1,5-2 Tbit/s. Sellist liiklust on väga raske töödelda isegi suurtele ettevõtetele, sealhulgas Oracle'ile ja Google'ile.
SYN ja SYN-ACK on paketid, mida kasutatakse ühenduse loomisel. Seetõttu on SYN-flood'i keeruline legaalsest koormusest eristada: pole selge, kas SYN tuli ühenduse loomiseks või on see osa flood'ist.

UDP-flood

Tavaliselt ei ole kurjategijatel sama võimsust, mis meil, seega võivad nad rünnakute korral kasutada amplifikatsiooni. See tähendab, et kurjategija skaneerib internetti ja leiab kas haavatavad või valesti seadistatud serverid, mis näiteks vastavad ühele SYN-paketile kolme SYN-ACK paketiga. Petetades allika aadressi sihtserveri aadressiga, saab ühe paketiga suurendada võimsust näiteks kolm korda ja suunata liiklus ohvrile.

Amplifikatsioonide probleem seisneb nende keerulises avastamises. Viimaste näidete hulka kuulub tuntud juhtum haavatava memcached'iga. Lisaks on nüüd palju IoT seadmeid, IP-kaameraid, mis on samuti enamasti vaikimisi valesti seadistatud ja seetõttu saavad kurjategijad nende kaudu rünnakuid tihti teha.

Keeruline SYN-flood

SYN-flood on tõenäoliselt kõige huvitavam rünnakutüüp arendaja vaatenurgast. Probleem on see, et süsteemiadministraatorid kasutavad sageli kaitseks IP-blokeeringut. Kahjuks kannatavad IP-blokeeringu all mitte ainult administraatorid, kes järgivad skripte, vaid ka mõned kalli raha eest ostetud kaitsesüsteemid.
Selline meetod võib osutuda katastroofiliseks, kuna kui kurjategijad annavad vale IP-aadressid, siis blokeerib ettevõte omaenda alamsüsteemi. Kui tulemüüri kaudu blokeeritakse oma klaster, võivad välised suhted kokku kukkuda ja ressurss puruneda.
Oma võrgu blokeerimine pole sugugi keeruline. Kui kliendi kontoris on WI-Fi-võrk, või kui ressursside tööd mõõdetakse erinevate jälgimissüsteemide abil, võtame selle jälgimisseadmest või kontori WI-Fi kliendi IP-aadressi ja kasutame seda allikana. Tulemusena näib, et ressurss on saadaval, kuid siht-IP-aadressid on blokeeritud. Nii võib olla blokeeritud HighLoad konverentsi Wi-Fi-võrk, kus esitletakse ettevõtte uut toodet, — ja see toob kaasa teatud ärilised ja majanduslikud kulud.
Testimise käigus ei saa me kasutada memcachedi kaudu amplifikatsiooni mingite väliste ressursside kaudu, kuna on kokkulepped liikluse edastamiseks ainult lubatud IP-aadressidele. Seetõttu kasutame amplifikatsiooni SYN ja SYN-ACK kaudu, kui ühe SYN saatmisel vastab süsteem kahe või kolme SYN-ACK-iga, ja lõpptulemusena rünnak suureneb kaks kuni kolm korda.

Tööriistad

Üks peamisi tööriistu, mida me L7 taseme koormuse jaoks kasutame, on Yandex-tank. Täpsemalt kasutatakse kui suurtükki fantoomi, lisaks on mitmeid skripte, et genereerida kuulid ja analüüsida tulemusi.
Võrguliikluse analüüsimiseks kasutatakse Tcpdumpi, serveri analühüüsiks — Nmapi. L3&4 taseme koormuse tekitamiseks kasutatakse OpenSSL-i ja veidi oma maagiat DPDK raamatukoguga. DPDK on Intelilt saadud raamatukogu, mis võimaldab töötada võrgu liidesega, mööda minnes Linuxi virnast, parandades seeläbi efektiivsust. Loomulikult kasutame DPDK-d mitte ainult L3&4 tasemel, vaid ka L7 tasemel, kuna see võimaldab genereerida väga suurt koormust, ulatudes miljonite päringuteni sekundis ühest masinast.
Kasutame ka teatud liiklust genereerivaid tööriistu ja spetsiaalseid vahendeid, mida kirjutame konkreetsete testide jaoks. Kui meenutada SSH haavatavust, siis eeltoodud komplektiga ei saa seda ära kasutada. Kui ründame e-posti protokolli, siis võtame kasutusele e-posti tööriistad või kirjutame neile lihtsalt skripte.

Järeldused

Kokkuvõtteks sooviksin öelda:

• Lisaks klassikalisele koormustestimisele tuleb kindlasti läbi viia ka stressitestimine. Meil on reaalne näide, kus partneri alltöövõtja viis läbi ainult koormustestimise. See näitas, et ressurss talub ettenähtud koormust. Kuid seejärel ilmus ettenägematu koormus, veebisaidi külastajad hakkasid ressursi kasutama veidi muul moel, — ja tulemuseks jäi alltöövõtja seisma. Seega, haavatavuste otsimine on vajalik, isegi kui te juba kaitsete end DDoS-rünnakute eest.
• On oluline isoleerida ühed osad süsteemist teistest. Kui teil on otsing, tuleb see viia eraldi masinatesse, isegi mitte Dockerisse. Sest kui otsing või autentimine ebaõnnestuvad, siis vähemalt midagi jätkab tööd. Internetipoe puhul saavad kasutajad jätkuvalt leida tooteid kataloogist, liikuda kinnisvaraportaalist, ostma, kui nad on juba autentitud, või autentima end OAuth2 kaudu.
• Ärge alahinnake igasuguseid pilveteenuseid.
• Kasutage CDN-i mitte ainult võrgulähenemise optimeerimiseks, vaid ka kaitsevahendina kanalite ammendamise rünnakute ja lihtsalt staatilise fludi eest.
• On vajalik kasutada spetsialiseeritud kaitsete teenuseid. L3&4 rünnakute kaitsmine kanalitasemel on keeruline, sest tõenäoliselt pole teil piisavalt kanalit. L7 rünnakutelt kaitsmine on samuti keeruline, kuna need võivad olla väga suured. Lisaks on väikeste rünnakute leidmine siiski spetsiaalsete teenuste ja algoritmide privileeg.
• Uuendage regulaarselt. See kehtib mitte ainult tuuma, vaid ka SSH deemonite kohta, eriti kui need on avatud väljastpoolt. Üldiselt tuleks uuendada kõike, sest te tõenäoliselt ei suuda iseseisvalt jälgida teatud haavatavusi.

Allikas: habr.com