{"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\/sl\/blog\/administrirovanie\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","title":{"rendered":"DDoS Assistance: How We Conduct Stress and Load Testing","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DDoS
\n
\nPodjetje Variti razvija za\u0161\u010dito pred boti in DDoS napadi ter izvaja stresne in obremenitvene teste. Na konferenci HighLoad++ 2018 smo govorili o tem, kako za\u0161\u010dititi vire pred razli\u010dnimi vrstami napadov. Na kratko: izolirajte dele sistema, uporabljajte obla\u010dne storitve in CDN ter redno posodabljajte. Vendar brez specializiranih podjetij za za\u0161\u010dito se vseeno ne boste mogli za\u0161\u010dititi \ud83d\ude42<\/i>
\n<\/a><\/noindex>
\nPred branjem besedila se lahko seznanite s kratkimi tezami na strani konference<\/a><\/noindex>.
\n\u010ce ne marate branja ali preprosto \u017eelite gledati video, je posnetek na\u0161ega predavanja spodaj v skrivenem delu.<\/p>\n

Posnetek predavanja<\/b>

\r\n \"Predvajaj\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Mnoge dru\u017ebe \u017ee znajo izvajati obremenitvene teste, vendar ne vse izvajajo stresne teste. Nekateri na\u0161i naro\u010dniki menijo, da je njihova spletna stran neprobojena, ker imajo visokointenzivni sistem, ki dobro \u0161\u010diti pred napadi. Mi pa dokazujemo, da to ni \u010disto res.
\nSeveda pred izvedbo testov pridobimo dovoljenje naro\u010dnika z podpisom in \u017eigom, in z na\u0161o pomo\u010djo DDoS napadov na nikogar ni mogo\u010de izvesti. Testiranje poteka v \u010dasu, ki ga izbere naro\u010dnik, ko je obremenitev njegovega vira minimalna in te\u017eave z dostopom ne vplivajo na stranke. Poleg tega, ker se lahko med testiranjem vedno zgodi kaj nepri\u010dakovanega, imamo stalni stik z naro\u010dnikom. To nam omogo\u010da, da ne le poro\u010damo o dose\u017eenih rezultatih, ampak tudi spreminjamo nekatere stvari med testiranjem. Ob zaklju\u010dku testiranja vedno pripravimo poro\u010dilo, v katerem navajamo odkrite pomanjkljivosti in dajemo priporo\u010dila za odpravo \u0161ibkih mest spletne strani. <\/p>\n

Kako delamo<\/h3>\n

\nPri izvajanju testiranja emuliramo botnet. Ker delamo s strankami, ki niso v na\u0161ih omre\u017ejih, da test ne bi kon\u010dal takoj v prvi minuti zaradi delovanja omejitev ali za\u0161\u010dite, nalagamo obremenitev ne iz enega IP, temve\u010d iz svoje podmre\u017ene skupine. Poleg tega imamo za ustvarjanje bistvene obremenitve svoj dovolj zmogljiv testni stre\u017enik.<\/p>\n

Postulati<\/h3>\n

<\/p>\n

Veliko \u2014 ne pomeni dobro<\/b>
\n\u010cim manjim optere\u0107enjem mo\u017eemo do\u0107i do kvara resursa, to je bolje. Ako uspemo da napravimo situaciju da sajt prestane da funkcioni\u0161e samo od jednog zahteva u sekundi, ili \u010dak od jednog zahteva u minutu, to bi bilo odli\u010dno. Zato \u0161to po zakonu ru\u017eno\u0107e, korisnici ili zlonamernici slu\u010dajno padnu ba\u0161 na ovu ranjivost. <\/p><\/blockquote>\n

Delimi\u010dni kvar je bolji od potpunog<\/b>
\nUvek savetujemo da sistemi budu heterogeni. I treba ih deliti upravo na fizi\u010dkom nivou, a ne samo kontejnerizacijom. U slu\u010daju fizi\u010dkog razdvajanja, \u010dak i ako ne\u0161to na sajtu zaka\u017ee, postoji velika verovatno\u0107a da ne\u0107e do\u0107i do potpunog prestanka rada, a korisnicima \u0107e biti omogu\u0107en pristup barem delu funkcionalnosti.<\/p><\/blockquote>\n

Ispravna arhitektura je osnova otpornosti<\/b>
\nOtpornost resursa i njegova sposobnost da izdr\u017ei napade i optere\u0107enja treba da se ugrade u fazi projektovanja, zapravo u fazi crtanja prvih blok dijagrama u svin\u010dniku. Jer ako se unesu fatalne gre\u0161ke, mogu\u0107e ih je ispraviti kasnije, ali veoma je te\u0161ko.<\/p><\/blockquote>\n

Dobar treba da bude ne samo kod, ve\u0107 i konfiguracija<\/b>
\nMnogi misle da dobra razvojna ekipa garantuje otpornost servisa. Dobra razvojna ekipa je zaista potrebna, ali tako\u0111e je potrebna i dobra eksploatacija, dobar DevOps. To zna\u010di da su potrebni stru\u010dnjaci koji \u0107e pravilno konfigurirati Linux i mre\u017eu, pravilno napisati konfiguracije u nginx, postaviti limite i ostalo. U suprotnom, resurs \u0107e dobro raditi samo u testu, a u produkciji \u0107e s vremenom do\u0107i do kvara.<\/p><\/blockquote>\n

Razlike izme\u0111u optere\u0107enja i stres testiranja<\/b>
\nOptere\u0107enje testiranje omogu\u0107ava da otkrijemo granice funkcionisanja sistema. Stres testiranje je usmereno na pronala\u017eenje slabih ta\u010daka sistema i koristi se da se taj sistem pokvari i vidi kako \u0107e se pona\u0161ati u procesu kvara odre\u0111enih delova. Pri tom tip optere\u0107enja obi\u010dno ostaje nepoznat klijentu do po\u010detka stres testiranja.<\/p><\/blockquote>\n

<\/p>\n

Odlike L7 napada<\/h3>\n

\nVrste optere\u0107enja obi\u010dno delimo na optere\u0107enja na L7 i L3&4 nivou. L7 je optere\u0107enje na nivou aplikacije, naj\u010de\u0161\u0107e se pod tim podrazumeva samo HTTP, dok mi podrazumevamo bilo koje optere\u0107enje na nivou TCP protokola.
\nL7 \u043d\u0430\u043fadi imajo dolo\u010dene zna\u010dilnosti. Prvi\u010d, prihajajo neposredno v aplikacijo, kar pomeni, da jih je z omre\u017enimi sredstvi te\u017eko odpraviti. Tak\u0161ni napadi uporabljajo logiko in zaradi tega zelo u\u010dinkovito in z malo prometa porabljajo CPU, pomnilnik, disk, bazo podatkov in druge vire.<\/p>\n

HTTP Flood<\/h3>\n

\nPri katerem koli napadu je la\u017eje ustvariti obremenitev kot jo obdelovati, in to velja tudi za L7. Napadni promet ni vedno enostavno razlikovati od legitimnega, najpogosteje je to mogo\u010de narediti po pogostosti, vendar \u010de je vse dobro na\u010drtovano, je nemogo\u010de razumeti iz logov, kje je napad in kje so legitimni zahtevki.
\nKot prvi primer si poglejmo napad HTTP Flood. Iz grafikona je razvidno, da so taki napadi obi\u010dajno zelo mo\u010dni; v spodnjem primeru je vrhunec \u0161tevila zahtevkov presegel 600.000 na minuto.<\/p>\n

\"DDoS
\n
\nHTTP Flood je najla\u017eji na\u010din za ustvarjanje obremenitve. Obi\u010dajno se za to vzame nek instrument za obremenitveno testiranje, na primer ApacheBench, in se zastavi zahteva in cilj. Pri tak\u0161nem preprostem pristopu je velika verjetnost, da naletimo na predpomnjenje stre\u017enika, vendar ga je enostavno obiti. Na primer, tako da dodamo naklju\u010dne vrstice v zahtevo, kar prisili stre\u017enik, da vedno vrne sve\u017eo stran.
\nPrav tako ne smemo pozabiti na user-agent pri ustvarjanju obremenitve. Mnogi user-agenti priljubljenih orodij za testiranje se filtrirajo s strani sistemskih administratorjev, in v tem primeru lahko obremenitev preprosto ne dose\u017ee backend-a. Rezultat se lahko znatno izbolj\u0161a, \u010de v zahtevo vklju\u010dimo bolj ali manj veljaven naslov iz brskalnika.
\nKljub preprostosti napada HTTP Flood ima tudi svoje pomanjkljivosti. Prvi\u010d, za ustvarjanje obremenitve so potrebne velike zmogljivosti. Drugi\u010d, taki napadi se zelo enostavno odkrijejo, zlasti \u010de prihajajo iz enega naslova. Rezultat je, da se zahtevki takoj za\u010dnejo filtrirati bodisi s strani sistemskih administratorjev bodisi celo na ravni ponudnika. <\/p>\n

Kaj iskati<\/h3>\n

\nDa bi zmanj\u0161ali \u0161tevilo zahtevkov na sekundo, ne da bi pri tem izgubili u\u010dinkovitost, je potrebno nekaj domi\u0161ljije in raziskovanja spletne strani. Obremenitev lahko povzro\u010di ne samo povezava ali stre\u017enik, ampak tudi posamezni deli aplikacije, kot so baze podatkov ali datote\u010dni sistemi. Pravno je dobro raziskati mesta na spletni strani, ki izvajajo velike izra\u010dune: kalkulatorji, strani za izbiro produktov in podobno. Kon\u010dno se pogosto zgodi, da obstaja nek php skript, ki generira stran iz ve\u010d sto tiso\u010d vrstic. Tak skript prav tako znatno obremeni stre\u017enik in lahko postane tar\u010da napada.<\/p>\n

Kje iskati<\/h3>\n

\nKo skeniramo vir pred testiranjem, najprej pogledamo seveda na samo spletno stran. I\u0161\u010demo razli\u010dna polja za vnos, te\u017eke datoteke \u2014 na splo\u0161no vse, kar lahko povzro\u010di te\u017eave viru in upo\u010dasni njegovo delovanje. Tukaj pomagajo enostavna orodja za razvijalce v Google Chrome in Firefoxu, ki prikazujejo \u010das odziva strani.
\nPrav tako skeniramo poddomene. Na primer, obstaja nek spletni prodajalec, abc.com, in ima poddomeno admin.abc.com. Verjetno gre za admin panel z prijavo, vendar \u010de vanj spu\u0161\u010damo obremenitev, lahko povzro\u010di te\u017eave za glavni vir.
\nSpletna stran ima lahko poddomeno api.abc.com. Verjetno gre za vir za mobilne aplikacije. Aplikacijo je mogo\u010de najti v App Store ali Google Play, namestiti posebno dostopno to\u010dko, dekonstruirati API in registrirati testne ra\u010dune. Problem je v tem, da mnogi ljudje pogosto mislijo, da je vse, kar je za\u0161\u010diteno z avtentikacijo, neobranljivo za napade na zavrnitev storitve. Domnevno je avtentikacija najbolj\u0161a CAPTCHA, vendar to ni res. Ustvarjanje 10-20 testnih ra\u010dunov je enostavno, in ko jih enkrat ustvarimo, pridobimo dostop do kompleksne in ne za\u0161\u010ditene funkcionalnosti.
\nSeveda gledamo zgodovino, robots.txt in WebArchive, ViewDNS in i\u0161\u010demo stare verzije vira. V\u010dasih se zgodi, da so razvijalci izdali, recimo, mail2.yandex.net, medtem ko je stara razli\u010dica, mail.yandex.net, ostala. Ta mail.yandex.net ne preneha s podporo, na njega se ne namenjajo razvojni viri, vendar \u0161e naprej porablja podatkovno bazo. Tako je mogo\u010de z uporabo stare razli\u010dice u\u010dinkovito izkoristiti vire backend-a in vsega, kar stoji za oblikovanjem. Seveda se to ne zgodi vedno, vendar se s tem kljub temu soo\u010damo kar pogosto.
\nSeveda, analiziramo vse parametre poizvedbe, strukturo pi\u0161kotkov. Lahko na primer vpi\u0161emo vrednost v JSON polje znotraj pi\u0161kotka, ustvarimo veliko hierarhijo in prisilimo vir, da deluje nerazumno dolgo.<\/p>\n

Obremenitev pri iskanju<\/h3>\n

\nPrvo, kar pride na misel pri preu\u010devanju spletnega mesta, je obremenitev baze podatkov, saj skoraj vsak ima iskalnik, in skoraj vsi so, na \u017ealost, slabo za\u0161\u010diteni. Razvijalci iz neznanega razloga ne posve\u010dajo dovolj pozornosti iskanju. Vendar je tukaj ena priporo\u010dilo \u2014 ne smete opravljati enotnih poizvedb, saj se lahko sre\u010date z okrepljenjem, kot pri HTTP floodu.
\nPrav tako naklju\u010dno poizvedovanje v bazo podatkov ni vedno u\u010dinkovito. Bolje je ustvariti seznam klju\u010dnih besed, ki se nana\u0161ajo na iskanje. \u010ce se vrnemo k primeru spletne trgovine: recimo, da spletna stran prodaja avtomobilske pnevmatike in omogo\u010da vnos premera pnevmatik, tip avtomobila in druge parametre. Kombinacije relevantnih besed bodo povzro\u010dile, da bo baza podatkov delovala v mnogo bolj zapletenih pogojih.
\nPoleg tega je smiselno uporabiti paginacijo: iskanju je veliko te\u017eje vrniti predzadnjo stran rezultatov kot prvo. To pomeni, da lahko s paginacijo nekoliko popestrite obremenitev.
\nV spodnjem primeru prikazujemo obremenitev pri iskanju. Vidimo, da je \u017ee od prve sekunde testa z desetimi poizvedbami na sekundo spletna stran padla in ni odgovarjala.<\/p>\n

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

Kaj pa, \u010de iskanja ni?<\/h3>\n

\n\u010ce iskanja ni, to ne pomeni, da spletna stran ne vsebuje drugih ranljivih vnosnih polj. Tak\u0161no polje je lahko avtentikacija. Zdaj razvijalci raje uporabljajo zapletene hashe, da za\u0161\u010ditijo bazo prijav pred napadi z mavri\u010dnimi tabelami. To je dobro, vendar tak\u0161ni hashi porabijo velike CPU vire. Velik pretok la\u017enih avtentikacij privede do odpovedi procesorja, in posledi\u010dno spletna stran preneha delovati.
\nPrisotnost razli\u010dnih obrazcev na spletnem mestu za komentarje in povratne informacije je prilo\u017enost, da tja po\u0161ljemo zelo velike besedila ali preprosto ustvarimo mno\u017ei\u010den spamming. V\u010dasih spletna mesta sprejemajo tudi vgrajene datoteke, vklju\u010dno s formatom gzip. V takem primeru vzamemo datoteko velikosti 1TB, jo z gzip-om stisnemo na nekaj bajtov ali kilobajtov in jo po\u0161ljemo na spletno stran. Nato se razpakira in rezultat je zelo zanimiv. <\/p>\n

Rest API<\/h3>\n

\n\u017deleli bi posvetiti malo pozornosti trenutno popularnim uslugama poput Rest API. Za\u0161tititi Rest API mnogo je te\u017ee nego obi\u010dnu web stranicu. \u010cak i banalne metode za\u0161tite od poku\u0161aja poga\u0111anja lozinki i druge nelegitimne aktivnosti ne rade za Rest API.
\nRest API se vrlo lako mo\u017ee slomiti, jer se direktno obra\u0107a bazi podataka. Posljedice prekida rada takve usluge mogu zna\u010dajno utjecati na poslovanje. Naime, Rest API obi\u010dno povezuje ne samo glavnu web stranicu, ve\u0107 i mobilnu aplikaciju, kao i neke unutarnje poslovne resurse. Ako sve to prestane s radom, u\u010dinak je mnogo ja\u010di nego u slu\u010daju kvara jednostavne web stranice. <\/p>\n

Optere\u0107enje pri radu s te\u0161kim sadr\u017eajem<\/h3>\n

\nAko nam predla\u017eu testirati neku obi\u010dnu jednostranu aplikaciju, odredi\u0161nu web stranicu, poslovnu vizitku, koje nemaju slo\u017eenu funkcionalnost, tra\u017eimo te\u0161ki sadr\u017eaj. Na primjer, velike slike koje server \u0161alje, binarne datoteke, pdf dokumentaciju \u2014 poku\u0161avamo sve to preuzeti. Ovi testovi dobro optere\u0107uju datote\u010dni sustav i zagu\u0161uju kanale, stoga su u\u010dinkoviti. To jest, \u010dak i ako ne sru\u0161ite server preuzimanjem velike datoteke pri malim brzinama, samo \u0107ete zagu\u0161iti kanal ciljanog servera, a tada \u0107e do\u0107i do nepristupa\u010dnosti usluge.
\nNa primjeru takvog testa vidi se da je pri brzini od 30 RPS stranica prestala odgovarati ili je davala 500 gre\u0161ke servera.<\/p>\n

\"DDoS
\n
\nNe smijemo zaboraviti ni na postavke servera. \u010cesto se mo\u017ee vidjeti da je osoba kupila virtualnu ma\u0161inu, postavila Apache, konfigurirala sve prema zadanoj postavci, postavila php aplikaciju, i ispod mo\u017eemo vidjeti rezultat. <\/p>\n

\"DDoS
\n
\nTu je optere\u0107enje i\u0161lo u korijen i iznosilo svega 10 RPS. \u010cekali smo 5 minuta i server je pao. Do kraja, istina, nije poznato za\u0161to je pao, ali postoji pretpostavka da je jednostavno 'pojeo' previ\u0161e memorije i zato je prestao odgovarati.<\/p>\n

Wave based<\/h3>\n

\nV zadnjih dveh letih so postali precej priljubljeni valovni napadi. To je povezano s tem, da \u0161tevilne organizacije kupujejo razli\u010dne naprave za za\u0161\u010dito pred DDoS-om, ki za za\u010detek filtriranja napada zahtevajo dolo\u010deno \u010dasovno obdobje zbiranja statistike. To pomeni, da v prvih 30-40 sekundah napada ne filtrirajo, ker zbirajo podatke in se u\u010dijo. Zato je v teh 30-40 sekundah mogo\u010de na spletno mesto poslati toliko pro\u0161enj, da je vir dolgo nedostopen, dokler se ne razbremeni vseh pozivov.
\nV primeru napada spodaj je bil interval 10 minut, po katerem je pri\u0161la nova, spremenjena serija napada.<\/p>\n

\"DDoS
\n
\nTo pomeni, da je za\u0161\u010dita opravila usposabljanje in za\u010dela filtrirati, toda pri\u0161la je nova, povsem druga\u010dna serija napada, in za\u0161\u010dita je spet za\u010dela u\u010denje. Dejansko filtracija preneha delovati, za\u0161\u010dita postane neu\u010dinkovita in spletna stran postane nedostopna.
\nZa valovne napade so zna\u010dilni zelo visoki vrhovi, lahko dose\u017eejo sto tiso\u010d ali milijon zahtevkov na sekundo v primeru L7. \u010ce govorimo o L3 in L4, lahko tam govorimo o stotinah gigabitov prometa ali, ustrezno, stotinah mpps, \u010de \u0161tejemo v paketih.
\nTe\u017eava tak\u0161nih napadov je v sinhronizaciji. Napadi prihajajo iz botnetov in za ustvarjanje zelo velikega enkratnega vrha je potrebna visoka stopnja sinhronizacije. Ta koordinacija ne uspe vedno: v\u010dasih nastane nekak\u0161en parabolni vrh, ki izgleda precej ob\u017ealovanja vredno.<\/p>\n

Ne \u017eivi le s HTTP-jem<\/h3>\n

\nPoleg HTTP na ravni L7 radi izkori\u0161\u010damo tudi druge protokole. Obi\u010dajno ima navadna spletna stran, \u0161e posebej pri obi\u010dajnem gostovanju, izpostavljene po\u0161tne protokole in MySQL. Po\u0161tni protokoli so manj dovzetni za obremenitve kot podatkovne baze, vendar jih je mogo\u010de obremeniti dovolj u\u010dinkovito in na izhodu dobiti preobremenjen CPU na stre\u017eniku.
\nUspe\u0161no smo uporabili ranljivost SSH iz leta 2016. Sedaj je ta ranljivost pri ve\u010dini popravljena, vendar to ne pomeni, da v SSH ne moremo obremeniti. Lahko. Preprosto ustvarimo ogromno obremenitev avtentifikacij, SSH skoraj povsem porabi CPU na stre\u017eniku in potem spletna stran pade \u017ee pri eni do dveh pro\u0161enj na sekundo. Ustrezno teh ena-dve pro\u0161enj po dnevnikih ni mogo\u010de razlikovati od legitimne obremenitve.
\nOhranjajo se tudi \u0161tevilne povezave, ki jih odpiramo na stre\u017enikih. Pred \u010dasom je s tem gre\u0161il Apache, sedaj pa to pogosto po\u010dne tudi Nginx, saj je pogosto nastavljen na privzeto. \u0160tevilo povezav, ki jih lahko Nginx dr\u017ei odprte, je omejeno, zato odpiramo to \u0161tevilo povezav in nove povezave Nginx ne sprejema, kar pomeni, da spletna stran ne deluje.
\nNa\u0161 testni klaster ima dovolj CPU, da napade SSL handshake. Na splo\u0161no, kot ka\u017ee praksa, tudi botneti to ob\u010dasno radi po\u010dnejo. Po eni strani je jasno, da brez SSL ni mogo\u010de, saj gre za uvrstitev v Google, rangiranje in varnost. Po drugi strani pa ima SSL, \u017eal, te\u017eave s CPU. <\/p>\n

L3&4<\/h3>\n

\nKo govorimo o napadu na ravneh L3&4, praviloma govorimo o napadu na ravni kanala. Tak\u0161na obremenitev je skoraj vedno prepoznavna od legitimne, razen \u010de gre za napad SYN-flood. Problem SYN-flood napadov za za\u0161\u010ditna sredstva je velik obseg. Najve\u010dja vrednost L3&4 je bila 1,5-2 Tbit\/s. Tak promet je zelo te\u017eko obdelati tudi velikim podjetjem, vklju\u010dno z Oracle in Google.
\nSYN in SYN-ACK so paketi, ki se uporabljajo pri vzpostavljanju povezave. Zato je SYN-flood te\u017eko razlikovati od legitimne obremenitve: ni jasno, ali gre za SYN, ki pride za vzpostavitev povezave, ali del poplave.<\/p>\n

UDP-flood<\/h3>\n

\nObi\u010dajno nimajo napadalci takih zmogljivosti, kot jih imamo mi, zato se za organizacijo napadov lahko uporabi amplifikacija. To pomeni, da napadalec skenira internet in najde bodisi ranljive bodisi nepravilno nastavljene stre\u017enike, ki, na primer, kot odgovor na en SYN-paket, odgovorijo s tremi SYN-ACK. S ponarejanjem izvorne naslova s tistega ciljanega stre\u017enika lahko z enim paketom pove\u010damo mo\u010d, recimo, trikrat, in preusmerimo promet na \u017ertev.<\/p>\n

\"DDoS
\n
\nProblem amplifikacij je v njihovi te\u017eki odkritosti. Med zadnjimi primeri lahko omenimo odmeven primer z ranljivim memcached. Poleg tega je danes na voljo veliko naprav IoT, IP-kamer, ki so tudi ve\u010dinoma nastavljene na privzeto, in nepravilno, zato napadalci to pogosto izkori\u0161\u010dajo za napade. <\/p>\n

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

Zapleten SYN-flood<\/h3>\n

\nSYN-flood je verjetno najzanimivej\u0161a vrsta napadov z vidika razvijalca. Te\u017eava je v tem, da sistemski skrbniki pogosto uporabljajo blokado po IP-ju kot za\u0161\u010dito. Pri tem pa zaradi blokade po IP-ju trpijo ne le skrbniki, ki delujejo po skriptih, temve\u010d tudi nekateri sistemi za\u0161\u010dite, ki se kupijo za velike denarce.
\nTak\u0161na metoda se lahko kon\u010da katastropalno, saj \u010de napadalci ponaredijo IP-naslove<\/a>, bo podjetje blokiralo lastno podsistem. Ko po\u017earni zid blokira lastni grozd, bodo zunanje interakcije propadle in vir bo prenehal delovati.
\nPoleg tega ni te\u017eko dose\u010di blokade lastne mre\u017ee. \u010ce ima stranka v pisarni Wi-Fi omre\u017eje ali \u010de se delovanje virov meri z razli\u010dnimi monitorji, vzamemo IP naslov tega monitorja ali pisarni\u0161kega Wi-Fi odjemalca in ga uporabimo kot vir. Tako je vir na videz dostopen, vendar so ciljni IP naslovi blokirani. Tako se lahko blokira Wi-Fi omre\u017eje konferencije HighLoad, kjer se predstavlja nov izdelek podjetja, kar povzro\u010di dolo\u010dene poslovne in gospodarske stro\u0161ke.
\nMed testiranjem ne moremo uporabljati amplifikacije preko memcached z nekaterimi zunanjimi viri, ker imamo dogovore o usmerjanju prometa le v dovoljene IP naslove. Zato uporabljamo amplifikacijo preko SYN in SYN-ACK, pri \u010demer na enega poslano SYN sistem odgovori z dvema ali tremi SYN-ACK, u\u010dinek napada pa se pove\u010da dvakrat ali trikrat. <\/p>\n

Orodja<\/h3>\n

\nEden od glavnih orodij, ki jih uporabljamo za obremenitev na ravni L7, je Yandex-tank. Konkretno se kot pu\u0161ka uporablja fantom, poleg tega pa imamo ve\u010d skriptov za generiranje nabojev in za analizo rezultatov.
\nZa analizo omre\u017enega prometa uporabljamo Tcpdump, za analizo stre\u017enika pa Nmap. Za ustvarjanje obremenitve na ravni L3&4 uporabljamo OpenSSL in malo lastne magije s knji\u017enico DPDK. DPDK je knji\u017enica podjetja Intel, ki omogo\u010da delo z omre\u017enim vmesnikom brez Linuxovega sklada, kar pove\u010duje u\u010dinkovitost. Seveda DPDK ne uporabljamo le na ravni L3&4, temve\u010d tudi na ravni L7, saj omogo\u010da ustvarjanje zelo visokega prometa, do ve\u010d milijonov zahtevkov na sekundo z ene naprave.
\nPrav tako uporabljamo dolo\u010dene generatore prometa in posebna orodja, ki jih pi\u0161emo za specifi\u010dne teste. \u010ce se spomnimo ranljivosti pod SSH, jo z zgoraj navedenim naborom ni mogo\u010de izkoristiti. \u010ce napadamo po\u0161tni protokol, uporabimo po\u0161tne pripomo\u010dke ali preprosto napi\u0161emo skripte zanje.<\/p>\n

\n

Zaklju\u010dki<\/h3>\n

\nKot zaklju\u010dek bi rad rekel:<\/p>\n