{"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 abistamisel: kuidas me teeme stressi- ja koormusteste","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DDoS
\n
\nEttev\u00f5te Variti arendab kaitset robotite ja DDoS-r\u00fcnnakute eest ning viib l\u00e4bi stressi- ja koormusteste. Konverentsil HighLoad++ 2018 r\u00e4\u00e4kisime, kuidas kaitsta ressursse erinevatest r\u00fcnnakutest. L\u00fchidalt: isoleerige s\u00fcsteemi osad, kasutage pilveteenuseid ja CDN-i ning v\u00e4rskendage regulaarselt. Kuid ilma spetsialiseeritud kaitset pakkuvate ettev\u00f5teteta ei saa te siiski hakkama \ud83d\ude42<\/i>
\n<\/a><\/noindex>
\nEnne teksti lugemist v\u00f5ite tutvuda l\u00fchikeste kokkuv\u00f5tetega konverentsi kodulehel<\/a><\/noindex>.
\nJa kui te ei armasta lugeda v\u00f5i soovite lihtsalt videot vaadata, on meie ettekande salvestus all spoileris.<\/p>\n

Ettekande video salvestus<\/b>

\r\n \"Vaata\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 kaitstud, kuna neil on highload s\u00fcsteem, mis kaitseb h\u00e4sti r\u00fcnnakute eest. Me aga n\u00e4itame, et see ei ole p\u00e4ris t\u00f5si.
\nMuidugi, enne testide l\u00e4biviimist saame kliendilt loa, allkirja ja pitseriga; meie abiga ei saa DDoS-r\u00fcnnakut teha kellelegi. Testimine toimub kliendi valitud ajal, mil tema ressursi k\u00fclastatavus on minimaalne, ja juurdep\u00e4\u00e4su probleemid ei m\u00f5juta kliente. Lisaks, kuna testimise k\u00e4igus v\u00f5ib alati midagi valesti minna, oleme pidevas kontaktis kliendiga. See v\u00f5imaldab mitte ainult saavutatud tulemusi teatada, vaid ka testimise ajal muudatusi teha. Testimise l\u00f5ppedes koostame alati aruande, milles toome v\u00e4lja tuvastatud puudused ja anname soovitusi saidi n\u00f5rkade kohtade likvideerimiseks. <\/p>\n

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

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

Postulaadid<\/h3>\n

<\/p>\n

Palju ei t\u00e4henda tingimata head<\/b>
\nMida v\u00e4iksema koormusega suudame ressursi rikki viia, seda parem. Kui suudame teha nii, et veebisait l\u00f5petab funktsioneerimise \u00fche p\u00e4ringu sekundis v\u00f5i isegi \u00fche p\u00e4ringu minutis, oleks see suurep\u00e4rane. Sest pahatahtlikult v\u00f5i lihtsalt juhuslikult satuvad kasutajad v\u00f5i r\u00fcndajad just sellesse n\u00f5rkusse. <\/p><\/blockquote>\n

Osaline rike on parem kui t\u00e4ielik<\/b>
\nSoovitame alati luua heterogeenseid s\u00fcsteeme. Need tuleks v\u00e4lja jagada just f\u00fc\u00fcsilisel tasandil, mitte ainult konteineriseerimise teel. F\u00fc\u00fcsilise jagamise korral, isegi kui saidil midagi eba\u00f5nnestub, on suur t\u00f5en\u00e4osus, et see ei lakkaks t\u00e4ielikult t\u00f6\u00f6tamast, ja kasutajatel oleks juurdep\u00e4\u00e4s v\u00e4hemalt osale funktsionaalsusest.<\/p><\/blockquote>\n

\u00d5ige arhitektuur on vastupidavuse alus<\/b>
\nRessursi rikke kindel ja tema v\u00f5ime taluda r\u00fcnnakuid ja koormusi tuleb kavandamise etapis, tegelikult juba esialgsete plokkdiagrammide joonistamise faasis, paika panna. Sest kui suurte vigadega rikutakse, on nende hilisem parandamine v\u00f5imalik, kuid v\u00e4ga keeruline.<\/p><\/blockquote>\n

Head ei peaks olema ainult koodis, vaid ka konfiguraatoris<\/b>
\nPaljud arvavad, et hea arendustiim on teenuse usaldusv\u00e4\u00e4rsuse garantii. Hea arendustiim on t\u00f5epoolest vajalik, kuid samuti on vajalik ka hea hooldus ja korralik DevOps. See t\u00e4hendab, et on vaja spetsialiste, kes konfigureerivad Linuxi ja v\u00f5rgu \u00f5igesti, kirjutavad nginx-i konfigureerimisfailid \u00f5igesti, seadistavad piirangud ja muud asjad. Vastasel juhul t\u00f6\u00f6tab ressurss h\u00e4sti ainult testimisel, kuid tootmises v\u00f5ib see mingil hetkel kokku kukkuda.<\/p><\/blockquote>\n

Koormuse ja stressitestoerimise erinevused<\/b>
\nKoormustestimine v\u00f5imaldab tuvastada s\u00fcsteemi toimimise piire. Stressitesting on suunatud s\u00fcsteemi n\u00f5rkade kohtade leidmisele ja selleks, et katsetada, kuidas s\u00fcsteem k\u00e4itub, kui osad sellest peaksid eba\u00f5nnestuma. Samuti on koormuse iseloom tavaliselt tellijale enne stressitesti algust teadmata.<\/p><\/blockquote>\n

<\/p>\n

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

\nMe jagame tavaliselt koormusi L7 ja L3&4 tasemele. L7 on rakendustasandi koormus, mida m\u00f5istetakse enamasti ainult HTTP-na, kuid meie all m\u00f5istame igasugust koormust TCP protokolli tasemel.
\nL7 r\u00fcnnakutel on teatud iseloomulikud jooned. Esiteks, need suunduvad otse rakendusse, mist\u00f5ttu nende kajastamine v\u00f5rgus on t\u00f5en\u00e4oliselt keeruline. Sellised r\u00fcnnakud h\u00f5lmavad loogikat ning seet\u00f5ttu tarbivad nad v\u00e4ga t\u00f5husalt, isegi v\u00e4ikese liikluse korral, CPU-d, m\u00e4lu, ketast, andmebaasi ja muid ressursse.<\/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 ei ole alati lihtne eristada legitiimsest ja enamikul juhtudel on seda v\u00f5imalik teha sageduse alusel, kuid kui k\u00f5ik on targalt planeeritud, siis logide p\u00f5hjal ei ole v\u00f5imalik aru saada, kus on r\u00fcnnak ja kus legitiimsed p\u00e4ringud.
\nEsimese n\u00e4itena vaatame HTTP Flood r\u00fcnnakut. Graafikult on n\u00e4ha, et sellised r\u00fcnnakud on tavaliselt v\u00e4ga tugevad, allolevas n\u00e4ites \u00fcletas tipup\u00e4ringute arv 600 000 minutis.<\/p>\n

\"DDoS
\n
\nHTTP Flood \u2014 lihtsaim viis koormuse tekitamiseks. Selleks kasutatakse tavaliselt m\u00f5nd koormustestimise t\u00f6\u00f6riista, n\u00e4iteks ApacheBench, kus m\u00e4\u00e4ratakse p\u00e4ring ja siht. Sellise lihtsa l\u00e4henemisega on suur t\u00f5en\u00e4osus serveri vahem\u00e4llu j\u00e4\u00e4da, kuid seda on lihtne v\u00e4ltida, n\u00e4iteks lisades p\u00e4ringusse juhuslikke ridu, mis sunnib serverit pidevalt v\u00e4rske lehte tagastama.
\n\u00c4rge unustage ka kasutajaliidest koormuse loomise protsessis. Paljusid populaarsete testimise t\u00f6\u00f6riistade kasutajaliideseid filtreerivad s\u00fcsteemiadministraatorid, ja sellisel juhul koormus ei pruugi isegi tagasiside j\u00f5uda. Oluliselt saab tulemust parandada, lisades p\u00e4ringusse \u00fcmber v\u00f5i v\u00e4hem kehtiva brauseri p\u00e4ise.
\nKuigi HTTP Flood'i r\u00fcnnakud on lihtsad, on neil ka oma puudused. Esiteks n\u00f5uavad nad suurteressursse koormuse tekitamiseks. Teiseks, sellised r\u00fcnnakud on v\u00e4ga lihtsad tuvastada, eriti kui need tulevad \u00fchelt aadressilt. L\u00f5ppkokkuv\u00f5ttes hakkavad p\u00e4ringud kohe filtreerima kas s\u00fcsteemiadministraatorid v\u00f5i isegi teenusepakkuja tasemel. <\/p>\n

Mida otsida<\/h3>\n

\nSelleks, et v\u00e4hendada p\u00e4ringute arvu sekundis, kaotamata samas efektiivsust, on vaja natuke loominguliselt l\u00e4heneda ja uurida veebisaiti. Koormust saab jagada mitte ainult kanalile v\u00f5i serverile, vaid ka rakenduse eriosadele, n\u00e4iteks andmebaasidele v\u00f5i failis\u00fcsteemidele. Samuti tasub otsida veebisaidi kohti, kus toimuvad suured arvutused: kalkulaatorid, tootevalikulehed ja muud sarnased. L\u00f5puks juhtub sageli, et veebisaidil on olemas php-skript, mis genereerib lehe sadadest tuhandetest ridadest. Selline skript koormab samuti serverit ja v\u00f5ib saada r\u00fcnnaku sihtm\u00e4rgiks.<\/p>\n

Kust otsida<\/h3>\n

\nKui skanneerime ressursi enne testimist, vaatame esmalt muidugi veebisaiti ise. Otsime erinevaid sisendi murdekohti, suured failid - k\u00f5ike, mis v\u00f5ib ressursile probleeme tekitada ja selle t\u00f6\u00f6d aeglustada. Abiks on ka tavalised arendust\u00f6\u00f6riistad Google Chrome'is ja Firefoxis, mis n\u00e4itavad lehe vastamisaegu.
\nMe scanime ka subdomeene. N\u00e4iteks on veebipoe, abc.com, subdomeen admin.abc.com. T\u00f5en\u00e4oliselt on see administraatori liides, mis on kaitstud sisselogimisega, kuid kui sellele koormust rakendada, v\u00f5ib see tekitada probleeme p\u00f5hiveebile.
\nVeebisaidil v\u00f5ib olla subdomeen api.abc.com. T\u00f5en\u00e4oliselt on see ressurss mobiilirakenduste jaoks. Rakenduse v\u00f5ib leida App Store'ist v\u00f5i Google Play'ist, seadistada eripunkti, anal\u00fc\u00fcsida API-d ja registreerida testkonto. Probleem on aga selles, et sageli arvavad inimesed, et k\u00f5ik, mis on kaitstud sisselogimisega, on teenuset\u00f5kestamise r\u00fcnnakute suhtes haavatamatud. Oletatakse, et sisselogimine on parim CAPTCHA, kuid see ei ole t\u00f5si. 10-20 testkontot loomine on lihtne, ja kui need on loodud, saame juurdep\u00e4\u00e4su keerulisele ja katmata funktsionaalsusele.
\nMuidugi vaatame me ajaloo, robots.txt ja WebArchive'i kaudu, otsime lehe varasemaid versioone. Aeg-ajalt juhtub, et arendajad saavad k\u00e4ima n\u00e4iteks mail2.yandex.net, samas kui vana versioon, mail.yandex.net, j\u00e4\u00e4b alles. See mail.yandex.net l\u00f5petab toetamised, selle arendustegevusele ei suunata ressursse, kuid see j\u00e4tkab andmebaasi tarbimist. Seega saab vana versiooni abil efektiivselt kasutada tagaplaneerimise ja k\u00f5igi nende ressursside potentsiaali, mis on seostatavad kujundusega. Loomulikult ei juhtu see alati, kuid sarnaste olukordadega kohtume siiski suhteliselt tihti.
\nMuidugi anal\u00fc\u00fcsime k\u00f5iki p\u00e4ringuparametreid ja k\u00fcpsiste struktuuri. N\u00e4iteks saame k\u00fcpsisesse JSON massiivi panna mingi v\u00e4\u00e4rtuse, luua suure sisemise struktuuri ja sundida ressursi toimima ebanormaalset pikka aega.<\/p>\n

Koormus otsingus<\/h3>\n

\nEsimene asi, mis p\u00e4he tuleb veebilehe uurimisel, on andmebaasi koormamine, kuna otsing on peaaegu k\u00f5igil ja kahjuks on see enamasti halvasti kaitstud. Miks arendajad ei p\u00f6\u00f6ra otsingule piisavalt t\u00e4helepanu? Siin on \u00fcks soovitus \u2013 \u00e4rge tehke sarnaseid p\u00e4ringuid, sest v\u00f5ite kokku puutuda vahem\u00e4luga, nagu HTTP \u00fclekoormuse puhul.
\nJuhuslike p\u00e4ringute tegemine andmebaasi pole ka alati t\u00f5hus. Palju parem on koostada m\u00e4rks\u00f5nade nimekiri, mis on seotud otsinguga. Kui tuua n\u00e4iteks internetipood: oletame, et veebileht m\u00fc\u00fcb autokehade ja v\u00f5imaldab seadistada rehvide raadiust, auto t\u00fc\u00fcpi ja muid parameetreid. Seega, asjakohaste s\u00f5nade kombinatsioonid panevad andmebaasi t\u00f6\u00f6tama palju keerulisemates tingimustes.
\nLisaks tasub kasutada lehtede jagamist: otsingul on palju keerulisem esitada eelviimast tulemuste lehte kui esimest. Teisis\u00f5nu, lehtede jagamisega saab koormust veidi mitmekesistada.
\nAlloleval n\u00e4itel illustreerime otsingu koormust. On n\u00e4ha, et juba testimise esimesel sekundil k\u00fcmne p\u00e4ringu sekundis kukkus leht kokku ja ei vastanud.<\/p>\n

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

Mida teha, kui otsingut ei leidu?<\/h3>\n

\nKui otsingut ei leidu, ei t\u00e4henda see, et saidil ei ole teisi haavatavaid sisestusv\u00e4lju. \u00dcheks selliseks v\u00f5ib olla autoriseerimine. Arendajad armastavad luua keerulisi r\u00e4si, et kaitsta sisselogimise andmebaasi r\u00fcnnakute eest radari tabelite abil. See on hea, kuid sellised r\u00e4si n\u00f5uavad suures mahus CPU ressursse. Suur valeautorisatsioonide voog v\u00f5ib p\u00f5hjustada protsessori \u00fclekoormuse, mis omakorda toob kaasa saidi toimimise peatamise.
\nSaidil olevad erinevad kommentaaride ja tagasiside vormid v\u00f5ivad olla p\u00f5hjus, miks sealt saadetakse v\u00e4ga suuri tekste v\u00f5i luuakse lihtsalt massilist sp\u00e4mmimist. M\u00f5nikord aktsepteerivad saidid manuseid, sealhulgas gzip formaadis. Sel juhul v\u00f5tame 1TB faili, tihendame selle gzipiga mitme baitini v\u00f5i kilobaidini ja saadame saidile. Seej\u00e4rel dekomprimeeritakse see ja tulemuseks on v\u00e4ga huvitav efekt. <\/p>\n

Rest API<\/h3>\n

\nSooviksin p\u00f6\u00f6rata veidi t\u00e4helepanu 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\u00fcnnakute ja muu ebaseadusliku tegevuse kaitsemeetodid.
\nRest API on v\u00e4ga lihtne rikutud, kuna see teeb otse\u00fchenduse andmebaasiga. Sellise teenuse t\u00f6\u00f6 katkestamine toob kaasa t\u00f5sised tagaj\u00e4rjed \u00e4ritegevusele. Fakt on see, et Rest API on tavaliselt seotud mitte ainult peamise veebisaidiga, vaid ka mobiilirakendusega ning erinevate sisemiste \u00e4riressurssidega. Ja kui see k\u00f5ik kokku kukub, on m\u00f5ju palju intensiivsem kui lihtsalt tavalise veebisaidi riknemisel. <\/p>\n

Raske sisu koormus<\/h3>\n

\nKui meile pakutakse v\u00e4lja testida m\u00f5nda tavap\u00e4rast \u00fchekordset rakendust, maandumislehte v\u00f5i visiitkaardivetti, millel pole keerulist funktsionaalsust, otsime me rasket sisu. N\u00e4iteks suured pildid, mida server edastab, binaarfailid, PDF-dokumendid \u2013 proovime k\u00f5ike seda allalaadida. Sellised testid koormavad h\u00e4sti failis\u00fcsteemi ja ummistavad kanaleid, seega on need t\u00f5husad. See t\u00e4hendab, et isegi kui te ei pane serverit kinni, allalaadides suurt faili madalatel kiirusel, ummistate te lihtsalt sihtserveri kanali ja seega tekib teenuse t\u00f5rge.
\nSellise testi n\u00e4itel on selgelt n\u00e4ha, et kiirusel 30 RPS l\u00f5petas veebisait vastamise v\u00f5i andis v\u00e4lja 500. serveri vead.<\/p>\n

\"DDoS
\n
\n\u00c4rge unustage serverite seadistamist. Tihti juhtub, et inimene ostab virtuaalmasina, paigaldab sinna Apache'i, seadistab k\u00f5ik vaikimisi ja paigutab php-rakenduse; allpool n\u00e4ete selle tulemusi. <\/p>\n

\"DDoS
\n
\nSiin toimus koormus juurest ja see oli vaid 10 RPS. Ootasime 5 minutit ja server kukkus. T\u00f5si on see, et l\u00f5puni ei ole teada, miks see kukkus, kuid on oletus, et lihtsalt m\u00e4lu jagus otsa ja seet\u00f5ttu l\u00f5petas see vastamise.<\/p>\n

P\u00f5hjaline laine<\/h3>\n

\nViimase aasta-kahe jooksul on lainep\u00f5hised r\u00fcnnakud muutunud \u00fcsna populaarseks. See on tingitud sellest, et paljud organisatsioonid ostavad teatud riistvara DDoS-i kaitseks, mis n\u00f5uab teatud aega statistika kogumiseks r\u00fcnnaku filtrimiseks. See t\u00e4hendab, et nad ei filtreeri r\u00fcnnakut esimestel 30-40 sekundil, kuna koguvad andmeid ja \u00f5pivad. Seega on nendel 30-40 sekundil v\u00f5imalik saata veebisaidile nii palju, et ressurss j\u00e4\u00e4b pikaks ajaks maas, kuni k\u00f5ik p\u00e4ringud saavad lahendatud.
\nAntud r\u00fcnnaku puhul oli intervall 10 minutit, p\u00e4rast mida saabus uus, muudetud r\u00fcnnaku osa.<\/p>\n

\"DDoS
\n
\nEhk siis kaitse on \u00f5ppinud, k\u00e4ivitanud filtreerimise, kuid saabub uus, t\u00e4iesti erinev r\u00fcnnakute osa ja kaitse alustab uuesti \u00f5ppimist. Tegelikult l\u00f5petab filtreerimine t\u00f6\u00f6tamise, kaitse muutub ebaefektiivseks ja veebileht ei ole enam ligip\u00e4\u00e4setav.
\nLaine r\u00fcnnakutele on iseloomulikud v\u00e4ga k\u00f5rged v\u00e4\u00e4rtused haripunktis, need v\u00f5ivad ulatuda sadade tuhandete v\u00f5i miljoni p\u00e4ringuni sekundis, kui r\u00e4\u00e4kida L7-st. L3 ja L4 puhul v\u00f5ib seal olla sadu gigabitte liiklust, v\u00f5i vastavalt sadu mpps, kui arvestada pakettide kaupa.
\nSelliste r\u00fcnnakute probleem seisneb s\u00fcnkroonimises. R\u00fcnnakud tulevad botiv\u00f5rkudest, ja et luua v\u00e4ga suur \u00fchekordne tipp, on vajalik k\u00f5rge s\u00fcnkroonimise tase. Ja see koordineerimine ei alati \u00f5nnestu: m\u00f5nikord saadakse v\u00e4lja mingi paraboolne tipp, mis n\u00e4eb \u00fcsna kahtlane v\u00e4lja.<\/p>\n

Ei ela HTTP ainu\u00fcksi<\/h3>\n

\nLisaks L7 taseme HTTP-le, meeleme kasutada ka teisi protokolle. \u00dcldiselt v\u00e4ljastavad tavalised veebi saidid, eriti tavalise hostimisega, v\u00e4lja postitusprotokolle ja MySQL-i. Postitusprotokollid taluvad koormusi v\u00e4hem kui andmebaasid, kuid neid saab koormata siiski \u00fcsna efektiivselt, mille tulemuseks on serveri k\u00f5rge CPU koormus.
\nMe saavutasime t\u00e4iesti reaalselt SSH 2016. aasta haavatavuse abil edu. Praeguseks on see haavatavus enamikus s\u00fcsteemides parandatud, kuid see ei t\u00e4henda, et SSH-le ei saaks koormust anda. Saab k\u00fcll. Lihtsalt antakse tohutut autoriseerimiskoormust, SSH kasutab peaaegu kogu serveri CPU-d ja edasi veebisait kukub alla juba \u00fche v\u00f5i kahe p\u00e4ringu t\u00f5ttu sekundis. Seega ei saa logide p\u00f5hjal neid \u00fchte v\u00f5i kahte p\u00e4ringut kuidagi eristada legaalsest koormusest.
\nKas meie serverites avatakse endiselt palju \u00fchendusi. Varem polnud sellega probleeme Apache'is, kuid praegu on see n\u00e4htav ka nginx'is, kuna seda seadistatakse sageli vaikimisi. Nginx suudab hoida avatud teatud arvu \u00fchendusi, mist\u00f5ttu kui see piir on \u00fcletatud, ei aktsepteeri nginx uut \u00fchendust ja veebisait ei t\u00f6\u00f6ta.
\nMeie testklaster omab piisavalt CPU-d, et r\u00fcnnata SSL handshake'i. Tegelikkuses meeldib seda m\u00f5nikord teha ka botnet'idele. \u00dchelt poolt on selge, et SSL on h\u00e4davajalik, kuna see m\u00f5jutab Google'i otsingu tulemust, j\u00e4rjestust ja turvalisust. Teisalt, kahjuks on SSL-l ka teatud probleemid CPU kasutuses. <\/p>\n

L3&4<\/h3>\n

\nKui r\u00e4\u00e4gime L3&4 tasandi r\u00fcnnakutest, r\u00e4\u00e4gime tavaliselt kanalitasandi r\u00fcnnakust. Selline koormus on peaaegu alati eristatav legaalsest, v\u00e4lja arvatud juhul, kui tegemist on SYN-flood r\u00fcnnakuga. SYN-flood r\u00fcnnakute probleemiks kaitsemeetmete jaoks on suur maht. L3&4 maksimaalne kiirus ulatus 1,5-2 Tbit\/s. Sellist liiklust on isegi suurte ettev\u00f5tete, sealhulgas Oracle'i ja Google'i, jaoks v\u00e4ga keeruline t\u00f6\u00f6delda.
\nSYN ja SYN-ACK on pakette, mida kasutatakse \u00fchenduse loomisel. Seet\u00f5ttu on SYN-floodi raske eristada legitiimsest koormusest: pole selge, kas see on SYN, mis tuli \u00fchenduse loomiseks, v\u00f5i osa flood'ist.<\/p>\n

UDP-flood<\/h3>\n

\nTavaliselt ei ole kurjategijatel nii suured ressursid nagu meil, seet\u00f5ttu v\u00f5ib r\u00fcnnakute korraldamiseks kasutada amplifikatsiooni. See t\u00e4hendab, et kurjategija skaneerib Internetti ja leiab kas haavatavad v\u00f5i valesti seadistatud serverid, mis n\u00e4iteks vastavad \u00fche SYN-paketi peale kolme SYN-ACK paketi. Petlikult allika aadressi muutes v\u00f5imalik \u00fche paketiga suurendada v\u00f5imsust n\u00e4iteks kolm korda ja suunata liiklus ohvrile.<\/p>\n

\"DDoS
\n
\nAmplifikatsioonide probleem seisneb nende keerulises tuvastamises. Viimaste n\u00e4idete seas v\u00f5ib tuua v\u00e4lja kuulsa juhtumi haavatavast memcached'ist. Lisaks on n\u00fc\u00fcd palju IoT-seadmeid, IP-kaameraid, mis on ka peamiselt vaikeseadistusega ja valesti seadistatud, mist\u00f5ttu kurjategijad kasutavad tihti just selliseid seadmeid r\u00fcnnakute l\u00e4biviimiseks. <\/p>\n

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

Keeruline SYN-flood<\/h3>\n

\nSYN-flood on ilmselt k\u00f5ige huvitavam r\u00fcnnaku t\u00fc\u00fcp arendaja vaatenurgast. Probleem on selles, et sageli kasutavad s\u00fcsteemiadministraatorid kaitseks IP-aadresside blokeerimist. Samuti kannatavad IP-aadresside blokeerimise all mitte ainult adminnid, kes j\u00e4rgivad skripte, vaid kahjuks ka m\u00f5ned kallid kaitses\u00fcsteemid.
\nSelline meetod v\u00f5ib tuua kaasa katastroofi, sest kui kurjategijad asendavad IP-aadressid<\/a>, blokeerib ettev\u00f5te enda alamv\u00f5rgu. Kui tulem\u00fc\u00fcr blokeerib enda klastrit, siis v\u00e4lised suhted lagunevad ja ressurss puruneb.
\nOma v\u00f5rgu blokeerimine pole keeruline. Kui kliendi b\u00fcroos on Wi-Fi-v\u00f5rk, v\u00f5i kui ressursi t\u00f6\u00f6kindlust m\u00f5\u00f5detakse erinevate monitooringute abil, siis v\u00f5tame selle monitooringus\u00fcsteemi v\u00f5i b\u00fcroo kliendi Wi-Fi IP-aadressi ja kasutame seda allikana. Tulemuseks n\u00e4ib ressurss olevat saadaval, kuid siht-IP-aadressid on blokeeritud. Nii v\u00f5ib olla blokeeritud n\u00e4iteks HighLoad konverentsi Wi-Fi-v\u00f5rk, kus esitletakse ettev\u00f5tte uut toodet, mis toob endaga kaasa teatud \u00e4rilised ja majanduslikud kulud.
\nTestimise k\u00e4igus ei saa me kasutada memcached'i suurendamist v\u00e4liste ressursside kaudu, kuna on kokkulepped, et liiklus suunatakse ainult lubatud IP-aadressidesse. Seega kasutame amplifikatsiooni SYN ja SYN-ACK kaudu, kus \u00fche SYN saatmise peale vastab s\u00fcsteem kahe v\u00f5i kolme SYN-ACK'iga, ja tulemuseks on r\u00fcnnaku kahekordistumine v\u00f5i kolmekordistumine. <\/p>\n

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

\n\u00dcks peamisi t\u00f6\u00f6riistu, mida kasutame L7 taseme koormuse tekitamiseks, on Yandex-tank. Eelk\u00f5ige kasutatakse tohutuna Phantom'i, lisaks on meil mitmeid skripte, mis genereerivad kuulide koormust ja anal\u00fc\u00fcsivad tulemusi.
\nV\u00f5rguliikluse anal\u00fc\u00fcsimiseks kasutatakse Tcpdump'i ja serveri anal\u00fc\u00fcsiks Nmap'i. L3&4 taseme koormuse tekitamiseks kasutatakse OpenSSL'i ja veidi oma maagiat DPDK raamatukoguga. DPDK on Inteli raamatukogu, mis v\u00f5imaldab t\u00f6\u00f6tada v\u00f5rgu liidesega, m\u00f6\u00f6da minnes Linuxi virnast, suurendades efektiivsust. Loomulikult kasutame DPDK't mitte ainult L3&4 tasemel, vaid ka L7 tasemel, kuna see v\u00f5imaldab luua v\u00e4ga k\u00f5rge koormuse voolu, ulatudes miljonite p\u00e4ringuteni sekundis \u00fchest masinast.
\nKasutame ka teatud liiklust genereerivaid t\u00f6\u00f6riistu ja spetsiaalseid t\u00f6\u00f6riistu, mida kirjutame konkreetsete testide jaoks. Kui meenutada SSH haavatavust, siis ei saa sissetoodud meetodit kasutada. Kui r\u00fcndame postiprotokolli, kasutame postiteenuseid v\u00f5i kirjutame lihtsalt nende peale skripte.<\/p>\n

\n

J\u00e4reldused<\/h3>\n

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