{"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\/sq\/blog\/administrirovanie\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","title":{"rendered":"DDoS n\u00eb ndihm\u00eb: si realizojm\u00eb teste stres dhe ngarkese","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DDoS
\n
\nCompania Variti zhvillon mbrojtjen nga robot\u00ebt dhe sulmet DDoS, si dhe kryen teste stresi dhe ngarkese. N\u00eb konferenc\u00ebn HighLoad++ 2018 ne fol\u00ebm p\u00ebr m\u00ebnyrat se si t\u00eb sigurojm\u00eb burimet nga lloje t\u00eb ndryshme sulmesh. N\u00ebse e thjeshtojm\u00eb: izolojini pjes\u00ebt e sistemit, p\u00ebrdorni sh\u00ebrbime cloud dhe CDN dhe aktualizoni rregullisht. Por pa kompani t\u00eb specializuara me mbrojtje, do t\u00eb jeni ende n\u00eb v\u00ebshtir\u00ebsi \ud83d\ude42<\/i>
\n<\/a><\/noindex>
\nPara se t\u00eb lexoni tekstin, mund t\u00eb njiheni me p\u00ebrmbledhjet e shkurtra n\u00eb faqen e konferenc\u00ebs<\/a><\/noindex>.
\nN\u00ebse nuk ju p\u00eblqen t\u00eb lexoni ose thjesht d\u00ebshironi t\u00eb shikoni videon, regjistrimi i fjalimit ton\u00eb \u00ebsht\u00eb m\u00eb posht\u00eb n\u00ebn spojler.<\/p>\n

Regjistrimi i fjalimit<\/b>

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

Shum\u00eb kompani tashm\u00eb din\u00eb t\u00eb kryejn\u00eb teste ngarkese, por jo t\u00eb gjitha b\u00ebjn\u00eb teste stresi. Disa nga klient\u00ebt tan\u00eb mendojn\u00eb se faqja e tyre \u00ebsht\u00eb e paprekshme, sepse kan\u00eb nj\u00eb sistem highload dhe ai i mbrojt mir\u00eb nga sulmet. Ne tregojm\u00eb se kjo nuk \u00ebsht\u00eb plot\u00ebsisht e v\u00ebrtet\u00eb.
\nNatyrisht, para se t\u00eb zhvillojm\u00eb provat, ne marrim leje nga klienti, e cila \u00ebsht\u00eb e n\u00ebnshkruar dhe e vulosur, dhe me ndihm\u00ebn ton\u00eb, nj\u00eb sulm DDoS nuk mund t\u00eb realizohet ndaj askujt. Testimi kryhet n\u00eb koh\u00ebn e zgjedhur nga klienti, kur vizitueshm\u00ebria e burimit t\u00eb tij \u00ebsht\u00eb minimale, dhe problemet me qasjen nuk do t\u00eb ndikojn\u00eb te klient\u00ebt. P\u00ebr m\u00eb tep\u00ebr, p\u00ebr shkak se gjat\u00eb testimit gjithmon\u00eb mund t\u00eb ndodhin di\u00e7ka t\u00eb papritur, ne kemi nj\u00eb kontakt t\u00eb vazhduesh\u00ebm me klientin. Kjo na lejon jo vet\u00ebm t\u00eb raportojm\u00eb p\u00ebr rezultatet e arritura, por gjithashtu t\u00eb b\u00ebjm\u00eb ndonj\u00eb ndryshim gjat\u00eb testimit. Pas p\u00ebrfundimit t\u00eb testimit, ne gjithmon\u00eb p\u00ebrpilojm\u00eb nj\u00eb raport, n\u00eb t\u00eb cilin theksojm\u00eb mang\u00ebsit\u00eb e zbuluara dhe japim rekomandime p\u00ebr eliminimin e dob\u00ebsive t\u00eb faqes s\u00eb internetit. <\/p>\n

Si punojm\u00eb<\/h3>\n

\nGjat\u00eb zhvillimit t\u00eb testimeve, ne imitojm\u00eb nj\u00eb botnet. Duke qen\u00eb se punojm\u00eb me klient\u00eb q\u00eb nuk ndodhen n\u00eb rrjetet tona, p\u00ebr t\u00eb siguruar q\u00eb testi t\u00eb mos p\u00ebrfundoj\u00eb pas minut\u00ebs s\u00eb par\u00eb p\u00ebr shkak t\u00eb aktivizimit t\u00eb kufijve ose mbrojtjes, ne krijojm\u00eb ngarkes\u00ebn jo nga nj\u00eb IP, por nga n\u00ebnrrjeti yn\u00eb. P\u00ebr m\u00eb tep\u00ebr, p\u00ebr t\u00eb krijuar nj\u00eb ngarkes\u00eb t\u00eb konsiderueshme, ne kemi nj\u00eb server testues mjaft t\u00eb fuqish\u00ebm.<\/p>\n

Postulatet<\/h3>\n

<\/p>\n

Shum\u00eb \u2014 nuk do t\u00eb thot\u00eb mir\u00eb<\/b>
\nSa m\u00eb pak ngarkes\u00eb t\u00eb arrijm\u00eb deri n\u00eb d\u00ebshtimin e burimit, aq m\u00eb mir\u00eb. N\u00ebse arrijm\u00eb q\u00eb faqja t\u00eb ndaloj\u00eb funksionimin nga nj\u00eb k\u00ebrkes\u00eb n\u00eb sekond\u00eb, apo edhe nga nj\u00eb k\u00ebrkes\u00eb n\u00eb minut\u00eb, kjo \u00ebsht\u00eb e shk\u00eblqyer. Sepse sipas ligjit t\u00eb rast\u00ebsis\u00eb, p\u00ebrdoruesit ose sulmuesit do t\u00eb zihet n\u00eb k\u00ebt\u00eb dob\u00ebsi. <\/p><\/blockquote>\n

D\u00ebshtim pjesor \u00ebsht\u00eb m\u00eb i mir\u00eb se i plot\u00eb<\/b>
\nNe gjithmon\u00eb rekomandojm\u00eb t\u00eb b\u00ebjm\u00eb sistemet heterogjene. Dhe ndarja e tyre duhet t\u00eb ndodh\u00eb pik\u00ebrisht n\u00eb nivelin fizik, dhe jo vet\u00ebm p\u00ebrmes kontenjerizimit. N\u00eb rast t\u00eb ndarjes fizike, edhe n\u00ebse di\u00e7ka d\u00ebshtonte n\u00eb faqen e internetit, ka mund\u00ebsi t\u00eb madhe q\u00eb t\u00eb mos nd\u00ebrpritet krejt\u00ebsisht puna e saj, dhe p\u00ebrdoruesit t\u00eb ruajn\u00eb qasjen ndoshta edhe n\u00eb nj\u00eb pjes\u00eb t\u00eb funksionalitetit.<\/p><\/blockquote>\n

Arkitektura e duhur \u00ebsht\u00eb baza e q\u00ebndrueshm\u00ebris\u00eb<\/b>
\nQ\u00ebndrueshm\u00ebria e burimit dhe aft\u00ebsia e tij p\u00ebr t\u00eb p\u00ebrballuar sulme dhe ngarkesa duhet t\u00eb parashikohet n\u00eb faz\u00ebn e projektimit, praktikisht n\u00eb faz\u00ebn e vizatimit t\u00eb diagrameve t\u00eb para n\u00eb sh\u00ebnim. Sepse n\u00ebse ngjallen gabime fatale, \u00ebsht\u00eb e mundur t\u00eb korrigjohen m\u00eb von\u00eb, por shum\u00eb e v\u00ebshtir\u00eb.<\/p><\/blockquote>\n

Q\u00eb \u00e7do gj\u00eb t\u00eb jet\u00eb e mir\u00eb, jo vet\u00ebm kodi, por edhe konfigurimi<\/b>
\nShum\u00eb mendojn\u00eb se nj\u00eb ekip i mir\u00eb zhvillimi \u00ebsht\u00eb garantimi i q\u00ebndrueshm\u00ebris\u00eb s\u00eb sh\u00ebrbimit. Nj\u00eb ekip i mir\u00eb zhvillimi \u00ebsht\u00eb padyshim i nevojsh\u00ebm, por duhet gjithashtu nj\u00eb menaxhim i mir\u00eb, nj\u00eb DevOps i duhur. Pra, na nevojiten specialist\u00eb q\u00eb do t\u00eb konfigurojn\u00eb sakt\u00eb Linux-in dhe rrjetin, do t\u00eb shkruajn\u00eb skenaret e konfigurimit n\u00eb nginx, do t\u00eb vendosin kufijt\u00eb dhe m\u00eb shum\u00eb. N\u00eb t\u00eb kund\u00ebrt, burimi do t\u00eb funksionoj\u00eb mir\u00eb vet\u00ebm n\u00eb test, por n\u00eb prodhim n\u00eb nj\u00eb moment t\u00eb caktuar gjith\u00e7ka do t\u00eb d\u00ebshtoj\u00eb.<\/p><\/blockquote>\n

Dallimet midis testimit t\u00eb ngarkes\u00ebs dhe testimit t\u00eb stresit<\/b>
\nTestimi i ngarkes\u00ebs lejon identifikimin e kufijve t\u00eb funksionimit t\u00eb sistemit. Testimi i stresit ka si q\u00ebllim gjetjen e pika t\u00eb dob\u00ebta t\u00eb sistemit dhe p\u00ebrdoret p\u00ebr t\u00eb prishur k\u00ebt\u00eb sistem dhe p\u00ebr t\u00eb par\u00eb si do t\u00eb sillet ai gjat\u00eb d\u00ebshtimit t\u00eb ndonj\u00eb pjese. N\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb, natyra e ngarkes\u00ebs zakonisht mbetet e panjohur p\u00ebr klientin deri n\u00eb fillimin e testimit t\u00eb stresit.<\/p><\/blockquote>\n

<\/p>\n

Ve\u00e7orit\u00eb dalluese t\u00eb sulmeve L7<\/h3>\n

\nLlojet e ngarkesave zakonisht i ndajn\u00eb n\u00eb ngarkesa n\u00eb nivelin L7 dhe L3&4. L7 \u00ebsht\u00eb ngarkesa n\u00eb nivelin e aplikacionit, m\u00eb shpesh n\u00ebnkuptohet vet\u00ebm HTTP, ne n\u00ebnkuptojm\u00eb \u00e7do ngarkes\u00eb n\u00eb nivelin e protokollit TCP.
\nL7 sulmet kan\u00eb karakteristika t\u00eb ve\u00e7anta. E para, ato vijn\u00eb drejtp\u00ebrdrejt n\u00eb aplikacion, duke e b\u00ebr\u00eb t\u00eb v\u00ebshtir\u00eb reflektimin e tyre me mjete rrjetike. K\u00ebto sulme p\u00ebrdorin logjik\u00ebn, dhe p\u00ebr k\u00ebt\u00eb arsye konsumojn\u00eb shum\u00eb efikasitet mjetet CPU, memorie, disk, baz\u00ebn e t\u00eb dh\u00ebnave dhe burime t\u00eb tjera, edhe me nj\u00eb trafik t\u00eb vog\u00ebl.<\/p>\n

HTTP Flood<\/h3>\n

\nN\u00eb rastin e \u00e7do sulmi, \u00ebsht\u00eb m\u00eb e leht\u00eb t\u00eb krijohet ngarkesa sesa t\u00eb p\u00ebrballohet ajo, dhe kjo \u00ebsht\u00eb e v\u00ebrtet\u00eb edhe p\u00ebr L7. Trafiku i sulmit nuk \u00ebsht\u00eb gjithmon\u00eb e thjesht\u00eb t\u00eb dallohet nga ai legjitim, dhe shpeshher\u00eb arrihet ta b\u00ebjm\u00eb k\u00ebt\u00eb n\u00ebp\u00ebrmjet frekuenc\u00ebs, por n\u00ebse gjith\u00e7ka \u00ebsht\u00eb planifikuar si\u00e7 duhet, \u00ebsht\u00eb e pamundur t\u00eb kuptohet nga log\u00ebt se ku \u00ebsht\u00eb sulmi dhe ku jan\u00eb k\u00ebrkesat legjitime.
\nSi nj\u00eb shembull t\u00eb par\u00eb, le t\u00eb shqyrtojm\u00eb sulmin HTTP Flood. Nga grafiku, duket se k\u00ebto sulme jan\u00eb zakonisht shum\u00eb t\u00eb fuqishme; n\u00eb shembullin m\u00eb posht\u00eb, numri i kulm\u00ebve t\u00eb k\u00ebrkesave e tejkalonte 600 mij\u00eb n\u00eb minut\u00eb.<\/p>\n

\"DDoS
\n
\nHTTP Flood \u2014 \u00ebsht\u00eb m\u00ebnyra m\u00eb e thjesht\u00eb p\u00ebr t\u00eb krijuar ngarkes\u00eb. N\u00eb p\u00ebrgjith\u00ebsi, p\u00ebr t\u00eb p\u00ebrdoret nj\u00eb mjet testimi ngarkese, si p.sh., ApacheBench, dhe i caktohen k\u00ebrkesa dhe q\u00ebllimi. Me nj\u00eb qasje kaq t\u00eb thjesht\u00eb, ka shum\u00eb mund\u00ebsi t\u00eb p\u00ebrballesh me sistemin e ruajtjes s\u00eb serverit, por \u00ebsht\u00eb leht\u00eb p\u00ebr ta shp\u00ebrthyer. P\u00ebr shembull, duke shtuar vargje rast\u00ebsore n\u00eb k\u00ebrkes\u00eb, \u00e7far\u00eb do ta detyroj\u00eb serverin q\u00eb t\u00eb kthej\u00eb vazhdimisht nj\u00eb faqe t\u00eb re.
\nPo ashtu, nuk duhet t\u00eb harrohet p\u00ebr user-agent n\u00eb procesin e krijimit t\u00eb ngarkes\u00ebs. Shum\u00eb user-agent t\u00eb mjeteve t\u00eb njohura t\u00eb testimit filtrohen nga administrator\u00ebt e sistemeve, dhe n\u00eb k\u00ebt\u00eb rast ngarkesa mund t\u00eb mos arrij\u00eb dot deri te backend-i. Resultatin mund ta p\u00ebrmir\u00ebsosh ndjesh\u00ebm duke futur n\u00eb k\u00ebrkes\u00eb nj\u00eb titull m\u00eb shum\u00eb ose m\u00eb pak t\u00eb vlefsh\u00ebm nga nj\u00eb shfletues.
\nPavar\u00ebsisht thjesht\u00ebsis\u00eb, sulmet HTTP Flood kan\u00eb dhe disavantazhe t\u00eb veta. S\u00eb pari, p\u00ebr t\u00eb krijuar ngarkes\u00eb k\u00ebrkohen burime t\u00eb m\u00ebdha. S\u00eb dyti, k\u00ebto sulme jan\u00eb shum\u00eb t\u00eb lehta p\u00ebr tu zbuluar, ve\u00e7an\u00ebrisht n\u00ebse vijn\u00eb nga nj\u00eb adres\u00eb. Si rezultat, k\u00ebrkesat fillojn\u00eb menj\u00ebher\u00eb t\u00eb filtrohen nga administrator\u00ebt e sistemeve ose madje edhe n\u00eb nivelin e ofruesit. <\/p>\n

\u00c7far\u00eb duhet t\u00eb k\u00ebrkosh<\/h3>\n

\nP\u00ebr t\u00eb reduktuar numrin e k\u00ebrkesave p\u00ebr sekond\u00eb pa humbur efektivitetin, nevojitet pak imagjinat\u00eb dhe eksplorim i faqes. K\u00ebshtu, mund t\u00eb ngarkoni jo vet\u00ebm kanal ose server, por edhe pjes\u00eb t\u00eb ve\u00e7anta t\u00eb aplikacionit, si\u00e7 jan\u00eb bazat e t\u00eb dh\u00ebnave ose sistemet e skedave. Gjithashtu, mund t\u00eb k\u00ebrkoni p\u00ebr vendet n\u00eb faqen q\u00eb b\u00ebjn\u00eb llogaritje t\u00eb m\u00ebdha: kalkulator\u00eb, faqe me p\u00ebrzgjedhje produktesh, etj. P\u00ebr m\u00eb tep\u00ebr, shpesh ndodh q\u00eb n\u00eb faqen ka nj\u00eb skenar php q\u00eb gjeneron nj\u00eb faqe nga disa qindra mij\u00ebra rreshta. Nj\u00eb skenar i till\u00eb gjithashtu ngarkon ndjesh\u00ebm serverin dhe mund t\u00eb b\u00ebhet objekt sulmi.<\/p>\n

Ku t\u00eb k\u00ebrkojm\u00eb<\/h3>\n

\nKur skanojm\u00eb burimin para se t\u00eb kryejm\u00eb testimin, ne fillimisht shikojm\u00eb, sigurisht, faqen e vet. K\u00ebrkojm\u00eb t\u00eb gjitha llojet e fushave t\u00eb hyrjes, skedar\u00ebve t\u00eb r\u00ebnd\u00eb \u2014 n\u00eb p\u00ebrgjith\u00ebsi \u00e7do gj\u00eb q\u00eb mund t\u00eb krijoj\u00eb probleme p\u00ebr burimin dhe ta ngadal\u00ebsoj\u00eb at\u00eb. K\u00ebtu ndihmojn\u00eb mjetet e zakonshme t\u00eb zhvillimit n\u00eb Google Chrome dhe Firefox, q\u00eb tregojn\u00eb koh\u00ebt e p\u00ebrgjigjeve t\u00eb faqes.
\nNe skanojm\u00eb gjithashtu n\u00ebn-domainet. P\u00ebr shembull, ka nj\u00eb dyqan online, abc.com, dhe ai ka nj\u00eb n\u00ebn-domain admin.abc.com. Ka shum\u00eb mund\u00ebsi q\u00eb kjo t\u00eb jet\u00eb paneli administrativ me autorizim, por n\u00ebse i japim ngarkes\u00eb, mund t\u00eb krijoj\u00eb probleme p\u00ebr burimin kryesor.
\nNj\u00eb faqe mund t\u00eb ket\u00eb n\u00ebn-domainin api.abc.com. Ka shum\u00eb mund\u00ebsi q\u00eb ky t\u00eb jet\u00eb nj\u00eb burim p\u00ebr aplikacione mobile. Aplikacioni mund t\u00eb gjendet n\u00eb App Store ose Google Play, t\u00eb vendoset nj\u00eb pik\u00eb qasje speciale, t\u00eb depurohet API dhe t\u00eb regjistrohen llogari testuese. Problemi \u00ebsht\u00eb se shpesh njer\u00ebzit mendojn\u00eb se gjith\u00e7ka q\u00eb \u00ebsht\u00eb e mbrojtur me autorizim \u00ebsht\u00eb e paprekshme nga sulmet e refuzimit t\u00eb sh\u00ebrbimit. Sipas tyre, autorizimi \u00ebsht\u00eb CAPTCHA m\u00eb e mir\u00eb, por kjo nuk \u00ebsht\u00eb e v\u00ebrtet\u00eb. T\u00eb b\u00ebsh 10-20 llogari testuese \u00ebsht\u00eb e thjesht\u00eb, dhe duke i krijuar ato, ne fitojm\u00eb qasje n\u00eb funksionalitetin e komplikuar dhe t\u00eb papenguar.
\nSigurisht, ne shqyrtojm\u00eb historin\u00eb, robots.txt dhe WebArchive, ViewDNS, duke k\u00ebrkuar versione t\u00eb vjetra t\u00eb burimit. Ndonj\u00ebher\u00eb ndodh q\u00eb zhvilluesit lan\u00e7ojn\u00eb, p\u00ebr shembull, mail2.yandex.net, nd\u00ebrsa versi e vjet\u00ebr, mail.yandex.net, mbetet. Ky mail.yandex.net nuk vazhdon t\u00eb mb\u00ebshtetet, p\u00ebr t\u00eb nuk alokohen burime zhvillimi, por ai vazhdon t\u00eb konsumoj\u00eb baz\u00ebn e t\u00eb dh\u00ebnave. P\u00ebr rrjedhoj\u00eb, me ndihm\u00ebn e versionit t\u00eb vjet\u00ebr mund t\u00eb angazhohen efikasitet burimet e backend-it dhe gjith\u00e7ka q\u00eb q\u00ebndron pas modelimit. Natyrisht, kjo nuk ndodh gjithmon\u00eb, por ne p\u00ebrballemi me di\u00e7ka t\u00eb till\u00eb mjaft shpesh.
\nSigurisht, ne analizojm\u00eb t\u00eb gjitha parametrat e k\u00ebrkes\u00ebs, struktur\u00ebn e cookie-ve. Mund t\u00eb thoni, mund t\u00eb ngarkojm\u00eb n\u00eb nj\u00eb varg JSON brenda cookie-ve ndonj\u00eb vler\u00eb, t\u00eb krijojm\u00eb nj\u00eb thell\u00ebsi t\u00eb madhe dhe t\u00eb b\u00ebjm\u00eb q\u00eb burimi t\u00eb funksionoj\u00eb pa kuptim p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb.<\/p>\n

Ngarkesa n\u00eb k\u00ebrkim<\/h3>\n

\nE para e par\u00eb q\u00eb vjen n\u00eb mendje kur shqyrtohet nj\u00eb sit \u00ebsht\u00eb ngarkimi i baz\u00ebs s\u00eb t\u00eb dh\u00ebnave, pasi q\u00eb k\u00ebrkimi \u00ebsht\u00eb i pranish\u00ebm n\u00eb pothuajse \u00e7do sit, dhe fatkeq\u00ebsisht pothuajse t\u00eb gjith\u00eb jan\u00eb t\u00eb mbrojtur dob\u00ebt. P\u00ebr nj\u00eb arsye, zhvilluesit nuk i kushtojn\u00eb k\u00ebrkimit kujdesin e duhur. Por ka nj\u00eb rekomandim \u2014 nuk \u00ebsht\u00eb e rekomandueshme t\u00eb b\u00ebni k\u00ebrkesa uniforme, sepse mund t\u00eb p\u00ebrballeni me caching, ashtu si n\u00eb rastin e sulmit HTTP flood.
\nB\u00ebrja e k\u00ebrkesave rast\u00ebsore n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave gjithashtu nuk \u00ebsht\u00eb gjithmon\u00eb efektive. M\u00eb mir\u00eb do t\u00eb ishte t\u00eb krijonit nj\u00eb list\u00eb fjal\u00ebsh ky\u00e7e q\u00eb i p\u00ebrkasin k\u00ebrkimit. N\u00ebse kthehemi n\u00eb shembullin e nj\u00eb dyqani online: supozoni se siti tregton goma p\u00ebr makina dhe lejon caktimin e rrethit t\u00eb gomave, tipin e makin\u00ebs dhe parametra t\u00eb tjer\u00eb. Prandaj, kombinimet e fjal\u00ebve relevante do ta b\u00ebjn\u00eb baz\u00ebn e t\u00eb dh\u00ebnave t\u00eb punoj\u00eb n\u00eb kushte shum\u00eb m\u00eb t\u00eb komplikuara.
\nP\u00ebr m\u00eb tep\u00ebr, duhet t\u00eb p\u00ebrdoret paginimi: \u00ebsht\u00eb shum\u00eb m\u00eb e v\u00ebshtir\u00eb p\u00ebr k\u00ebrkimin t\u00eb marr\u00eb faqen parafundit t\u00eb rezultatit, sesa at\u00eb t\u00eb par\u00eb. Pra, p\u00ebrmes paginimit mund t\u00eb diversifikoni pak ngarkes\u00ebn.
\nN\u00eb shembullin m\u00eb posht\u00eb, ne tregojm\u00eb ngarkes\u00ebn n\u00eb k\u00ebrkim. \u00cbsht\u00eb e dukshme se q\u00eb n\u00eb sekond\u00ebn e par\u00eb t\u00eb testit, me shpejt\u00ebsi dhjet\u00eb k\u00ebrkesa n\u00eb sekond\u00eb, siti ra dhe nuk p\u00ebrgjigjej.<\/p>\n

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

N\u00ebse nuk ka k\u00ebrkese?<\/h3>\n

\nN\u00ebse nuk ka k\u00ebrkese, kjo nuk do t\u00eb thot\u00eb q\u00eb faqja nuk p\u00ebrmban fusha t\u00eb tjera t\u00eb ndjeshme. Nj\u00eb nga k\u00ebto mund t\u00eb jet\u00eb autentikimi. Aktualisht, zhvilluesit p\u00eblqejn\u00eb t\u00eb b\u00ebjn\u00eb hash-e t\u00eb komplikuara p\u00ebr t\u00eb mbrojtur baz\u00ebn e t\u00eb dh\u00ebnave t\u00eb login-eve nga sulmet me tabela t\u00eb p\u00ebrhershme. Kjo \u00ebsht\u00eb e mir\u00eb, por k\u00ebta hash-e konsumojn\u00eb shum\u00eb burime CPU. Nj\u00eb fluks i madh i falsifikimeve t\u00eb autentikimit \u00e7on n\u00eb d\u00ebshtimin e procesorit, dhe si pasoj\u00eb, faqja ndalon s\u00eb funksionuari.
\nPrania e formave t\u00eb ndryshme p\u00ebr komente dhe feedback n\u00eb faqen e internetit \u00ebsht\u00eb nj\u00eb arsye p\u00ebr t\u00eb d\u00ebrguar tekste shum\u00eb t\u00eb m\u00ebdha atje ose thjesht p\u00ebr t\u00eb krijuar nj\u00eb fluks t\u00eb madh. Ndonj\u00ebher\u00eb faqet pranojn\u00eb skedar\u00eb t\u00eb ngarkuar, p\u00ebrfshir\u00eb n\u00eb formatin gzip. N\u00eb k\u00ebt\u00eb rast, ne marim nj\u00eb skedar me madh\u00ebsi 1TB, e kompresojm\u00eb at\u00eb me gzip n\u00eb disa bite ose kilobajt\u00eb dhe e d\u00ebrgojm\u00eb n\u00eb faqen e internetit. M\u00eb pas, ai dekompresohet dhe rezulton nj\u00eb efekt shum\u00eb interesante. <\/p>\n

Rest API<\/h3>\n

\nD\u00ebshiroj t\u00eb kushtoj pak v\u00ebmendje sh\u00ebrbimeve kaq popullore sot, si\u00e7 \u00ebsht\u00eb Rest API. Mbrojtja e Rest API \u00ebsht\u00eb shum\u00eb m\u00eb e v\u00ebshtir\u00eb se nj\u00eb faqe interneti normale. M\u00ebnyrat bazike p\u00ebr t\u00eb mbrojtur p\u00ebrpjekjet p\u00ebr t\u00eb thyer fjal\u00ebkalimin dhe aktivitete t\u00eb tjera t\u00eb paligjshme nuk funksionojn\u00eb as p\u00ebr Rest API.
\nRest API \u00ebsht\u00eb shum\u00eb e leht\u00eb p\u00ebr t'u thyer, sepse ai lidhet drejtp\u00ebrdrejt me baz\u00ebn e t\u00eb dh\u00ebnave. D\u00ebshtimi i k\u00ebtij sh\u00ebrbimi ka pasoja t\u00eb r\u00ebnda p\u00ebr biznesin. Kjo ndodhi sepse Rest API zakonisht lidhet jo vet\u00ebm me sitin kryesor, por edhe me aplikacionin mobil dhe disa burime t\u00eb brendshme tregtare. Dhe n\u00ebse t\u00eb gjitha k\u00ebto bien, efekti \u00ebsht\u00eb shum\u00eb m\u00eb i fort\u00eb se n\u00eb rastin e d\u00ebshtimit t\u00eb nj\u00eb faqesh thjesht. <\/p>\n

Ngarkesa mbi p\u00ebrmbajtje t\u00eb r\u00ebnd\u00eb<\/h3>\n

\nN\u00ebse na ofrohet t\u00eb testojm\u00eb nj\u00eb aplikacion t\u00eb zakonsh\u00ebm me nj\u00eb faqe, nj\u00eb landing, ose nj\u00eb faqe vizit\u00eb pa funksionalitete t\u00eb komplikuara, ne k\u00ebrkojm\u00eb p\u00ebrmbajtje t\u00eb r\u00ebnd\u00eb. P\u00ebr shembull, imazhe t\u00eb m\u00ebdha q\u00eb serveri i ofron, skedar\u00eb binar\u00eb, dokumentacion PDF \u2014 provojm\u00eb t\u00eb gjitha k\u00ebto q\u00eb t'i shkarkojm\u00eb. K\u00ebto teste ngarkojn\u00eb mir\u00eb sistemin e skedar\u00ebve dhe mbushin kanalet, prandaj jan\u00eb efektive. K\u00ebshtu q\u00eb, edhe n\u00ebse nuk e \u00e7oni posht\u00eb serverin duke shkarkuar nj\u00eb skedar t\u00eb madh me shpejt\u00ebsi t\u00eb ul\u00ebt, thjesht do t\u00eb mbushni kanalin e serverit dhe at\u00ebher\u00eb do t\u00eb ndodhi nj\u00eb d\u00ebshtim sh\u00ebrbimi.
\nN\u00eb shembullin e k\u00ebtij testi, duket se me nj\u00eb shpejt\u00ebsi prej 30 RPS, faqja e internetit ka ndaluar s\u00eb p\u00ebrgjiguri ose ka dh\u00ebn\u00eb gabime 500 t\u00eb serverit.<\/p>\n

\"DDoS
\n
\n\u00cbsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb mos harrosh konfigurimin e server\u00ebve. Shpesh ndodh q\u00eb nj\u00eb person t\u00eb blej\u00eb nj\u00eb virtualizim, t\u00eb instaloj\u00eb Apache, t\u00eb konfiguroj\u00eb gjith\u00e7ka sipas defaults, t\u00eb vendos\u00eb nj\u00eb aplikacion php dhe m\u00eb posht\u00eb mund t\u00eb shihni rezultatin. <\/p>\n

\"DDoS
\n
\nK\u00ebtu ngarkesa shkoi n\u00eb rr\u00ebnj\u00eb dhe p\u00ebrb\u00ebnte vet\u00ebm 10 RPS. Ne prisnim 5 minuta dhe serveri ra. \u00cbsht\u00eb ende e paqart\u00eb pse ra, por ka nj\u00eb supozim se thjesht b\u00ebri mbip\u00ebrdorim t\u00eb memories dhe prandaj ndali p\u00ebrgjigjen.<\/p>\n

V\u00ebrtit\u00ebs i bazuar n\u00eb val\u00eb<\/h3>\n

\nN\u00eb vitet e fundit, sulmet me val\u00eb jan\u00eb b\u00ebr\u00eb mjaft t\u00eb njohura. Kjo \u00ebsht\u00eb e lidhur me faktin se shum\u00eb organizata blejn\u00eb pajisje t\u00eb ndryshme p\u00ebr mbrojtjen nga DDoS, t\u00eb cilat k\u00ebrkojn\u00eb nj\u00eb koh\u00eb t\u00eb caktuar p\u00ebr grumbullimin e statistikave p\u00ebr t\u00eb filluar filtrimin e sulmit. Kjo do t\u00eb thot\u00eb se ato nuk filtrojn\u00eb sulmin n\u00eb 30-40 sekondat e para, sepse grumbullojn\u00eb t\u00eb dh\u00ebna dhe m\u00ebsohen. N\u00eb p\u00ebrputhje me k\u00ebt\u00eb, gjat\u00eb k\u00ebtyre 30-40 sekondave mund t\u00eb l\u00ebshosh kaq shum\u00eb mbi faqen sa burimi do t\u00eb mbetet i bllokuar p\u00ebr nj\u00eb periudh\u00eb t\u00eb gjat\u00eb, derisa t\u00eb p\u00ebrballohen t\u00eb gjitha k\u00ebrkesat.
\nN\u00eb rastin e sulmit m\u00eb posht\u00eb, kishte nj\u00eb interval prej 10 minutash, pas t\u00eb cilit erdhi nj\u00eb sasi e re, e ndryshuar e sulmit.<\/p>\n

\"DDoS
\n
\nPra k\u00ebsaj, mbrojtja ka m\u00ebsuar, ka filluar filtrimin, por ka ardhur nj\u00eb sulm krejt tjet\u00ebr, dhe mbrojtja fillon p\u00ebrs\u00ebri t\u00eb m\u00ebsoj\u00eb. N\u00eb fakt, filtrimi ndalon s\u00eb funksionuari, mbrojtja b\u00ebhet e paefikase, dhe faqja b\u00ebhet e paparashikueshme.
\nSulmet e val\u00ebve karakterizohen nga vlera shum\u00eb t\u00eb larta n\u00eb maj\u00eb, mund t\u00eb arrijn\u00eb deri n\u00eb nj\u00ebqind mij\u00eb ose nj\u00eb milion k\u00ebrkesa n\u00eb sekond\u00eb, n\u00eb rastin e L7. N\u00ebse flasim p\u00ebr L3&4, at\u00ebher\u00eb mund t\u00eb ket\u00eb qindra gigabite trafik, ose p\u00ebrkat\u00ebsisht qindra mpps, n\u00ebse llogaritet n\u00eb paketa.
\nProblemi i k\u00ebtyre sulmeve q\u00ebndron n\u00eb sinkronizim. Sulmet vijn\u00eb nga nj\u00eb botnet, dhe p\u00ebr t\u00eb krijuar nj\u00eb maj\u00eb t\u00eb madhe nj\u00eb her\u00eb, k\u00ebrkohet nj\u00eb shkall\u00eb e lart\u00eb sinkronizimi. Dhe kjo koordinat\u00eb nuk \u00ebsht\u00eb gjithmon\u00eb e mundur: ndonj\u00ebher\u00eb rezulton nj\u00eb maj\u00eb parabolike, e cila duket mjaft keq.<\/p>\n

Nuk jetojm\u00eb vet\u00ebm me HTTP<\/h3>\n

\nP\u00ebrve\u00e7 HTTP n\u00eb nivelin L7, ne gjithashtu p\u00eblqejm\u00eb t\u00eb shfryt\u00ebzojm\u00eb protokole t\u00eb tjera. N\u00eb p\u00ebrgjith\u00ebsi, nj\u00eb faqe webi e zakonshme, e ve\u00e7an\u00ebrisht nj\u00eb host i zakonsh\u00ebm, ka protokolle postare dhe MySQL q\u00eb duken nga jasht\u00eb. Protokollat postare jan\u00eb m\u00eb pak t\u00eb ndjeshme ndaj ngarkesave se sa bazat e dh\u00ebnash, por ato gjithashtu mund t\u00eb ngarkohen mjaft efektivisht duke sjell\u00eb nj\u00eb CPU t\u00eb mbingarkuar n\u00eb server.
\nNe kemi pasur sukses realist me ndihm\u00ebn e dob\u00ebsis\u00eb SSH t\u00eb vitit 2016. Tanime, kjo dob\u00ebsi \u00ebsht\u00eb rregulluar te shumica e njer\u00ebzve, por kjo nuk do t\u00eb thot\u00eb se nuk mund t\u00eb ushtrohet ngarkes\u00eb n\u00eb SSH. Mund t\u00eb ushtrohet. Thjesht motivohet nj\u00eb ngarkes\u00eb e madhe e autorizimeve, SSH konsumon pothuajse t\u00eb gjith\u00eb CPU-n\u00eb n\u00eb server dhe pastaj faqja web p\u00ebrmbyset nga vet\u00ebm nj\u00eb ose dy k\u00ebrkesa n\u00eb sekond\u00eb. P\u00ebr pasoj\u00eb, k\u00ebto nj\u00eb ose dy k\u00ebrkesa nuk mund t\u00eb dallohen nga ngarkesa legjitime n\u00eb logjet.
\nMbeten shum\u00eb lidhje aktive q\u00eb hapim n\u00eb servera. M\u00eb par\u00eb kjo ishte nj\u00eb mang\u00ebsi e Apache, tani n\u00eb fakt kjo \u00ebsht\u00eb nj\u00eb mang\u00ebsi e nginx, pasi shpesh konfigurohet p\u00ebr default. Numri i lidhjeve q\u00eb nginx mund t\u00eb mbaj\u00eb t\u00eb hapura \u00ebsht\u00eb i kufizuar, p\u00ebrkat\u00ebsisht ne hapim k\u00ebt\u00eb num\u00ebr lidhjesh, nj\u00eb lidhje e re tashm\u00eb nuk pranohet nga nginx, dhe si rezultat, faqja e internetit nuk punon.
\nKlusteri yn\u00eb testues ka mjaft CPU p\u00ebr t\u00eb sulmuar SSL handshake. N\u00eb parim, praktikisht tregon se botnet\u00ebt ndonj\u00ebher\u00eb e p\u00eblqejn\u00eb k\u00ebt\u00eb. Nga nj\u00ebra an\u00eb, \u00ebsht\u00eb e qart\u00eb se pa SSL nuk b\u00ebhet fjal\u00eb, sepse renditja n\u00eb Google, siguria. Nga ana tjet\u00ebr, me keqardhje, SSL ka nj\u00eb problem me CPU. <\/p>\n

L3&4<\/h3>\n

\nKur flasim p\u00ebr nj\u00eb sulm n\u00eb nivelet L3&4, zakonisht flasim p\u00ebr nj\u00eb sulm n\u00eb nivelin e kanalit. Nj\u00eb ngarkes\u00eb e till\u00eb pothuajse gjithmon\u00eb \u00ebsht\u00eb e dallueshme nga legjitimja, n\u00ebse nuk \u00ebsht\u00eb nj\u00eb sulm SYN-flood. Problemi i sulmeve SYN-flood p\u00ebr mjetet e mbrojtjes \u00ebsht\u00eb sasia e madhe. Vlera maksimale e L3&4 ka qen\u00eb 1.5-2 Tbit\/s. Ky trafik \u00ebsht\u00eb shum\u00eb i v\u00ebshtir\u00eb p\u00ebr t'u p\u00ebrpunuar edhe p\u00ebr kompanit\u00eb e m\u00ebdha, duke p\u00ebrfshir\u00eb Oracle dhe Google.
\nSYN dhe SYN-ACK jan\u00eb paketa q\u00eb p\u00ebrdoren p\u00ebr t\u00eb vendosur nj\u00eb lidhje. Prandaj, \u00ebsht\u00eb e v\u00ebshtir\u00eb t\u00eb dallohet nj\u00eb SYN-flood nga nj\u00eb ngarkes\u00eb legjitime: nuk \u00ebsht\u00eb e qart\u00eb n\u00ebse \u00ebsht\u00eb nj\u00eb SYN q\u00eb ka ardhur p\u00ebr t\u00eb vendosur lidhjen, apo nj\u00eb pjes\u00eb e flud\u00ebs.<\/p>\n

UDP-flood<\/h3>\n

\nZakonisht, sulmuesit nuk kan\u00eb fuqin\u00eb q\u00eb kemi ne, prandaj p\u00ebr t\u00eb organizuar sulme mund t\u00eb p\u00ebrdoret amplifikimi. K\u00ebshtu, sulmuesi skanon internetin dhe gjen servera t\u00eb cenuesh\u00ebm ose t\u00eb konfiguruar gabimisht, t\u00eb cil\u00ebt, p\u00ebr shembull, n\u00eb p\u00ebrgjigje t\u00eb nj\u00eb pakete SYN, p\u00ebrgjigjen me tri SYN-ACK. Duke falsifikuar adres\u00ebn e burimit me adres\u00ebn e serverit t\u00eb synuar, \u00ebsht\u00eb e mundur t\u00eb rritet fuqia e nj\u00eb pakete, le t\u00eb themi, tri her\u00eb dhe t\u00eb ridrejtohet trafiku ndaj viktim\u00ebs.<\/p>\n

\"DDoS
\n
\nProblemi me amplifikimin \u00ebsht\u00eb se \u00ebsht\u00eb e v\u00ebshtir\u00eb t\u00eb zbulohet. Nj\u00eb nga rastet m\u00eb t\u00eb fundit \u00ebsht\u00eb rasti i njohur me memcached t\u00eb cenuesh\u00ebm. P\u00ebr m\u00eb tep\u00ebr, tani ka shum\u00eb pajisje IoT, kamera IP, t\u00eb cilat gjithashtu jan\u00eb kryesisht t\u00eb konfiguruara sipas parazgjedhjeve dhe zakonisht ato jan\u00eb t\u00eb konfiguruara gabimisht, prandaj p\u00ebrmes k\u00ebtyre pajisjeve, sulmuesit kryejn\u00eb sulme m\u00eb shpesh. <\/p>\n

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

SYN-flood i v\u00ebshtir\u00eb<\/h3>\n

\nSYN-flood, ndoshta, \u00ebsht\u00eb tipi m\u00eb interesant i sulmeve nga k\u00ebndv\u00ebshtrimi i zhvilluesit. Problemi \u00ebsht\u00eb se shpesh administrator\u00ebt e sistemeve p\u00ebrdorin bllokimin nga IP p\u00ebr mbrojtje. P\u00ebr m\u00eb tep\u00ebr, bllokimi nga IP ndikon jo vet\u00ebm administrator\u00ebt e sistemit q\u00eb veprojn\u00eb sipas skenar\u00ebve, por fatkeq\u00ebsisht edhe disa sisteme mbrojt\u00ebse q\u00eb blihen p\u00ebr shum\u00eb para.
\nNj\u00eb metod\u00eb e till\u00eb mund t\u00eb rezultoj\u00eb katastrofike, sepse n\u00ebse kriminel\u00ebt z\u00ebvend\u00ebsojn\u00eb adresat IP<\/a>, kompania do t\u00eb bllokoj\u00eb n\u00ebn rrjetin e saj. Kur Firewall-i bllokon klasterin e saj, nd\u00ebrveprimet e jashtme do t\u00eb d\u00ebshtojn\u00eb dhe burimi do t\u00eb prishet.
\nP\u00ebr m\u00eb tep\u00ebr, arrijtja e bllokimit t\u00eb rrjetit t\u00eb vet \u00ebsht\u00eb e leht\u00eb. N\u00ebse n\u00eb zyr\u00ebn e klientit ka nj\u00eb rrjet WI-Fi, ose n\u00ebse funksionaliteti i burimeve matet p\u00ebrmes monitorimeve t\u00eb ndryshme, at\u00ebher\u00eb ne marrim adres\u00ebn IP t\u00eb k\u00ebtij sistemi t\u00eb monitorimit ose t\u00eb Wi-Fi t\u00eb zyr\u00ebs s\u00eb klientit dhe e p\u00ebrdorim at\u00eb si burim. N\u00eb fund, burimi duket se \u00ebsht\u00eb i aksesuesh\u00ebm, por adresat IP t\u00eb synuara jan\u00eb t\u00eb bllokuara. K\u00ebshtu, mund t\u00eb bllokohet rrjeti Wi-Fi i konferenc\u00ebs HighLoad, ku prezantohet nj\u00eb produkt i ri i kompanis\u00eb, dhe kjo sjell disa kosto biznesi dhe ekonomike.
\nGjat\u00eb testimit, nuk mund t\u00eb p\u00ebrdorim amplifikimin p\u00ebrmes memcached nga ndonj\u00eb burim t\u00eb jasht\u00ebm, sepse ekzistojn\u00eb marr\u00ebveshje p\u00ebr shtrimin e trafikut vet\u00ebm n\u00eb adresat IP t\u00eb lejuara. Prandaj, ne p\u00ebrdorim amplifikimin p\u00ebrmes SYN dhe SYN-ACK, kur p\u00ebr d\u00ebrgimin e nj\u00eb SYN sistemi p\u00ebrgjigjet me dy-tre SYN-ACK, dhe n\u00eb p\u00ebrfundim sulmi dyfishohet n\u00eb dy-tre her\u00eb. <\/p>\n

Mjetet<\/h3>\n

\nNj\u00eb nga mjetet kryesore q\u00eb p\u00ebrdorim p\u00ebr ngarkes\u00ebn n\u00eb nivelin L7 \u00ebsht\u00eb Yandex-tank. Sakt\u00ebsisht, si arm\u00eb p\u00ebrdoret fantazi, plus ka disa skripta p\u00ebr gjenerimin e municioneve dhe p\u00ebr analizimin e rezultateve.
\nP\u00ebr analiz\u00ebn e trafikut rrjetor p\u00ebrdoret Tcpdump, p\u00ebr analiz\u00ebn e serverit \u2014 Nmap. P\u00ebr krijimin e ngarkes\u00ebs n\u00eb nivelin L3&4 p\u00ebrdoren OpenSSL dhe pak magji ton\u00eb me bibliotek\u00ebn DPDK. DPDK \u00ebsht\u00eb nj\u00eb bibliotek\u00eb nga Intel, e cila lejon t\u00eb punoj\u00eb me nd\u00ebrfaqen rrjetore duke anashkaluar stakun Linux, dhe k\u00ebshtu rrit efikasitetin. Sigurisht, DPDK e p\u00ebrdorim jo vet\u00ebm n\u00eb nivelin L3&4, por edhe n\u00eb nivelin L7, sepse lejon krijimin e nj\u00eb fluksi shum\u00eb t\u00eb lart\u00eb ngarkese, brenda disa milion\u00eb k\u00ebrkesave n\u00eb sekond\u00eb nga nj\u00eb makin\u00eb.
\nNe p\u00ebrdorim gjithashtu disa gjenerues trafiku dhe mjete speciale, t\u00eb cilat i shkruajm\u00eb p\u00ebr teste specifike. N\u00ebse kujtojm\u00eb dob\u00ebsin\u00eb n\u00ebn SSH, grupi i m\u00ebsip\u00ebrm nuk mund t\u00eb shfryt\u00ebzohet. N\u00ebse sulmojm\u00eb protokollin e post\u00ebs, ne p\u00ebrdorim mjete postare ose thjesht shkruajm\u00eb skripte mbi to.<\/p>\n

\n

P\u00ebrfundimet<\/h3>\n

\nSi p\u00ebrfundim, do t\u00eb doja t\u00eb them:<\/p>\n