{"id":31924,"date":"2019-10-31T21:44:01","date_gmt":"2019-10-31T18:44:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy\/"},"modified":"2019-10-31T21:44:01","modified_gmt":"2019-10-31T18:44:01","slug":"ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","title":{"rendered":"DDoS abi: kuidas me l\u00e4bime stressi- ja koormustestid","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DDoS
\n
\nEttev\u00f5te Variti arendab botivastast kaitset ja DDoS-r\u00fcnnakute vastu, samuti viib l\u00e4bi stressi- ja koormustestimist. Konverentsil HighLoad++ 2018 r\u00e4\u00e4kisime, kuidas kaitsta ressursse erinevate r\u00fcnnakute eest. L\u00fchidalt: isoleerige s\u00fcsteemi osi, kasutage pilveteenuseid ja CDN-i ning uuendage regulaarselt. Kuid ilma spetsialiseeritud kaitsefirmadeta ei suuda te siiski hakkama saada \ud83d\ude42<\/i>
\n<\/a><\/noindex>
\nEnne teksti lugemist v\u00f5ite tutvuda l\u00fchikeste kokkuv\u00f5tetega konverentsi veebisaidil<\/a><\/noindex>.
\nJa kui te ei armasta lugemist v\u00f5i soovite lihtsalt videot vaadata, siis allpool spoliers jaotises on meie ettekande salvestus.<\/p>\n

Ettekande video<\/b>

\r\n \"M\u00e4ngi\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Paljud ettev\u00f5tted oskavad juba teha koormusteste, kuid mitte k\u00f5ik ei tee stressiteste. M\u00f5ned meie kliendid arvavad, et nende veebisait on haavatamatu, sest neil on highload s\u00fcsteem, mis kaitseb r\u00fcnnakute eest. Me n\u00e4itame, et see ei ole kaugeltki t\u00f5si.
\nMuidugi saame enne testide l\u00e4biviimist kliendilt loa, allkirja ja templiga, ja meie abiga ei saa DDoS-r\u00fcnnakut kellelegi teha. Testimine toimub kliendi valitud ajal, kui tema ressursi k\u00fclastatavus on minimaalne ja ligip\u00e4\u00e4su probleemid ei kajastu klientides. Lisaks, kuna testimise ajal v\u00f5ib alati juhtuda midagi ootamatut, on meil pidev kontakt kliendiga. See v\u00f5imaldab mitte ainult saavutatud tulemusi edastada, vaid ka testimise k\u00e4igus midagi muuta. Testimise l\u00f5ppedes koostame alati aruande, kus m\u00e4rgime avastatud puudused ja anname soovitusi n\u00f5rkade kohtade k\u00f5rvaldamiseks veebisaidil. <\/p>\n

Kuidas me t\u00f6\u00f6tame<\/h3>\n

\nTestimise l\u00e4biviimisel emuleerime botiv\u00f5rku. Kuna t\u00f6\u00f6tame klientidega, kes ei asu meie v\u00f5rkudes, siis et test ei l\u00f5ppeks esimese minuti jooksul limiitide v\u00f5i kaitse aktiveerimise t\u00f5ttu, suuname koormuse mitte \u00fchelt IP-aadressilt, vaid oma alamv\u00f5rgust. Lisaks on meil piisavalt v\u00f5imas testserver, et genereerida m\u00e4rkimisv\u00e4\u00e4rset koormust.<\/p>\n

Postulaadid<\/h3>\n

<\/p>\n

Palju \u2014 ei t\u00e4henda h\u00e4sti<\/b>
\nMida v\u00e4iksem on koormus, millega suudame ressursi rikki ajada, seda parem. Kui saame saavutada, et veebisait l\u00f5petab toimimise \u00fche p\u00e4ringu sekundis v\u00f5i isegi \u00fche p\u00e4ringu minutis, oleks see suurep\u00e4rane. Sest Murphy seaduse kohaselt satuvad kasutajad v\u00f5i pahatahtlikud isikud juhuslikult just sellesse haavasse. <\/p><\/blockquote>\n

Osaline rike on parem kui t\u00e4ielik<\/b>
\nSoovitame alati, et s\u00fcsteemid oleksid heterogeensed. Ja neid tuleks jagada f\u00fc\u00fcsilisel tasandil, mitte ainult konteineriseerimisega. F\u00fc\u00fcsilise eraldamise korral, isegi kui veebisaidil midagi eba\u00f5nnestub, on t\u00f5en\u00e4osus, et see ei lakkaks t\u00e4ielikult toimimast, suur ja kasutajatel s\u00e4ilib juurdep\u00e4\u00e4s v\u00e4hemalt osa funktsionaalsusele.<\/p><\/blockquote>\n

\u00d5ige arhitektuur on stabiilsuse alus<\/b>
\nRessursi t\u00f5rke taluvus ja selle v\u00f5ime taluda r\u00fcnnakuid ja koormusi peaksid olema kavandatud juba projekteerimise etapil, sisuliselt esimestel mustritel joonistades. Sest kui sisse imbuvad fataalsed vead, on hiljem nende parandamine v\u00f5imalik, kuid v\u00e4ga keeruline.<\/p><\/blockquote>\n

Hea peaks olema mitte ainult kood, vaid ka konfiguratsioon<\/b>
\nPaljud arvavad, et hea arendusmeeskond tagab teenuse t\u00f5rke taluvuse. Hea arendusmeeskond on t\u00f5epoolest vajalik, kuid vajalik on ka hea kasutus, hea DevOps. Ehk on vajalikud spetsialistid, kes konfigureerivad \u00f5igesti Linuxi ja v\u00f5rgu, kirjutavad \u00f5igesti nginx\u2019i konfiguratsioonid, seadistavad limiidid jne. Vastasel juhul t\u00f6\u00f6tab ressurss h\u00e4sti ainult katses, kuid tootmises murdub mingi hetk k\u00f5ik kokku.<\/p><\/blockquote>\n

Koormuse ja stressitestimise erinevused<\/b>
\nKoormustestimine v\u00f5imaldab tuvastada s\u00fcsteemi toimimise piire. Stressitestimine on suunatud s\u00fcsteemi n\u00f5rkade kohtade leidmisele ja seda kasutatakse selleks, et s\u00fcsteemi purustada ja vaadata, kuidas see k\u00e4itub teatud osade rikke korral. Samas j\u00e4\u00e4b koormuse iseloom tavaliselt kliendile teadmata enne stressitestimise algust.<\/p><\/blockquote>\n

<\/p>\n

L7 r\u00fcnnakute erip\u00e4rad<\/h3>\n

\nLiike koormusi jagame tavaliselt L7 ja L3&4 tasemete koormusteks. L7 on rakenduse taseme koormus, mille alla m\u00f5istetakse k\u00f5ige sagedamini ainult HTTP, kuid meie m\u00f5istame alla igasugust koormust TCP protokolli tasemel.
\nL7 r\u00fcnnakutel on teatavad iseloomulikud tunnused. Esiteks, need tulevad otse rakendusse, seega ei ole neid t\u00f5en\u00e4oliselt v\u00f5imalik v\u00f5rgu vahenditega peegeldada. Sellised r\u00fcnnakud kasutavad loogikat ja seet\u00f5ttu tarbivad nad v\u00e4ga efektiivselt CPU-d, m\u00e4lu, ketast, andmebaasi ja muid ressursse, isegi v\u00e4ikese liikluse korral.<\/p>\n

HTTP Flood<\/h3>\n

\nIga r\u00fcnnaku korral on koormuse tekitamine lihtsam kui selle t\u00f6\u00f6tlemine ja L7 puhul on see samuti t\u00f5si. R\u00fcnnaku liiklust on sageli keeruline eristada seaduslikust liiklusest ning enamikul juhtudel on v\u00f5imalik seda teha ainult sageduse p\u00f5hjal. Kuid kui k\u00f5ik on korralikult planeeritud, on logide p\u00f5hjal v\u00f5imatu m\u00f5ista, kus on r\u00fcnnak ja kus seaduslikud p\u00e4ringud.
\nEsimese n\u00e4itena vaatleme HTTP Flood r\u00fcnnakut. Graafikult on n\u00e4ha, et sellised r\u00fcnnakud on tavaliselt v\u00e4ga v\u00f5imsad; allolevas n\u00e4ites \u00fcletas haripunktis tehtud p\u00e4ringute arv 600 000 minutis.<\/p>\n

\"DDoS
\n
\nHTTP Flood on k\u00f5ige lihtsam viis koormuse tekitamiseks. Tavaaliselt kasutatakse selleks mingit koormustestimise t\u00f6\u00f6riista, n\u00e4iteks ApacheBench, ja m\u00e4\u00e4ratakse p\u00e4ring ja siht. Sellise lihtsa l\u00e4henemise puhul on suur t\u00f5en\u00e4osus sattuda serveri caching'usse, kuid seda on lihtne \u00fcle petta. N\u00e4iteks lisades p\u00e4ringusse juhuslikke kujundeid, mis sunnib serverit pidevalt uuendama lehte.
\n\u00c4rge unustage, et koormuse tekitamise protsessis on oluline ka user-agent. Paljusid populaarsest testimisest kasutatavad user-agent'id filtreerivad s\u00fcsteemiadministratorid, ja siis v\u00f5ib koormus lihtsalt mitte j\u00f5uda tausts\u00fcsteemi. Tulemusi on oluliselt v\u00f5imalik parandada, lisades p\u00e4ringusse enam-v\u00e4hem valideeritud veebibrauseri pealkirja.
\nMaljerpoli all lihtsuses, HTTP Flood r\u00fcnnakutel on ka oma puudused. Esiteks, koormuse tekitamiseks on vaja suurt v\u00f5imsust. Teiseks, sellised r\u00fcnnakud on v\u00e4ga kergesti tuvastatavad, eriti kui nad tulevad \u00fchest aadressist. L\u00f5ppkokkuv\u00f5ttes hakkavad p\u00e4ringud koheselt filtreerima kas s\u00fcsteemiadministraatorid v\u00f5i isegi teenusepakkuja tasemel. <\/p>\n

Mida otsida<\/h3>\n

\nKuna v\u00e4hendada sekundis esitatavate p\u00e4ringute arvu, kaotamata samas efektiivsust, tuleb veidi loovust ja uurida saiti. Niisiis, koormata v\u00f5ib mitte ainult kanalit v\u00f5i serverit, vaid ka konkreetseid rakenduse osi, n\u00e4iteks andmebaase v\u00f5i failis\u00fcsteeme. Samuti tasub otsida kohti saidil, mis teevad suuri arvutusi: kalkulaatorid, tooteotsingu lehed jne. L\u00f5puks juhtub tihti, et saidil on mingi php-skript, mis genereerib lehe mitmest sajast tuhandest reast. Selline skript koormab samuti serverit suurel m\u00e4\u00e4ral ja v\u00f5ib muutuda r\u00fcnnaku objektiks.<\/p>\n

Kus otsida<\/h3>\n

\nKui me skaneerime ressurssi enne testimise l\u00e4biviimist, vaatame k\u00f5igepealt loomulikult saiti endalt. Otsime igasuguseid sisendv\u00e4lju, suuri faile \u2014 k\u00f5ike, mis v\u00f5ib ressursile probleeme tekitada ja selle t\u00f6\u00f6d aeglustada. Siin aitavad tavalised arendustooted Google Chrome'is ja Firefoxis, mis n\u00e4itavad lehe vastuseaega.
\nSamuti skaneerime alamdomeene. N\u00e4iteks on olemas mingi veebipood, abc.com, ja sellel on alamdomeen admin.abc.com. T\u00f5en\u00e4oliselt on see administraatorirakendus, kuid kui sellele koormust rakendada, v\u00f5ib see peamise ressursi jaoks probleeme tekitada.
\nSaidil v\u00f5ib olla alamdomeen api.abc.com. T\u00f5en\u00e4oliselt on see ressurss mobiilirakenduste jaoks. Rakenduse leidmiseks v\u00f5ib minna App Store'i v\u00f5i Google Play'sse, seadistada spetsiaalne juurdep\u00e4\u00e4supunkt, anal\u00fc\u00fcsida API-d ja registreerida testkonto. Probleem on selles, et tihti arvavad inimesed, et k\u00f5ik, mis on autoriseerimisega kaitstud, on teenuse keelamise r\u00fcnnakute suhtes haavatamatu. Oletatakse, et autoriseerimine on parim CAPTCHA, kuid see pole nii. 10\u201320 testkonto loomine on lihtne ja nende loomisega saame juurdep\u00e4\u00e4su keerulisele ja avatud funktsionaalsusele.
\nMuidugi vaatame ajalugu, robots.txt ja WebArchive'i, ViewDNS-i, otsime ressursi vanu versioone. Vahel juhtub, et arendajad k\u00e4ivitavad, \u00fctleme, mail2.yandex.net, kuid vana versioon, mail.yandex.net, j\u00e4\u00e4b alles. See mail.yandex.net l\u00f5petab toe saamise, selle arendamiseks ei eraldata ressursse, kuid see j\u00e4tkab andmebaasi tarbimist. Seega saab vana versiooni abil t\u00f5husalt kasutada tagapool olevaid ressursse ja k\u00f5ike, mis on seotud kujundusega. Loomulikult see ei juhtu alati, kuid me kohtame sarnaste olukordadega ikka ja j\u00e4lle suhteliselt tihti.
\nMuidugi uurime k\u00f5iki p\u00e4ringu parameetreid ja k\u00fcpsiste struktuuri. Saame n\u00e4iteks JSON-massiivi k\u00fcpsisesse mingi v\u00e4\u00e4rtuse ja luua suure sisemise struktuuri, sundides ressursi t\u00f6\u00f6tama erilise aeglusega.<\/p>\n

Otsingu koormus<\/h3>\n

\nEsimene asi, mis p\u00e4he tuleb, kui uurida veebisaiti, on andmebaasi koormamine, kuna otsing on peaaegu k\u00f5igis ja enamikul neist on kahjuks n\u00f5rk kaitse. Miks arendajad j\u00e4\u00e4vad otsingu piisavalt t\u00e4helepanuta? Kuid siin on soovitus \u2014 v\u00e4ltige \u00fchesuguste p\u00e4ringute tegemist, sest v\u00f5ite kokku puutuda vahem\u00e4luga, nagu ka HTTP \u00fclekoormuse korral.
\nOtsingu jaoks andmebaasi juhuslike p\u00e4ringute tegemine ei ole ka alati efektiivne. Oluliselt parem on koostada loetelu m\u00e4rks\u00f5nadest, mis on seotud otsinguga. Kui p\u00f6\u00f6rduda tagasi n\u00e4ite juurde, kus veebipood m\u00fc\u00fcb autoteste ja v\u00f5imaldab m\u00e4\u00e4rata rehvide raadiust, autotype'i ja muid parameetreid. Seega kombinatsioonid asjakohastest s\u00f5nadest panevad andmebaasi t\u00f6\u00f6tama palju keerulisemates tingimustes.
\nLisaks on soovitatav kasutada lehek\u00fclgede jagamist: otsingul on palju keerulisem n\u00e4idata eelviimast otsingutulemust, kui esimest. Seega saab lehek\u00fclgede jagamise abil koormust veidi mitmekesistada.
\nAllpool on n\u00e4idatud otsingu koormus. N\u00e4hes, et juba testi esimesel sekundil k\u00fcmne p\u00e4ringu tasa hukkas sait ja ei vastanud.<\/p>\n

\"DDoS
\n<\/p>\n

Mis juhtub, kui otsingut ei ole?<\/h3>\n

\nKui otsingut ei ole, ei t\u00e4henda see, et sait ei sisaldaks teisi haavatavaid sisendv\u00e4lju. Selliseks v\u00e4ljad v\u00f5ivad olla autoriseerimine. Praegu armastavad arendajad luua keerulisi r\u00e4si, et kaitsta sisselogimise andmebaasi r\u00fcndamise eest kaarelistest tabelitest. See on hea, aga sellised r\u00e4si tarbivad palju CPU ressurssi. Suur valeautoriseerimise voog toob kaasa protsessori kokkuvarisemise ja seet\u00f5ttu l\u00f5petab sait t\u00f6\u00f6tamise.
\nErinevate kommentaari- ja tagasiside vormide olemasolu veebisaidil on p\u00f5hjus saata sinna v\u00e4ga suuri tekste v\u00f5i lihtsalt luua massilist r\u00e4mpsposti. M\u00f5nikord aktsepteerivad saidid ka sissehainetud faile, sealhulgas gzip-formaadis. Sellisel juhul v\u00f5tame 1TB faili, komprimeerime selle gzip abil paariks baitiks v\u00f5i kilobaitiks ja saadame saidile. Edasi dekompressitakse see ja saadakse v\u00e4ga huvitav efekt. <\/p>\n

Rest API<\/h3>\n

\nSooviksime p\u00f6\u00f6rata natuke t\u00e4helepanu praegu populaarsetele teenustele, nagu Rest API. Rest API kaitsmine on palju keerulisem kui tavalise veebisaidi. Rest API jaoks ei t\u00f6\u00f6ta isegi tavalised parooliv\u00f5tmise ja muu ebaseadusliku tegevuse kaitsemeetodid.
\nRest API-d on v\u00e4ga lihtne rikki minna, kuna see p\u00f6\u00f6rdub otse andmebaasi poole. Sellegipoolest v\u00f5ib sellise teenuse v\u00e4lja l\u00fclitamine kaasa tuua piisavalt t\u00f5siseid tagaj\u00e4rgi \u00e4ri jaoks. Asi on selles, et Rest API on tavaliselt seotud mitte ainult pea veebisaidiga, vaid ka mobiilirakenduste ja muude sisemiste \u00e4riallikatega. Ja kui k\u00f5ik see kokku kukub, on m\u00f5ju palju t\u00f5sisemat, kui lihtsalt tavalise veebisaidi rikki minek. <\/p>\n

Raske sisu koormus<\/h3>\n

\nKui meile pakutakse testida m\u00f5nda tavalist \u00fche lehe rakendust, maandumist v\u00f5i visiitkaarti, millel ei ole keerulisi funktsioone, siis otsime rasket sisu. N\u00e4iteks suured pildid, mida server edastab, binaarfailid, pdf-dokumendid - proovime k\u00f5ike seda alla laadida. Sellised testid koormavad h\u00e4sti failis\u00fcsteemi ja blokeerivad kanaleid, mist\u00f5ttu on need t\u00f5husad. Seega, isegi kui te ei kaota serverit, laadides alla suurt faili madalatel kiirusel, blokeerite te lihtsalt sihtserveri kanali ja siis tekib teenuse katkestus.
\nSellise testi n\u00e4itel on selge, et kiirusel 30 RPS peatus veebisait vastamast v\u00f5i andis 500. viga serveris.<\/p>\n

\"DDoS
\n
\nEi tohiks unustada ka serverite seadistamist. Tihti v\u00f5ib kohata, et inimene on ostnud virtuaalserveri, installinud sinna Apache, seadistanud k\u00f5ik vaikeseadetega, paigaldanud PHP-rakenduse ja allpool v\u00f5ib n\u00e4ha tulemust. <\/p>\n

\"DDoS
\n
\nSiin kulges koormus juurtasandil ja oli vaid 10 RPS. Ootasime 5 minutit ja server kukkus kokku. T\u00f5epoolest, ei ole selge, miks see kukkus, aga on oletus, et see lihtsalt \u00fcletas m\u00e4lu ja seet\u00f5ttu l\u00f5petas vastamise.<\/p>\n

Lainep\u00f5hine<\/h3>\n

\nViimase \u00fche kuni kahe aasta jooksul on laineatakid muutunud \u00fcsna 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\u00fcnnakut filtreerima. See t\u00e4hendab, et nad ei filtreeri r\u00fcnnakut esimesed 30-40 sekundit, kuna koguvad andmeid ja \u00f5pivad. Seega v\u00f5ib nende 30-40 sekundi jooksul veebisaidile saata nii palju p\u00e4ringuid, et ressurss on pikaks ajaks maas, kuni k\u00f5ik p\u00e4ringud on l\u00e4bi t\u00f6\u00f6deldud.
\nAntud r\u00fcnnaku puhul oli vahemik 10 minutit, mille j\u00e4rel tuli uus, muudetud r\u00fcnnaku kogus.<\/p>\n

\"DDoS
\n
\nSee t\u00e4hendab, et kaitse \u00f5ppis, aktiveeris filtreerimise, kuid tuli t\u00e4iesti uus, t\u00e4iesti erinev r\u00fcnnakuvoog, ja kaitse alustas uuesti \u00f5ppimist. Tegelikult lakkab filtreerimine t\u00f6\u00f6tamast, kaitse muutub ebaefektiivseks ja veebisait ei ole kergesti ligip\u00e4\u00e4setav.
\nLaineatakitele on iseloomulikud v\u00e4ga k\u00f5rged tipud, v\u00f5ivad ulatuda saja tuhande v\u00f5i miljoni p\u00e4ringuni sekundis L7 puhul. Kui r\u00e4\u00e4kida L3&4-st, siis seal v\u00f5ivad olla sadu gigabitte liiklust v\u00f5i vastavalt sadu mpps, kui arvestada pakettide kaupa.
\nSelliste r\u00fcnnakute probleem on s\u00fcnkroniseerimine. R\u00fcnnakud tulevad botiv\u00f5rgust ja suure s\u00fcndmuse loomiseks on vajalik k\u00f5rge s\u00fcnkroniseerimisaste. See koosk\u00f5lastamine ei \u00f5nnestu alati: m\u00f5nikord saadakse v\u00e4ljundiks mingisugune paraboliline tipp, mis n\u00e4eb \u00fcsna kaunis v\u00e4lja.<\/p>\n

Ei ainult HTTP<\/h3>\n

\nLisaks HTTP-le L7 tasemel, me armastame ka teisi protokolle \u00e4ra kasutada. Tavalise veebisaidi puhul, veelgi enam tavalise hostimise puhul, on v\u00e4ljas postituse protokollid ja MySQL. Postituse protokollid on koormustele v\u00e4hem vastuv\u00f5tlikud kui andmebaasid, kuid neidki saab koormata \u00fcsna efektiivselt, saades v\u00e4ljundiks serveri k\u00f5rge CPU koormuse.
\nOleme t\u00e4iesti reaalselt saavutanud edu SSH 2016. aasta haavatavuse kaudu. Praegu on see haavatavus peaaegu k\u00f5igis parendatud, kuid see ei t\u00e4henda, et SSH-le ei saaks koormust anda. Saab. Lihtsalt antakse tohutu autoriseerimise koormus, SSH s\u00f6\u00f6b peaaegu kogu serveri CPU ja seej\u00e4rel visatakse veebisait maas juba \u00fchest-kahest p\u00e4ringust sekundis. Seega neid \u00fchte-kahte p\u00e4ringut logides ei saa kuidagi eristada seaduslikust koormusest.
\nJ\u00e4tkuvalt on olemas palju \u00fchendusi, mida avame serverites. Varem oli sellega probleeme Apache'is, n\u00fc\u00fcd eksib selles osas tihti ka nginx, kuna see on tihti vaikimisi seadistatud. Nginx'i poolt avatav \u00fchenduste arv on piiratud, seega kui see arv t\u00e4is, ei saa uus \u00fchendus enam luua, mist\u00f5ttu veebisait ei t\u00f6\u00f6ta.
\nMeie testkluster omab piisavalt CPU-d, et r\u00fcnnata SSL handshake'i. Praktika n\u00e4itab, et botnetid armastavad seda ka teha. \u00dchest k\u00fcljest on selge, et SSL'ist ei saa m\u00f6\u00f6da, kuna see m\u00f5jutab Google'i v\u00e4ljundit, j\u00e4rjestust ja turvalisust. Teisest k\u00fcljest on SSL-il kahjuks probleem CPU kasutuse poolest. <\/p>\n

L3&4<\/h3>\n

\nKui r\u00e4\u00e4gime L3&4 taseme r\u00fcnnakutest, r\u00e4\u00e4gime tavaliselt kanalitaseme r\u00fcnnakutest. Selline koormus on peaaegu alati eristatav legaalsest, kui tegemist ei ole SYN-flood r\u00fcnnakuga. SYN-flood r\u00fcnnakute probleemiks kaitsevahendite jaoks on suur maht. Maksimaalne L3&4 maht oli 1,5-2 Tbit\/s. Sellist liiklust on v\u00e4ga raske t\u00f6\u00f6delda isegi suurtele ettev\u00f5tetele, sealhulgas Oracle'ile ja Google'ile.
\nSYN ja SYN-ACK on paketid, mida kasutatakse \u00fchenduse loomisel. Seet\u00f5ttu on SYN-flood'i keeruline legaalsest koormusest eristada: pole selge, kas SYN tuli \u00fchenduse loomiseks v\u00f5i on see osa flood'ist.<\/p>\n

UDP-flood<\/h3>\n

\nTavaliselt ei ole kurjategijatel sama v\u00f5imsust, mis meil, seega v\u00f5ivad nad r\u00fcnnakute korral kasutada amplifikatsiooni. See t\u00e4hendab, et kurjategija skaneerib internetti ja leiab kas haavatavad v\u00f5i valesti seadistatud serverid, mis n\u00e4iteks vastavad \u00fchele SYN-paketile kolme SYN-ACK paketiga. Petetades allika aadressi sihtserveri aadressiga, saab \u00fche paketiga suurendada v\u00f5imsust n\u00e4iteks kolm korda ja suunata liiklus ohvrile.<\/p>\n

\"DDoS
\n
\nAmplifikatsioonide probleem seisneb nende keerulises avastamises. Viimaste n\u00e4idete hulka kuulub tuntud juhtum haavatava memcached'iga. Lisaks on n\u00fc\u00fcd palju IoT seadmeid, IP-kaameraid, mis on samuti enamasti vaikimisi valesti seadistatud ja seet\u00f5ttu saavad kurjategijad nende kaudu r\u00fcnnakuid tihti teha. <\/p>\n

\"DDoS
\n<\/p>\n

Keeruline SYN-flood<\/h3>\n

\nSYN-flood on t\u00f5en\u00e4oliselt k\u00f5ige huvitavam r\u00fcnnakut\u00fc\u00fcp arendaja vaatenurgast. Probleem on see, et s\u00fcsteemiadministraatorid kasutavad sageli kaitseks IP-blokeeringut. Kahjuks kannatavad IP-blokeeringu all mitte ainult administraatorid, kes j\u00e4rgivad skripte, vaid ka m\u00f5ned kalli raha eest ostetud kaitses\u00fcsteemid.
\nSelline meetod v\u00f5ib osutuda katastroofiliseks, kuna kui kurjategijad annavad vale IP-aadressid<\/a>, siis blokeerib ettev\u00f5te omaenda alams\u00fcsteemi. Kui tulem\u00fc\u00fcri kaudu blokeeritakse oma klaster, v\u00f5ivad v\u00e4lised suhted kokku kukkuda ja ressurss puruneda.
\nOma v\u00f5rgu blokeerimine pole sugugi keeruline. Kui kliendi kontoris on WI-Fi-v\u00f5rk, v\u00f5i kui ressursside t\u00f6\u00f6d m\u00f5\u00f5detakse erinevate j\u00e4lgimiss\u00fcsteemide abil, v\u00f5tame selle j\u00e4lgimisseadmest v\u00f5i kontori WI-Fi kliendi IP-aadressi ja kasutame seda allikana. Tulemusena n\u00e4ib, et ressurss on saadaval, kuid siht-IP-aadressid on blokeeritud. Nii v\u00f5ib olla blokeeritud HighLoad konverentsi Wi-Fi-v\u00f5rk, kus esitletakse ettev\u00f5tte uut toodet, \u2014 ja see toob kaasa teatud \u00e4rilised ja majanduslikud kulud.
\nTestimise k\u00e4igus ei saa me kasutada memcachedi kaudu amplifikatsiooni mingite v\u00e4liste ressursside kaudu, kuna on kokkulepped liikluse edastamiseks ainult lubatud IP-aadressidele. Seet\u00f5ttu kasutame amplifikatsiooni SYN ja SYN-ACK kaudu, kui \u00fche SYN saatmisel vastab s\u00fcsteem kahe v\u00f5i kolme SYN-ACK-iga, ja l\u00f5pptulemusena r\u00fcnnak suureneb kaks kuni kolm korda. <\/p>\n

T\u00f6\u00f6riistad<\/h3>\n

\n\u00dcks peamisi t\u00f6\u00f6riistu, mida me L7 taseme koormuse jaoks kasutame, on Yandex-tank. T\u00e4psemalt kasutatakse kui suurt\u00fckki fantoomi, lisaks on mitmeid skripte, et genereerida kuulid ja anal\u00fc\u00fcsida tulemusi.
\nV\u00f5rguliikluse anal\u00fc\u00fcsimiseks kasutatakse Tcpdumpi, serveri anal\u00fch\u00fc\u00fcsiks \u2014 Nmapi. L3&4 taseme koormuse tekitamiseks kasutatakse OpenSSL-i ja veidi oma maagiat DPDK raamatukoguga. DPDK on Intelilt saadud raamatukogu, mis v\u00f5imaldab t\u00f6\u00f6tada v\u00f5rgu liidesega, m\u00f6\u00f6da minnes Linuxi virnast, parandades seel\u00e4bi efektiivsust. Loomulikult kasutame DPDK-d mitte ainult L3&4 tasemel, vaid ka L7 tasemel, kuna see v\u00f5imaldab genereerida v\u00e4ga suurt koormust, ulatudes miljonite p\u00e4ringuteni sekundis \u00fchest masinast.
\nKasutame ka teatud liiklust genereerivaid t\u00f6\u00f6riistu ja spetsiaalseid vahendeid, mida kirjutame konkreetsete testide jaoks. Kui meenutada SSH haavatavust, siis eeltoodud komplektiga ei saa seda \u00e4ra kasutada. Kui r\u00fcndame e-posti protokolli, siis v\u00f5tame kasutusele e-posti t\u00f6\u00f6riistad v\u00f5i kirjutame neile lihtsalt skripte.<\/p>\n

\n

J\u00e4reldused<\/h3>\n

\nKokkuv\u00f5tteks sooviksin \u00f6elda:<\/p>\n