Variti zhvillon mbrojtje kundër bots dhe sulmeve DDoS, dhe gjithashtu kryen testimin e stresit dhe ngarkesës. Në konferencën HighLoad++ 2018 folëm se si të sigurojmë burime nga lloje të ndryshme sulmesh. Shkurtimisht: izoloni pjesë të sistemit, përdorni shërbimet cloud dhe CDN-të dhe përditësoni rregullisht. Por ju ende nuk do të jeni në gjendje të përballoni mbrojtjen pa kompani të specializuara :)
Para se të lexoni tekstin, mund të lexoni abstrakte të shkurtra .
Dhe nëse nuk ju pëlqen të lexoni ose thjesht dëshironi të shikoni videon, regjistrimi i raportit tonë është më poshtë nën spoiler.
Video incizim i raportit
Shumë kompani tashmë e dinë se si të bëjnë testimin e ngarkesës, por jo të gjitha bëjnë testimin e stresit. Disa nga klientët tanë mendojnë se faqja e tyre është e paprekshme, sepse ata kanë një sistem të ngarkesës së lartë dhe mbron mirë nga sulmet. Ne tregojmë se kjo nuk është plotësisht e vërtetë.
Natyrisht, përpara se të kryejmë teste, marrim leje nga klienti, të nënshkruar dhe të vulosur, dhe me ndihmën tonë një sulm DDoS nuk mund të kryhet ndaj askujt. Testimi kryhet në një kohë të zgjedhur nga klienti, kur trafiku drejt burimit të tij është minimal dhe problemet e aksesit nuk do të ndikojnë tek klientët. Përveç kësaj, duke qenë se diçka mund të shkojë gjithmonë keq gjatë procesit të testimit, ne kemi kontakte të vazhdueshme me klientin. Kjo ju lejon jo vetëm të raportoni rezultatet e arritura, por edhe të ndryshoni diçka gjatë testimit. Pas përfundimit të testimit, ne gjithmonë hartojmë një raport në të cilin theksojmë mangësitë e zbuluara dhe japim rekomandime për eliminimin e dobësive të faqes.
Si po punojme
Gjatë testimit, ne imitojmë një botnet. Meqenëse ne punojmë me klientë që nuk janë të vendosur në rrjetet tona, në mënyrë që të sigurohemi që testi të mos përfundojë në minutën e parë për shkak të kufizimeve ose mbrojtjes që shkaktohet, ne e furnizojmë ngarkesën jo nga një IP, por nga nënrrjeti ynë. Plus, për të krijuar një ngarkesë të konsiderueshme, ne kemi serverin tonë mjaft të fuqishëm të testimit.
Postulatet
Shumë nuk do të thotë mirë
Sa më pak ngarkesë të mund të sjellim një burim në dështim, aq më mirë. Nëse mund ta bëni sitin të ndalojë së funksionuari me një kërkesë në sekondë, apo edhe një kërkesë në minutë, kjo është shumë mirë. Sepse sipas ligjit të poshtërësisë, përdoruesit ose sulmuesit aksidentalisht do të bien në këtë cenueshmëri të veçantë.
Dështimi i pjesshëm është më i mirë se dështimi i plotë
Ne gjithmonë këshillojmë që sistemet të jenë heterogjene. Për më tepër, ia vlen t'i ndani ato në nivel fizik, dhe jo vetëm nga kontejnerizimi. Në rastin e ndarjes fizike, edhe nëse diçka dështon në sajt, ekziston një probabilitet i lartë që ai të mos ndalojë së punuari plotësisht dhe përdoruesit do të vazhdojnë të kenë akses në të paktën një pjesë të funksionalitetit.
Arkitektura e mirë është baza për qëndrueshmëri
Toleranca e gabimeve të një burimi dhe aftësia e tij për t'i bërë ballë sulmeve dhe ngarkesave duhet të përcaktohet në fazën e projektimit, në fakt, në fazën e vizatimit të grafikëve të parë të rrjedhës në një fletore. Sepse nëse zvarriten gabime fatale, është e mundur të korrigjohen ato në të ardhmen, por është shumë e vështirë.
Jo vetëm kodi duhet të jetë i mirë, por edhe konfigurimi
Shumë njerëz mendojnë se një ekip i mirë zhvillimi është një garanci për shërbimin tolerant ndaj gabimeve. Një ekip i mirë zhvillimi është vërtet i nevojshëm, por duhet të ketë edhe operacione të mira, DevOps të mira. Kjo do të thotë, ne kemi nevojë për specialistë që do të konfigurojnë saktë Linux dhe rrjetin, do të shkruajnë saktë konfigurimet në nginx, do të vendosin kufij, etj. Përndryshe, burimi do të funksionojë mirë vetëm në testim, dhe në një moment gjithçka do të prishet në prodhim.
Dallimet midis testimit të ngarkesës dhe stresit
Testimi i ngarkesës ju lejon të identifikoni kufijtë e funksionimit të sistemit. Testimi i stresit ka për qëllim gjetjen e dobësive në një sistem dhe përdoret për të thyer këtë sistem dhe për të parë se si do të sillet në procesin e dështimit të pjesëve të caktuara. Në këtë rast, natyra e ngarkesës zakonisht mbetet e panjohur për klientin përpara se të fillojë testimi i stresit.
Karakteristikat dalluese të sulmeve L7
Zakonisht i ndajmë llojet e ngarkesave në ngarkesa në nivelet L7 dhe L3&4. L7 është një ngarkesë në nivelin e aplikacionit, më shpesh nënkupton vetëm HTTP, por nënkuptojmë çdo ngarkesë në nivelin e protokollit TCP.
Sulmet L7 kanë disa veçori dalluese. Së pari, ato vijnë drejtpërdrejt në aplikacion, domethënë nuk ka gjasa që ato të pasqyrohen përmes mjeteve të rrjetit. Sulmet e tilla përdorin logjikën, dhe për shkak të kësaj, ata konsumojnë CPU, memorie, diskun, bazën e të dhënave dhe burime të tjera në mënyrë shumë efikase dhe me pak trafik.
Përmbytje HTTP
Në rastin e ndonjë sulmi, ngarkesa është më e lehtë për t'u krijuar sesa për t'u trajtuar, dhe në rastin e L7 kjo është gjithashtu e vërtetë. Nuk është gjithmonë e lehtë të dallosh trafikun e sulmit nga trafiku legjitim, dhe më shpesh kjo mund të bëhet me frekuencë, por nëse gjithçka është planifikuar në mënyrë korrekte, atëherë është e pamundur të kuptosh nga regjistrat se ku është sulmi dhe ku janë kërkesat legjitime.
Si shembull i parë, merrni parasysh një sulm HTTP Flood. Grafiku tregon se sulme të tilla janë zakonisht shumë të fuqishme; në shembullin e mëposhtëm, numri maksimal i kërkesave tejkaloi 600 mijë në minutë.
HTTP Flood është mënyra më e lehtë për të krijuar ngarkesë. Në mënyrë tipike, ai merr një lloj mjeti testimi të ngarkesës, siç është ApacheBench, dhe vendos një kërkesë dhe një objektiv. Me një qasje kaq të thjeshtë, ekziston një probabilitet i lartë për të hyrë në memorien e serverit, por është e lehtë ta anashkalosh atë. Për shembull, shtimi i vargjeve të rastësishme në kërkesë, gjë që do ta detyrojë serverin të shërbejë vazhdimisht një faqe të re.
Gjithashtu, mos harroni për agjentin e përdoruesit në procesin e krijimit të një ngarkese. Shumë agjentë përdorues të mjeteve të njohura të testimit filtrohen nga administratorët e sistemit, dhe në këtë rast ngarkesa thjesht mund të mos arrijë në fund. Ju mund ta përmirësoni ndjeshëm rezultatin duke futur një kokë pak a shumë të vlefshme nga shfletuesi në kërkesë.
Sado të thjeshta që janë sulmet HTTP Flood, ato gjithashtu kanë të metat e tyre. Së pari, nevojiten sasi të mëdha energjie për të krijuar ngarkesën. Së dyti, sulme të tilla janë shumë të lehta për t'u zbuluar, veçanërisht nëse ato vijnë nga një adresë. Si rezultat, kërkesat menjëherë fillojnë të filtrohen ose nga administratorët e sistemit ose edhe në nivelin e ofruesit.
Çfarë të kërkoni
Për të zvogëluar numrin e kërkesave për sekondë pa humbur efikasitetin, duhet të tregoni pak imagjinatë dhe të eksploroni faqen. Kështu, ju mund të ngarkoni jo vetëm kanalin ose serverin, por edhe pjesët individuale të aplikacionit, për shembull, bazat e të dhënave ose sistemet e skedarëve. Mund të kërkoni gjithashtu vende në faqe që bëjnë llogaritje të mëdha: kalkulatorë, faqe të përzgjedhjes së produktit, etj. Së fundi, shpesh ndodh që faqja të ketë një lloj skripti PHP që gjeneron një faqe prej disa qindra mijëra rreshtash. Një skenar i tillë gjithashtu ngarkon ndjeshëm serverin dhe mund të bëhet një objektiv për një sulm.
Ku të shikojmë
Kur skanojmë një burim përpara se të testojmë, së pari shikojmë, natyrisht, vetë sitin. Ne jemi duke kërkuar për të gjitha llojet e fushave të hyrjes, skedarët e rëndë - në përgjithësi, gjithçka që mund të krijojë probleme për burimin dhe të ngadalësojë funksionimin e tij. Mjetet e zhvillimit banal në Google Chrome dhe Firefox ndihmojnë këtu, duke treguar kohën e përgjigjes së faqes.
Ne gjithashtu skanojmë nënfushat. Për shembull, ekziston një dyqan i caktuar në internet, abc.com, dhe ai ka një nëndomain admin.abc.com. Me shumë mundësi, ky është një panel administratori me autorizim, por nëse vendosni një ngarkesë mbi të, mund të krijojë probleme për burimin kryesor.
Sajti mund të ketë një nëndomain api.abc.com. Me shumë mundësi, ky është një burim për aplikacionet celulare. Aplikacioni mund të gjendet në App Store ose Google Play, të instaloni një pikë të veçantë aksesi, të analizoni API-në dhe të regjistroni llogaritë e testimit. Problemi është se njerëzit shpesh mendojnë se çdo gjë që mbrohet me autorizim është imune ndaj sulmeve të mohimit të shërbimit. Me sa duket, autorizimi është CAPTCHA më i mirë, por nuk është. Është e lehtë të bësh 10-20 llogari testimi, por duke i krijuar ato, ne kemi akses në funksione komplekse dhe të pa maskuara.
Natyrisht, ne shikojmë historinë, robots.txt dhe WebArchive, ViewDNS dhe kërkojmë versione të vjetra të burimit. Ndonjëherë ndodh që zhvilluesit kanë nxjerrë, të themi, mail2.yandex.net, por versioni i vjetër, mail.yandex.net, mbetet. Ky mail.yandex.net nuk mbështetet më, burimet e zhvillimit nuk i janë ndarë, por vazhdon të konsumojë bazën e të dhënave. Prandaj, duke përdorur versionin e vjetër, mund të përdorni në mënyrë efektive burimet e backend dhe gjithçka që qëndron pas paraqitjes. Sigurisht, kjo nuk ndodh gjithmonë, por ne ende e hasim këtë mjaft shpesh.
Natyrisht, ne analizojmë të gjithë parametrat e kërkesës dhe strukturën e cookie-ve. Ju mund, të themi, të hidhni disa vlera në një grup JSON brenda një cookie, të krijoni shumë fole dhe ta bëni burimin të funksionojë për një kohë të gjatë të paarsyeshme.
Ngarkesa e kërkimit
Gjëja e parë që ju vjen në mendje kur hulumtoni një faqe është ngarkimi i bazës së të dhënave, pasi pothuajse të gjithë kanë një kërkim, dhe pothuajse për të gjithë, për fat të keq, është i mbrojtur dobët. Për disa arsye, zhvilluesit nuk i kushtojnë vëmendje të mjaftueshme kërkimit. Por këtu ka një rekomandim - nuk duhet të bëni kërkesa të të njëjtit lloj, sepse mund të hasni në caching, siç është rasti me HTTP flood.
Bërja e pyetjeve të rastësishme në bazën e të dhënave nuk është gjithashtu gjithmonë efektive. Është shumë më mirë të krijoni një listë me fjalë kyçe që janë të rëndësishme për kërkimin. Nëse kthehemi te shembulli i një dyqani online: le të themi se faqja shet goma makinash dhe ju lejon të vendosni rrezen e gomave, llojin e makinës dhe parametra të tjerë. Prandaj, kombinimet e fjalëve përkatëse do ta detyrojnë bazën e të dhënave të funksionojë në kushte shumë më komplekse.
Për më tepër, ia vlen të përdorni faqezim: është shumë më e vështirë që një kërkim të kthejë faqen e parafundit të rezultateve të kërkimit sesa e para. Kjo do të thotë, me ndihmën e faqezimit mund të diversifikoni pak ngarkesën.
Shembulli më poshtë tregon ngarkesën e kërkimit. Mund të shihet se që në sekondën e parë të testit me një shpejtësi prej dhjetë kërkesash në sekondë, faqja u rrëzua dhe nuk u përgjigj.
Nëse nuk ka kërkim?
Nëse nuk ka kërkim, kjo nuk do të thotë që faqja nuk përmban fusha të tjera të cenueshme të hyrjes. Kjo fushë mund të jetë autorizim. Në ditët e sotme, zhvilluesve u pëlqen të bëjnë hash komplekse për të mbrojtur bazën e të dhënave të hyrjes nga një sulm i tabelës së ylberit. Kjo është e mirë, por hash të tillë konsumojnë shumë burime të CPU. Një rrjedhë e madhe e autorizimeve të rreme çon në një dështim të procesorit dhe si rezultat, faqja ndalon së punuari.
Prania në faqen e të gjitha llojeve të formave për komente dhe reagime është një arsye për të dërguar tekste shumë të mëdha atje ose thjesht për të krijuar një përmbytje masive. Ndonjëherë faqet pranojnë skedarë të bashkangjitur, përfshirë në formatin gzip. Në këtë rast, marrim një skedar 1 TB, e kompresojmë atë në disa bajt ose kilobajt duke përdorur gzip dhe e dërgojmë në sit. Pastaj zbërthehet dhe fitohet një efekt shumë interesant.
Pusho API
Do të doja t'i kushtoja pak vëmendje shërbimeve të tilla të njohura si Rest API. Sigurimi i një API Rest është shumë më i vështirë sesa një faqe interneti e zakonshme. Edhe metodat e parëndësishme të mbrojtjes kundër forcës brutale të fjalëkalimit dhe aktiviteteve të tjera të paligjshme nuk funksionojnë për Rest API.
Rest API është shumë e lehtë për t'u thyer, sepse i qaset drejtpërdrejt bazës së të dhënave. Në të njëjtën kohë, dështimi i një shërbimi të tillë sjell pasoja mjaft të rënda për biznesin. Fakti është se Rest API zakonisht përdoret jo vetëm për faqen kryesore të internetit, por edhe për aplikacionin celular dhe disa burime të brendshme të biznesit. Dhe nëse e gjithë kjo bie, atëherë efekti është shumë më i fortë sesa në rastin e një dështimi të thjeshtë të faqes në internet.
Ngarkimi i përmbajtjes së rëndë
Nëse na ofrohet të testojmë disa aplikacione të zakonshme me një faqe, faqe uljeje ose faqe interneti të kartës së biznesit që nuk kanë funksionalitet kompleks, ne kërkojmë përmbajtje të rëndë. Për shembull, imazhe të mëdha që dërgon serveri, skedarë binare, dokumentacion pdf - ne përpiqemi t'i shkarkojmë të gjitha këto. Teste të tilla ngarkojnë mirë sistemin e skedarëve dhe bllokojnë kanalet, dhe për këtë arsye janë efektive. Kjo do të thotë, edhe nëse nuk e ulni serverin, duke shkarkuar një skedar të madh me shpejtësi të ulët, thjesht do të bllokoni kanalin e serverit të synuar dhe më pas do të ndodhë një mohim i shërbimit.
Një shembull i një testi të tillë tregon se me një shpejtësi prej 30 RPS, faqja ndaloi së përgjigjuri ose prodhoi gabime të 500-të të serverit.
Mos harroni për vendosjen e serverëve. Shpesh mund të zbuloni se një person bleu një makinë virtuale, instaloi Apache atje, konfiguroi gjithçka si parazgjedhje, instaloi një aplikacion PHP dhe më poshtë mund të shihni rezultatin.
Këtu ngarkesa shkoi në rrënjë dhe arriti në vetëm 10 RPS. Pritëm 5 minuta dhe serveri u rrëzua. Është e vërtetë që nuk dihet plotësisht pse ai ra, por supozohet se ai thjesht kishte shumë memorie dhe për këtë arsye nuk u përgjigj.
Bazuar në valë
Në vitet e fundit ose dy, sulmet me valë janë bërë mjaft të njohura. Kjo për faktin se shumë organizata blejnë pjesë të caktuara të pajisjeve për mbrojtjen DDoS, të cilat kërkojnë një kohë të caktuar për të grumbulluar statistika për të filluar filtrimin e sulmit. Domethënë, ata nuk e filtrojnë sulmin në 30-40 sekondat e para, sepse grumbullojnë të dhëna dhe mësojnë. Prandaj, në këto 30-40 sekonda mund të nisni aq shumë në sit sa burimi do të qëndrojë për një kohë të gjatë derisa të pastrohen të gjitha kërkesat.
Në rastin e sulmit më poshtë, kishte një interval prej 10 minutash, pas së cilës erdhi një pjesë e re, e modifikuar e sulmit.
Kjo do të thotë, mbrojtja mësoi, filloi filtrimin, por erdhi një pjesë e re, krejtësisht e ndryshme e sulmit dhe mbrojtja filloi të mësonte përsëri. Në fakt, filtrimi ndalon së punuari, mbrojtja bëhet e paefektshme dhe faqja është e padisponueshme.
Sulmet me valë karakterizohen nga vlera shumë të larta në kulm, mund të arrijnë 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 gigabit trafik, ose, në përputhje me rrethanat, qindra mpps, nëse numëroni në pako.
Problemi me sulme të tilla është sinkronizimi. Sulmet vijnë nga një botnet dhe kërkojnë një shkallë të lartë sinkronizimi për të krijuar një pikë shumë të madhe një herë. Dhe ky koordinim nuk funksionon gjithmonë: ndonjëherë rezultati është një lloj maja parabolike, e cila duket mjaft patetike.
Jo vetëm HTTP
Përveç HTTP në L7, na pëlqen të shfrytëzojmë protokolle të tjera. Si rregull, një uebsajt i rregullt, veçanërisht një host i rregullt, ka protokolle postare dhe MySQL që qëndrojnë jashtë. Protokollet e postës i nënshtrohen më pak ngarkesës sesa bazat e të dhënave, por ato gjithashtu mund të ngarkohen në mënyrë mjaft efikase dhe të përfundojnë me një CPU të mbingarkuar në server.
Ne ishim mjaft të suksesshëm duke përdorur cenueshmërinë SSH 2016. Tani kjo dobësi është rregulluar pothuajse për të gjithë, por kjo nuk do të thotë që ngarkesa nuk mund të dorëzohet në SSH. Mund. Ka thjesht një ngarkesë të madhe autorizimesh, SSH ha pothuajse të gjithë CPU-në në server, dhe më pas faqja e internetit shembet nga një ose dy kërkesa në sekondë. Prandaj, këto një ose dy kërkesa të bazuara në regjistrat nuk mund të dallohen nga një ngarkesë legjitime.
Shumë lidhje që hapim në serverë gjithashtu mbeten të rëndësishme. Më parë, Apache ishte fajtor për këtë, tani nginx vuan nga kjo, pasi shpesh konfigurohet si parazgjedhje. Numri i lidhjeve që nginx mund të mbajë hapur është i kufizuar, kështu që ne hapim këtë numër lidhjesh, nginx nuk pranon më një lidhje të re dhe si rezultat faqja nuk funksionon.
Grupi ynë i testimit ka mjaftueshëm CPU për të sulmuar shtrëngimin e duarve SSL. Në parim, siç tregon praktika, botnets ndonjëherë pëlqejnë ta bëjnë këtë gjithashtu. Nga njëra anë, është e qartë se nuk mund të bësh pa SSL, sepse rezultatet e Google, renditja, siguria. Nga ana tjetër, SSL për fat të keq ka një problem CPU.
L3&4
Kur flasim për një sulm në nivelet L3&4, zakonisht flasim për një sulm në nivelin e lidhjes. Një ngarkesë e tillë është pothuajse gjithmonë e dallueshme nga ajo e ligjshme, përveç nëse është një sulm SYN-flood. Problemi me sulmet SYN-flood për mjetet e sigurisë është vëllimi i tyre i madh. Vlera maksimale L3&4 ishte 1,5-2 Tbit/s. Ky lloj trafiku ë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 kur vendoset një lidhje. Prandaj, SYN-flood është e vështirë të dallohet nga një ngarkesë legjitime: nuk është e qartë nëse ky është një SYN që erdhi për të krijuar një lidhje, apo pjesë e një përmbytjeje.
UDP-përmbytje
Në mënyrë tipike, sulmuesit nuk kanë aftësitë që kemi ne, kështu që përforcimi mund të përdoret për të organizuar sulme. Kjo do të thotë, sulmuesi skanon internetin dhe gjen serverë të cenueshëm ose të konfiguruar gabimisht që, për shembull, në përgjigje të një pakete SYN, përgjigjen me tre SYN-ACK. Duke mashtruar adresën e burimit nga adresa e serverit të synuar, është e mundur të rritet fuqia, të themi, tre herë me një paketë të vetme dhe të ridrejtohet trafiku te viktima.
Problemi me amplifikimit është se ato janë të vështira për t'u zbuluar. Shembujt e fundit përfshijnë rastin e bujshëm të memcached vulnerabël. Plus, tani ka shumë pajisje IoT, kamera IP, të cilat gjithashtu janë kryesisht të konfiguruara si parazgjedhje, dhe si parazgjedhje ato janë konfiguruar gabimisht, kjo është arsyeja pse sulmuesit më shpesh kryejnë sulme përmes pajisjeve të tilla.
Vështirë SYN-përmbytje
SYN-flood është ndoshta lloji më interesant i sulmit nga këndvështrimi i një zhvilluesi. Problemi është se administratorët e sistemit shpesh përdorin bllokimin e IP për mbrojtje. Për më tepër, bllokimi i IP-së prek jo vetëm administratorët e sistemit që veprojnë duke përdorur skriptet, por edhe, për fat të keq, disa sisteme sigurie që blihen për shumë para.
Kjo metodë mund të kthehet në një fatkeqësi, sepse nëse sulmuesit zëvendësojnë adresat IP, kompania do të bllokojë nën-rrjetin e saj. Kur Firewall bllokon grupin e vet, dalja do të dështojë në ndërveprimet e jashtme dhe burimi do të dështojë.
Për më tepër, nuk është e vështirë të bllokosh rrjetin tënd. Nëse zyra e klientit ka një rrjet Wi-Fi, ose nëse performanca e burimeve matet duke përdorur sisteme të ndryshme monitorimi, atëherë marrim adresën IP të këtij sistemi monitorimi ose Wi-Fi të zyrës së klientit dhe e përdorim atë si burim. Në fund, burimi duket se është i disponueshëm, por adresat IP të synuara janë të bllokuara. Kështu, rrjeti Wi-Fi i konferencës HighLoad, ku po prezantohet produkti i ri i kompanisë, mund të bllokohet dhe kjo sjell kosto të caktuara biznesi dhe ekonomike.
Gjatë testimit, ne nuk mund të përdorim amplifikimin përmes memcached me ndonjë burim të jashtëm, sepse ka marrëveshje për të dërguar trafik vetëm në adresat IP të lejuara. Prandaj, ne përdorim amplifikimin përmes SYN dhe SYN-ACK, kur sistemi i përgjigjet dërgimit të një SYN me dy ose tre SYN-ACK, dhe në dalje sulmi shumëzohet me dy ose tre herë.
Mjete
Një nga mjetet kryesore që përdorim për ngarkesën e punës L7 është Yandex-tank. Në veçanti, një fantazmë përdoret si armë, plus ka disa skripta për gjenerimin e fishekëve dhe për analizimin e rezultateve.
Tcpdump përdoret për të analizuar trafikun e rrjetit, dhe Nmap përdoret për të analizuar serverin. Për të krijuar ngarkesën në nivelin L3&4, përdoren OpenSSL dhe pak nga magjia jonë me bibliotekën DPDK. DPDK është një bibliotekë nga Intel që ju lejon të punoni me ndërfaqen e rrjetit duke anashkaluar pirgun e Linux, duke rritur kështu efikasitetin. Natyrisht, ne përdorim DPDK jo vetëm në nivelin L3&4, por edhe në nivelin L7, sepse na lejon të krijojmë një fluks ngarkese shumë të lartë, brenda intervalit prej disa milionë kërkesash në sekondë nga një makinë.
Ne përdorim gjithashtu gjeneratorë të caktuar të trafikut dhe mjete speciale që i shkruajmë për teste specifike. Nëse kujtojmë cenueshmërinë nën SSH, atëherë grupi i mësipërm nuk mund të shfrytëzohet. Nëse sulmojmë protokollin e postës, ne marrim shërbimet e postës ose thjesht shkruajmë skripta mbi to.
Gjetjet
Si përfundim dua të them:
- Përveç testimit klasik të ngarkesës, është e nevojshme të kryhet testimi i stresit. Ne kemi një shembull të vërtetë ku nënkontraktori i një partneri ka kryer vetëm testimin e ngarkesës. Ai tregoi se burimi mund të përballojë ngarkesën normale. Por më pas u shfaq një ngarkesë jonormale, vizitorët e sitit filluan ta përdorin burimin pak më ndryshe, dhe si rezultat nënkontraktori u shtri. Kështu, ia vlen të kërkoni dobësi edhe nëse jeni tashmë të mbrojtur nga sulmet DDoS.
- Është e nevojshme të izolohen disa pjesë të sistemit nga të tjerët. Nëse keni një kërkim, duhet ta zhvendosni në makina të veçanta, domethënë as në Docker. Sepse nëse kërkimi ose autorizimi dështon, 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ë shkojnë nga grumbulluesi, të blejnë nëse janë tashmë të autorizuar ose të autorizojnë nëpërmjet OAuth2.
- Mos i lini pas dore të gjitha llojet e shërbimeve cloud.
- Përdorni CDN jo vetëm për të optimizuar vonesat e rrjetit, por edhe si një mjet mbrojtjeje kundër sulmeve ndaj lodhjes së kanalit dhe thjesht vërshimit në trafikun statik.
- Është e nevojshme të përdoren shërbime të specializuara të mbrojtjes. Ju nuk mund të mbroheni nga sulmet L3&4 në nivel kanali, sepse me shumë mundësi thjesht nuk keni një kanal të mjaftueshëm. Ju gjithashtu nuk ka gjasa të luftoni sulmet L7, pasi ato mund të jenë shumë të mëdha. Plus, kërkimi për sulme të vogla është ende prerogativë e shërbimeve speciale, algoritmeve speciale.
- Përditëso rregullisht. Kjo vlen jo vetëm për kernelin, por edhe për demonin SSH, veçanërisht nëse i keni të hapura nga jashtë. Në parim, gjithçka duhet të përditësohet, sepse nuk ka gjasa të jeni në gjendje të gjurmoni disa dobësi vetë.
Burimi: www.habr.com