DDoS abistamisel: kuidas me teeme stressi- ja koormusteste

Ettevõte Variti arendab kaitset robotite ja DDoS-rünnakute eest ning viib läbi stressi- ja koormusteste. Konverentsil HighLoad++ 2018 rääkisime, kuidas kaitsta ressursse erinevatest rünnakutest. Lühidalt: isoleerige süsteemi osad, kasutage pilveteenuseid ja CDN-i ning värskendage regulaarselt. Kuid ilma spetsialiseeritud kaitset pakkuvate ettevõteteta ei saa te siiski hakkama 🙂

Enne teksti lugemist võite tutvuda lühikeste kokkuvõtetega konverentsi kodulehel.
Ja kui te ei armasta lugeda või soovite lihtsalt videot vaadata, on meie ettekande salvestus all spoileris.

Ettekande video salvestus

Paljud ettevõtted oskavad juba teha koormusteste, kuid mitte kõik ei tee stressiteste. Mõned meie kliendid arvavad, et nende veebisait on kaitstud, kuna neil on highload süsteem, mis kaitseb hästi rünnakute eest. Me aga näitame, et see ei ole päris tõsi.
Muidugi, enne testide läbiviimist saame kliendilt loa, allkirja ja pitseriga; meie abiga ei saa DDoS-rünnakut teha kellelegi. Testimine toimub kliendi valitud ajal, mil tema ressursi külastatavus on minimaalne, ja juurdepääsu probleemid ei mõjuta kliente. Lisaks, kuna testimise käigus võib alati midagi valesti minna, oleme pidevas kontaktis kliendiga. See võimaldab mitte ainult saavutatud tulemusi teatada, vaid ka testimise ajal muudatusi teha. Testimise lõppedes koostame alati aruande, milles toome välja tuvastatud puudused ja anname soovitusi saidi nõrkade kohtade likvideerimiseks.

Kuidas me töötame

Testimise läbiviimisel emuleerime botivõrku. Kuna me töötame klientidega, kes ei asu meie võrkudes, et test ei lõppeks esimesel minutil limiitide või kaitse aktiveerimise tõttu, suuname koormuse mitte ühelt IP-lt, vaid oma alamvõrgust. Lisaks, et tekitada märkimisväärset koormust, on meil oma piisavalt võimas testiserver.

Postulaadid

Palju ei tähenda tingimata head
Mida väiksema koormusega suudame ressursi rikki viia, seda parem. Kui suudame teha nii, et veebisait lõpetab funktsioneerimise ühe päringu sekundis või isegi ühe päringu minutis, oleks see suurepärane. Sest pahatahtlikult või lihtsalt juhuslikult satuvad kasutajad või ründajad just sellesse nõrkusse.

Osaline rike on parem kui täielik
Soovitame alati luua heterogeenseid süsteeme. Need tuleks välja jagada just füüsilisel tasandil, mitte ainult konteineriseerimise teel. Füüsilise jagamise korral, isegi kui saidil midagi ebaõnnestub, on suur tõenäosus, et see ei lakkaks täielikult töötamast, ja kasutajatel oleks juurdepääs vähemalt osale funktsionaalsusest.

Õige arhitektuur on vastupidavuse alus
Ressursi rikke kindel ja tema võime taluda rünnakuid ja koormusi tuleb kavandamise etapis, tegelikult juba esialgsete plokkdiagrammide joonistamise faasis, paika panna. Sest kui suurte vigadega rikutakse, on nende hilisem parandamine võimalik, kuid väga keeruline.

Head ei peaks olema ainult koodis, vaid ka konfiguraatoris
Paljud arvavad, et hea arendustiim on teenuse usaldusväärsuse garantii. Hea arendustiim on tõepoolest vajalik, kuid samuti on vajalik ka hea hooldus ja korralik DevOps. See tähendab, et on vaja spetsialiste, kes konfigureerivad Linuxi ja võrgu õigesti, kirjutavad nginx-i konfigureerimisfailid õigesti, seadistavad piirangud ja muud asjad. Vastasel juhul töötab ressurss hästi ainult testimisel, kuid tootmises võib see mingil hetkel kokku kukkuda.

Koormuse ja stressitestoerimise erinevused
Koormustestimine võimaldab tuvastada süsteemi toimimise piire. Stressitesting on suunatud süsteemi nõrkade kohtade leidmisele ja selleks, et katsetada, kuidas süsteem käitub, kui osad sellest peaksid ebaõnnestuma. Samuti on koormuse iseloom tavaliselt tellijale enne stressitesti algust teadmata.

L7 rünnakute eripärad

Me jagame tavaliselt koormusi L7 ja L3&4 tasemele. L7 on rakendustasandi koormus, mida mõistetakse enamasti ainult HTTP-na, kuid meie all mõistame igasugust koormust TCP protokolli tasemel.
L7 rünnakutel on teatud iseloomulikud jooned. Esiteks, need suunduvad otse rakendusse, mistõttu nende kajastamine võrgus on tõenäoliselt keeruline. Sellised rünnakud hõlmavad loogikat ning seetõttu tarbivad nad väga tõhusalt, isegi väikese liikluse korral, CPU-d, mälu, ketast, andmebaasi ja muid ressursse.

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 ei ole alati lihtne eristada legitiimsest ja enamikul juhtudel on seda võimalik teha sageduse alusel, kuid kui kõik on targalt planeeritud, siis logide põhjal ei ole võimalik aru saada, kus on rünnak ja kus legitiimsed päringud.
Esimese näitena vaatame HTTP Flood rünnakut. Graafikult on näha, et sellised rünnakud on tavaliselt väga tugevad, allolevas näites ületas tipupäringute arv 600 000 minutis.

HTTP Flood — lihtsaim viis koormuse tekitamiseks. Selleks kasutatakse tavaliselt mõnd koormustestimise tööriista, näiteks ApacheBench, kus määratakse päring ja siht. Sellise lihtsa lähenemisega on suur tõenäosus serveri vahemällu jääda, kuid seda on lihtne vältida, näiteks lisades päringusse juhuslikke ridu, mis sunnib serverit pidevalt värske lehte tagastama.
Ärge unustage ka kasutajaliidest koormuse loomise protsessis. Paljusid populaarsete testimise tööriistade kasutajaliideseid filtreerivad süsteemiadministraatorid, ja sellisel juhul koormus ei pruugi isegi tagasiside jõuda. Oluliselt saab tulemust parandada, lisades päringusse ümber või vähem kehtiva brauseri päise.
Kuigi HTTP Flood'i rünnakud on lihtsad, on neil ka oma puudused. Esiteks nõuavad nad suurteressursse koormuse tekitamiseks. Teiseks, sellised rünnakud on väga lihtsad tuvastada, eriti kui need tulevad ühelt aadressilt. Lõppkokkuvõttes hakkavad päringud kohe filtreerima kas süsteemiadministraatorid või isegi teenusepakkuja tasemel.

Mida otsida

Selleks, et vähendada päringute arvu sekundis, kaotamata samas efektiivsust, on vaja natuke loominguliselt läheneda ja uurida veebisaiti. Koormust saab jagada mitte ainult kanalile või serverile, vaid ka rakenduse eriosadele, näiteks andmebaasidele või failisüsteemidele. Samuti tasub otsida veebisaidi kohti, kus toimuvad suured arvutused: kalkulaatorid, tootevalikulehed ja muud sarnased. Lõpuks juhtub sageli, et veebisaidil on olemas php-skript, mis genereerib lehe sadadest tuhandetest ridadest. Selline skript koormab samuti serverit ja võib saada rünnaku sihtmärgiks.

Kust otsida

Kui skanneerime ressursi enne testimist, vaatame esmalt muidugi veebisaiti ise. Otsime erinevaid sisendi murdekohti, suured failid - kõike, mis võib ressursile probleeme tekitada ja selle tööd aeglustada. Abiks on ka tavalised arendustööriistad Google Chrome'is ja Firefoxis, mis näitavad lehe vastamisaegu.
Me scanime ka subdomeene. Näiteks on veebipoe, abc.com, subdomeen admin.abc.com. Tõenäoliselt on see administraatori liides, mis on kaitstud sisselogimisega, kuid kui sellele koormust rakendada, võib see tekitada probleeme põhiveebile.
Veebisaidil võib olla subdomeen api.abc.com. Tõenäoliselt on see ressurss mobiilirakenduste jaoks. Rakenduse võib leida App Store'ist või Google Play'ist, seadistada eripunkti, analüüsida API-d ja registreerida testkonto. Probleem on aga selles, et sageli arvavad inimesed, et kõik, mis on kaitstud sisselogimisega, on teenusetõkestamise rünnakute suhtes haavatamatud. Oletatakse, et sisselogimine on parim CAPTCHA, kuid see ei ole tõsi. 10-20 testkontot loomine on lihtne, ja kui need on loodud, saame juurdepääsu keerulisele ja katmata funktsionaalsusele.
Muidugi vaatame me ajaloo, robots.txt ja WebArchive'i kaudu, otsime lehe varasemaid versioone. Aeg-ajalt juhtub, et arendajad saavad käima näiteks mail2.yandex.net, samas kui vana versioon, mail.yandex.net, jääb alles. See mail.yandex.net lõpetab toetamised, selle arendustegevusele ei suunata ressursse, kuid see jätkab andmebaasi tarbimist. Seega saab vana versiooni abil efektiivselt kasutada tagaplaneerimise ja kõigi nende ressursside potentsiaali, mis on seostatavad kujundusega. Loomulikult ei juhtu see alati, kuid sarnaste olukordadega kohtume siiski suhteliselt tihti.
Muidugi analüüsime kõiki päringuparametreid ja küpsiste struktuuri. Näiteks saame küpsisesse JSON massiivi panna mingi väärtuse, luua suure sisemise struktuuri ja sundida ressursi toimima ebanormaalset pikka aega.

Koormus otsingus

Esimene asi, mis pähe tuleb veebilehe uurimisel, on andmebaasi koormamine, kuna otsing on peaaegu kõigil ja kahjuks on see enamasti halvasti kaitstud. Miks arendajad ei pööra otsingule piisavalt tähelepanu? Siin on üks soovitus – ärge tehke sarnaseid päringuid, sest võite kokku puutuda vahemäluga, nagu HTTP ülekoormuse puhul.
Juhuslike päringute tegemine andmebaasi pole ka alati tõhus. Palju parem on koostada märksõnade nimekiri, mis on seotud otsinguga. Kui tuua näiteks internetipood: oletame, et veebileht müüb autokehade ja võimaldab seadistada rehvide raadiust, auto tüüpi ja muid parameetreid. Seega, asjakohaste sõnade kombinatsioonid panevad andmebaasi töötama palju keerulisemates tingimustes.
Lisaks tasub kasutada lehtede jagamist: otsingul on palju keerulisem esitada eelviimast tulemuste lehte kui esimest. Teisisõnu, lehtede jagamisega saab koormust veidi mitmekesistada.
Alloleval näitel illustreerime otsingu koormust. On näha, et juba testimise esimesel sekundil kümne päringu sekundis kukkus leht kokku ja ei vastanud.

Mida teha, kui otsingut ei leidu?

Kui otsingut ei leidu, ei tähenda see, et saidil ei ole teisi haavatavaid sisestusvälju. Üheks selliseks võib olla autoriseerimine. Arendajad armastavad luua keerulisi räsi, et kaitsta sisselogimise andmebaasi rünnakute eest radari tabelite abil. See on hea, kuid sellised räsi nõuavad suures mahus CPU ressursse. Suur valeautorisatsioonide voog võib põhjustada protsessori ülekoormuse, mis omakorda toob kaasa saidi toimimise peatamise.
Saidil olevad erinevad kommentaaride ja tagasiside vormid võivad olla põhjus, miks sealt saadetakse väga suuri tekste või luuakse lihtsalt massilist spämmimist. Mõnikord aktsepteerivad saidid manuseid, sealhulgas gzip formaadis. Sel juhul võtame 1TB faili, tihendame selle gzipiga mitme baitini või kilobaidini ja saadame saidile. Seejärel dekomprimeeritakse see ja tulemuseks on väga huvitav efekt.

Rest API

Sooviksin pöörata veidi tähelepanu sellistele tuttavatele teenustele nagu Rest API. Rest API kaitsmine on palju keerulisem kui tavalise veebisaidi kaitsmine. Rest API puhul ei toimi isegi elementaarsed paroolide rünnakute ja muu ebaseadusliku tegevuse kaitsemeetodid.
Rest API on väga lihtne rikutud, kuna see teeb otseühenduse andmebaasiga. Sellise teenuse töö katkestamine toob kaasa tõsised tagajärjed äritegevusele. Fakt on see, et Rest API on tavaliselt seotud mitte ainult peamise veebisaidiga, vaid ka mobiilirakendusega ning erinevate sisemiste äriressurssidega. Ja kui see kõik kokku kukub, on mõju palju intensiivsem kui lihtsalt tavalise veebisaidi riknemisel.

Raske sisu koormus

Kui meile pakutakse välja testida mõnda tavapärast ühekordset rakendust, maandumislehte või visiitkaardivetti, millel pole keerulist funktsionaalsust, otsime me rasket sisu. Näiteks suured pildid, mida server edastab, binaarfailid, PDF-dokumendid – proovime kõike seda allalaadida. Sellised testid koormavad hästi failisüsteemi ja ummistavad kanaleid, seega on need tõhusad. See tähendab, et isegi kui te ei pane serverit kinni, allalaadides suurt faili madalatel kiirusel, ummistate te lihtsalt sihtserveri kanali ja seega tekib teenuse tõrge.
Sellise testi näitel on selgelt näha, et kiirusel 30 RPS lõpetas veebisait vastamise või andis välja 500. serveri vead.

Ärge unustage serverite seadistamist. Tihti juhtub, et inimene ostab virtuaalmasina, paigaldab sinna Apache'i, seadistab kõik vaikimisi ja paigutab php-rakenduse; allpool näete selle tulemusi.

Siin toimus koormus juurest ja see oli vaid 10 RPS. Ootasime 5 minutit ja server kukkus. Tõsi on see, et lõpuni ei ole teada, miks see kukkus, kuid on oletus, et lihtsalt mälu jagus otsa ja seetõttu lõpetas see vastamise.

Põhjaline laine

Viimase aasta-kahe jooksul on lainepõhised rünnakud muutunud üsna populaarseks. See on tingitud sellest, et paljud organisatsioonid ostavad teatud riistvara DDoS-i kaitseks, mis nõuab teatud aega statistika kogumiseks rünnaku filtrimiseks. See tähendab, et nad ei filtreeri rünnakut esimestel 30-40 sekundil, kuna koguvad andmeid ja õpivad. Seega on nendel 30-40 sekundil võimalik saata veebisaidile nii palju, et ressurss jääb pikaks ajaks maas, kuni kõik päringud saavad lahendatud.
Antud rünnaku puhul oli intervall 10 minutit, pärast mida saabus uus, muudetud rünnaku osa.

Ehk siis kaitse on õppinud, käivitanud filtreerimise, kuid saabub uus, täiesti erinev rünnakute osa ja kaitse alustab uuesti õppimist. Tegelikult lõpetab filtreerimine töötamise, kaitse muutub ebaefektiivseks ja veebileht ei ole enam ligipääsetav.
Laine rünnakutele on iseloomulikud väga kõrged väärtused haripunktis, need võivad ulatuda sadade tuhandete või miljoni päringuni sekundis, kui rääkida L7-st. L3 ja L4 puhul võib seal olla sadu gigabitte liiklust, või vastavalt sadu mpps, kui arvestada pakettide kaupa.
Selliste rünnakute probleem seisneb sünkroonimises. Rünnakud tulevad botivõrkudest, ja et luua väga suur ühekordne tipp, on vajalik kõrge sünkroonimise tase. Ja see koordineerimine ei alati õnnestu: mõnikord saadakse välja mingi paraboolne tipp, mis näeb üsna kahtlane välja.

Ei ela HTTP ainuüksi

Lisaks L7 taseme HTTP-le, meeleme kasutada ka teisi protokolle. Üldiselt väljastavad tavalised veebi saidid, eriti tavalise hostimisega, välja postitusprotokolle ja MySQL-i. Postitusprotokollid taluvad koormusi vähem kui andmebaasid, kuid neid saab koormata siiski üsna efektiivselt, mille tulemuseks on serveri kõrge CPU koormus.
Me saavutasime täiesti reaalselt SSH 2016. aasta haavatavuse abil edu. Praeguseks on see haavatavus enamikus süsteemides parandatud, kuid see ei tähenda, et SSH-le ei saaks koormust anda. Saab küll. Lihtsalt antakse tohutut autoriseerimiskoormust, SSH kasutab peaaegu kogu serveri CPU-d ja edasi veebisait kukub alla juba ühe või kahe päringu tõttu sekundis. Seega ei saa logide põhjal neid ühte või kahte päringut kuidagi eristada legaalsest koormusest.
Kas meie serverites avatakse endiselt palju ühendusi. Varem polnud sellega probleeme Apache'is, kuid praegu on see nähtav ka nginx'is, kuna seda seadistatakse sageli vaikimisi. Nginx suudab hoida avatud teatud arvu ühendusi, mistõttu kui see piir on ületatud, ei aktsepteeri nginx uut ühendust ja veebisait ei tööta.
Meie testklaster omab piisavalt CPU-d, et rünnata SSL handshake'i. Tegelikkuses meeldib seda mõnikord teha ka botnet'idele. Ühelt poolt on selge, et SSL on hädavajalik, kuna see mõjutab Google'i otsingu tulemust, järjestust ja turvalisust. Teisalt, kahjuks on SSL-l ka teatud probleemid CPU kasutuses.

L3&4

Kui räägime L3&4 tasandi rünnakutest, räägime tavaliselt kanalitasandi rünnakust. Selline koormus on peaaegu alati eristatav legaalsest, välja arvatud juhul, kui tegemist on SYN-flood rünnakuga. SYN-flood rünnakute probleemiks kaitsemeetmete jaoks on suur maht. L3&4 maksimaalne kiirus ulatus 1,5-2 Tbit/s. Sellist liiklust on isegi suurte ettevõtete, sealhulgas Oracle'i ja Google'i, jaoks väga keeruline töödelda.
SYN ja SYN-ACK on pakette, mida kasutatakse ühenduse loomisel. Seetõttu on SYN-floodi raske eristada legitiimsest koormusest: pole selge, kas see on SYN, mis tuli ühenduse loomiseks, või osa flood'ist.

UDP-flood

Tavaliselt ei ole kurjategijatel nii suured ressursid nagu meil, seetõttu võib rünnakute korraldamiseks kasutada amplifikatsiooni. See tähendab, et kurjategija skaneerib Internetti ja leiab kas haavatavad või valesti seadistatud serverid, mis näiteks vastavad ühe SYN-paketi peale kolme SYN-ACK paketi. Petlikult allika aadressi muutes võimalik ühe paketiga suurendada võimsust näiteks kolm korda ja suunata liiklus ohvrile.

Amplifikatsioonide probleem seisneb nende keerulises tuvastamises. Viimaste näidete seas võib tuua välja kuulsa juhtumi haavatavast memcached'ist. Lisaks on nüüd palju IoT-seadmeid, IP-kaameraid, mis on ka peamiselt vaikeseadistusega ja valesti seadistatud, mistõttu kurjategijad kasutavad tihti just selliseid seadmeid rünnakute läbiviimiseks.

Keeruline SYN-flood

SYN-flood on ilmselt kõige huvitavam rünnaku tüüp arendaja vaatenurgast. Probleem on selles, et sageli kasutavad süsteemiadministraatorid kaitseks IP-aadresside blokeerimist. Samuti kannatavad IP-aadresside blokeerimise all mitte ainult adminnid, kes järgivad skripte, vaid kahjuks ka mõned kallid kaitsesüsteemid.
Selline meetod võib tuua kaasa katastroofi, sest kui kurjategijad asendavad IP-aadressid, blokeerib ettevõte enda alamvõrgu. Kui tulemüür blokeerib enda klastrit, siis välised suhted lagunevad ja ressurss puruneb.
Oma võrgu blokeerimine pole keeruline. Kui kliendi büroos on Wi-Fi-võrk, või kui ressursi töökindlust mõõdetakse erinevate monitooringute abil, siis võtame selle monitooringusüsteemi või büroo kliendi Wi-Fi IP-aadressi ja kasutame seda allikana. Tulemuseks näib ressurss olevat saadaval, kuid siht-IP-aadressid on blokeeritud. Nii võib olla blokeeritud näiteks HighLoad konverentsi Wi-Fi-võrk, kus esitletakse ettevõtte uut toodet, mis toob endaga kaasa teatud ärilised ja majanduslikud kulud.
Testimise käigus ei saa me kasutada memcached'i suurendamist väliste ressursside kaudu, kuna on kokkulepped, et liiklus suunatakse ainult lubatud IP-aadressidesse. Seega kasutame amplifikatsiooni SYN ja SYN-ACK kaudu, kus ühe SYN saatmise peale vastab süsteem kahe või kolme SYN-ACK'iga, ja tulemuseks on rünnaku kahekordistumine või kolmekordistumine.

Tööriistad

Üks peamisi tööriistu, mida kasutame L7 taseme koormuse tekitamiseks, on Yandex-tank. Eelkõige kasutatakse tohutuna Phantom'i, lisaks on meil mitmeid skripte, mis genereerivad kuulide koormust ja analüüsivad tulemusi.
Võrguliikluse analüüsimiseks kasutatakse Tcpdump'i ja serveri analüüsiks Nmap'i. L3&4 taseme koormuse tekitamiseks kasutatakse OpenSSL'i ja veidi oma maagiat DPDK raamatukoguga. DPDK on Inteli raamatukogu, mis võimaldab töötada võrgu liidesega, mööda minnes Linuxi virnast, suurendades efektiivsust. Loomulikult kasutame DPDK't mitte ainult L3&4 tasemel, vaid ka L7 tasemel, kuna see võimaldab luua väga kõrge koormuse voolu, ulatudes miljonite päringuteni sekundis ühest masinast.
Kasutame ka teatud liiklust genereerivaid tööriistu ja spetsiaalseid tööriistu, mida kirjutame konkreetsete testide jaoks. Kui meenutada SSH haavatavust, siis ei saa sissetoodud meetodit kasutada. Kui ründame postiprotokolli, kasutame postiteenuseid või kirjutame lihtsalt nende peale skripte.

Järeldused

Kokkuvõtteks tahaksime öelda:

• Lisaks klassikalisele koormustestimisele on hädavajalik teha ka stressitestimist. Meil on reaalsed näited, kus partneri alltöövõtja teostas ainult koormustestimist. See näitas, et ressursid taluvad normaalset koormust. Kuid hiljem tekkis ebatavaline koormus, ja veebisaidi külastajad hakkasid ressurssi veidi teisiti kasutama — ja lõpuks jooksis alltöövõtja kokku. Seega on oluline otsida haavatavusi, isegi kui olete juba DDoS-rünnakute eest kaitstud.
• Oluline on isoleerida süsteemi osad üksteisest. Kui teil on otsing, tuleks see viia eraldi masinatele, mitte isegi konteinerisse. Sest kui otsing või autentimine ebaõnnestub, jääb vähemalt midagi tööle. Internetipoe puhul saavad kasutajad jätkuvalt tooteid katalooge kaudu otsida, liikuda agregaatorkeskkondadest ja osta, kui nad on juba sisse logitud, või registreeruda OAuth2 kaudu.
• Ärge alahindage erinevaid pilveteenuseid.
• Kasutage CDN-i mitte ainult võrgu viivituste optimeerimiseks, vaid ka kanali ammendamise rünnakute ja staatika selliste rünnakute eest kaitsmiseks.
• Kasutage spetsialiseeritud kaitseteenuseid. Te ei saa ise kaitsta L3&4 rünnakute eest kanalitasemel, sest tõenäoliselt pole teil lihtsalt piisavalt kanalit. L7 rünnakute vastu on samuti väga keeruline kaitsta, kuna need võivad olla väga suured. Pluss, väikeste rünnakute leidmine jääb tõepoolest spetsialistide teenuste ja algoritmide ülesandeks.
• Hoia regulaarselt uuendusi. See kehtib mitte ainult kernel'i, vaid ka SSH deemonite kohta, eriti kui need on väljas avatud. Üldiselt on soovitatav uuendada kõike, kuna on keeruline ise jälgida erinevaid haavatavusi.

Allikas: habr.com