DDoS në ndihmë: si realizojmë teste stres dhe ngarkese

Compania Variti zhvillon mbrojtjen nga robotët dhe sulmet DDoS, si dhe kryen teste stresi dhe ngarkese. Në konferencën HighLoad++ 2018 ne folëm për mënyrat se si të sigurojmë burimet nga lloje të ndryshme sulmesh. Nëse e thjeshtojmë: izolojini pjesët e sistemit, përdorni shërbime cloud dhe CDN dhe aktualizoni rregullisht. Por pa kompani të specializuara me mbrojtje, do të jeni ende në vështirësi 🙂

Para se të lexoni tekstin, mund të njiheni me përmbledhjet e shkurtra në faqen e konferencës.
Nëse nuk ju pëlqen të lexoni ose thjesht dëshironi të shikoni videon, regjistrimi i fjalimit tonë është më poshtë nën spojler.

Regjistrimi i fjalimit

Shumë kompani tashmë dinë të kryejnë teste ngarkese, por jo të gjitha bëjnë teste stresi. Disa nga klientët tanë mendojnë se faqja e tyre është e paprekshme, sepse kanë një sistem highload dhe ai i mbrojt mirë nga sulmet. Ne tregojmë se kjo nuk është plotësisht e vërtetë.
Natyrisht, para se të zhvillojmë provat, ne marrim leje nga klienti, e cila është e nënshkruar dhe e vulosur, dhe me ndihmën tonë, një sulm DDoS nuk mund të realizohet ndaj askujt. Testimi kryhet në kohën e zgjedhur nga klienti, kur vizitueshmëria e burimit të tij është minimale, dhe problemet me qasjen nuk do të ndikojnë te klientët. Për më tepër, për shkak se gjatë testimit gjithmonë mund të ndodhin diçka të papritur, ne kemi një kontakt të vazhdueshëm me klientin. Kjo na lejon jo vetëm të raportojmë për rezultatet e arritura, por gjithashtu të bëjmë ndonjë ndryshim gjatë testimit. Pas përfundimit të testimit, ne gjithmonë përpilojmë një raport, në të cilin theksojmë mangësitë e zbuluara dhe japim rekomandime për eliminimin e dobësive të faqes së internetit.

Si punojmë

Gjatë zhvillimit të testimeve, ne imitojmë një botnet. Duke qenë se punojmë me klientë që nuk ndodhen në rrjetet tona, për të siguruar që testi të mos përfundojë pas minutës së parë për shkak të aktivizimit të kufijve ose mbrojtjes, ne krijojmë ngarkesën jo nga një IP, por nga nënrrjeti ynë. Për më tepër, për të krijuar një ngarkesë të konsiderueshme, ne kemi një server testues mjaft të fuqishëm.

Postulatet

Shumë — nuk do të thotë mirë
Sa më pak ngarkesë të arrijmë deri në dështimin e burimit, aq më mirë. Nëse arrijmë që faqja të ndalojë funksionimin nga një kërkesë në sekondë, apo edhe nga një kërkesë në minutë, kjo është e shkëlqyer. Sepse sipas ligjit të rastësisë, përdoruesit ose sulmuesit do të zihet në këtë dobësi.

Dështim pjesor është më i mirë se i plotë
Ne gjithmonë rekomandojmë të bëjmë sistemet heterogjene. Dhe ndarja e tyre duhet të ndodhë pikërisht në nivelin fizik, dhe jo vetëm përmes kontenjerizimit. Në rast të ndarjes fizike, edhe nëse diçka dështonte në faqen e internetit, ka mundësi të madhe që të mos ndërpritet krejtësisht puna e saj, dhe përdoruesit të ruajnë qasjen ndoshta edhe në një pjesë të funksionalitetit.

Arkitektura e duhur është baza e qëndrueshmërisë
Qëndrueshmëria e burimit dhe aftësia e tij për të përballuar sulme dhe ngarkesa duhet të parashikohet në fazën e projektimit, praktikisht në fazën e vizatimit të diagrameve të para në shënim. Sepse nëse ngjallen gabime fatale, është e mundur të korrigjohen më vonë, por shumë e vështirë.

Që çdo gjë të jetë e mirë, jo vetëm kodi, por edhe konfigurimi
Shumë mendojnë se një ekip i mirë zhvillimi është garantimi i qëndrueshmërisë së shërbimit. Një ekip i mirë zhvillimi është padyshim i nevojshëm, por duhet gjithashtu një menaxhim i mirë, një DevOps i duhur. Pra, na nevojiten specialistë që do të konfigurojnë saktë Linux-in dhe rrjetin, do të shkruajnë skenaret e konfigurimit në nginx, do të vendosin kufijtë dhe më shumë. Në të kundërt, burimi do të funksionojë mirë vetëm në test, por në prodhim në një moment të caktuar gjithçka do të dështojë.

Dallimet midis testimit të ngarkesës dhe testimit të stresit
Testimi i ngarkesës lejon identifikimin e kufijve të funksionimit të sistemit. Testimi i stresit ka si qëllim gjetjen e pika të dobëta të sistemit dhe përdoret për të prishur këtë sistem dhe për të parë si do të sillet ai gjatë dështimit të ndonjë pjese. Në të njëjtën kohë, natyra e ngarkesës zakonisht mbetet e panjohur për klientin deri në fillimin e testimit të stresit.

Veçoritë dalluese të sulmeve L7

Llojet e ngarkesave zakonisht i ndajnë në ngarkesa në nivelin L7 dhe L3&4. L7 është ngarkesa në nivelin e aplikacionit, më shpesh nënkuptohet vetëm HTTP, ne nënkuptojmë çdo ngarkesë në nivelin e protokollit TCP.
L7 sulmet kanë karakteristika të veçanta. E para, ato vijnë drejtpërdrejt në aplikacion, duke e bërë të vështirë reflektimin e tyre me mjete rrjetike. Këto sulme përdorin logjikën, dhe për këtë arsye konsumojnë shumë efikasitet mjetet CPU, memorie, disk, bazën e të dhënave dhe burime të tjera, edhe me një trafik të vogël.

HTTP Flood

Në rastin e çdo sulmi, është më e lehtë të krijohet ngarkesa sesa të përballohet ajo, dhe kjo është e vërtetë edhe për L7. Trafiku i sulmit nuk është gjithmonë e thjeshtë të dallohet nga ai legjitim, dhe shpeshherë arrihet ta bëjmë këtë nëpërmjet frekuencës, por nëse gjithçka është planifikuar siç duhet, është e pamundur të kuptohet nga logët se ku është sulmi dhe ku janë kërkesat legjitime.
Si një shembull të parë, le të shqyrtojmë sulmin HTTP Flood. Nga grafiku, duket se këto sulme janë zakonisht shumë të fuqishme; në shembullin më poshtë, numri i kulmëve të kërkesave e tejkalonte 600 mijë në minutë.

HTTP Flood — është mënyra më e thjeshtë për të krijuar ngarkesë. Në përgjithësi, për të përdoret një mjet testimi ngarkese, si p.sh., ApacheBench, dhe i caktohen kërkesa dhe qëllimi. Me një qasje kaq të thjeshtë, ka shumë mundësi të përballesh me sistemin e ruajtjes së serverit, por është lehtë për ta shpërthyer. Për shembull, duke shtuar vargje rastësore në kërkesë, çfarë do ta detyrojë serverin që të kthejë vazhdimisht një faqe të re.
Po ashtu, nuk duhet të harrohet për user-agent në procesin e krijimit të ngarkesës. Shumë user-agent të mjeteve të njohura të testimit filtrohen nga administratorët e sistemeve, dhe në këtë rast ngarkesa mund të mos arrijë dot deri te backend-i. Resultatin mund ta përmirësosh ndjeshëm duke futur në kërkesë një titull më shumë ose më pak të vlefshëm nga një shfletues.
Pavarësisht thjeshtësisë, sulmet HTTP Flood kanë dhe disavantazhe të veta. Së pari, për të krijuar ngarkesë kërkohen burime të mëdha. Së dyti, këto sulme janë shumë të lehta për tu zbuluar, veçanërisht nëse vijnë nga një adresë. Si rezultat, kërkesat fillojnë menjëherë të filtrohen nga administratorët e sistemeve ose madje edhe në nivelin e ofruesit.

Çfarë duhet të kërkosh

Për të reduktuar numrin e kërkesave për sekondë pa humbur efektivitetin, nevojitet pak imagjinatë dhe eksplorim i faqes. Kështu, mund të ngarkoni jo vetëm kanal ose server, por edhe pjesë të veçanta të aplikacionit, siç janë bazat e të dhënave ose sistemet e skedave. Gjithashtu, mund të kërkoni për vendet në faqen që bëjnë llogaritje të mëdha: kalkulatorë, faqe me përzgjedhje produktesh, etj. Për më tepër, shpesh ndodh që në faqen ka një skenar php që gjeneron një faqe nga disa qindra mijëra rreshta. Një skenar i tillë gjithashtu ngarkon ndjeshëm serverin dhe mund të bëhet objekt sulmi.

Ku të kërkojmë

Kur skanojmë burimin para se të kryejmë testimin, ne fillimisht shikojmë, sigurisht, faqen e vet. Kërkojmë të gjitha llojet e fushave të hyrjes, skedarëve të rëndë — në përgjithësi çdo gjë që mund të krijojë probleme për burimin dhe ta ngadalësojë atë. Këtu ndihmojnë mjetet e zakonshme të zhvillimit në Google Chrome dhe Firefox, që tregojnë kohët e përgjigjeve të faqes.
Ne skanojmë gjithashtu nën-domainet. Për shembull, ka një dyqan online, abc.com, dhe ai ka një nën-domain admin.abc.com. Ka shumë mundësi që kjo të jetë paneli administrativ me autorizim, por nëse i japim ngarkesë, mund të krijojë probleme për burimin kryesor.
Një faqe mund të ketë nën-domainin api.abc.com. Ka shumë mundësi që ky të jetë një burim për aplikacione mobile. Aplikacioni mund të gjendet në App Store ose Google Play, të vendoset një pikë qasje speciale, të depurohet API dhe të regjistrohen llogari testuese. Problemi është se shpesh njerëzit mendojnë se gjithçka që është e mbrojtur me autorizim është e paprekshme nga sulmet e refuzimit të shërbimit. Sipas tyre, autorizimi është CAPTCHA më e mirë, por kjo nuk është e vërtetë. Të bësh 10-20 llogari testuese është e thjeshtë, dhe duke i krijuar ato, ne fitojmë qasje në funksionalitetin e komplikuar dhe të papenguar.
Sigurisht, ne shqyrtojmë historinë, robots.txt dhe WebArchive, ViewDNS, duke kërkuar versione të vjetra të burimit. Ndonjëherë ndodh që zhvilluesit lançojnë, për shembull, mail2.yandex.net, ndërsa versi e vjetër, mail.yandex.net, mbetet. Ky mail.yandex.net nuk vazhdon të mbështetet, për të nuk alokohen burime zhvillimi, por ai vazhdon të konsumojë bazën e të dhënave. Për rrjedhojë, me ndihmën e versionit të vjetër mund të angazhohen efikasitet burimet e backend-it dhe gjithçka që qëndron pas modelimit. Natyrisht, kjo nuk ndodh gjithmonë, por ne përballemi me diçka të tillë mjaft shpesh.
Sigurisht, ne analizojmë të gjitha parametrat e kërkesës, strukturën e cookie-ve. Mund të thoni, mund të ngarkojmë në një varg JSON brenda cookie-ve ndonjë vlerë, të krijojmë një thellësi të madhe dhe të bëjmë që burimi të funksionojë pa kuptim për një kohë të gjatë.

Ngarkesa në kërkim

E para e parë që vjen në mendje kur shqyrtohet një sit është ngarkimi i bazës së të dhënave, pasi që kërkimi është i pranishëm në pothuajse çdo sit, dhe fatkeqësisht pothuajse të gjithë janë të mbrojtur dobët. Për një arsye, zhvilluesit nuk i kushtojnë kërkimit kujdesin e duhur. Por ka një rekomandim — nuk është e rekomandueshme të bëni kërkesa uniforme, sepse mund të përballeni me caching, ashtu si në rastin e sulmit HTTP flood.
Bërja e kërkesave rastësore në bazën e të dhënave gjithashtu nuk është gjithmonë efektive. Më mirë do të ishte të krijonit një listë fjalësh kyçe që i përkasin kërkimit. Nëse kthehemi në shembullin e një dyqani online: supozoni se siti tregton goma për makina dhe lejon caktimin e rrethit të gomave, tipin e makinës dhe parametra të tjerë. Prandaj, kombinimet e fjalëve relevante do ta bëjnë bazën e të dhënave të punojë në kushte shumë më të komplikuara.
Për më tepër, duhet të përdoret paginimi: është shumë më e vështirë për kërkimin të marrë faqen parafundit të rezultatit, sesa atë të parë. Pra, përmes paginimit mund të diversifikoni pak ngarkesën.
Në shembullin më poshtë, ne tregojmë ngarkesën në kërkim. Është e dukshme se që në sekondën e parë të testit, me shpejtësi dhjetë kërkesa në sekondë, siti ra dhe nuk përgjigjej.

Nëse nuk ka kërkese?

Nëse nuk ka kërkese, kjo nuk do të thotë që faqja nuk përmban fusha të tjera të ndjeshme. Një nga këto mund të jetë autentikimi. Aktualisht, zhvilluesit pëlqejnë të bëjnë hash-e të komplikuara për të mbrojtur bazën e të dhënave të login-eve nga sulmet me tabela të përhershme. Kjo është e mirë, por këta hash-e konsumojnë shumë burime CPU. Një fluks i madh i falsifikimeve të autentikimit çon në dështimin e procesorit, dhe si pasojë, faqja ndalon së funksionuari.
Prania e formave të ndryshme për komente dhe feedback në faqen e internetit është një arsye për të dërguar tekste shumë të mëdha atje ose thjesht për të krijuar një fluks të madh. Ndonjëherë faqet pranojnë skedarë të ngarkuar, përfshirë në formatin gzip. Në këtë rast, ne marim një skedar me madhësi 1TB, e kompresojmë atë me gzip në disa bite ose kilobajtë dhe e dërgojmë në faqen e internetit. Më pas, ai dekompresohet dhe rezulton një efekt shumë interesante.

Rest API

Dëshiroj të kushtoj pak vëmendje shërbimeve kaq popullore sot, siç është Rest API. Mbrojtja e Rest API është shumë më e vështirë se një faqe interneti normale. Mënyrat bazike për të mbrojtur përpjekjet për të thyer fjalëkalimin dhe aktivitete të tjera të paligjshme nuk funksionojnë as për Rest API.
Rest API është shumë e lehtë për t'u thyer, sepse ai lidhet drejtpërdrejt me bazën e të dhënave. Dështimi i këtij shërbimi ka pasoja të rënda për biznesin. Kjo ndodhi sepse Rest API zakonisht lidhet jo vetëm me sitin kryesor, por edhe me aplikacionin mobil dhe disa burime të brendshme tregtare. Dhe nëse të gjitha këto bien, efekti është shumë më i fortë se në rastin e dështimit të një faqesh thjesht.

Ngarkesa mbi përmbajtje të rëndë

Nëse na ofrohet të testojmë një aplikacion të zakonshëm me një faqe, një landing, ose një faqe vizitë pa funksionalitete të komplikuara, ne kërkojmë përmbajtje të rëndë. Për shembull, imazhe të mëdha që serveri i ofron, skedarë binarë, dokumentacion PDF — provojmë të gjitha këto që t'i shkarkojmë. Këto teste ngarkojnë mirë sistemin e skedarëve dhe mbushin kanalet, prandaj janë efektive. Kështu që, edhe nëse nuk e çoni poshtë serverin duke shkarkuar një skedar të madh me shpejtësi të ulët, thjesht do të mbushni kanalin e serverit dhe atëherë do të ndodhi një dështim shërbimi.
Në shembullin e këtij testi, duket se me një shpejtësi prej 30 RPS, faqja e internetit ka ndaluar së përgjiguri ose ka dhënë gabime 500 të serverit.

Është e rëndësishme të mos harrosh konfigurimin e serverëve. Shpesh ndodh që një person të blejë një virtualizim, të instalojë Apache, të konfigurojë gjithçka sipas defaults, të vendosë një aplikacion php dhe më poshtë mund të shihni rezultatin.

Këtu ngarkesa shkoi në rrënjë dhe përbënte vetëm 10 RPS. Ne prisnim 5 minuta dhe serveri ra. Është ende e paqartë pse ra, por ka një supozim se thjesht bëri mbipërdorim të memories dhe prandaj ndali përgjigjen.

Vërtitës i bazuar në valë

Në vitet e fundit, sulmet me valë janë bërë mjaft të njohura. Kjo është e lidhur me faktin se shumë organizata blejnë pajisje të ndryshme për mbrojtjen nga DDoS, të cilat kërkojnë një kohë të caktuar për grumbullimin e statistikave për të filluar filtrimin e sulmit. Kjo do të thotë se ato nuk filtrojnë sulmin në 30-40 sekondat e para, sepse grumbullojnë të dhëna dhe mësohen. Në përputhje me këtë, gjatë këtyre 30-40 sekondave mund të lëshosh kaq shumë mbi faqen sa burimi do të mbetet i bllokuar për një periudhë të gjatë, derisa të përballohen të gjitha kërkesat.
Në rastin e sulmit më poshtë, kishte një interval prej 10 minutash, pas të cilit erdhi një sasi e re, e ndryshuar e sulmit.

Pra kësaj, mbrojtja ka mësuar, ka filluar filtrimin, por ka ardhur një sulm krejt tjetër, dhe mbrojtja fillon përsëri të mësojë. Në fakt, filtrimi ndalon së funksionuari, mbrojtja bëhet e paefikase, dhe faqja bëhet e paparashikueshme.
Sulmet e valëve karakterizohen nga vlera shumë të larta në majë, mund të arrijnë deri në njëqind mijë ose një milion kërkesa në sekondë, në rastin e L7. Nëse flasim për L3&4, atëherë mund të ketë qindra gigabite trafik, ose përkatësisht qindra mpps, nëse llogaritet në paketa.
Problemi i këtyre sulmeve qëndron në sinkronizim. Sulmet vijnë nga një botnet, dhe për të krijuar një majë të madhe një herë, kërkohet një shkallë e lartë sinkronizimi. Dhe kjo koordinatë nuk është gjithmonë e mundur: ndonjëherë rezulton një majë parabolike, e cila duket mjaft keq.

Nuk jetojmë vetëm me HTTP

Përveç HTTP në nivelin L7, ne gjithashtu pëlqejmë të shfrytëzojmë protokole të tjera. Në përgjithësi, një faqe webi e zakonshme, e veçanërisht një host i zakonshëm, ka protokolle postare dhe MySQL që duken nga jashtë. Protokollat postare janë më pak të ndjeshme ndaj ngarkesave se sa bazat e dhënash, por ato gjithashtu mund të ngarkohen mjaft efektivisht duke sjellë një CPU të mbingarkuar në server.
Ne kemi pasur sukses realist me ndihmën e dobësisë SSH të vitit 2016. Tanime, kjo dobësi është rregulluar te shumica e njerëzve, por kjo nuk do të thotë se nuk mund të ushtrohet ngarkesë në SSH. Mund të ushtrohet. Thjesht motivohet një ngarkesë e madhe e autorizimeve, SSH konsumon pothuajse të gjithë CPU-në në server dhe pastaj faqja web përmbyset nga vetëm një ose dy kërkesa në sekondë. Për pasojë, këto një ose dy kërkesa nuk mund të dallohen nga ngarkesa legjitime në logjet.
Mbeten shumë lidhje aktive që hapim në servera. Më parë kjo ishte një mangësi e Apache, tani në fakt kjo është një mangësi e nginx, pasi shpesh konfigurohet për default. Numri i lidhjeve që nginx mund të mbajë të hapura është i kufizuar, përkatësisht ne hapim këtë numër lidhjesh, një lidhje e re tashmë nuk pranohet nga nginx, dhe si rezultat, faqja e internetit nuk punon.
Klusteri ynë testues ka mjaft CPU për të sulmuar SSL handshake. Në parim, praktikisht tregon se botnetët ndonjëherë e pëlqejnë këtë. Nga njëra anë, është e qartë se pa SSL nuk bëhet fjalë, sepse renditja në Google, siguria. Nga ana tjetër, me keqardhje, SSL ka një problem me CPU.

L3&4

Kur flasim për një sulm në nivelet L3&4, zakonisht flasim për një sulm në nivelin e kanalit. Një ngarkesë e tillë pothuajse gjithmonë është e dallueshme nga legjitimja, nëse nuk është një sulm SYN-flood. Problemi i sulmeve SYN-flood për mjetet e mbrojtjes është sasia e madhe. Vlera maksimale e L3&4 ka qenë 1.5-2 Tbit/s. Ky trafik është shumë i vështirë për t'u përpunuar edhe për kompanitë e mëdha, duke përfshirë Oracle dhe Google.
SYN dhe SYN-ACK janë paketa që përdoren për të vendosur një lidhje. Prandaj, është e vështirë të dallohet një SYN-flood nga një ngarkesë legjitime: nuk është e qartë nëse është një SYN që ka ardhur për të vendosur lidhjen, apo një pjesë e fludës.

UDP-flood

Zakonisht, sulmuesit nuk kanë fuqinë që kemi ne, prandaj për të organizuar sulme mund të përdoret amplifikimi. Kështu, sulmuesi skanon internetin dhe gjen servera të cenueshëm ose të konfiguruar gabimisht, të cilët, për shembull, në përgjigje të një pakete SYN, përgjigjen me tri SYN-ACK. Duke falsifikuar adresën e burimit me adresën e serverit të synuar, është e mundur të rritet fuqia e një pakete, le të themi, tri herë dhe të ridrejtohet trafiku ndaj viktimës.

Problemi me amplifikimin është se është e vështirë të zbulohet. Një nga rastet më të fundit është rasti i njohur me memcached të cenueshëm. Për më tepër, tani ka shumë pajisje IoT, kamera IP, të cilat gjithashtu janë kryesisht të konfiguruara sipas parazgjedhjeve dhe zakonisht ato janë të konfiguruara gabimisht, prandaj përmes këtyre pajisjeve, sulmuesit kryejnë sulme më shpesh.

SYN-flood i vështirë

SYN-flood, ndoshta, është tipi më interesant i sulmeve nga këndvështrimi i zhvilluesit. Problemi është se shpesh administratorët e sistemeve përdorin bllokimin nga IP për mbrojtje. Për më tepër, bllokimi nga IP ndikon jo vetëm administratorët e sistemit që veprojnë sipas skenarëve, por fatkeqësisht edhe disa sisteme mbrojtëse që blihen për shumë para.
Një metodë e tillë mund të rezultojë katastrofike, sepse nëse kriminelët zëvendësojnë adresat IP, kompania do të bllokojë nën rrjetin e saj. Kur Firewall-i bllokon klasterin e saj, ndërveprimet e jashtme do të dështojnë dhe burimi do të prishet.
Për më tepër, arrijtja e bllokimit të rrjetit të vet është e lehtë. Nëse në zyrën e klientit ka një rrjet WI-Fi, ose nëse funksionaliteti i burimeve matet përmes monitorimeve të ndryshme, atëherë ne marrim adresën IP të këtij sistemi të monitorimit ose të Wi-Fi të zyrës së klientit dhe e përdorim atë si burim. Në fund, burimi duket se është i aksesueshëm, por adresat IP të synuara janë të bllokuara. Kështu, mund të bllokohet rrjeti Wi-Fi i konferencës HighLoad, ku prezantohet një produkt i ri i kompanisë, dhe kjo sjell disa kosto biznesi dhe ekonomike.
Gjatë testimit, nuk mund të përdorim amplifikimin përmes memcached nga ndonjë burim të jashtëm, sepse ekzistojnë marrëveshje për shtrimin e trafikut vetëm në adresat IP të lejuara. Prandaj, ne përdorim amplifikimin përmes SYN dhe SYN-ACK, kur për dërgimin e një SYN sistemi përgjigjet me dy-tre SYN-ACK, dhe në përfundim sulmi dyfishohet në dy-tre herë.

Mjetet

Një nga mjetet kryesore që përdorim për ngarkesën në nivelin L7 është Yandex-tank. Saktësisht, si armë përdoret fantazi, plus ka disa skripta për gjenerimin e municioneve dhe për analizimin e rezultateve.
Për analizën e trafikut rrjetor përdoret Tcpdump, për analizën e serverit — Nmap. Për krijimin e ngarkesës në nivelin L3&4 përdoren OpenSSL dhe pak magji tonë me bibliotekën DPDK. DPDK është një bibliotekë nga Intel, e cila lejon të punojë me ndërfaqen rrjetore duke anashkaluar stakun Linux, dhe kështu rrit efikasitetin. Sigurisht, DPDK e përdorim jo vetëm në nivelin L3&4, por edhe në nivelin L7, sepse lejon krijimin e një fluksi shumë të lartë ngarkese, brenda disa milionë kërkesave në sekondë nga një makinë.
Ne përdorim gjithashtu disa gjenerues trafiku dhe mjete speciale, të cilat i shkruajmë për teste specifike. Nëse kujtojmë dobësinë nën SSH, grupi i mësipërm nuk mund të shfrytëzohet. Nëse sulmojmë protokollin e postës, ne përdorim mjete postare ose thjesht shkruajmë skripte mbi to.

Përfundimet

Si përfundim, do të doja të them:

• Përveç testimit klasik të ngarkesës, është e nevojshme të bëhet gjithashtu testimi i stresit. Ne kemi një shembull real, kur një nënkontraktues i partnerit zhvilloi vetëm testimin e ngarkesës. Kjo tregoi se burimi përballonte ngarkesën normale. Por më pas u shfaq një ngarkesë anormale, vizitorët e sajtit filluan ta përdorin burimin pak ndryshe dhe në fund nënkontraktuesi dështoi. Prandaj, është e rëndësishme të kërkosh dobësi, edhe nëse je tashmë i mbrojtur nga sulmet DDoS.
• Është e nevojshme të izolohini disa pjesë të sistemit nga të tjerat. Nëse keni një kërkim, ai duhet të vendoset në makina të veçanta, pra edhe jo në Docker. Sepse nëse dështojnë kërkimi ose autorizimi, të paktën diçka do të vazhdojë të funksionojë. Në rastin e një dyqani online, përdoruesit do të vazhdojnë të gjejnë produkte në katalog, të kalojnë nga aggregatorët, të blejnë, nëse janë tashmë të autorizuar, ose të autorizohen përmes OAuth2.
• Nuk duhet të neglizhoni shërbimet e ndryshme cloud.
• Përdorni CDN jo vetëm për të optimizuar vonesat në rrjet, por edhe si një mjet mbrojtjeje nga sulmet për shfrytëzimin e kanaleve dhe thjesht fludë në statik.
• Është e nevojshme të përdoren shërbime të specializuara për mbrojtje. Nga sulmet L3&4 në nivelin e kanalit nuk do të mbroheni vetë, sepse most likely që thjesht nuk keni një kanal të mjaftueshëm. Po ashtu, nga sulmet L7 është e vështirë të mbroheni, pasi ato mund të jenë shumë të mëdha. Plus, gjetja e sulmeve të vogla është megjithatë një privilegj i shërbimeve speciale, algoritmeve speciale.
• Bëni përditësime të rregullta. Kjo nuk është e rëndësishme vetëm për bërthamën, por edhe për demon SSH, veçanërisht nëse i keni të hapur drejt jashtë. Në parim, duhet të përditësoni gjithçka, sepse do të jetë e vështirë të mbani nën kontroll vlefshmërinë e paqëndrueshme vetë.

Burimi: habr.com