{"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 stresi dhe ngarkese","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DDoS
\n
\nKompania Variti zhvillon mbrojtje kund\u00ebr bot\u00ebve dhe sulmeve DDoS, si dhe kryen testime stresi dhe ngarkese. N\u00eb konferenc\u00ebn HighLoad++ 2018 fol\u00ebm se si t\u00eb sigurojm\u00eb burimet nga lloje t\u00eb ndryshme sulmesh. N\u00ebse e shohim shkurt: izoloni pjes\u00ebt e sistemit, p\u00ebrdorni sh\u00ebrbime cloud dhe CDN dhe p\u00ebrdit\u00ebsoni rregullisht. Por pa kompani t\u00eb specializuara p\u00ebr mbrojtje, nuk do t'ia dilni dot \ud83d\ude42<\/i>
\n<\/a><\/noindex>
\nPara se t\u00eb lexoni tekstin, mund t\u00eb shikoni disa pik\u00eb t\u00eb shkurtra n\u00eb faqen e konferenc\u00ebs<\/a><\/noindex>.
\nDhe n\u00ebse nuk ju p\u00eblqen t\u00eb lexoni ose thjesht doni t\u00eb shihni videon, regjistrimi i fjalimit ton\u00eb \u00ebsht\u00eb m\u00eb posht\u00eb n\u00ebn spoiler.<\/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 mbron mir\u00eb nga sulmet. Ne tregojm\u00eb se kjo nuk \u00ebsht\u00eb krejt\u00ebsisht e v\u00ebrtet\u00eb.
\nSigurisht, para se t\u00eb kryejm\u00eb testet, marrim leje nga klienti, me n\u00ebnshkrim dhe vul\u00eb, dhe me ndihm\u00ebn ton\u00eb nuk mund t\u00eb b\u00ebhet nj\u00eb sulm DDoS ndaj askujt. Testimi kryhet n\u00eb koh\u00ebn e zgjedhur nga klienti, kur vizitat n\u00eb burimin e tij jan\u00eb minimale, dhe problemet me aksesin nuk do t\u00eb ndikojn\u00eb te klient\u00ebt. P\u00ebr m\u00eb tep\u00ebr, pasi gjat\u00eb procesit t\u00eb testimit gjithmon\u00eb mund t\u00eb ndodhin di\u00e7ka keq, ne kemi kontakt t\u00eb vazhduesh\u00ebm me klientin. Kjo lejon jo vet\u00ebm t\u00eb raportojm\u00eb mbi rezultatet e arritura, por gjithashtu t\u00eb b\u00ebjm\u00eb ndryshime gjat\u00eb testimit. Pas p\u00ebrfundimit t\u00eb testimit, ne gjithmon\u00eb p\u00ebrgatisim nj\u00eb raport, n\u00eb t\u00eb cilin tregojm\u00eb p\u00ebr mang\u00ebsit\u00eb e zbuluara dhe japim rekomandime p\u00ebr eliminimin e pikave t\u00eb dob\u00ebta t\u00eb faqes. <\/p>\n

Si punojm\u00eb<\/h3>\n

\nGjat\u00eb kryerjes s\u00eb testeve, ne emulojm\u00eb nj\u00eb botnet. Duke qen\u00eb se punojm\u00eb me klient\u00eb q\u00eb nuk jan\u00eb n\u00eb rrjetet tona, p\u00ebr t\u00eb siguruar q\u00eb testi t\u00eb mos p\u00ebrfundoj\u00eb n\u00eb minut\u00ebn e par\u00eb p\u00ebr shkak t\u00eb kufizimeve apo mbrojtjeve, ne paraqesim ngarkes\u00ebn jo vet\u00ebm 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, kemi nj\u00eb server testimi mjaft t\u00eb fuqish\u00ebm.<\/p>\n

Postulati<\/h3>\n

<\/p>\n

Shum\u00eb \u2014 nuk do t\u00eb thot\u00eb mir\u00eb<\/b>
\nSa m\u00eb pak ngarkes\u00eb q\u00eb arrijm\u00eb t\u00eb \u00e7ojm\u00eb burimin n\u00eb d\u00ebshtim, aq m\u00eb mir\u00eb. N\u00ebse arrijm\u00eb t\u00eb b\u00ebjm\u00eb q\u00eb faqja t\u00eb ndaloj\u00eb funksionimin nga nj\u00eb k\u00ebrkes\u00eb n\u00eb sekond\u00eb, ose madje edhe nga nj\u00eb k\u00ebrkes\u00eb n\u00eb minut\u00eb, kjo \u00ebsht\u00eb e shk\u00eblqyer. Sepse sipas ligjit t\u00eb fatit, p\u00ebrdoruesit ose keqb\u00ebr\u00ebsit do t\u00eb bien rast\u00ebsisht n\u00eb k\u00ebt\u00eb dob\u00ebsi. <\/p><\/blockquote>\n

Nj\u00eb d\u00ebshtim parcial \u00ebsht\u00eb m\u00eb i mir\u00eb se nj\u00eb i plot\u00eb<\/b>
\nNe gjithmon\u00eb k\u00ebshillojm\u00eb q\u00eb sistemet t\u00eb jen\u00eb heterogjene. Dhe ndarja e tyre duhet t\u00eb b\u00ebhet n\u00eb nivelin fizik, jo vet\u00ebm me containerization. N\u00eb rastin e ndarjes fizike, madje edhe n\u00ebse di\u00e7ka d\u00ebshton n\u00eb sit, ka nj\u00eb mund\u00ebsi t\u00eb madhe q\u00eb ai t\u00eb mos ndaloj\u00eb pun\u00ebn krejt\u00ebsisht, dhe p\u00ebrdoruesit t\u00eb ken\u00eb akses t\u00eb pakt\u00ebn n\u00eb pjes\u00ebn e funksionalitetit.<\/p><\/blockquote>\n

Arkitektura e duhur \u00ebsht\u00eb themeli i q\u00ebndrueshm\u00ebris\u00eb<\/b>
\nQ\u00ebndrueshm\u00ebria e burimit dhe aft\u00ebsia e tij p\u00ebr t\u00eb mbajtur sulmet dhe ngarkesat duhet t\u00eb planifikohen n\u00eb faz\u00ebn e projektimit, n\u00eb thelb n\u00eb faz\u00ebn kur \u00e7izojm\u00eb bllok-shecat e para n\u00eb fletore. Sepse n\u00ebse futen gabime fatale, mund t'i korrigjojm\u00eb m\u00eb von\u00eb, por \u00ebsht\u00eb shum\u00eb e v\u00ebshtir\u00eb.<\/p><\/blockquote>\n

Jo vet\u00ebm kodi duhet t\u00eb jet\u00eb i mir\u00eb, por edhe konfigurimi<\/b>
\nShum\u00eb mendojn\u00eb se nj\u00eb ekip i mir\u00eb zhvillimi \u00ebsht\u00eb garancia p\u00ebr q\u00ebndrueshm\u00ebrin\u00eb e sh\u00ebrbimit. Nj\u00eb ekip i mir\u00eb zhvillimi \u00ebsht\u00eb me t\u00eb v\u00ebrtet\u00eb i nevojsh\u00ebm, por \u00ebsht\u00eb e nevojshme gjithashtu nj\u00eb menaxhim i mir\u00eb, nj\u00eb DevOps i mir\u00eb. Pra, nevojiten specialist\u00eb q\u00eb do ta konfigurojn\u00eb sakt\u00ebsisht Linux dhe rrjetin, do t\u00eb shkruajn\u00eb sakt\u00eb konfigurimet n\u00eb nginx, do t\u00eb vendosin kufij etj. Ndryshe, burimi do t\u00eb funksionoj\u00eb mir\u00eb vet\u00ebm n\u00eb testim, nd\u00ebrsa n\u00eb prodhim n\u00eb ndonj\u00eb moment gjith\u00e7ka do t\u00eb prishet.<\/p><\/blockquote>\n

Dallimet midis testimit t\u00eb ngarkes\u00ebs dhe atij t\u00eb stresit<\/b>
\nTestimi i ngarkes\u00ebs lejon identifikimin e kufijve t\u00eb funksionimit t\u00eb sistemit. Testimi i stresit \u00ebsht\u00eb i orientuar p\u00ebr t\u00eb gjetur dob\u00ebsit\u00eb e sistemit dhe p\u00ebrdoret p\u00ebr t\u00eb thyer k\u00ebt\u00eb sistem dhe p\u00ebr t\u00eb par\u00eb se si do t\u00eb sillen gjat\u00eb d\u00ebshtimit t\u00eb pjes\u00ebve t\u00eb ndryshme. Kurse karakteri i ngarkes\u00ebs zakonisht mbetet i panjohur p\u00ebr klientin deri n\u00eb fillimin e testimit t\u00eb stresit.<\/p><\/blockquote>\n

<\/p>\n

Karakteristikat dalluese t\u00eb sulmeve L7<\/h3>\n

\nLlojet e ngarkesave zakonisht i ndajm\u00eb n\u00eb ngarkesa n\u00eb nivelin L7 dhe L3&4. L7 \u00ebsht\u00eb ngarkesa n\u00eb nivelin e aplikacionit, m\u00eb s\u00eb shpeshti n\u00ebnkuptohet vet\u00ebm HTTP, ne n\u00ebnkuptojm\u00eb \u00e7do ngarkes\u00eb n\u00eb nivelin e protokollit TCP.
\nAtak\u00ebt L7 kan\u00eb disa karakteristika dalluese. S\u00eb pari, ato vijn\u00eb drejtp\u00ebrdrejt n\u00eb aplikacion, \u00e7ka e b\u00ebn shum\u00eb t\u00eb v\u00ebshtir\u00eb reflektimin e tyre p\u00ebrmes mjeteve rrjetore. K\u00ebto sulme angazhojn\u00eb logjik\u00ebn, dhe p\u00ebr k\u00ebt\u00eb arsye jan\u00eb shum\u00eb efikase dhe n\u00eb trafik t\u00eb vog\u00ebl konsumojn\u00eb CPU-n\u00eb, memorjen, disqin, baz\u00ebn e t\u00eb dh\u00ebnave dhe burime t\u00eb tjera.<\/p>\n

HTTP Flood<\/h3>\n

\nN\u00eb rastin e \u00e7do sulmi, \u00ebsht\u00eb m\u00eb e leht\u00eb t\u00eb krijosh ngarkes\u00ebn sesa ta p\u00ebrballosh at\u00eb, 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 shpesh kjo arrihet me frekuenc\u00ebn, por n\u00ebse gjith\u00e7ka \u00ebsht\u00eb e planifikuar mir\u00eb, \u00ebsht\u00eb e pamundur t\u00eb kuptosh nga logjet 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 zakonisht k\u00ebto sulme jan\u00eb shum\u00eb t\u00eb fuqishme, n\u00eb shembullin m\u00eb posht\u00eb numri maksimal i k\u00ebrkesave kalonte 600 mij\u00eb n\u00eb minut\u00eb.<\/p>\n

\"DDoS
\n
\nHTTP Flood \u00ebsht\u00eb m\u00ebnyra m\u00eb e thjesht\u00eb p\u00ebr t\u00eb krijuar ngarkes\u00eb. Zakonisht, p\u00ebr t\u00eb p\u00ebrdoret ndonj\u00eb mjet testi ngarkese, si p.sh. ApacheBench, dhe caktohen k\u00ebrkesa dhe q\u00ebllimi. Me nj\u00eb qasje kaq t\u00eb thjesht\u00eb, ka nj\u00eb probabilitet t\u00eb madh p\u00ebr t'u p\u00ebrballur me keqkalimin e serverit, por kjo \u00ebsht\u00eb e leht\u00eb p\u00ebr t'u anashkaluar. P\u00ebr shembull, duke shtuar rreshta rast\u00ebsor\u00eb n\u00eb k\u00ebrkes\u00eb, \u00e7ka do i detyronte serverin t\u00eb dor\u00ebzoj\u00eb vazhdimisht nj\u00eb faqe t\u00eb fresk\u00ebt.
\nPo ashtu, nuk duhet harruar p\u00ebr user-agentin gjat\u00eb procesit t\u00eb krijimit t\u00eb ngarkes\u00ebs. Shum\u00eb user-agent t\u00eb mjeteve t\u00eb njohura t\u00eb testimit filtrohen nga administrator\u00ebt sistemor\u00eb, dhe n\u00eb k\u00ebt\u00eb rast, ngarkesa mund thjesht t\u00eb mos arrij\u00eb n\u00eb backend. Mund t\u00eb p\u00ebrmir\u00ebsohet ndjesh\u00ebm rezultati duke futur n\u00eb k\u00ebrkes\u00eb nj\u00eb titull relativisht t\u00eb vlefsh\u00ebm nga shfletuesi.
\nPavar\u00ebsisht thjesht\u00ebsis\u00eb, sulmet HTTP Flood kan\u00eb edhe disavantazhet e tyre. S\u00eb pari, p\u00ebr t\u00eb krijuar ngarkes\u00eb nevojiten fuqi t\u00eb m\u00ebdha. S\u00eb dyti, k\u00ebto sulme zbulohet shum\u00eb leht\u00eb, sidomos kur vijn\u00eb nga nj\u00eb adres\u00eb e vetme. Si pasoj\u00eb, k\u00ebrkesat fillojn\u00eb menj\u00ebher\u00eb t\u00eb filtrohen nga administrator\u00ebt sistemor\u00eb ose madje edhe n\u00eb nivelin e ofruesit. <\/p>\n

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

\nP\u00ebr t\u00eb ulur numrin e k\u00ebrkesave n\u00eb sekund\u00eb dhe n\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb t\u00eb ruajm\u00eb efikasitetin, duhet t\u00eb tregojm\u00eb pak imagjinat\u00eb dhe t\u00eb hulumtojm\u00eb faqen. K\u00ebshtu, mund t\u00eb ngarkohet jo vet\u00ebm kanali apo serveri, por edhe pjes\u00eb t\u00eb ve\u00e7anta t\u00eb aplikacionit, p\u00ebr shembull, baza t\u00eb dh\u00ebnash ose sisteme skedar\u00ebsh. Gjithashtu, mund t\u00eb k\u00ebrkojm\u00eb vende n\u00eb faqe q\u00eb b\u00ebjn\u00eb llogaritje t\u00eb m\u00ebdha: kalkulator\u00eb, faqe p\u00ebr p\u00ebrzgjedhjen e produkteve dhe t\u00eb ngjashme. S\u00eb fundmi, shpesh ndodh q\u00eb n\u00eb faqe ka nj\u00eb skenar php, i cili gjeneron nj\u00eb faqe nga disa qindra mij\u00ebra rreshta. Ky skenar gjithashtu ngarkon ndjesh\u00ebm serverin dhe mund t\u00eb b\u00ebhet objekt i nj\u00eb sulmi.<\/p>\n

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

\nKur skanojm\u00eb nj\u00eb burim para se t\u00eb kryejm\u00eb testin, ne n\u00eb radh\u00eb t\u00eb par\u00eb shikojm\u00eb, sigurisht, faqen vet\u00eb. K\u00ebrkojm\u00eb \u00e7do lloj fushe inputi, skedar\u00eb t\u00eb r\u00ebnd\u00eb - n\u00eb p\u00ebrgjith\u00ebsi gjith\u00e7ka q\u00eb mund t\u00eb krijoj\u00eb probleme p\u00ebr burimin dhe t\u00eb ngadal\u00ebsoj\u00eb pun\u00ebn e tij. K\u00ebtu ndihmojn\u00eb mjete t\u00eb zakonshme zhvillimi n\u00eb Google Chrome dhe Firefox, t\u00eb cilat tregojn\u00eb koh\u00ebt e p\u00ebrgjigjeve t\u00eb faqes.
\nGjithashtu skanojm\u00eb subdomenet. P\u00ebr shembull, ka nj\u00eb dyqan online, abc.com, dhe ai ka nj\u00eb subdomen admin.abc.com. Me siguri, kjo \u00ebsht\u00eb admin paneli me regjistrim, por n\u00ebse e ngarkohet, ajo mund t\u00eb krijoj\u00eb probleme p\u00ebr burimin kryesor.
\nNj\u00eb faqe mund t\u00eb ket\u00eb subdomen api.abc.com. Me siguri, ky \u00ebsht\u00eb burimi p\u00ebr aplikacionet mobile. Mund t\u00eb gjejm\u00eb aplikacionin n\u00eb App Store ose Google Play, t\u00eb vendosim nj\u00eb pik\u00eb t\u00eb ve\u00e7ant\u00eb qasjeje, t\u00eb analizojm\u00eb API-n\u00eb dhe t\u00eb regjistrojm\u00eb llogari testimi. Problemi \u00ebsht\u00eb se shpesh njer\u00ebzit mendojn\u00eb se gjith\u00e7ka q\u00eb \u00ebsht\u00eb e mbrojtur nga regjistrimi \u00ebsht\u00eb e paprekshme nga sulmet p\u00ebr ndalimin e sh\u00ebrbimit. Si\u00e7 duket regjistrimi \u00ebsht\u00eb CAPTCHA m\u00eb e mir\u00eb, por kjo nuk \u00ebsht\u00eb e v\u00ebrtet\u00eb. T\u00eb b\u00ebsh 10-20 llogari testimi \u00ebsht\u00eb e leht\u00eb, dhe kur i krijojm\u00eb, ne fitojm\u00eb qasje n\u00eb funksionalitete t\u00eb nd\u00ebrlikuara dhe t\u00eb papritura.
\nSigurisht, ne shikojm\u00eb n\u00eb historin\u00eb, n\u00eb robots.txt dhe WebArchive, ViewDNS, k\u00ebrkojm\u00eb versionet e vjetra t\u00eb burimit. Ndonj\u00ebher\u00eb ndodh q\u00eb zhvilluesit l\u00ebshojn\u00eb, le t\u00eb themi, mail2.yandex.net, nd\u00ebrsa nj\u00eb version i vjet\u00ebr, mail.yandex.net, mbetet. Ky mail.yandex.net ndalon s\u00eb mb\u00ebshteturi, burimet e zhvillimit nuk i kushtohen, por ai vazhdon t\u00eb konsumoj\u00eb baz\u00ebn e t\u00eb dh\u00ebnave. Prandaj, me ndihm\u00ebn e versionit t\u00eb vjet\u00ebr, mund t\u00eb angazhojm\u00eb n\u00eb m\u00ebnyr\u00eb efektive burimet e backend-it dhe gjith\u00e7ka q\u00eb q\u00ebndron pas dizajnit. Sigurisht, kjo nuk ndodh gjithmon\u00eb, por ne p\u00ebrballemi me t\u00eb ngjashme mjaft shpesh.
\nNatyrisht, ne do t\u00eb analizojm\u00eb t\u00eb gjitha parametrit e k\u00ebrkes\u00ebs, struktur\u00ebn e cookie. Mund t\u00eb themi, t\u00eb ngarkojm\u00eb nj\u00eb vler\u00eb n\u00eb nj\u00eb array JSON brenda cookie, t\u00eb krijojm\u00eb nj\u00eb thell\u00ebsi t\u00eb madhe dhe ta b\u00ebjm\u00eb burimin t\u00eb punoj\u00eb shum\u00eb ngadal\u00eb.<\/p>\n

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

\nE para gj\u00eb q\u00eb vjen n\u00eb mendje gjat\u00eb hulumtimit t\u00eb nj\u00eb site \u00ebsht\u00eb ngarkimi i baz\u00ebs s\u00eb t\u00eb dh\u00ebnave, pasi k\u00ebrkimi \u00ebsht\u00eb pothuajse n\u00eb t\u00eb gjitha, dhe pothuajse t\u00eb gjith\u00eb e kan\u00eb, fatkeq\u00ebsisht, t\u00eb mbrojtur dob\u00ebt. Pse zhvilluesit nuk i kushtojn\u00eb mjaftuesh\u00ebm v\u00ebmendje k\u00ebrkimeve? Por ka nj\u00eb rekomandim \u2014 nuk duhet b\u00ebr\u00eb k\u00ebrkesa t\u00eb nj\u00ebjta, sepse mund t\u00eb p\u00ebrballesh me caching, ashtu si\u00e7 ndodh me sulmet HTTP flood.
\nT\u00eb b\u00ebsh k\u00ebrkesa rast\u00ebsore n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave nuk \u00ebsht\u00eb gjithmon\u00eb e efektshme. M\u00eb mir\u00eb \u00ebsht\u00eb t\u00eb krijosh nj\u00eb list\u00eb fjal\u00ebsh ky\u00e7e q\u00eb lidhen me k\u00ebrkimin. N\u00ebse kthehemi te shembulli i nj\u00eb dyqani online: supozoni, faqja shet goma makinash dhe lejon p\u00ebrcaktimin e rrethit t\u00eb gomave, tipit t\u00eb makin\u00ebs dhe parametrave t\u00eb tjer\u00eb. Prandaj, kombinimet e fjal\u00ebve p\u00ebrkat\u00ebse do t\u00eb detyrojn\u00eb baz\u00ebn e t\u00eb dh\u00ebnave t\u00eb punoj\u00eb n\u00eb kushte shum\u00eb m\u00eb komplekse.
\nP\u00ebr m\u00eb tep\u00ebr, duhet t\u00eb p\u00ebrdoret pagination: k\u00ebrkimeve u \u00ebsht\u00eb shum\u00eb m\u00eb e v\u00ebshtir\u00eb t\u00eb japin faqen parafundore t\u00eb rezultateve sesa at\u00eb t\u00eb par\u00eb. Pra, p\u00ebrmes pagination, mund t\u00eb ndryshojm\u00eb pak ngarkes\u00ebn.
\nN\u00eb shembullin m\u00eb posht\u00eb tregojm\u00eb ngarkes\u00ebn n\u00eb k\u00ebrkim. \u00cbsht\u00eb e dukshme se n\u00eb sekond\u00ebn e par\u00eb t\u00eb testit me nj\u00eb shpejt\u00ebsi prej dhjet\u00eb k\u00ebrkesash n\u00eb sekund\u00eb, faqja ra dhe nuk p\u00ebrgjigjej.<\/p>\n

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

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

\nN\u00ebse nuk ka k\u00ebrkim, nuk do t\u00eb thot\u00eb se faqja nuk p\u00ebrmban fusha t\u00eb tjera t\u00eb prekshme. Nj\u00eb fush\u00eb e till\u00eb mund t\u00eb jet\u00eb autorizimi. Tani zhvilluesit p\u00eblqejn\u00eb t\u00eb krijojn\u00eb hash t\u00eb nd\u00ebrlikuar p\u00ebr t\u00eb mbrojtur baz\u00ebn e emrave t\u00eb p\u00ebrdoruesve nga sulmet me tabela t\u00eb dukshme. Kjo \u00ebsht\u00eb mir\u00eb, por k\u00ebto hash konsumojn\u00eb burime t\u00eb m\u00ebdha CPU. Nj\u00eb fluks i madh autorizimesh t\u00eb rreme \u00e7on n\u00eb d\u00ebshtimin e procesorit, dhe si pasoj\u00eb, faqja ndalon s\u00eb funksionuari.
\nPrania e \u00e7do forme p\u00ebr komentet dhe reagimet n\u00eb faq\u00eb \u00ebsht\u00eb nj\u00eb mund\u00ebsi p\u00ebr t\u00eb d\u00ebrguar aty tekste shum\u00eb t\u00eb m\u00ebdha ose thjesht p\u00ebr t\u00eb krijuar nj\u00eb mas\u00eb t\u00eb madhe mesazhe. Ndonj\u00ebher\u00eb faqet pranojn\u00eb skedar\u00eb t\u00eb ngjeshur, p\u00ebrfshir\u00eb n\u00eb formatin gzip. N\u00eb k\u00ebt\u00eb rast, ne marrim nj\u00eb skedar q\u00eb \u00ebsht\u00eb 1TB, e ngjeshim at\u00eb me gzip n\u00eb disa byte ose kilobyte dhe e d\u00ebrgojm\u00eb n\u00eb faq\u00eb. M\u00eb pas, ai deshifrohet dhe rezultati \u00ebsht\u00eb shum\u00eb interesant. <\/p>\n

Rest API<\/h3>\n

\nDo t\u00eb doja t\u00eb dedikoja pak v\u00ebmendje sh\u00ebrbimeve kaq t\u00eb njohura tani, si Rest API. Mbrojtja e Rest API \u00ebsht\u00eb shum\u00eb m\u00eb e komplikuar se nj\u00eb website i zakonsh\u00ebm. Metodat e zakonshme t\u00eb mbrojtjes nga p\u00ebrpjekjet p\u00ebr thyerjen e fjal\u00ebkalimeve dhe aktiviteteve t\u00eb tjera t\u00eb paligjshme nuk funksionojn\u00eb p\u00ebr Rest API.
\nRest API \u00ebsht\u00eb shum\u00eb e leht\u00eb p\u00ebr t'u thyer, sepse ai iu drejtohet drejtp\u00ebrdrejt databaz\u00ebs. Nd\u00ebrkoh\u00eb, d\u00ebshtimi i nj\u00eb sh\u00ebrbimi t\u00eb till\u00eb ka pasoja mjaft serioze p\u00ebr biznesin. Arsyetimi \u00ebsht\u00eb se Rest API zakonisht \u00ebsht\u00eb i lidhur jo vet\u00ebm me website-in kryesor, por edhe me aplikacionin mobil, si dhe me disa burime t\u00eb brendshme t\u00eb biznesit. Dhe n\u00ebse e gjith\u00eb kjo d\u00ebshton, ndikimi \u00ebsht\u00eb shum\u00eb m\u00eb i fort\u00eb se n\u00eb rastin e d\u00ebshtimit t\u00eb nj\u00eb website-i t\u00eb zakonsh\u00ebm. <\/p>\n

Ngarkesa mbi p\u00ebrmbajtjen e r\u00ebnd\u00eb<\/h3>\n

\nN\u00ebse na ofrohet t\u00eb testojm\u00eb ndonj\u00eb aplikacion t\u00eb zakonsh\u00ebm me nj\u00eb faqe, nj\u00eb landing page, nj\u00eb website vizit\u00eb, nuk kemi ndonj\u00eb funksionalitet t\u00eb komplikuar, ne k\u00ebrkojm\u00eb p\u00ebrmbajtje t\u00eb r\u00ebnd\u00eb. P\u00ebr shembull, imazhe t\u00eb m\u00ebdha q\u00eb serveri i d\u00ebrgon, skedar\u00eb binar\u00eb, dokumentacion PDF - ne provojm\u00eb t\u00eb shkarkojm\u00eb t\u00eb gjitha k\u00ebto. K\u00ebto teste ngarkojn\u00eb mir\u00eb sistemi i skedar\u00ebve dhe bllokojn\u00eb kanalet, dhe prandaj jan\u00eb efektive. Pra, edhe n\u00ebse nuk e d\u00ebrgoni serverin n\u00eb tok\u00eb duke shkarkuar nj\u00eb skedar t\u00eb madh me shpejt\u00ebsi t\u00eb vogla, thjesht do t\u00eb bllokoni kanalin e serverit t\u00eb synuar dhe at\u00ebher\u00eb do t\u00eb ndodh\u00eb nj\u00eb refuzim sh\u00ebrbimi.
\nN\u00eb shembuj t\u00eb till\u00eb testi, duket se me shpejt\u00ebsin\u00eb 30 RPS, website-i nuk u p\u00ebrgjigj m\u00eb, ose nxori gabime 500.<\/p>\n

\"DDoS
\n
\nNuk duhet t\u00eb harrojm\u00eb as rregullimin e server\u00ebve. Shpesh takojm\u00eb njer\u00ebz q\u00eb kan\u00eb bler\u00eb nj\u00eb virtual, kan\u00eb vendosur Apache aty, kan\u00eb rregulluar gjith\u00e7ka sipas parashikimeve, kan\u00eb vendosur aplikacionin 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 ishte vet\u00ebm 10 RPS. Ne prit\u00ebm 5 minuta, dhe serveri ra. N\u00eb t\u00eb v\u00ebrtet\u00eb, nuk dihet deri n\u00eb fund pse ra, por ka dyshime se ai thjesht \u00ebsht\u00eb mbushur me memorie, dhe p\u00ebr k\u00ebt\u00eb arsye ndaloi p\u00ebrgjigjen.<\/p>\n

Wave based<\/h3>\n

\nN\u00eb vitet e fundit, sulmet val\u00ebt jan\u00eb b\u00ebr\u00eb mjaft t\u00eb njohura. Kjo lidhet me faktin se shum\u00eb organizata blejn\u00eb pajisje t\u00eb ndryshme p\u00ebr mbrojtje nga DDoS, t\u00eb cilat k\u00ebrkojn\u00eb nj\u00eb koh\u00eb t\u00eb caktuar p\u00ebr t\u00eb koleksionuar statistik\u00ebn p\u00ebr t\u00eb filluar filtrimin e sulmit. K\u00ebshtu q\u00eb nuk filtrojn\u00eb sulmin n\u00eb 30-40 sekondat e para, sepse grumbullojn\u00eb t\u00eb dh\u00ebna dhe m\u00ebsojn\u00eb. P\u00ebr pasoj\u00eb, n\u00eb k\u00ebto 30-40 sekonda, mund t\u00eb d\u00ebrgohet aq shum\u00eb sa burimi do t\u00eb ndahet p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb, derisa t\u00eb p\u00ebrfundojn\u00eb t\u00eb gjitha k\u00ebrkesat.
\nN\u00eb rastin e sulmit m\u00eb posht\u00eb, kishte nj\u00eb interval prej 10 minutash, pas s\u00eb cil\u00ebs erdhi nj\u00eb sasi e re, e ndryshuar e sulmit.<\/p>\n

\"DDoS
\n
\nK\u00ebshtu q\u00eb mbrojtja u m\u00ebsoi, filloi filtrimin, por erdhi nj\u00eb sasi e re, krejt ndryshe e sulmit, dhe mbrojtja filloi p\u00ebrs\u00ebri t\u00eb m\u00ebsoj\u00eb. N\u00eb fakt, filtrimi ndalon s\u00eb funksionuari, mbrojtja b\u00ebhet e pavlefshme, dhe faqja nuk \u00ebsht\u00eb e disponueshme.
\nP\u00ebr sulmet val\u00ebve jan\u00eb karakteristik\u00eb vlerat shum\u00eb t\u00eb larta n\u00eb kulm, ato mund t\u00eb arrijn\u00eb qindra mij\u00ebra ose miliona k\u00ebrkesa n\u00eb sekond\u00eb, kur flasim p\u00ebr L7. N\u00ebse flasim p\u00ebr L3&4, at\u00ebher\u00eb mund t\u00eb ket\u00eb qindra gigabit trafik, ose, p\u00ebrkat\u00ebsisht, qindra mpps n\u00ebse llogariten n\u00eb paketa.
\nProblemi i k\u00ebtyre sulmeve \u00ebsht\u00eb n\u00eb sinkronizim. Sulmet vijn\u00eb nga botneti, dhe p\u00ebr t\u00eb krijuar nj\u00eb kulm shum\u00eb t\u00eb lart\u00eb n\u00eb nj\u00eb moment t\u00eb ve\u00e7ant\u00eb, k\u00ebrkohet nj\u00eb shkall\u00eb e lart\u00eb sinkronizimi. Dhe kjo koordinim nuk \u00ebsht\u00eb gjithmon\u00eb e mundur: ndonj\u00ebher\u00eb n\u00eb fund del nj\u00eb kulm parabolik, q\u00eb duket mjaft i shkurt\u00ebr.<\/p>\n

Jo vet\u00ebm HTTP<\/h3>\n

\nP\u00ebrve\u00e7 HTTP n\u00eb nivelin L7, ne gjithashtu na p\u00eblqen t\u00eb eksploatojm\u00eb protokolle t\u00eb tjera. Zakonisht, nj\u00eb faqe interneti e zakonshme, sidomos n\u00eb nj\u00eb hosting t\u00eb zakonsh\u00ebm, ka protokollet e post\u00ebs dhe MySQL q\u00eb duken n\u00eb jashtsi. Protokollet e post\u00ebs jan\u00eb m\u00eb pak t\u00eb ndjeshme ndaj ngarkesave se sa bazat e t\u00eb dh\u00ebnave, por mund t\u00eb ngarkohen gjithashtu mjaft efektivisht dhe n\u00eb rezultatin e saj marrim CPU t\u00eb mbingarkuar n\u00eb server.
\nNe kemi arritur sukses me an\u00eb t\u00eb nj\u00eb t\u00eb met\u00eb n\u00eb SSH q\u00eb u zbuluar n\u00eb vitin 2016. Tani kjo e met\u00eb \u00ebsht\u00eb rreth 90% e rregulluar nga t\u00eb gjith\u00eb, por kjo nuk do t\u00eb thot\u00eb se nuk mund t\u00eb ngarkohet SSH. Mund t\u00eb ngarkohet. Thjesht jepet nj\u00eb ngarkes\u00eb e madhe autorizimesh, SSH shqet\u00ebson pothuajse t\u00eb gjith\u00eb CPU-n\u00eb n\u00eb server dhe m\u00eb pas faqja interneti ndalet nga nj\u00eb ose dy k\u00ebrkesa n\u00eb sekond\u00eb. K\u00ebshtu, k\u00ebto nj\u00eb ose dy k\u00ebrkesa n\u00eb log nuk mund t\u00eb dallohet asgj\u00eb nga ngarkesa legjitime.
\nMbeten aktuale edhe shum\u00eb lidhjet q\u00eb ne i hapim n\u00eb servera. Disa her\u00eb, Apache kishte probleme me k\u00ebt\u00eb, tani n\u00eb fakt edhe nginx ka probleme, pasi shpesh konfigurimi i tij b\u00ebhet automatikisht. Numri i lidhjeve q\u00eb nginx mund t\u00eb mbaj\u00eb t\u00eb hapura \u00ebsht\u00eb i kufizuar, p\u00ebr rrjedhoj\u00eb n\u00ebse hapim k\u00ebt\u00eb num\u00ebr lidhjesh, nginx nuk pranon nj\u00eb lidhje t\u00eb re dhe si rezultat, faqja nuk funksionon.
\nKlustri yn\u00eb teste ka mjaftuesh\u00ebm CPU p\u00ebr t\u00eb sulmuar SSL handshake. N\u00eb parim, si\u00e7 tregon praktika, edhe botnetet ndonj\u00ebher\u00eb e b\u00ebjn\u00eb k\u00ebt\u00eb. Nga nj\u00ebra an\u00eb, \u00ebsht\u00eb e qart\u00eb q\u00eb pa SSL nuk mund t\u00eb b\u00ebhet, sepse renditja n\u00eb Google, sigurimi dhe mbrojtja jan\u00eb t\u00eb r\u00ebnd\u00ebsishme. Nga ana tjet\u00ebr, p\u00ebr fat t\u00eb keq, SSL ka nj\u00eb problem me CPU. <\/p>\n

L3&4<\/h3>\n

\nKur flasim p\u00ebr sulmin n\u00eb nivelet L3&4, zakonisht flasim p\u00ebr sulmin n\u00eb nivelin e kanalit. Nj\u00eb ngarkes\u00eb e till\u00eb pothuajse gjithmon\u00eb \u00ebsht\u00eb e dallueshme nga e ligjshme, n\u00ebse nuk \u00ebsht\u00eb nj\u00eb sulm SYN-flood. Problemi i sulmeve SYN-flood p\u00ebr mjetet mbrojt\u00ebse q\u00ebndron n\u00eb v\u00ebllimin e madh. Maksimumi i L3&4 ka qen\u00eb 1.5-2 Tbit\/s. Nj\u00eb trafik i till\u00eb \u00ebsht\u00eb shum\u00eb i v\u00ebshtir\u00eb p\u00ebr t'u menaxhuar madje edhe nga kompanit\u00eb e m\u00ebdha, duke p\u00ebrfshir\u00eb Oracle dhe Google.
\nSYN dhe SYN-ACK jan\u00eb paketa q\u00eb p\u00ebrdoren kur krijohet nj\u00eb lidhje. Prandaj, SYN-flood dhe \u00ebsht\u00eb e v\u00ebshtir\u00eb t\u00eb dallohet nga ngarkesa e ligjshme: \u00ebsht\u00eb e paqart\u00eb n\u00ebse ky \u00ebsht\u00eb nj\u00eb SYN q\u00eb erdhi p\u00ebr t\u00eb krijuar lidhjen, apo nj\u00eb pjes\u00eb e flud\u00ebs.<\/p>\n

UDP-flood<\/h3>\n

\nZakonisht, sulmuesit nuk kan\u00eb ato kapacitete q\u00eb kemi ne, prandaj p\u00ebr organizimin e sulmeve mund t\u00eb p\u00ebrdoret amplifikimi. K\u00ebshtu, sulmuesi skanon internetin dhe gjen ose server\u00eb t\u00eb dob\u00ebt ose t\u00eb konfiguruar gabim, t\u00eb cilat, p\u00ebr shembull, n\u00eb p\u00ebrgjigje t\u00eb nj\u00eb SYN-pakete, p\u00ebrgjigjen me tre SYN-ACK. Duke falsifikuar adres\u00ebn e burimit nga adresa e serverit t\u00eb synuar, mund t\u00eb rritet fuqia, le t\u00eb themi, n\u00eb tri her\u00eb me nj\u00eb paket\u00eb dhe t\u00eb redirected trafikun n\u00eb viktim\u00eb.<\/p>\n

\"DDoS
\n
\nProblemi i amplifikimeve q\u00ebndron n\u00eb zbulimin e tyre t\u00eb komplikuar. Nga shembujt m\u00eb t\u00eb fundit mund t\u00eb p\u00ebrmendim rastin e njohur me memcached. Po ashtu, tani ka shum\u00eb pajisje IoT, kamera IP, q\u00eb gjithashtu jan\u00eb kryesisht t\u00eb konfiguruara automatikisht dhe gabimisht, prandaj ndodhin sulme m\u00eb shpesh p\u00ebrmes k\u00ebtyre pajisjeve. <\/p>\n

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

SYN-flood i komplikuar<\/h3>\n

\nSYN-flood, ndoshta, \u00ebsht\u00eb lloji m\u00eb interesant i t\u00eb gjitha sulmeve nga pik\u00ebpamja e zhvilluesit. Problemi \u00ebsht\u00eb se shpesh administrator\u00ebt e sistemeve p\u00ebrdorin bllokimin e IP p\u00ebr mbrojtje. Dhe me bllokimin e IP preken jo vet\u00ebm administrator\u00ebt e sistemeve q\u00eb veprojn\u00eb sipas skenar\u00ebve, por, fatkeq\u00ebsisht, edhe disa sisteme mbrojt\u00ebse q\u00eb blihen me para t\u00eb m\u00ebdha.
\nKy metod\u00eb mund t\u00eb ket\u00eb pasoja katastrofike, sepse n\u00ebse keqb\u00ebr\u00ebsit z\u00ebvend\u00ebsojn\u00eb Adresa IP<\/a>, kompania do t\u00eb bllokoj\u00eb subnetin e saj t\u00eb vet. Kur Firewall bllokon klasterin e saj, nd\u00ebrveprimet e jashtme do t\u00eb d\u00ebshtojn\u00eb dhe burimi do t\u00eb prishet.
\nP\u00ebrve\u00e7 k\u00ebsaj, arritja e bllokimit t\u00eb rrjetit t\u00eb vet nuk \u00ebsht\u00eb e v\u00ebshtir\u00eb. N\u00ebse n\u00eb zyr\u00ebn e klientit ka nj\u00eb rrjet Wi-Fi, ose n\u00ebse funksionaliteti i burimeve matet me ndihm\u00ebn e monitorimeve t\u00eb ndryshme, ne marrim adres\u00ebn IP t\u00eb k\u00ebtij sistemi monitorimi ose t\u00eb klientit t\u00eb Wi-Fi dhe e p\u00ebrdorim at\u00eb si burim. N\u00eb p\u00ebrfundim, burimi duket se \u00ebsht\u00eb i aksesuesh\u00ebm, por adresat IP t\u00eb synuara jan\u00eb t\u00eb bllokuara. N\u00eb k\u00ebt\u00eb m\u00ebnyr\u00eb, mund t\u00eb bllokohet rrjeti Wi-Fi i konferenc\u00ebs HighLoad, ku prezantohet nj\u00eb produkt i ri i kompanis\u00eb, \u2014 dhe kjo sjell ndihma t\u00eb caktuara p\u00ebr biznesin dhe ekonomin\u00eb.
\nGjat\u00eb testimit ne nuk mund t\u00eb p\u00ebrdorim amplifikimin p\u00ebrmes memcached nga disa burime t\u00eb jashtme, sepse ka marr\u00ebveshje p\u00ebr d\u00ebrgimin e trafikut vet\u00ebm n\u00eb adresat IP t\u00eb lejuara. P\u00ebr rrjedhoj\u00eb, 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 si rezultat sulmi shum\u00ebzohet me dy-tre her\u00eb. <\/p>\n

Mjetet<\/h3>\n

\nNj\u00eb nga instrumentet kryesore q\u00eb p\u00ebrdorim p\u00ebr ngarkes\u00ebn n\u00eb nivel L7 \u00ebsht\u00eb Yandex-tank. N\u00eb ve\u00e7anti, si arm\u00eb p\u00ebrdoret fantom, plus ka disa skripta p\u00ebr gjenerimin e municionit dhe p\u00ebr analiz\u00ebn e rezultateve.
\nP\u00ebr analiz\u00ebn e trafikut rrjetor p\u00ebrdoret Tcpdump, p\u00ebr analiz\u00ebn e serverit \u2014 Nmap. P\u00ebr t\u00eb krijuar ngarkesa n\u00eb nivel L3&4 p\u00ebrdorim OpenSSL dhe pak magji ton\u00eb me librarin\u00eb DPDK. DPDK \u00ebsht\u00eb nj\u00eb bibliotek\u00eb nga Intel q\u00eb lejon pun\u00ebn me nd\u00ebrfaqen rrjetore, duke kaluar p\u00ebrmes stack-ut t\u00eb Linux dhe k\u00ebshtu rrit efikasitetin. Natyrisht, DPDK ne e p\u00ebrdorim jo vet\u00ebm n\u00eb nivelin L3&4, por edhe n\u00eb nivelin L7, sepse ajo lejon krijimin e nj\u00eb fluksi shum\u00eb t\u00eb lart\u00eb ngarkese, n\u00eb kufijt\u00eb e disa milion k\u00ebrkesave n\u00eb sekond\u00eb nga nj\u00eb makin\u00eb.
\nNe p\u00ebrdorim gjithashtu disa gjenerator\u00eb trafiku dhe vegla speciale q\u00eb i shkruajm\u00eb p\u00ebr teste specifike. Duke kujtuar vulnerability-n n\u00ebn SSH, me setin e p\u00ebrmendur m\u00eb sip\u00ebr ajo nuk mund t\u00eb eksploatohet. N\u00ebse sulmojm\u00eb protokollin e post\u00ebs, ne marrim utilitar\u00ebt e post\u00ebs ose thjesht shkruajm\u00eb skripta p\u00ebr to.<\/p>\n

\n

P\u00ebrfundimet<\/h3>\n

\nSi nj\u00eb p\u00ebrfundim, do t\u00eb d\u00ebshironim t\u00eb theksonim:<\/p>\n