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

Kompania Variti zhvillon mbrojtje kundër botëve dhe sulmeve DDoS, si dhe kryen testime stresi dhe ngarkese. Në konferencën HighLoad++ 2018 folëm se si të sigurojmë burimet nga lloje të ndryshme sulmesh. Nëse e shohim shkurt: izoloni pjesët e sistemit, përdorni shërbime cloud dhe CDN dhe përditësoni rregullisht. Por pa kompani të specializuara për mbrojtje, nuk do t'ia dilni dot 🙂

Para se të lexoni tekstin, mund të shikoni disa pikë të shkurtra në faqen e konferencës.
Dhe nëse nuk ju pëlqen të lexoni ose thjesht doni të shihni videon, regjistrimi i fjalimit tonë është më poshtë nën spoiler.

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 mbron mirë nga sulmet. Ne tregojmë se kjo nuk është krejtësisht e vërtetë.
Sigurisht, para se të kryejmë testet, marrim leje nga klienti, me nënshkrim dhe vulë, dhe me ndihmën tonë nuk mund të bëhet një sulm DDoS ndaj askujt. Testimi kryhet në kohën e zgjedhur nga klienti, kur vizitat në burimin e tij janë minimale, dhe problemet me aksesin nuk do të ndikojnë te klientët. Për më tepër, pasi gjatë procesit të testimit gjithmonë mund të ndodhin diçka keq, ne kemi kontakt të vazhdueshëm me klientin. Kjo lejon jo vetëm të raportojmë mbi rezultatet e arritura, por gjithashtu të bëjmë ndryshime gjatë testimit. Pas përfundimit të testimit, ne gjithmonë përgatisim një raport, në të cilin tregojmë për mangësitë e zbuluara dhe japim rekomandime për eliminimin e pikave të dobëta të faqes.

Si punojmë

Gjatë kryerjes së testeve, ne emulojmë një botnet. Duke qenë se punojmë me klientë që nuk janë në rrjetet tona, për të siguruar që testi të mos përfundojë në minutën e parë për shkak të kufizimeve apo mbrojtjeve, ne paraqesim ngarkesën jo vetëm nga një IP, por nga nënrrjeti ynë. Për më tepër, për të krijuar një ngarkesë të konsiderueshme, kemi një server testimi mjaft të fuqishëm.

Postulati

Shumë — nuk do të thotë mirë
Sa më pak ngarkesë që arrijmë të çojmë burimin në dështim, aq më mirë. Nëse arrijmë të bëjmë që faqja të ndalojë funksionimin nga një kërkesë në sekondë, ose madje edhe nga një kërkesë në minutë, kjo është e shkëlqyer. Sepse sipas ligjit të fatit, përdoruesit ose keqbërësit do të bien rastësisht në këtë dobësi.

Një dështim parcial është më i mirë se një i plotë
Ne gjithmonë këshillojmë që sistemet të jenë heterogjene. Dhe ndarja e tyre duhet të bëhet në nivelin fizik, jo vetëm me containerization. Në rastin e ndarjes fizike, madje edhe nëse diçka dështon në sit, ka një mundësi të madhe që ai të mos ndalojë punën krejtësisht, dhe përdoruesit të kenë akses të paktën në pjesën e funksionalitetit.

Arkitektura e duhur është themeli i qëndrueshmërisë
Qëndrueshmëria e burimit dhe aftësia e tij për të mbajtur sulmet dhe ngarkesat duhet të planifikohen në fazën e projektimit, në thelb në fazën kur çizojmë bllok-shecat e para në fletore. Sepse nëse futen gabime fatale, mund t'i korrigjojmë më vonë, por është shumë e vështirë.

Jo vetëm kodi duhet të jetë i mirë, por edhe konfigurimi
Shumë mendojnë se një ekip i mirë zhvillimi është garancia për qëndrueshmërinë e shërbimit. Një ekip i mirë zhvillimi është me të vërtetë i nevojshëm, por është e nevojshme gjithashtu një menaxhim i mirë, një DevOps i mirë. Pra, nevojiten specialistë që do ta konfigurojnë saktësisht Linux dhe rrjetin, do të shkruajnë saktë konfigurimet në nginx, do të vendosin kufij etj. Ndryshe, burimi do të funksionojë mirë vetëm në testim, ndërsa në prodhim në ndonjë moment gjithçka do të prishet.

Dallimet midis testimit të ngarkesës dhe atij të stresit
Testimi i ngarkesës lejon identifikimin e kufijve të funksionimit të sistemit. Testimi i stresit është i orientuar për të gjetur dobësitë e sistemit dhe përdoret për të thyer këtë sistem dhe për të parë se si do të sillen gjatë dështimit të pjesëve të ndryshme. Kurse karakteri i ngarkesës zakonisht mbetet i panjohur për klientin deri në fillimin e testimit të stresit.

Karakteristikat dalluese të sulmeve L7

Llojet e ngarkesave zakonisht i ndajmë në ngarkesa në nivelin L7 dhe L3&4. L7 është ngarkesa në nivelin e aplikacionit, më së shpeshti nënkuptohet vetëm HTTP, ne nënkuptojmë çdo ngarkesë në nivelin e protokollit TCP.
Atakët L7 kanë disa karakteristika dalluese. Së pari, ato vijnë drejtpërdrejt në aplikacion, çka e bën shumë të vështirë reflektimin e tyre përmes mjeteve rrjetore. Këto sulme angazhojnë logjikën, dhe për këtë arsye janë shumë efikase dhe në trafik të vogël konsumojnë CPU-në, memorjen, disqin, bazën e të dhënave dhe burime të tjera.

HTTP Flood

Në rastin e çdo sulmi, është më e lehtë të krijosh ngarkesën sesa ta përballosh atë, dhe kjo është e vërtetë edhe për L7. Trafiku i sulmit nuk është gjithmonë e thjeshtë të dallohet nga ai legjitim, dhe shpesh kjo arrihet me frekuencën, por nëse gjithçka është e planifikuar mirë, është e pamundur të kuptosh nga logjet 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 zakonisht këto sulme janë shumë të fuqishme, në shembullin më poshtë numri maksimal i kërkesave kalonte 600 mijë në minutë.

HTTP Flood është mënyra më e thjeshtë për të krijuar ngarkesë. Zakonisht, për të përdoret ndonjë mjet testi ngarkese, si p.sh. ApacheBench, dhe caktohen kërkesa dhe qëllimi. Me një qasje kaq të thjeshtë, ka një probabilitet të madh për t'u përballur me keqkalimin e serverit, por kjo është e lehtë për t'u anashkaluar. Për shembull, duke shtuar rreshta rastësorë në kërkesë, çka do i detyronte serverin të dorëzojë vazhdimisht një faqe të freskët.
Po ashtu, nuk duhet harruar për user-agentin gjatë procesit të krijimit të ngarkesës. Shumë user-agent të mjeteve të njohura të testimit filtrohen nga administratorët sistemorë, dhe në këtë rast, ngarkesa mund thjesht të mos arrijë në backend. Mund të përmirësohet ndjeshëm rezultati duke futur në kërkesë një titull relativisht të vlefshëm nga shfletuesi.
Pavarësisht thjeshtësisë, sulmet HTTP Flood kanë edhe disavantazhet e tyre. Së pari, për të krijuar ngarkesë nevojiten fuqi të mëdha. Së dyti, këto sulme zbulohet shumë lehtë, sidomos kur vijnë nga një adresë e vetme. Si pasojë, kërkesat fillojnë menjëherë të filtrohen nga administratorët sistemorë ose madje edhe në nivelin e ofruesit.

Çfarë duhet të kërkoni

Për të ulur numrin e kërkesave në sekundë dhe në të njëjtën kohë të ruajmë efikasitetin, duhet të tregojmë pak imagjinatë dhe të hulumtojmë faqen. Kështu, mund të ngarkohet jo vetëm kanali apo serveri, por edhe pjesë të veçanta të aplikacionit, për shembull, baza të dhënash ose sisteme skedarësh. Gjithashtu, mund të kërkojmë vende në faqe që bëjnë llogaritje të mëdha: kalkulatorë, faqe për përzgjedhjen e produkteve dhe të ngjashme. Së fundmi, shpesh ndodh që në faqe ka një skenar php, i cili gjeneron një faqe nga disa qindra mijëra rreshta. Ky skenar gjithashtu ngarkon ndjeshëm serverin dhe mund të bëhet objekt i një sulmi.

Ku të kërkojmë

Kur skanojmë një burim para se të kryejmë testin, ne në radhë të parë shikojmë, sigurisht, faqen vetë. Kërkojmë çdo lloj fushe inputi, skedarë të rëndë - në përgjithësi gjithçka që mund të krijojë probleme për burimin dhe të ngadalësojë punën e tij. Këtu ndihmojnë mjete të zakonshme zhvillimi në Google Chrome dhe Firefox, të cilat tregojnë kohët e përgjigjeve të faqes.
Gjithashtu skanojmë subdomenet. Për shembull, ka një dyqan online, abc.com, dhe ai ka një subdomen admin.abc.com. Me siguri, kjo është admin paneli me regjistrim, por nëse e ngarkohet, ajo mund të krijojë probleme për burimin kryesor.
Një faqe mund të ketë subdomen api.abc.com. Me siguri, ky është burimi për aplikacionet mobile. Mund të gjejmë aplikacionin në App Store ose Google Play, të vendosim një pikë të veçantë qasjeje, të analizojmë API-në dhe të regjistrojmë llogari testimi. Problemi është se shpesh njerëzit mendojnë se gjithçka që është e mbrojtur nga regjistrimi është e paprekshme nga sulmet për ndalimin e shërbimit. Siç duket regjistrimi është CAPTCHA më e mirë, por kjo nuk është e vërtetë. Të bësh 10-20 llogari testimi është e lehtë, dhe kur i krijojmë, ne fitojmë qasje në funksionalitete të ndërlikuara dhe të papritura.
Sigurisht, ne shikojmë në historinë, në robots.txt dhe WebArchive, ViewDNS, kërkojmë versionet e vjetra të burimit. Ndonjëherë ndodh që zhvilluesit lëshojnë, le të themi, mail2.yandex.net, ndërsa një version i vjetër, mail.yandex.net, mbetet. Ky mail.yandex.net ndalon së mbështeturi, burimet e zhvillimit nuk i kushtohen, por ai vazhdon të konsumojë bazën e të dhënave. Prandaj, me ndihmën e versionit të vjetër, mund të angazhojmë në mënyrë efektive burimet e backend-it dhe gjithçka që qëndron pas dizajnit. Sigurisht, kjo nuk ndodh gjithmonë, por ne përballemi me të ngjashme mjaft shpesh.
Natyrisht, ne do të analizojmë të gjitha parametrit e kërkesës, strukturën e cookie. Mund të themi, të ngarkojmë një vlerë në një array JSON brenda cookie, të krijojmë një thellësi të madhe dhe ta bëjmë burimin të punojë shumë ngadalë.

Ngarkesa në kërkim

E para gjë që vjen në mendje gjatë hulumtimit të një site është ngarkimi i bazës së të dhënave, pasi kërkimi është pothuajse në të gjitha, dhe pothuajse të gjithë e kanë, fatkeqësisht, të mbrojtur dobët. Pse zhvilluesit nuk i kushtojnë mjaftueshëm vëmendje kërkimeve? Por ka një rekomandim — nuk duhet bërë kërkesa të njëjta, sepse mund të përballesh me caching, ashtu siç ndodh me sulmet HTTP flood.
Të bësh kërkesa rastësore në bazën e të dhënave nuk është gjithmonë e efektshme. Më mirë është të krijosh një listë fjalësh kyçe që lidhen me kërkimin. Nëse kthehemi te shembulli i një dyqani online: supozoni, faqja shet goma makinash dhe lejon përcaktimin e rrethit të gomave, tipit të makinës dhe parametrave të tjerë. Prandaj, kombinimet e fjalëve përkatëse do të detyrojnë bazën e të dhënave të punojë në kushte shumë më komplekse.
Për më tepër, duhet të përdoret pagination: kërkimeve u është shumë më e vështirë të japin faqen parafundore të rezultateve sesa atë të parë. Pra, përmes pagination, mund të ndryshojmë pak ngarkesën.
Në shembullin më poshtë tregojmë ngarkesën në kërkim. Është e dukshme se në sekondën e parë të testit me një shpejtësi prej dhjetë kërkesash në sekundë, faqja ra dhe nuk përgjigjej.

Nëse nuk ka kërkim?

Nëse nuk ka kërkim, nuk do të thotë se faqja nuk përmban fusha të tjera të prekshme. Një fushë e tillë mund të jetë autorizimi. Tani zhvilluesit pëlqejnë të krijojnë hash të ndërlikuar për të mbrojtur bazën e emrave të përdoruesve nga sulmet me tabela të dukshme. Kjo është mirë, por këto hash konsumojnë burime të mëdha CPU. Një fluks i madh autorizimesh të rreme çon në dështimin e procesorit, dhe si pasojë, faqja ndalon së funksionuari.
Prania e çdo forme për komentet dhe reagimet në faqë është një mundësi për të dërguar aty tekste shumë të mëdha ose thjesht për të krijuar një masë të madhe mesazhe. Ndonjëherë faqet pranojnë skedarë të ngjeshur, përfshirë në formatin gzip. Në këtë rast, ne marrim një skedar që është 1TB, e ngjeshim atë me gzip në disa byte ose kilobyte dhe e dërgojmë në faqë. Më pas, ai deshifrohet dhe rezultati është shumë interesant.

Rest API

Do të doja të dedikoja pak vëmendje shërbimeve kaq të njohura tani, si Rest API. Mbrojtja e Rest API është shumë më e komplikuar se një website i zakonshëm. Metodat e zakonshme të mbrojtjes nga përpjekjet për thyerjen e fjalëkalimeve dhe aktiviteteve të tjera të paligjshme nuk funksionojnë për Rest API.
Rest API është shumë e lehtë për t'u thyer, sepse ai iu drejtohet drejtpërdrejt databazës. Ndërkohë, dështimi i një shërbimi të tillë ka pasoja mjaft serioze për biznesin. Arsyetimi është se Rest API zakonisht është i lidhur jo vetëm me website-in kryesor, por edhe me aplikacionin mobil, si dhe me disa burime të brendshme të biznesit. Dhe nëse e gjithë kjo dështon, ndikimi është shumë më i fortë se në rastin e dështimit të një website-i të zakonshëm.

Ngarkesa mbi përmbajtjen e rëndë

Nëse na ofrohet të testojmë ndonjë aplikacion të zakonshëm me një faqe, një landing page, një website vizitë, nuk kemi ndonjë funksionalitet të komplikuar, ne kërkojmë përmbajtje të rëndë. Për shembull, imazhe të mëdha që serveri i dërgon, skedarë binarë, dokumentacion PDF - ne provojmë të shkarkojmë të gjitha këto. Këto teste ngarkojnë mirë sistemi i skedarëve dhe bllokojnë kanalet, dhe prandaj janë efektive. Pra, edhe nëse nuk e dërgoni serverin në tokë duke shkarkuar një skedar të madh me shpejtësi të vogla, thjesht do të bllokoni kanalin e serverit të synuar dhe atëherë do të ndodhë një refuzim shërbimi.
Në shembuj të tillë testi, duket se me shpejtësinë 30 RPS, website-i nuk u përgjigj më, ose nxori gabime 500.

Nuk duhet të harrojmë as rregullimin e serverëve. Shpesh takojmë njerëz që kanë blerë një virtual, kanë vendosur Apache aty, kanë rregulluar gjithçka sipas parashikimeve, kanë vendosur aplikacionin php, dhe më poshtë mund të shihni rezultatin.

Këtu ngarkesa shkoi në rrënjë dhe ishte vetëm 10 RPS. Ne pritëm 5 minuta, dhe serveri ra. Në të vërtetë, nuk dihet deri në fund pse ra, por ka dyshime se ai thjesht është mbushur me memorie, dhe për këtë arsye ndaloi përgjigjen.

Wave based

Në vitet e fundit, sulmet valët janë bërë mjaft të njohura. Kjo lidhet me faktin se shumë organizata blejnë pajisje të ndryshme për mbrojtje nga DDoS, të cilat kërkojnë një kohë të caktuar për të koleksionuar statistikën për të filluar filtrimin e sulmit. Kështu që nuk filtrojnë sulmin në 30-40 sekondat e para, sepse grumbullojnë të dhëna dhe mësojnë. Për pasojë, në këto 30-40 sekonda, mund të dërgohet aq shumë sa burimi do të ndahet për një kohë të gjatë, derisa të përfundojnë të gjitha kërkesat.
Në rastin e sulmit më poshtë, kishte një interval prej 10 minutash, pas së cilës erdhi një sasi e re, e ndryshuar e sulmit.

Kështu që mbrojtja u mësoi, filloi filtrimin, por erdhi një sasi e re, krejt ndryshe e sulmit, dhe mbrojtja filloi përsëri të mësojë. Në fakt, filtrimi ndalon së funksionuari, mbrojtja bëhet e pavlefshme, dhe faqja nuk është e disponueshme.
Për sulmet valëve janë karakteristikë vlerat shumë të larta në kulm, ato mund të arrijnë qindra mijëra ose miliona kërkesa në sekondë, kur flasim për L7. Nëse flasim për L3&4, atëherë mund të ketë qindra gigabit trafik, ose, përkatësisht, qindra mpps nëse llogariten në paketa.
Problemi i këtyre sulmeve është në sinkronizim. Sulmet vijnë nga botneti, dhe për të krijuar një kulm shumë të lartë në një moment të veçantë, kërkohet një shkallë e lartë sinkronizimi. Dhe kjo koordinim nuk është gjithmonë e mundur: ndonjëherë në fund del një kulm parabolik, që duket mjaft i shkurtër.

Jo vetëm HTTP

Përveç HTTP në nivelin L7, ne gjithashtu na pëlqen të eksploatojmë protokolle të tjera. Zakonisht, një faqe interneti e zakonshme, sidomos në një hosting të zakonshëm, ka protokollet e postës dhe MySQL që duken në jashtsi. Protokollet e postës janë më pak të ndjeshme ndaj ngarkesave se sa bazat e të dhënave, por mund të ngarkohen gjithashtu mjaft efektivisht dhe në rezultatin e saj marrim CPU të mbingarkuar në server.
Ne kemi arritur sukses me anë të një të metë në SSH që u zbuluar në vitin 2016. Tani kjo e metë është rreth 90% e rregulluar nga të gjithë, por kjo nuk do të thotë se nuk mund të ngarkohet SSH. Mund të ngarkohet. Thjesht jepet një ngarkesë e madhe autorizimesh, SSH shqetëson pothuajse të gjithë CPU-në në server dhe më pas faqja interneti ndalet nga një ose dy kërkesa në sekondë. Kështu, këto një ose dy kërkesa në log nuk mund të dallohet asgjë nga ngarkesa legjitime.
Mbeten aktuale edhe shumë lidhjet që ne i hapim në servera. Disa herë, Apache kishte probleme me këtë, tani në fakt edhe nginx ka probleme, pasi shpesh konfigurimi i tij bëhet automatikisht. Numri i lidhjeve që nginx mund të mbajë të hapura është i kufizuar, për rrjedhojë nëse hapim këtë numër lidhjesh, nginx nuk pranon një lidhje të re dhe si rezultat, faqja nuk funksionon.
Klustri ynë teste ka mjaftueshëm CPU për të sulmuar SSL handshake. Në parim, siç tregon praktika, edhe botnetet ndonjëherë e bëjnë këtë. Nga njëra anë, është e qartë që pa SSL nuk mund të bëhet, sepse renditja në Google, sigurimi dhe mbrojtja janë të rëndësishme. Nga ana tjetër, për fat të keq, SSL ka një problem me CPU.

L3&4

Kur flasim për sulmin në nivelet L3&4, zakonisht flasim për sulmin në nivelin e kanalit. Një ngarkesë e tillë pothuajse gjithmonë është e dallueshme nga e ligjshme, nëse nuk është një sulm SYN-flood. Problemi i sulmeve SYN-flood për mjetet mbrojtëse qëndron në vëllimin e madh. Maksimumi i L3&4 ka qenë 1.5-2 Tbit/s. Një trafik i tillë është shumë i vështirë për t'u menaxhuar madje edhe nga kompanitë e mëdha, duke përfshirë Oracle dhe Google.
SYN dhe SYN-ACK janë paketa që përdoren kur krijohet një lidhje. Prandaj, SYN-flood dhe është e vështirë të dallohet nga ngarkesa e ligjshme: është e paqartë nëse ky është një SYN që erdhi për të krijuar lidhjen, apo një pjesë e fludës.

UDP-flood

Zakonisht, sulmuesit nuk kanë ato kapacitete që kemi ne, prandaj për organizimin e sulmeve mund të përdoret amplifikimi. Kështu, sulmuesi skanon internetin dhe gjen ose serverë të dobët ose të konfiguruar gabim, të cilat, për shembull, në përgjigje të një SYN-pakete, përgjigjen me tre SYN-ACK. Duke falsifikuar adresën e burimit nga adresa e serverit të synuar, mund të rritet fuqia, le të themi, në tri herë me një paketë dhe të redirected trafikun në viktimë.

Problemi i amplifikimeve qëndron në zbulimin e tyre të komplikuar. Nga shembujt më të fundit mund të përmendim rastin e njohur me memcached. Po ashtu, tani ka shumë pajisje IoT, kamera IP, që gjithashtu janë kryesisht të konfiguruara automatikisht dhe gabimisht, prandaj ndodhin sulme më shpesh përmes këtyre pajisjeve.

SYN-flood i komplikuar

SYN-flood, ndoshta, është lloji më interesant i të gjitha sulmeve nga pikëpamja e zhvilluesit. Problemi është se shpesh administratorët e sistemeve përdorin bllokimin e IP për mbrojtje. Dhe me bllokimin e IP preken jo vetëm administratorët e sistemeve që veprojnë sipas skenarëve, por, fatkeqësisht, edhe disa sisteme mbrojtëse që blihen me para të mëdha.
Ky metodë mund të ketë pasoja katastrofike, sepse nëse keqbërësit zëvendësojnë Adresa IP, kompania do të bllokojë subnetin e saj të vet. Kur Firewall bllokon klasterin e saj, ndërveprimet e jashtme do të dështojnë dhe burimi do të prishet.
Përveç kësaj, arritja e bllokimit të rrjetit të vet nuk është e vështirë. Nëse në zyrën e klientit ka një rrjet Wi-Fi, ose nëse funksionaliteti i burimeve matet me ndihmën e monitorimeve të ndryshme, ne marrim adresën IP të këtij sistemi monitorimi ose të klientit të Wi-Fi dhe e përdorim atë si burim. Në përfundim, burimi duket se është i aksesueshëm, por adresat IP të synuara janë të bllokuara. Në këtë mënyrë, mund të bllokohet rrjeti Wi-Fi i konferencës HighLoad, ku prezantohet një produkt i ri i kompanisë, — dhe kjo sjell ndihma të caktuara për biznesin dhe ekonominë.
Gjatë testimit ne nuk mund të përdorim amplifikimin përmes memcached nga disa burime të jashtme, sepse ka marrëveshje për dërgimin e trafikut vetëm në adresat IP të lejuara. Për rrjedhojë, 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 si rezultat sulmi shumëzohet me dy-tre herë.

Mjetet

Një nga instrumentet kryesore që përdorim për ngarkesën në nivel L7 është Yandex-tank. Në veçanti, si armë përdoret fantom, plus ka disa skripta për gjenerimin e municionit dhe për analizën e rezultateve.
Për analizën e trafikut rrjetor përdoret Tcpdump, për analizën e serverit — Nmap. Për të krijuar ngarkesa në nivel L3&4 përdorim OpenSSL dhe pak magji tonë me librarinë DPDK. DPDK është një bibliotekë nga Intel që lejon punën me ndërfaqen rrjetore, duke kaluar përmes stack-ut të Linux dhe kështu rrit efikasitetin. Natyrisht, DPDK ne e përdorim jo vetëm në nivelin L3&4, por edhe në nivelin L7, sepse ajo lejon krijimin e një fluksi shumë të lartë ngarkese, në kufijtë e disa milion kërkesave në sekondë nga një makinë.
Ne përdorim gjithashtu disa gjeneratorë trafiku dhe vegla speciale që i shkruajmë për teste specifike. Duke kujtuar vulnerability-n nën SSH, me setin e përmendur më sipër ajo nuk mund të eksploatohet. Nëse sulmojmë protokollin e postës, ne marrim utilitarët e postës ose thjesht shkruajmë skripta për to.

Përfundimet

Si një përfundim, do të dëshironim të theksonim:

• Përveç testimit tradicional të ngarkesës, është absolutisht e nevojshme të kryhet gjithashtu testimi i stresit. Kemi një shembull real, kur një nënkontraktor i partnerit kryen vetëm testimin e ngarkesës. Kjo tregoi se burimi përballonte ngarkesën standarde. Por më pas ndodhi një ngarkesë jostandarde, vizitorët e faqes filluan ta përdorin burimin pak ndryshe, - dhe në fund nënkontraktori dështoi. Pra, është e rëndësishme të kërkoni vulnerabilitete, edhe nëse tashmë jeni të mbrojtur nga sulmet DDoS.
• Është e nevojshme të izoloheni disa pjesë të sistemit nga të tjerat. Nëse keni kërkimin, duhet ta nxirrni atë në makina të veçanta, dmth as që nuk duhet ta keni 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 aggregatori, të blejnë, nëse tashmë janë të autorizuar, ose të autorizohen përmes OAuth2.
• Nuk duhet të neglizhoni shërbimet e ndryshme të reve.
• Përdorni CDN jo vetëm për optimizimin e vonesave rrjetore, por edhe si një mjet mbrojtjeje nga sulmet për shpenzimin e kanaleve dhe thjesht për flud në statik.
• Është e nevojshme të përdoren shërbime të specializuara mbrojtjeje. Nga sulmet L3&4 në nivelin e kanaleve, nuk do të mund të mbroheni vetë, sepse ndoshta nuk keni një kanal të mjaftueshëm. Po ashtu, për sulmet L7 ndoshta nuk do të arrini të mbroheni, pasi ato mund të jenë shumë të mëdha. Plus, kërkimi i sulmeve të vogla është akoma një prerogativë e shërbimeve speciale, algoritmeve të veçanta.
• Azhornohuni rregullisht. Kjo nuk i referohet vetëm bërthamës, por edhe daemon-it të SSH, sidomos nëse ato janë të hapura në jashtë. Në parim, duhet të azhornohet gjithçka, sepse do të jeni të pamundur të ndjekni vulnerabilitete të ndryshme vetë.

Burimi: habr.com